Comment by chris_nielsen | Hacker News Reader

Comment by chris_nielsen | Hacker News Reader

Parent Full thread

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 pity that he didn’t call it “quickest experiment”, because that’s what a Lean Startup MVP is, just the quickest experiment you can use to validate your businesses assumptions. And how can using a “quickest experiment” be old and broken? It’s a perfectly valid approach sometimes.

The other common use of the term MVP is to ruthlessly cull a products features before the first release. To find the MINIMUM PRODUCT that would be VIABLE. People use the term that way because that’s what it sounds like an MVP would be. And again… it’s a perfectly valid approach. How could it be old and broken to pragmatically limit the scope of a first release to the minimum set of features that users find viable so that you can keep as much time as possible for responding to change.

Anyway, I think the two kinds of MVPs are still good tools in the right hands when used in the right situations. I’d hate to throw away good tools just because they don’t work in every possible situation.

> 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.

> 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.

Yeah I think we actually agree, that’s why I said it’s a valid approach “sometimes”.

Like any tool, Lean Startup MVPs aren’t the right tool for every situation. You need extreme uncertainty.

If you’re a FAANG and you’re releasing a new version of a well established type of product like an email client, what giant existential risks do you have? FAANG have existing customers, we all know people use email. There’s no questions to answer, no uncertainty, so MVPs are the wrong tool for the job.

Why bother running experiments if we have 20 years of data showing us that we have customers and they like using email…

> But if you're FAANG and launch that sort of MVP going against mature products from your competitors

Then you haven't launched a viable product. You haven't made an MVP.

Is it really a Minimum Viable Product if it needs to have every single feature that the incumbents already have?

If it doesn't stand a chance it's not viable, right?

What is smallest product we can build to learn something from and iterate with. If you build something too small that no one uses because it doesn't have enough features, then you can't learn anything from it (apart from you need to build more).

Reply on news.ycombinator.com