5 ms·

Software MVPs can no longer be low quality

28 points by synergy20 2y ago

bckr 2y ago
I love anything that says we need to build better software. That said, just how crappy are people’s MVPs these days? The point of an MVP is to make something tiny and less polished, but functional, not actually broken. > And in the age of AI, there's only going to be more software, along with LLMs that avoid the need to even use software. This doesn’t make any sense. An LLM is software.
- sabbaticaldev 2y ago
  Yes LLM is software but you don’t need to create a software to translate documents anymore, for example. ChatGPT is enough. So a translation mvp app won’t cut it. But a high quality one would
- flashgordon 2y ago
  Dont get me started on this. I have heard this "embarassed by quality" argument for almost 15 years. And the wierd thing is founders actually take this to mean building purposefully shitty products. And these days with amazing tooling building not-so-shitty product is actually in my observation only 10-20% more effort but pays off a lot in the medium time. I am so annoyed at the number of times we ship something with "oh this is as simple as adding X and we can refine later". The X rarely gets used, the later never comes (rightly so as the feature was never useful to begin with and was nothing more than a personal gut of who ever was championing it). Worse the bugs around X show up much sooner as it has to N^2 interface with the rest of the features. There is a tangible and short term cost to all this tech-debt that gets treated as "oh thats just engineering". Ok end of weekly rant.
onion2k 2y ago
I think this is true, but it hinges on a very specific definition of 'quality'. An MVP only needs to demonstrate that it solves the problem it aims to solve - everything else can be awful and people will still buy in if they see the value the software gives them. People need to see 'quality' in the solution to the problem, not necessarily in things like UX, UI, perf, code quality etc.
- sabbaticaldev 2y ago
  Yes but most low hang fruits are gone by now unless if one chase underdeveloped markets
  - onion2k 2y ago
    There are still massive markets that are chronically underserved by tech. The idea that 'software is eating the world' is done already is so far from true.
mholt 2y ago
There may be something to this. I've been letting people use semi-supervised development previews of Timelinize[0] for a little over a year now -- it is unfinished, unpolished, buggy software, but I wanted to get it in people's hands while I stand by in real-time ready for feedback, to prove out the concept and see if I am even on the right track. I let users know it is in the very early, rough stages, and to really just follow the instructions and do the happy path for now. The feedback is lukewarm, and most users are disinterested at this point. Which is unfortunate, since I believe that a fully functional application would actually draw them in, because a few testers did actually express amazement at the basic idea of what they saw the software do for them in an initial trial run. Most feedback got lost in the weeds of the known bugs and unfinished aspects, though, which didn't really tell me anything I didn't already know, and it just discouraged testers from trying more/again. Could be a did it wrong. But at this point I'm having to forge ahead in my nights/weekends and basically finish writing this very complicated piece of software in the hopes it'll be something great, even though it doesn't exactly have direct competition that I know of. (Ultimately, though, I just need it to be great for me and my family. I am just hoping others will find it useful too.) When I finally do release a public beta, it had better be good. That's what I know now. PS. Looking for a different name that doesn't sound like Tylenol -- according to repeated user feedback. [0] https://x.com/timelinize https://x.com/timelinize and https://timelinize.com https://timelinize.com
- yardie 2y ago
  That is not a MVP. It's also not a DP. And from your description it's not even a beta. What you have is a PoC (proof of concept). Also you should carefully screen who you expose this to. If the feedback is lukewarm you are using the wrong testers. Because your PoC is too early. It appears everyone has different expectations. You were expecting enthusiastic feedback to gauge interest, your testers were expecting a product near completion.
- IggleSniggle 2y ago
  I went to your website and clicked around but I couldn't really tell what I can use this for. I can guess, but at the moment it just kinda seems like "look all your data shoved into a single unified database!" Maybe I just missed it browsing on mobile, but I think you use cases more than you need to address bugs or unfinished aspects. Sidenote, but I've stopped visiting Twitter/X since you basically can't ever see a post without being logged in.
itsoktocry 2y ago
A MVP should be whatever is "minimally viable"; it's right there in the name. It never meant bad software.
- yardie 2y ago
  I would add the P stands for product. Something you are willing to purchase. I'll pay for a working, shipping product. No effing way I'm ever paying for a beta. If I'm "testing" then my feedback and time is the exchange.
valenterry 2y ago
I can't express how much I agree with it!
rodolphoarruda 2y ago
My MVP has a very poor quality UI, and I feel the pain for it. On the other hand, UX is OK and functionality is 100% what its typical persona expects for their business process. So, it works and customers are happy. My everyday wish is to give its UI a revamp, but I don't have the means to do it now.
danyala 2y ago
This is true, unless you build a low quality MVP and it does well.
KaiserPro 2y ago
It was never about "low quality" it had to be viable. That meant it did a thing better than the competition or current solution. What it meant was that you were allowed to not have features, or required someone to guide a user when they first used it. Also Viable is doing a lot of heavy lifting here. Viable for a some internal tool is wildly different to a product released by a large company.
tossandthrow 2y ago
Well, the time frame to ship an mvp should be kept constant. Naturally, better tools enable more capable MVPs. Just a couple of years ago, I would not have dreamt of creating an mvp with advanced Ai functionality. Now that's just another part of any mvp.
Aurornis 2y ago
> Your competition is no longer non-software solutions. It's probably existing, but sub-optimal software. Which means if you're going to compete with it, your software needs to be significantly better. This is the crux of this person’s argument, but it’s not a generally true statement. If you are competing with existing software, then it’s true that you need to bring something new to the table: A new feature that people need, a lower price for core functionality, or a better experience. If you don’t have any differentiator, of course you’re going to fail. However, you still need to find what that MVP is and ship that. I think there is a real problem of people taking the old MVP advice too literally about shipping software when you’re still embarrassed by the quality. Recently there are numerous examples of companies shipping things that are so MVP that they’re either nearly unusable or missing actual key features that people need. The recent trend of AI hardware assistants is a prime example. The products are so MVP that they’re not even enjoyable to use and the promised killer features are missing. As a result, the reviews are terrible and people are noticing. Even if they can improve the product later, it’s going to be very difficult to recover from all of those initial negative impressions.
- karmakaze 2y ago
  Yep, the view in the post is narrow and singular. It just happens to be the type of apps that show up on HN. I would call them lifestyle apps where "craft and taste" is what differentiates them.
- xboxnolifes 2y ago
  People overly focus on the M and completely forget about the V in MVP.
mritchie712 2y ago
> read some of the writings of @karrisaarinen at @linear. He speaks about the need to build with taste and quality when you are building in a mature market against incumbents. This is true in mature markets. No one would give Linear a real shot if it was worse than Jira or the dozens of others like it. To get someone to take the product seriously, it needed to be really good on at least one key dimension and couldn't be terrible on others. Analytics software is a mature market. Our differentiator at Definite[0] is that we give you a full data stack in one platform. You can't build that as a product in a few weeks. We ran MVP's where we manually built data stacks for customers, but our product took a year to get into an MVP state. 0 - https://www.definite.app/ https://www.definite.app/
- deleted 2y ago
  [deleted]
hiatus 2y ago
> Your competition is no longer non-software solutions. It's probably existing, but sub-optimal software. Which means if you're going to compete with it, your software needs to be significantly better. This depends highly on your target niche though. Beyond what the author mentions in terms of competition, I think higher quality MVPs are demanded for another reason: as the state of our tooling improves, the product of those tools will be expected to have improved as well. Iterating is faster with interpreted languages compared to compiled languages. Libraries make it near effortless to add features like social login, we have entire ecosystems of templating (things like Tailwind). AI has lowered the barrier for graphic generation and other elements that were once deemed "nice to haves".
datadrivenangel 2y ago
People have been talking about "minimum lovable products" for years now. It's well known that garbage won't be viable. Paradoxically though, most new products wait far too long until they begin testing viability, so MVP logic still applies.
deleted 2y ago
[deleted]
MattHeard 2y ago
If the quality is too low, it's not viable. This was always true.
drewcoo 2y ago
Do people not talk about "red ocean/blue ocean" anymore? https://www.blueoceanstrategy.com/tools/red-ocean-vs-blue-ocean-strategy/ https://www.blueoceanstrategy.com/tools/red-ocean-vs-blue-oc... The author's point is that a blue ocean strategy won't work in a red ocean. > This advice made sense when there wasn't much software out there. But the author is under the impression that until recently every market was blue ocean and now, suddenly, all are red. I can only assume he's been a heads-down dev not paying much attention to the business in the past.
juancn 2y ago
Shippable MVPs were never about trading quality for time to market. That's a misunderstanding, borne from people taking the idea too literally. You could: - trade tech debt (future changes are harder) for time to market - features for time to market - a bit of usability for time to market But not quality, never quality if you're going to ship it.
xnx 2y ago
MVP is a great approach, but very tricky to balance against "you only get one chance to make a first impression".

28 points by synergy20 2y ago

bckr 2y ago

I love anything that says we need to build better software. That said, just how crappy are people’s MVPs these days? The point of an MVP is to make something tiny and less polished, but functional, not actually broken. > And in the age of AI, there's only going to be more software, along with LLMs that avoid the need to even use software. This doesn’t make any sense. An LLM is software.

sabbaticaldev 2y ago
Yes LLM is software but you don’t need to create a software to translate documents anymore, for example. ChatGPT is enough. So a translation mvp app won’t cut it. But a high quality one would
flashgordon 2y ago
Dont get me started on this. I have heard this "embarassed by quality" argument for almost 15 years. And the wierd thing is founders actually take this to mean building purposefully shitty products. And these days with amazing tooling building not-so-shitty product is actually in my observation only 10-20% more effort but pays off a lot in the medium time. I am so annoyed at the number of times we ship something with "oh this is as simple as adding X and we can refine later". The X rarely gets used, the later never comes (rightly so as the feature was never useful to begin with and was nothing more than a personal gut of who ever was championing it). Worse the bugs around X show up much sooner as it has to N^2 interface with the rest of the features. There is a tangible and short term cost to all this tech-debt that gets treated as "oh thats just engineering". Ok end of weekly rant.

onion2k 2y ago

I think this is true, but it hinges on a very specific definition of 'quality'. An MVP only needs to demonstrate that it solves the problem it aims to solve - everything else can be awful and people will still buy in if they see the value the software gives them. People need to see 'quality' in the solution to the problem, not necessarily in things like UX, UI, perf, code quality etc.

sabbaticaldev 2y ago
Yes but most low hang fruits are gone by now unless if one chase underdeveloped markets
- onion2k 2y ago
  There are still massive markets that are chronically underserved by tech. The idea that 'software is eating the world' is done already is so far from true.

mholt 2y ago

There may be something to this. I've been letting people use semi-supervised development previews of Timelinize[0] for a little over a year now -- it is unfinished, unpolished, buggy software, but I wanted to get it in people's hands while I stand by in real-time ready for feedback, to prove out the concept and see if I am even on the right track. I let users know it is in the very early, rough stages, and to really just follow the instructions and do the happy path for now. The feedback is lukewarm, and most users are disinterested at this point. Which is unfortunate, since I believe that a fully functional application would actually draw them in, because a few testers did actually express amazement at the basic idea of what they saw the software do for them in an initial trial run. Most feedback got lost in the weeds of the known bugs and unfinished aspects, though, which didn't really tell me anything I didn't already know, and it just discouraged testers from trying more/again. Could be a did it wrong. But at this point I'm having to forge ahead in my nights/weekends and basically finish writing this very complicated piece of software in the hopes it'll be something great, even though it doesn't exactly have direct competition that I know of. (Ultimately, though, I just need it to be great for me and my family. I am just hoping others will find it useful too.) When I finally do release a public beta, it had better be good. That's what I know now. PS. Looking for a different name that doesn't sound like Tylenol -- according to repeated user feedback. [0] https://x.com/timelinize https://x.com/timelinize and https://timelinize.com https://timelinize.com

yardie 2y ago
That is not a MVP. It's also not a DP. And from your description it's not even a beta. What you have is a PoC (proof of concept). Also you should carefully screen who you expose this to. If the feedback is lukewarm you are using the wrong testers. Because your PoC is too early. It appears everyone has different expectations. You were expecting enthusiastic feedback to gauge interest, your testers were expecting a product near completion.
IggleSniggle 2y ago
I went to your website and clicked around but I couldn't really tell what I can use this for. I can guess, but at the moment it just kinda seems like "look all your data shoved into a single unified database!" Maybe I just missed it browsing on mobile, but I think you use cases more than you need to address bugs or unfinished aspects. Sidenote, but I've stopped visiting Twitter/X since you basically can't ever see a post without being logged in.

itsoktocry 2y ago

A MVP should be whatever is "minimally viable"; it's right there in the name. It never meant bad software.

yardie 2y ago
I would add the P stands for product. Something you are willing to purchase. I'll pay for a working, shipping product. No effing way I'm ever paying for a beta. If I'm "testing" then my feedback and time is the exchange.

valenterry 2y ago

I can't express how much I agree with it!

rodolphoarruda 2y ago

My MVP has a very poor quality UI, and I feel the pain for it. On the other hand, UX is OK and functionality is 100% what its typical persona expects for their business process. So, it works and customers are happy. My everyday wish is to give its UI a revamp, but I don't have the means to do it now.

danyala 2y ago

This is true, unless you build a low quality MVP and it does well.

KaiserPro 2y ago

It was never about "low quality" it had to be viable. That meant it did a thing better than the competition or current solution. What it meant was that you were allowed to not have features, or required someone to guide a user when they first used it. Also Viable is doing a lot of heavy lifting here. Viable for a some internal tool is wildly different to a product released by a large company.

tossandthrow 2y ago

Well, the time frame to ship an mvp should be kept constant. Naturally, better tools enable more capable MVPs. Just a couple of years ago, I would not have dreamt of creating an mvp with advanced Ai functionality. Now that's just another part of any mvp.

Aurornis 2y ago

> Your competition is no longer non-software solutions. It's probably existing, but sub-optimal software. Which means if you're going to compete with it, your software needs to be significantly better. This is the crux of this person’s argument, but it’s not a generally true statement. If you are competing with existing software, then it’s true that you need to bring something new to the table: A new feature that people need, a lower price for core functionality, or a better experience. If you don’t have any differentiator, of course you’re going to fail. However, you still need to find what that MVP is and ship that. I think there is a real problem of people taking the old MVP advice too literally about shipping software when you’re still embarrassed by the quality. Recently there are numerous examples of companies shipping things that are so MVP that they’re either nearly unusable or missing actual key features that people need. The recent trend of AI hardware assistants is a prime example. The products are so MVP that they’re not even enjoyable to use and the promised killer features are missing. As a result, the reviews are terrible and people are noticing. Even if they can improve the product later, it’s going to be very difficult to recover from all of those initial negative impressions.

karmakaze 2y ago
Yep, the view in the post is narrow and singular. It just happens to be the type of apps that show up on HN. I would call them lifestyle apps where "craft and taste" is what differentiates them.
xboxnolifes 2y ago
People overly focus on the M and completely forget about the V in MVP.

mritchie712 2y ago

> read some of the writings of @karrisaarinen at @linear. He speaks about the need to build with taste and quality when you are building in a mature market against incumbents. This is true in mature markets. No one would give Linear a real shot if it was worse than Jira or the dozens of others like it. To get someone to take the product seriously, it needed to be really good on at least one key dimension and couldn't be terrible on others. Analytics software is a mature market. Our differentiator at Definite[0] is that we give you a full data stack in one platform. You can't build that as a product in a few weeks. We ran MVP's where we manually built data stacks for customers, but our product took a year to get into an MVP state. 0 - https://www.definite.app/ https://www.definite.app/

deleted 2y ago
[deleted]

hiatus 2y ago

> Your competition is no longer non-software solutions. It's probably existing, but sub-optimal software. Which means if you're going to compete with it, your software needs to be significantly better. This depends highly on your target niche though. Beyond what the author mentions in terms of competition, I think higher quality MVPs are demanded for another reason: as the state of our tooling improves, the product of those tools will be expected to have improved as well. Iterating is faster with interpreted languages compared to compiled languages. Libraries make it near effortless to add features like social login, we have entire ecosystems of templating (things like Tailwind). AI has lowered the barrier for graphic generation and other elements that were once deemed "nice to haves".

datadrivenangel 2y ago

People have been talking about "minimum lovable products" for years now. It's well known that garbage won't be viable. Paradoxically though, most new products wait far too long until they begin testing viability, so MVP logic still applies.

deleted 2y ago

[deleted]

MattHeard 2y ago

If the quality is too low, it's not viable. This was always true.

drewcoo 2y ago

Do people not talk about "red ocean/blue ocean" anymore? https://www.blueoceanstrategy.com/tools/red-ocean-vs-blue-ocean-strategy/ https://www.blueoceanstrategy.com/tools/red-ocean-vs-blue-oc... The author's point is that a blue ocean strategy won't work in a red ocean. > This advice made sense when there wasn't much software out there. But the author is under the impression that until recently every market was blue ocean and now, suddenly, all are red. I can only assume he's been a heads-down dev not paying much attention to the business in the past.

juancn 2y ago

Shippable MVPs were never about trading quality for time to market. That's a misunderstanding, borne from people taking the idea too literally. You could: - trade tech debt (future changes are harder) for time to market - features for time to market - a bit of usability for time to market But not quality, never quality if you're going to ship it.

xnx 2y ago

MVP is a great approach, but very tricky to balance against "you only get one chance to make a first impression".