The difference is at least 20x to get to a successful product launch
MVPs, prototypes, & products
When looking at many early-stage start-up pitch decks, there often is a peculiar concept of time in the roadmaps. Founders usually set aside a time X from zero to a working prototype and a time Y to get from the prototype to a ready-made product. The exciting thing now is that X and Y are usually in the same order of magnitude. So far, we have yet to see a single company for which that is true. At the very least, Y – the time from prototype to product – is 20-time X – the time from zero to prototype. Misunderstanding this law barely kills companies but leads to stress and frustration.
Before we can look into the reasons for this law, we need to define three key terms:
MVP: A minimum viable product (MVP) has received a plethora of different names recently. Regardless of the naming, an MVP is the bare minimum concept to produce a value proposition. The common notion that the typical MVP is at least one order of magnitude too large stems from the tendency of technical founders to build a technical solution. However, an MVP is not technical in nature but market-focused. It is not AI, blockchain, or the buzzword currently thrown around, but solving a potential customer’s need. An MVP can be built using email, pen & paper, or manual work.
Prototype: A prototype is a draft of the technical solution for the problem identified in the MVP. A prototype should usually work and demonstrate how the solution is intended to work. It works under controlled circumstances and in a batch size of one.
Product: A product is a certified, scalable, and sellable implementation of the value position. It works in all supported environments and without the supervision of the producer. Furthermore, it runs stable and reliable for the time of service, and thus, users can rely on it.
Getting to a prototype
Building a prototype is usually an exhilarating endeavour. Utilising much technical debt, the developers can fiddle around with the most modern tech stacks and create a service that works 95 % of the time. The edges are a little rough here and there, but it gets us from zero to one. With the prototype, start-ups can attract pilot customers so eager to use the service – to get their needs met – that they accept the flaws and occasional breakdowns. Also, since only a few users are supported, bugs can be hot-fixed by the development team.
Getting from an MVP to a prototype requires rigorous focus on value creation just to implement the features the intended user desperately needs. Thus, there is an internal conflict between the user experience and the development sides about what features to include and what not. Technical project management includes numerous loops to finding viable technical solutions to the challenges. On the other hand, the tools are simple, like a Kanban board and an off-the-shelf deployment pipeline. Quality runs second to fulfilling abstract performance metrics. The prototype’s goal is not to be scalable but to work in a single integration and learn for the future, where we want to build a product from it.
Arriving at the prototype often feels like a eureka moment. Finally, the vision becomes a reality and value is created magically by a machine – not like in the MVP by the founders sitting on one end of a massager interface. Since it works in almost all cases, there should only be a small number of tweaks left to create a product.
Getting to a product
Product development is the boring uncle of prototype development. When product development starts, the prototype should outline the technical solutions to complex problems. The goal of the product development stage is not to solve the customer’s problem but to solve it at scale. These goals translate into stability, scalability, and compliance. Thus, much legacy code must be rewritten and replaced with more conservative solutions at this stage.
Project management likewise requires more stability and less experimentation in this stage. In this stage, only it makes sense to consider SCRUM, which provides processes that can support the new requirements better than the more experimental prior process. It also requires a more disciplined development style from the organisation itself. Thus, this change can be frustrating and problematic for many developers from the early stage. These developers will need time to adapt. Due to the higher complexity – rough edges will not be accepted anymore in a product – project management also needs to ask for specialisation. In the simplest case, the user interfaces should be separated from the technical engines.
This requirement for change in project management often does not receive sufficient consideration. Still, it is not the reason for the explosion in complexity.
Mistakes have been made
We go back to the goals of stability, scalability and compliance for the mistakes and look at oversights in all of them. Together, they cause a 20 x explosion in complexity for the organisation.
When we start with stability, we need to go from 95 % to at least 99.95 %. While this looks like we are already almost there at first sight, it reduces the failure rate from 1 in 20, which no user would accept, to 1 in 2000. That is 100 in 2000 to 1 in 2000 or a reduction of failures by 99 %. Please also note that stability of 99.95 % is a barely acceptable minimum. Framing the development effort that way, we can now easily see why the complexity increases. It gives a common wisdom, “the easy things are the hard things,” a sound foundation. The acceptance level also depends on the type of service. Critical services for the customer need to be more stable than vanity services. This complexity in integration is inversely proportional to the business opportunity. Also, errors in a product cannot be hot fixed by developers as it might infer with the rest of the code. Also, developers will have to support a broader installation base.
As a leeway to the second point, we look at scalability. Scalability usually translates into processes that need to support all production, sales and support scenarios. Production processes, in particular, are an entire engineering challenge that does need no consideration in the prototype stage. Even more, production and product are deeply entangled. A last-minute feature change requires reconstructing at least parts of the production processes. While this is evident for physical products, it also holds for digital products. While support and sales are less of an engineering task, they are also deeply connected to the product and arguably part of it. Mainly sales can get away with a wild west attitude in the early days of market coverage but hinder the scalability in the long run if both marketing and sales are not highly integrated and well-coordinated. These processes will add new fields of long-lasting work in the product development.
The smallest and most plannable goal of product development is compliance. While most start-ups know what rules they need to comply with, they often underestimate the costs of time and the required workforce. The simple best practice is to ask a similar start-up for their experience in complying and carbon copying their estimates.
While the three arguments mentioned above lead to underestimated product development times, a fourth annoyance happens in all early-stage organisations that many larger organisations don’t have to care about in this depth: customer discovery. While ideally, in the prototyping stage, we learn about the customer persona or organisation to understand what we need to support. We will find out in projects and conversations that there is a general misunderstanding in the feature set. Discussed in countless poorly drawn comic strips, the phenomenon is well known, but the root cause isn’t. For one, if a product is more of a concept than a fact, all participants will fill in the blanks the way they would prefer. So never stop getting feedback. And for the other, customers underestimate the complexity and slowness on their sides, forcing the developing party to work with a hefty security margin for realistic estimates.
Comments