Lately I've been wrestling with MVP..
Searching around for related material, I collected some good pieces with slightly different angles but each making its own case.
A type
(omitted)
Reading The Lean Startup, I realized how much of my development has been seat-of-the-pants. I had been thoughtlessly focused on adding only the features I thought I needed. I was just hammering away at building, without even knowing whether those features delivered value. I came to think: as this book puts it, I should form hypotheses, build, and evolve through incremental learning.
While reading this book, I came across Park Yeong-rok's piece \"Quick And Dirty.\" It also seems to answer many of the things I'd been wrestling with. In particular, I like how it compares Lean Startup and TDD. Let me quote that part:
Lean Startup, you could say, is TDD at a slightly larger scale.
- Form a hypothesis, and set an indicator that lets you verify it.
- Build an MVP that lets you test the hypothesis. quick & dirty!
- If the hypothesis is verified, raise the completeness.
- If the hypothesis turns out wrong, form a new hypothesis.
(omitted) More detail (original) → http://www.slipp.net/wiki/pages/viewpage.action?pageId=8650756
B type
(omitted)
What's not working in Korea is actually the early Build - Measure - Learn part. I agree with the technical-debt point, but oddly, people here who've read Lean Startup keep coming back to talk about MVP.
In Korea we make way too many MVPs. Build happens at insane intensity. There's no company, no organization you can go to where people aren't Build-ing.
What's not working in Korea is the Measure / Learn part. You need to look at the whole process, but I'm honestly exhausted by people bringing up Lean Startup only to land on MVP again... (T_T) (Before, even talking with someone very senior at a pretty big company, I was shocked to see the whole conversation boil down to MVP. Well, that person barely understood the Korean reality, so I can kind of understand.)
We (developers working in Korea) are always building something. On build alone, we might be world-class. We push through unreasonable schedules and unreasonable scopes.
But beyond just technical debt, I don't see anyone measuring what we learned from the last project.
The same problem I've seen at every company I've been at: people release an MVP with extraordinary diligence — and that's it.
An MVP is, as the name says, a Minimum Viable Product, so if you build and ship it and don't measure and decide what you learned to feed back into the next MVP or next improvement, it's meaningless. No different from just grinding developers.
\"It's an MVP, so ship fast. Because it's an MVP...\" — I've been hearing that for 14 years now. ;;;
If Build - Measure - Learn as a whole isn't moving, I don't consider it Lean Startup. And from what I can see, Korean companies only have Build out of those three. They don't know how to Measure, and there's no will for Learn.
Personally, no matter how many people read The Lean Startup, I'm convinced it won't work here. And at those startups, developers will keep exhausting themselves just Building MVPs.
(omitted) More detail (original) → http://www.slipp.net/questions/98
C type
jaceshim (comment)
I see it a little differently.
Viewing every project in Korea as an MVP may not be a conceptual reading of MVP — it feels like a judgment based on the process and output of the project.
An MVP is a prototype for verifying the planner/developer's hypothesis about some service or product.
To put it more concretely: when you're planning some service or product, I think it's right to see MVP as the means of testing how well users bite.
But looking at the points raised earlier:
\"Because we push developers to their limit, it's an MVP (extracting the minimum that the given resource can produce). Because we pushed to the limit, we had to trim the feature list, and we only implement what's achievable, so it's an MVP. To the CEO, only the bare minimum got built, so it's an MVP. To the planner, features were trimmed so there's nothing more to remove, so it's an MVP.\"
Isn't this kind of judgment just plugging MVP in by the dictionary definition?
MVP isn't a product that's simply tailored to limited resources — shouldn't it be seen as the minimum feature set that verifies a hypothesis, built with the minimum resources?
So saying every project in Korea is an MVP — isn't that not because they start as MVPs, but because they end up becoming MVPs in the course of doing them?
On the other hand, the MVP the book talks about, I think, is something considered thoroughly from the start.
More detail (original) → http://www.slipp.net/questions/98
D type
(omitted)
Quick & Dirty How-to
Before we jump into the real topic, let's briefly review the cycle of TDD, the finest way to reach clean code.
- Write a test that can confirm it works correctly.
- Make it runnable. More important than anything else is seeing the green bar fast. Seeing the green bar quickly forgives every sin — but only for a moment.
- Make it right. Now that the system works, clean up the sins you just committed.
Lean Startup, you could say, is TDD at a slightly larger scale.
- Form a hypothesis, set an indicator to verify it.
- Build an MVP that can test the hypothesis. quick & dirty!
- If the hypothesis is verified, raise the completeness.
- If the hypothesis turns out wrong, form a new hypothesis.
Platform 2¾
The problem lies right on Platform 2¾, between 2 and 3. Because Lean Startup is not a book for developers but a general methodology for startups, it doesn't set aside time between 2 and 3 for the third step of the TDD cycle. That's what they call reading between the lines. If a startup that succeeded at hypothesis verification misses this 2.5 refactoring, they'll hand their seat over to the followers who come right behind. The followers have the reference answer — they don't have to build an MVP fast, they can run toward a finished product from the start, so they can reach the finished product faster. You can build up to an MVP quick & dirty, but you can't speed through to a finished product without clean code.
But even if a developer recognizes the hidden 2.5 between 2 and 3, it's not simple. The CEO has already built blind faith in quick & dirty because they verified the hypothesis with quick & dirty, and they think we can just keep going quick & dirty forever. They think we can keep moving at the same speed. Telling such a CEO that we need time to clean up the code rarely lands. Even if they agree in words, their subsequent actions don't leave room for the 2.5 work. That's the decisive difference between startups that keep extending out after proof of concept and startups that fall behind in the race.
A great engineer CEO, or a CEO who understands how great engineers work, understands 2.5. But most CEOs can't accept 2.5. Startups that grow fast and then get overtaken by competitors generally have a CEO weak on the engineering mindset. There are good domestic cases, too. Think of the two hottest startup areas of the past 2–3 years. Then compare the two leading companies in those areas today and two years ago. One keeps discovering new growth drivers and is accelerating; the other grew outwardly only, and even that has been overtaken by a competitor. Of course there are multiple reasons for the difference, and many possible analyses, but my judgment is that the decisive difference was the engineering mindset.
Conditions for an MVP
Of course, the story above is a happy one either way. Of the roughly 30 startups I've been directly or indirectly involved with in my 5 years since founding my own, only two succeeded at proof of concept. So for most startups, the clean code developers need to worry about is step 2, not step 2.5. At step 2, should we just charge ahead quick & dirty? Is PHP fine? (Of course not.) Before we get into how to do quick & dirty, there's one more thing to address: not the development, but the conditions for the MVP itself.
MVP isn't Park Byung-ho, it's Minimum Viable Product. Or rather — Minimum Viable Product. That's one of the things most startups get wrong. An MVP must be small enough. eBay's very first product only had two features on its website: listing used items and browsing them. Transactions were by email and fees were sent by postal mail — a primitive website. How many bugs could a product like that have, and how messy could the code get? If the MVP is small enough, even if you build it extremely fast and quick & dirty, the technical debt you pile up in the process isn't much. Once the hypothesis is verified, you can pay it back right away.
But most startups work hard to build a Maximum, not a Minimum. They think customers aren't coming because something's missing, so they keep expanding the product — even before the hypothesis is verified. And the technical debt from quick & dirty piles up to a level you can't handle. If the hypothesis is verified, that debt isn't a big deal. Because you're already making money, or you're about to, you can hire great developers and spend the time to pay it down — that's step 2.5. But if the hypothesis isn't verified and you keep growing a quick & dirty product, it slows down until at some point you can't do anything. When it reaches that state, developers tend to run away or, if not run, raise the white flag. I can't count how many times I've gone to help such startups. (Actually I can — eight times.)
And even if the hypothesis does get verified somehow, if the product built quick & dirty in the meantime has already bloated too much, sometimes even bringing in great developers later isn't enough. You cleared step 2, and you're fully ready to do 2.5 — but you may find yourself in a situation where 2.5 is no longer possible.
So when building an MVP, startups have to exercise extreme restraint. They need to use the hypothesis-verification cycle, and they need to understand that adding features while the hypothesis' success/failure is undecided eats into the odds of success. Build the MVP within a level where you can control technical debt. Technical debt is still debt — pile up enough and you go bankrupt.
(omitted)
More detail → http://youngrok.com/QuickAndDirty
