Lean Startup Blues

Yesterday I had an interesting session with a company who’s been a big believer in Lean Startup and the MVP concept but have lately reduced the amount of MVP-driven product development dramatically. Not because there is less uncertainty to iterate through but due to something we can call the “Lean Startup Blues” - the lack of faith that the MVP process works at scale over the long term.

The main challenge is that building MVPs is not enough. Some organizations don’t really close the learning loop as often as they would like to. They build MVPs but they don’t spend enough effort to really learn whether this MVP is in the right direction. What typically happens is that they move on to another idea after the MVP goes to production. Iterative development is dangerous when there isn’t a steady captain at the helm. The ability to shift direction brings back the classic dysfunction where the first phase of many ideas are abandoned or moved into maintenance mode where it is hard to have a serious impact. It is actually the fear of this that drives many Product Managers and business stakeholders to specify all they think they will need up front because they know they have a limited window in which to get it. After this window is closed most chances are their project will be abandoned. Several difficult changes need to happen to overcome this problem. First, people need to trust that MVPs will lead to learning and a wise decision between pursuing an MVP towards a real feature/product or killing it.Then, people need to trust that the right prioritization decisions will be made in the future and that if it is really a good idea to continue investing in an idea then this will happen. To make it harder, people need to think holistically - taking the chance that their ideas will not turn out to be winners and therefore will be abandoned - as opposed to trying to force implementation of their ideas by going for a full implementation instead of an MVP.

Using the right Kanban reality board can at least make visible the amount of this dysfunction going on by showing the size of features and the amount of MVPs that are left as is without leveraging the learning to drive further development and business value in that direction. Steps like “Deployed”, “Validate/Learn”, “Pursue” can help you see what is really going on. Having WIP limits on these stages will force some discussion about what to kill and what to pursue and end purgatory for the miserable MMFs.

Another thing that might be a challenge is actually learning whether the MVP hints at gold or not. Data-driven decision making is the holy grail but it is very hard to get there. Some organizations are giving up on it and don’t do any learning/feedback at all. Soft learning is better than no learning process at all in my opinion.

The problem with MVP purgatory is not just that we lose on the business benefits. It is also that since an MVP is typically an experiment, it typically leaves the product in a state of debt. Both technical debt - since we developed an MVP we allowed some shortcuts on the architecture/automation/clean code/etc. And Product Debt - We added a feature, it covers a certain set of use cases, but if we did the MVP right it is not whole. far from it. It was actually painful to go with it in the first place but since we were looking for the real minimum to enable learning, we did it. But the assumption is that we will either follow through or kill it. Letting the MVP stay in the product as is leads to usability issues, maintenance issues and makes future development more difficult.

Leave enough MVPs in purgatory and people will simply stop using the MVP approach. They will prefer to skip on the fast learning loop and get back to familiar ground of developing something cleaner and more usable even if it is not useful.

The way out of this mess is to have a clear policy that says you either kill it. really kill it. Or you clean it. really clean it. Please decide. And limit the amount of ideas that are in progress without a clear decision. And don’t allow starting a new MVP unless there is room for it. Make room for it by selecting another idea and kill it or clean it. Or pivot it. This is “Stop starting start finishing” applied at the MVP portfolio level.

By the way MVP is just one option of how to approach building something. It is a good option when there is a lot of business/requirements uncertainty. If not, just build minimal slices of functionality that are marketable (also called Minimum Marketable Features / MMFs) and release them. Don’t expect to do much learning and don’t skip on the technical excellence while building them. With MVPs you keep the option to kill it or grow it to later. But that option has a price. Refactoring to clean or killing a feature doesn’t come for free.  If there isn’t a lot of uncertainty that price might not be worth it. So define your policies for how to build different kind of risk profile ideas/features/products. assign the right profile to each idea. feel free to move ideas between profiles along the way as more information becomes available. Make the team building it aware of the profile. Explain to them the context. This will help them make the right tradeoffs along the way.

Another interesting thing to look at would be the “Killed Ideas/RIP” bucket. You would expect to see some ideas ending up there. That is a good thing. But you should also expect to see the cycle time until that area grow shorter and shorter meaning faster learning loop. (Just be careful to avoid setting it as a target otherwise people might not kill an item just to avoid increasing the time to kill metric…)