How a product is born. Part 1: The MVP

In the previous part, we examined the idea: whether there is a market, where the money will come from and who will do the work. If you have answered those questions and decided to continue, the next question is simple: how can you check your assumptions while spending as little as possible?

That is what an MVP is for. It is also where confusion starts costing people time and money.

Why you need an MVP

In my experience, an MVP is almost always useful. If you have enough money to launch different versions and test hypotheses at random, you can choose that approach. For everyone else, an MVP makes testing the core idea less expensive.

Its job is to answer a specific question about the future product. Building a complete business will take further steps. At this stage, you need enough evidence to judge whether the basic hypothesis works.

The common mistake: MVP and Minimal Lovable Product

Many people believe they are building an MVP while expecting a different result from the first release. There is a term for that expectation: a Minimal Lovable Product, or MLP, a small product that people enjoy using.

The distinction matters.

An MVP tests a hypothesis. An MLP aims to win users over in a market the creator already understands, addressing a known problem. Those are different tasks.

Customers sometimes tell us: “We absolutely need this feature. Who would want the service without it?” Each feature carries an expectation. We need to establish exactly what it will test.

Every additional capability can raise costs, extend the schedule and draw attention away from the central question.

A familiar scenario: a founder calls the first release an MVP but expects a complete business from day one. People will share the product, recommend it to friends and return. Sometimes that happens.

It may require an experienced founder, the right market and problem, and enough funding for several years. Luck plays a role too. But it makes a poor foundation for the first release plan.

It is useful to work out before launch whether you can fund every item on your wish list for the coming years.

MVP formats: from a landing page to people behind the scenes

The format depends on what you still need to learn. Some questions require a working service. Others can be answered with a page and a conversation with a buyer.

Landing page

The simplest option is a single page describing the product with one target action: submit an enquiry, click a button or register. The main question is whether people take that action.

Clicks and enquiries provide an initial signal of interest. Willingness to pay and repeat use need separate tests. Even so, this stage can help you decide whether months of development are worth considering.

The cost of the page and test advertising depends on the scope you choose. Set the experiment budget in advance.

A useful feature of this approach is that a founder can get a market response without having a development team.

Wizard of Oz: a person under the hood

In this MVP, the user sees an interface or service while people do part of the work behind it. The team manually delivers an outcome it intends to automate later.

Consider a hypothetical example. A user requests a product recommendation and receives it through an interface. For now, an employee prepares that recommendation behind the scenes. This tests the value of the outcome before the team builds complex technology.

A similar story is often told about “smart” checkouts supposedly run entirely by people watching cameras. Specific examples need care. Amazon describes Just Walk Out as automated and explains employees' separate role in data annotation. That example cannot establish that a checkout was entirely manual.

The main Wizard of Oz trap lies elsewhere. The hypothesis is supported, the service has demand and everything looks fine. Then it turns out that the manual process is too difficult to automate. Operating costs rise in proportion to the business.

Investors may be especially disappointed if they expected different economics. One attraction of IT businesses is the ability to scale some operations without matching increases in cost. A substantial manual workload requires that advantage to be calculated again.

Find out in advance whether the work people do now can be automated later. Describe the processes and discuss them with developers capable of assessing the architecture at the level of a future CTO. For this kind of experiment, I recommend primarily using your own funds and being transparent about how the service works.

Concierge service

This approach resembles Wizard of Oz, but the manual service is openly acknowledged. The team or founders work directly with customers and immerse themselves in the process.

In early Airbnb, the founders personally recruited users and helped improve listings. Paul Graham describes that work. At early Zappos, the founder photographed shoes in shops, listed them online and bought and shipped a pair after receiving an order.

First, the team manually finds a route to the customer and solves a specific problem. Then it evaluates which parts can be automated and scaled.

I find this especially useful for businesses connected to the physical world. You test the concept, learn about the customer's circumstances and make decisions based on experience.

Good hypotheses are necessary. Direct feedback soon reveals things you could never work out at a desk.

Smoke test

Another minimal approach is to offer a product before you invest in creating or stocking it.

Suppose you want to sell coffee cups. Publish an offer. See how many enquiries arrive, what prices people discuss and which questions they ask. Plan purchases after that test. The offer should honestly explain the product's availability.

You can test interest without filling a warehouse in advance.

This is useful when producing a product or holding physical inventory requires substantial initial investment. You obtain the first evidence of demand before incurring those costs.

Technical debt as a first-release tool

An MVP team sometimes deliberately simplifies a solution to test an idea sooner. It helps to distinguish technical debt from sensible limits on scope. A good existing module does not, by itself, create debt.

Suppose the test needs to serve 10,000 users. Infrastructure for a million can be discussed when there is evidence for that scale. The number is a condition of this example; real load must be assessed through usage scenarios.

Authentication can use an existing solution. Payments can go through a provider available in your jurisdiction. Existing KYC services and their usage requirements are also worth investigating.

When the MVP presents a choice between building a supporting mechanism yourself and using a suitable existing module, examine the module first. Your time and money are needed for the product's business logic: how it works for a person, which problem it solves and whether it solves it at all.

A cafe founder buys tables and coffee, then concentrates on serving guests. The first version of a digital product follows similar logic.

P.S. Once you have tens of thousands of cafes, producing some things yourself might make sense. You still have to reach that point.

Record deliberate shortcuts: what you did, which limitations you accepted and when you will revisit the decision. Detailed debt metrics and management deserve a separate discussion. Here, the priority is keeping the first version within the bounds of the hypothesis test.

Timing: when an MVP grows beyond its purpose

My working reference for a tightly scoped MVP is two to four months of development, ideally a quarter. That is an observation from practice. A particular project's schedule depends on its scope and requirements. Within the chosen period, the team should reach users and obtain feedback.

If development stretches to six months or more, examine the scope again. Mandatory fintech requirements can complicate a launch. Elsewhere, you may find that too many features have entered the first release.

It helps to understand the process. Developers write code. Each new customer idea adds work. Expecting someone else to stop scope growth on their own is risky.

We try to tell customers: “Stop. This can wait until the next stage.” We often meet resistance. The founder is already living in a future where every feature is needed at once.

Scope needs attention from the founder or a team responsible for the business outcome. The amount of code written cannot answer the market question.

A prolonged project may never reach users. Features and connections accumulate, yet the release is still unfinished, overloaded and confusing.

It then becomes difficult to maintain. Formally, this is still an early stage: the market demands quick changes, but the system is already large. Sharp changes of direction lead to temporary workarounds. More accumulate, making the product harder to steer.

Fintech: where cutting costs is dangerous

Fintech startups have requirements that cannot be postponed for the sake of a cheap experiment. Security and the mandatory requirements applying to the particular service come first.

Mistakes can damage a reputation, cause customers financial losses and have legal consequences. Cutting checks on critical operations is dangerous.

At the same time, investigate existing solutions for supporting mechanisms: KYC, AML, payment integrations and verification. Building these from scratch requires time, money and expertise.

A suitable service can reduce the development scope. You still need to choose the provider, check the integration and understand the allocation of responsibilities. An existing module leaves those questions with the founder.

What matters

An MVP helps answer a specific question: does the core concept work? The test should cost what is necessary to obtain a sound answer.

When the thought “we still need this feature” returns, pause. Consider whether it affects the hypothesis test or mainly improves the impression the product makes.

Define the minimum needed to test the idea or obtain the first payment. Reach users. Gather feedback. Decide what to change. Then repeat the cycle.

The next part examines Product Market Fit: what happens after launch and how to tell whether the market needs your product.