Home
/
Blog
/
MVP: testing a product idea before full development

MVP: testing a product idea before full development

Valeria Gruzdeva
Founder of Web Gruzdeva
min read
MVP: testing a product idea before full development
5
min read
An MVP, or minimum viable product, tests a key assumption about a proposed solution. Its purpose is to gather evidence about need and usage, not to deliver a small copy of every planned feature.
Building a large service immediately makes mistaken assumptions expensive. A small test helps identify what to develop, change or stop sooner.

Which uncertainty are you testing?

Identify the main risk before development. Do people need the service? Will they pay? Can they complete an important action? Can your team deliver?
These are different questions and may need different tests. A button click indicates interest, not willingness to pay regularly.
A gift-selection service might first test whether people struggle to choose a gift for a specific date, then whether they will pay for assistance and return.

A hypothesis should describe behaviour

Replace “customers will like the idea” with who will do what, in which situation, and why that matters to your decision.
For illustration: last-minute gift buyers will request personal recommendations after reading the terms. This is a sample hypothesis, not a validated research finding.
Define the test duration, audience and decision criteria in advance. Choosing a success threshold after seeing results makes it easy to mistake hopes for evidence.
MVP validation cycle: hypothesis, test and conclusion

Possible test formats

Landing page with a clear offer

A page can test responses to wording, terms and an action: booking a consultation, joining a waiting list or sending an enquiry.
Say clearly if the product is not ready. Do not imply that people can buy something your team cannot deliver. Plan how to respond to interested visitors.

A manually delivered service

Do part of the work manually to test value before automating it. For example, collect requests through a form and have a specialist prepare recommendations.
This reveals real questions and time costs. Describe the terms honestly and do not promise instant delivery for a manual process.

Interactive prototype

A prototype demonstrates interface logic and tests whether people understand navigation before expensive screen development.
Completing a prototype successfully does not prove demand or profitability. A convenient product may still be something people do not want to buy.

A working version with one core feature

To test actual use, deliver the core journey from start to result. For example, accept a task and return an answer without complex personalisation.
Minimum scope does not mean broken buttons or incomprehensible errors. The basic version must deliver the journey it promises.
Idea validation formats: landing page, manual service and interactive prototype

Preparing an MVP

  1. Describe the audience and usage context.
  2. Identify the riskiest assumption.
  3. Choose a format that provides relevant evidence.
  4. Define a measurable action and decision criterion.
  5. Prepare content and the delivery process.
  6. Run the test with suitable participants.
  7. Compare results with the hypothesis and choose the next step.
Do not try to prove everything at once. A small, clear experiment is easier to analyse and repeat with a revised offer.

Choosing metrics

To test interest, track enquiries and their quality. To test usability, track journey completion and difficulties. To test value, look at actual usage and repeat requests.
Testing willingness to pay needs real purchase conditions rather than “I would buy it” answers. A paid test also requires readiness to fulfil your obligations.
Distinguish a negative result from a technical failure. A form that did not submit cannot demonstrate that people do not need the product.

Common mistakes

An audience that is too broad. You cannot tell who found the offer useful.
Features instead of a hypothesis. The team builds accounts, a catalogue and notifications without knowing which assumption it is testing.
Judging only by views. Many visits may not lead to meaningful actions.
Ignoring feedback. Rejection can reveal problems with price, trust or context.
Premature automation. Resources go into a complex system before the manual process has demonstrated value.

Frequently asked questions

Are an MVP and a prototype the same?

Not always. A prototype tests presentation and interaction; an MVP may deliver actual value. Choose based on the hypothesis.

Can I scale immediately after a successful test?

First check whether the result is consistent and the process can handle higher volume. One experiment does not eliminate every risk.

Getting started

Write down one hypothesis and the simplest honest way to test it. If that calls for a landing page or small website, we can plan the journey, measurement and first version without unnecessary features.

Made on
Tilda