Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Minimal Viable Product is old and busted

michaeldehaan.substack.com

Post reply on HN
Print view View original

71–80 of 132 posts

Re: Minimal Viable Product is old and busted

#71

Post by onion2k »

rwmj wrote: post #65
borski wrote: post #36

Earlier quoted context omitted.

I came here to say this. The author of the article does not understand what an MVP is. An MVP is the eventual answer to a metric fuckton of customer development, not what you go into customer development with. If you think you already know what the customer wants, I wish you luck at your next startup after this one fails; you don’t know that, and neither does your customer, or they would have built / bought it alread…

With Ansible, Mike already had a successful prototype (func) which had been developed and used by the Fedora infrastructure team for a while. He then left Red Hat and worked on Ansible. So he did in fact already know what the customer wanted! However that's an unusual case for a start-up. https://opensource.com/article/21/2/ansible-origin-story

I think in that case you're not building a minimum viable product because that's already happened. The MVP was what Ansible was when the Fedora team were using it. When Mike left to form a company around the product it was much more than that - because there was already a really good understanding of what people would pay for.

Re: Minimal Viable Product is old and busted

#72

Post by cestith »

If it's not viable, it's not a minimum viable product because it's not viable. If it's not something you can sell or at least market to customers, it's not a minimum viable product because it's not a product. If it doesn't meet enough needs in a clear enough way, it's not a minimum viable product because you haven't met the minimum.

MVP is not a longterm goal, but it can be an important stepping stone. All three of those words matter, though, not just the "minimum". It has to be a viable product. Once you have an product that is viable, you can start selling it as a solution to some problems and find out what else those paying customers want it to do. Don't give up three years of income making a product more than it has to be, but don't release that small starter version yet if it's buggy or confusing, either.

Re: Minimal Viable Product is old and busted

#73

Post by mangoman »

I generally agree that MVP tends to be cargo-culted rather than chosen as an intentional strategy. Most people who tend to spew the term often don't even know what they mean. I also agree on people tending to focus way too much on the 'minimum' and not nearly enough on the 'viable'. for example, how can you know if investing in the UI or design of a product is necessary for viability? I've seen that any interesting UI is often cut in the effort to find an MVP... but, well, sometimes an interesting design actually increases viability.

Re: Minimal Viable Product is old and busted

#75

Post by rwmj »

onion2k wrote: post #71
rwmj wrote: post #65

Earlier quoted context omitted.

With Ansible, Mike already had a successful prototype (func) which had been developed and used by the Fedora infrastructure team for a while. He then left Red Hat and worked on Ansible. So he did in fact already know what the customer wanted! However that's an unusual case for a start-up. https://opensource.com/article/21/2/ansible-origin-story

I think in that case you're not building a minimum viable product because that's already happened. The MVP was what Ansible was when the Fedora team were using it. When Mike left to form a company around the product it was much more than that - because there was already a really good understanding of what people would pay for.

Mike is also a great developer and infrastructure person so in a sense he is his own customer.

Re: Minimal Viable Product is old and busted

#76

Post by Ologn »

In 2011 I released an app which was an education in MVP for me. I knew there was an free open source Java library that parsed Microsoft Access Library, so one day I had the idea to write an Android app for it. As there was no competition at all to parse Microsoft Access databases on the Android device(1) at that time, I figured I could release it without much features, so four days after having the idea I release the app - you can load one database and then one table from the disk and page forward (not backwards) through it. I had an immediate user base despite so few features as there was no alternative at the time.

The education was in what the users wanted. I had ideas about what users might want next, like column sorting, and was thinking of what big O sorting method to use for doing that. My other ideas for features people might want were more technically complex than that.

No one asked about column sorting in the first few months. First they asked if you could page backwards through the table. Then they wanted search. Then they wanted case insensitive search. Then they wanted wildcard search. Then someone said they always loaded the same database, and had to go through the filesystem to find it each new session, and could I have a recent files tab.

I had no idea what features users thought were important. Some were probably important to more than one person, as I got multiple comments and e-mails asking for search. Pretty much everything I implemented was something asked by multiple users. The only exception to that is if one user asked for a feature, but it was simple and obviously a good idea. Some features multiple users asked for, but I put on the backlog because I knew it would take a lot of time to implement correctly.

It was an unusual scenario in that I had a sizable user base who loved that they could look at their Microsoft Access databases on their phones, even though it initially was written in four days. The main lesson was all these ideas I had about the challenges of which big-O algorithm to use were for features users never asked for, and a lot of what they wanted was pretty simple. I knew users would probably want to read Microsoft Access databases on their phones, but I had no idea at all which features of doing that were most important to them until they told me.

Re: Minimal Viable Product is old and busted

#77

Post by dncornholio »

Let's come up with an edgy title, go on a rant that has nothing to do with the title and call it a productive day!

> The whole MVP process presumes you don’t know what you are making for a product, and that is death

This is not how MVP is defined. The MVP is the actually definition of a pre-determined product.

Re: Minimal Viable Product is old and busted

#78

Post by dncornholio »

wilde wrote: post #60

I think the way MVP is usually quoted at people is confusing. It should be something like “maximize the amount of feedback you’re getting from customers”.

Or: do the least amount of work for a reasonable amount of return. You are not maximising anything (yet) imo.

Re: Minimal Viable Product is old and busted

#80

Post by altdataseller »

izacus wrote: post #54
drewcoo wrote: post #3

This seems to be arguing that the complete implementation is what matters most. That seems expensive and risky.

Yes, a complete, well-rounded implementation is what makes for a successful product (where well-rounded == supports use-cases for customers well). It is expensive (which is why it costs a lot to create a startup) and it is very risky (which is why most startups fail because they mess this up).

Exactly, none of this stuff is easy. And it's not supposed to be easy and risk-free. Otherwise, anyone could build a successful startup/product
Post reply on HN