MVP

What is an MVP?

MVP (minimum viable product) is the simplest version of a product that customers can actually use. It allows a specific assumption about customer need, usage behaviour or willingness to pay to be tested under real conditions. Its purpose is insight: with as little effort as possible, it is meant to answer a question that could otherwise only be estimated. A comparable case is a trial stall at a weekly market, which shows whether anyone buys a dish before a restaurant is opened.

The concept comes from the methodology of step-by-step, data-driven product development in young companies (lean startup) and belongs to the early stage of a company. It appears in the business plan, in grant applications and in the documents of early funding rounds. Later it resurfaces in technical review, when investors or buyers want to know how much of the original code is still in the product. Those involved are mainly founders, product owners, first customers and early-stage investors.

Purpose and limits of an MVP

An MVP solves a narrowly defined problem completely, not a large problem incompletely. "Viable" means that the product provides real benefit to the customer and therefore triggers real behaviour. A product that nobody can seriously use yields no usable data. The small scope is therefore no justification for poor execution of the core service itself.

It is also important to be clear about what an MVP is not meant to deliver. It is not a first part of the final product that is merely extended later, and not a means of generating revenue as early as possible. Payments from test customers are evidence of willingness to pay, not the goal. Often the MVP is largely replaced after the test. Whoever plans it as the foundation of the later product tends to build too much and lose sight of the actual question.

Forms of MVP

Depending on the assumption, different forms are suitable, which differ in effort and informative value:

• Offer page with pre-order: A description of the product with a price and the option to order bindingly or make a deposit. It tests demand and willingness to pay before anything is developed.
• Manually delivered service (concierge MVP): The team first delivers the promised service by hand. The customer experiences the benefit, and the company learns the processes in detail.
• Automated interface with a manual back end: The customer operates software, but the processing is still done by staff. This makes it possible to test whether automation is worthwhile.
• Single function: One single core function is implemented as software, and everything else is left out.

The legal obligations of a regular offering also apply during the test phase. If the company processes personal data on behalf of its business customers, a data processing agreement is required under Article 28 of the General Data Protection Regulation (Datenschutz-Grundverordnung, DSGVO). If people are still working behind an automated interface, customers should know that staff handle their data.

Assumption, success criterion and decision

Before implementation comes the assumption to be tested, together with a measurable success criterion and a deadline. A usable assumption names the target group, the benefit and the price, for example: a certain group of business customers pays a certain monthly amount for a certain saving of time. The criterion defines which result confirms the assumption, for example a minimum number of paying customers within eight weeks. Without a criterion set in advance, almost any result is interpreted as a success in hindsight.

When the deadline has passed, one of three decisions follows: expand, change or discard. If the result leads to a fundamental change of target group or revenue model, this is called a pivot. A frequent problem is not a failed MVP, but an MVP that is kept running for years because no decision was taken.

The MVP in a funding round and technical due diligence

In early funding rounds, the MVP itself is less convincing than the results it has delivered: paying customers, usage data, repurchase rates and the decisions derived from them. Investors also pay attention to the speed of learning, that is, how many assumptions the team has tested, with what resources and in what time. In a Series A, the first larger funding round with professional investors, the MVP phase usually lies far in the past. Evidence of product-market fit, that is, of lasting, paying demand in a customer segment, and reliable key figures are then expected.

Later the MVP has an after-effect in the technical due diligence. Quickly developed code that was carried into the product without rework increases technical debt, that is, technical legacy issues in code and architecture that later require rework. The reviewers also ask whether the rights to the code lie with the company. For employed developers, the economic rights in computer programs belong in principle to the employer under Section 69b of the German Copyright Act (Urheberrechtsgesetz, UrhG). For code written by founders before incorporation or by freelance developers, an express contractual grant of rights is needed (IP assignment).

Practical example: concierge MVP for outpatient care services

A founding team assumes that outpatient care services will pay EUR 300 a month for software that takes over daily route planning and halves the planning time of the care service manager. Instead of developing the software immediately, the team chooses a manually delivered service.

• Ten care services submit their assignment data daily through a form. The team creates the route plans with standard tools and sends them back by the evening before. Because data of people in need of care is processed in the course of this, the team concludes a data processing agreement with each care service.
• Success criterion: at least six care services pay the full price for three months after four free weeks.
• Effort: two people over about four months (four weeks of testing and three months of paid operation), instead of a development of the full software lasting several months.
• Result: seven of ten care services pay, that is 70% against a threshold of 60%. This gives 7 × 300 = EUR 2,100 of monthly revenue. The analysis shows that above all the short-notice rescheduling in the event of staff absences is used.

The assumption therefore counts as confirmed, albeit with a shift of emphasis. The revenue of EUR 2,100 is not the yardstick. What is informative is that paying customers confirmed the assumption before money flowed into development. The team develops the rescheduling function first and sets a new criterion for the next stage.

Distinction: MVP, prototype, proof of concept and pilot project

• Prototype: shows how a product could look or work and is usually demonstrated internally or in conversations. An MVP, by contrast, is actually used by customers.
• Proof of concept: demonstrates that a technical solution works in principle. The MVP tests whether customers need it and pay for it.
• Pilot project: tests a largely finished product at the customer's site under real conditions, often with a larger business customer. The MVP comes before it.
• Product-market fit: the state in which a market demands a product on a lasting basis. MVPs are a tool on the way there.

Common mistakes

• Building too much. Every function that contributes nothing to testing the assumption lengthens development and complicates the analysis.
• No success criterion. Without a threshold set in advance, the result cannot be assessed objectively.
• The wrong test customers. Feedback from the personal circle is polite but not very informative. The behaviour of customers who pay is reliable.
• Confusing usage with willingness to pay. An offering used free of charge does not prove that customers would pay for it.
• Taking over code unreviewed. If MVP code becomes the product core without rework, technical legacy issues arise that come to light in later reviews.
• Rights to the code unresolved. If freelance developers have not granted rights, essential rights in the product may not lie with the company.

Frequently asked questions

What does the abbreviation MVP stand for?

Minimum viable product, that is, the smallest functional or minimally marketable product. In sport the same abbreviation stands for most valuable player; in a startup and software context, the product is always meant.

How long should developing an MVP take?

As a rule, a few weeks to a few months. If it takes longer, the scope is usually too large or the assumption too vaguely formulated.

Is an MVP enough for a funding round?

Rarely on its own. Investors assess the results the MVP has delivered, that is, paying customers, usage data and the decisions that follow from them. For a Series A, reliable growth and retention metrics are also expected.

What is the difference between an MVP and a prototype?

A prototype illustrates an idea; an MVP is used by customers under real conditions. Only the MVP therefore delivers data on actual behaviour and willingness to pay.

Does an MVP have to be software?

No. A manually delivered service or an offer page with pre-order can test an assumption faster and more cheaply than a programmed solution.

The Roemer Capital view

The companies Roemer Capital advises have usually left the MVP phase behind. It has an after-effect, however, in two respects that Roemer Capital has clients check before a funding round or a sale. The first is whether the rights to the early code lie fully with the company, the second is how much unreviewed code from this phase is still in the product. Both are asked about in technical due diligence, and gaps can usually be closed more easily before the process than under the time pressure of a review under way.

In the equity story, the growth narrative for investors, Roemer Capital uses the early tests as evidence that the team bases its decisions on data, not on assumptions.