Product Growth & Scaling
Lean Releases / MVP
One principle of working “agile” means shipping new features in small increments. Related to that is the concept of a “Minimum Viable Product” (MVP).
While there are many definitions and opinions on what exactly an MVP is, for me the MVP is a first product version that already provides value to the customer (and, if applicable, generates transactions, = the customer pays for it).
Another common view is that an MVP is an experiment with the intention to achieve the highest possible amount of learning (from the minimum amount of effort). In my point of view, this should be seen more like a prototype and part of the discovery stage as we explored earlier in the playbook. Through prototyping, the level of uncertainty can be reduced so that you have enough confidence to launch a proper MVP.
In other words:
- If the learning for your team is priority number 1, call it a prototype.
- If providing value to the customer is priority number 1, call it an MVP.
Alternatively, you could also consider the MVP definition of Henrik Kniberg: If testing is your focus, call it your earliest testable product, but if the user value is your priority, call it the earliest usable product.
Yet all MVP definitions have something in common: you launch the “MVP” as lean as possible in order to create impact for the company as fast as possible and to collect user feedback/data very early on before adding more functionality to the product that might not even be relevant:
Marty Cagan’s second inconvenient truth is bolstering the thought of why launching lean is beneficial (even with sufficient discovery work initially): “Even with the ideas that do prove to be valuable, usable and feasible, it typically takes several iterations to get the implementation of this idea to the point where it actually delivers the expected business value”.
Story Mapping is a great way/team exercise to narrow down the initial “MVP” scope (and further releases):
Furthermore, there are often ways to reduce the technical complexity of features significantly without compromising the value for the user, and being creative together with your engineering team can often generate amazing “shortcuts”:
- Can we keep certain processes manual in the beginning?
- Can we re-use an existing feature by adapting/ “hacking” just some minor part of it?
- Can we re-use our existing API?
- Can we build certain steps with 3rd party solutions?
- Can something be ugly for now?
- Does it need to scale?
Big Bets / New Products
The most successful and fastest-growing startups have 1 thing in common: They consistently launch completely new products for their users as growth with just one product is limited. By adding more products (that fit still the overall company vision and space), new growth can be achieved.
To deliver bold new products, it is beneficial to set up a completely new team to avoid being stuck in incremental improvements and legacy issues.
Reforge posted a great in-depth article about this topic with the example of Stripe: