Live data from Hacker News

Minimal Viable Product is old and busted

michaeldehaan.substack.com

41–50 of 132 posts

Re: Minimal Viable Product is old and busted

#41

I think there’s two kinds of MVP in common use and they’re both valid tools in specific situations. In Lean Startup, Eric Ries argues that if your business has giant unknowns. Big leap of faith assumptions. Then you’re best off using the scientific process to validate those unknowns before you do anything else. Start with a theory, design experiments and analyse the results. Repeat. The MVP is the experiment. It’s a…

> And again… it’s a perfectly valid approach.

It's a valid approach in certain markets.

But if you're FAANG and launch that sort of MVP going against mature products from your competitors, often replacing a more feature complete product with an existing user base that you try to port over... well, you're going to get destroyed. As keeps happening to Google because they don't seem to realise that the market has moved on and you can't launch things like Gmail any more.

Re: Minimal Viable Product is old and busted

#42

Bit of an arrogant and directionless rant with no concrete detail and many false dichotomies. "Just build the right product" is like saying "just don't write bugs" or "just have money." It feels like DeHaan is reacting to the idea of exploration because he thinks you should just know everything to begin with. Knowing everything upfront is definitely better than exploring your domain, product and market incrementally.…

This wasn't what I got out of the article. Too many people focus on the Minimum, and don't care about the Viable or the Product. There are table stakes. MVP doesn't mean half-assed and buggy. They misuse the concept and release any old crap. As a result, MVP has become too much of a buzzword and the intention behind it got lost.

The author speaks as if 'minimum', 'viable', 'product' are a Venn diagram rather than 2 adjectives and a noun, which muddies their point a bit. The Venn diagram version that people use is often feasible (can it be built), viable (will it sell), desirable (do people want to use it), which would've made their point clearer.

I think the trouble with MVP is that what we consider the "minimum that's viable" has changed — if you look at early days of Twitter for example (both its UI and the frequent 'fail whale' outages), it wouldn't pass muster today but at the time was enough to become one of the main platforms of the web.

Nowadays, you'd need a much more polished MVP in order to compete because the standard of what end-users expect has risen a lot (both in terms of functionality & NFRs, like security, robustness, interop, etc.).

Re: Minimal Viable Product is old and busted

#43
post #8

Your company shouldn’t be in search of a business model, you should know what you need to build. This is exactly what killed my first startup. We believed we fully understood what the customer needs and that we should build the right product before we started selling. We were actually trying to build the minimum viable product, but we were hilariously (with hindsight) wrong about what the customers wanted. Almost all…

I think there's some degree of nuance that isn't captured with comments like yours. I agree with your comment in principle, but there are interpretations of this method that are too extreme and that's where most of the bad MVPisms come from (and what I assume this blog post is a response to). As with any process, what most people are doing is not what was intended, and so we have to discuss what people are doing more so than the theory.

Data is only as valuable as the insight, understanding and intuition at the disposal of those gathering and actioning the data. There are organisations that truly embrace this idea of "we know nothing, the data will guide us" and they get lost because they're chasing a bunch of numbers for the sake of numbers on weak experiments that don't marry up to anything of meaning.

You need some amount of difficult-to-define "understanding" and "intuition" to be able to turn any learnings (whether gathered from experience or data) into a product: without it, you'll fail, regardless of process. There are many successful products that started out as someone absolutely committed to a belief in what is needed by the market, there are many successful products that were developed by following the data from day one, and likewise there are many unsuccessful products following both patterns.

My personal disdain for MVP-ing is exactly because it is so difficult to get right, and is very easy to get wrong, and it leaves little room for corrective action: I'm sure we all have experience with zombie startups, years old, still frantically "MVPing" everything under the sun. Personally, I'd much rather work within an organisation that has a clear vision about the problem they're trying to solve with flexibility around how it is to be solved, even if it ultimately leads to failure.

Customers lie, but so does data.

Re: Minimal Viable Product is old and busted

#45

I think there’s two kinds of MVP in common use and they’re both valid tools in specific situations. In Lean Startup, Eric Ries argues that if your business has giant unknowns. Big leap of faith assumptions. Then you’re best off using the scientific process to validate those unknowns before you do anything else. Start with a theory, design experiments and analyse the results. Repeat. The MVP is the experiment. It’s a…

> And again… it’s a perfectly valid approach. It's a valid approach in certain markets. But if you're FAANG and launch that sort of MVP going against mature products from your competitors, often replacing a more feature complete product with an existing user base that you try to port over... well, you're going to get destroyed. As keeps happening to Google because they don't seem to realise that the market has moved…

> But if you're FAANG and launch that sort of MVP going against mature products from your competitors, often replacing a more feature complete product with an existing user base that you try to port over... well, you're going to get destroyed.

I think what you're describing though is if you cull too many features, i.e. if you try to launch _below_ the minimum that's viable for your product-market fit, you'll always get destroyed.

You get some more leeway if you're the only offering in a problem space, but going up against incumbents really raises the bar of what the viable minimum is.

That said, you _can_ offer less features but a better execution — e.g. there's a lot of challenge banks (Monzo, Revolut, Starling, etc.) doing well in the UK at the moment (in the sense of customer acquisition, at least).

I remember when they were applying for their banking licences, a lot of people working in traditional fintech were saying that they'd be a flash in the pan & that customers wouldn't switch to these new businesses until they had parity in terms of offering things like loans and mortgages. But the offering of trad banks was _so bad_ that people were willing to overlook a lot of missing features for a better UX on their day-to-day banking.

Re: Minimal Viable Product is old and busted

#46

Bit of an arrogant and directionless rant with no concrete detail and many false dichotomies. "Just build the right product" is like saying "just don't write bugs" or "just have money." It feels like DeHaan is reacting to the idea of exploration because he thinks you should just know everything to begin with. Knowing everything upfront is definitely better than exploring your domain, product and market incrementally.…

"just have money" - this is my new mantra.

Re: Minimal Viable Product is old and busted

#48
post #8

Your company shouldn’t be in search of a business model, you should know what you need to build. This is exactly what killed my first startup. We believed we fully understood what the customer needs and that we should build the right product before we started selling. We were actually trying to build the minimum viable product, but we were hilariously (with hindsight) wrong about what the customers wanted. Almost all…

I think there's some degree of nuance that isn't captured with comments like yours. I agree with your comment in principle, but there are interpretations of this method that are too extreme and that's where most of the bad MVPisms come from (and what I assume this blog post is a response to). As with any process, what most people are doing is not what was intended, and so we have to discuss what people are doing more…

it leaves little room for corrective action

Building an MVP means getting something in front of customers as soon as possible, in order to test your product works for customers and change it if you're wrong. The entire point of an MVP is to give you as much time to change things as possible.

Everything you do prior to putting your product in front of someone might be wrong. The only validation that counts is the customer handing you their money. The longer you spend building before getting something out there the more expensive any mistakes might be. Consequently, making an MVP and only building the absolute minimum viable solution to a problem, give you as much correction time as possible.

I'd much rather work within an organisation that has a clear vision about the problem they're trying to solve with flexibility around how it is to be solved

We all would. The question is about how the org goes about getting clarity about the problem. If they think they fully understand it without talking to customers or putting something in front of customers in order to give the customer something to talk about, run the hell away. Those discussions will happen as soon as the customer sees something. If you've built a full product that you think is ideal, and then the customer doesn't agree, then you either lose the customer or you have to do a ton of work to change the product. Those are expensive mistakes that kill a startup. Having those conversations as early as possible is how you avoid that cost.

Re: Minimal Viable Product is old and busted

#49
post #8

Your company shouldn’t be in search of a business model, you should know what you need to build. This is exactly what killed my first startup. We believed we fully understood what the customer needs and that we should build the right product before we started selling. We were actually trying to build the minimum viable product, but we were hilariously (with hindsight) wrong about what the customers wanted. Almost all…

The other big reason for an MVP is to get from 'customers told us they want this' to 'customers are actually paying for this' as quickly as possible. All to often potential customers say they want X, but really have no idea what they want. The only surefire way to know if a product is on the right path is to have customers using and paying for the product.

Re: Minimal Viable Product is old and busted

#50
post #48

Earlier quoted context omitted.

I think there's some degree of nuance that isn't captured with comments like yours. I agree with your comment in principle, but there are interpretations of this method that are too extreme and that's where most of the bad MVPisms come from (and what I assume this blog post is a response to). As with any process, what most people are doing is not what was intended, and so we have to discuss what people are doing more…

it leaves little room for corrective action Building an MVP means getting something in front of customers as soon as possible, in order to test your product works for customers and change it if you're wrong. The entire point of an MVP is to give you as much time to change things as possible. Everything you do prior to putting your product in front of someone might be wrong. The only validation that counts is the cust…

> The only validation that counts is the customer handing you their money.

TLDR; of this whole thread.

I wrote something similar in a direct response to your first comment while you were writing this one :)

Post reply on HN