Minimum viable product
When a company starts, it must define its initial offering. The idea of an MVP is to come up with the minimum list of features that would allow the company to explore and validate the market potential of their idea.
In the book Inspired ([[@cagan2018Inspired: how to create tech products customers love]]), Marty Cagan argues that the "P" should stand for prototype instead of product. The argument is that if one tries to build a product at the discovery phase, it will lead to all sorts of contradictions (if it's a product, we should be able to sell it, but it may not be as high-quality as expected, which means engineering teams will take longer to build it, etc.)
Developing an MVP for science-based startups is hard, because there's already a specific insight that is going to be commercialized (solutions in search of a market).
The crucial task of product development for an MVP is limiting the number of features. That means, defining what not to build. (Which is specified in the Product Requirements Document.)
The objective of the MVP is manyfold. On the one hand it should allow to test the market thesis, meaning that there's someone willing to pay for the solution. On the other, it should demonstrate which core features are relevant for different users.
And the constraints are also important: the MVP should be developable with the resources already available.
At this point, I like to bring in jobs theory to the discussion, since it allows to map out the metrics the users will use to judge our offer.
One of the complicated aspects is that premature scaling can limit system iteration. Careful consideration is necessary to optimize the learnings that an MVP will produce.
Backlinks
These are the other notes that link to this one.
Comment
