A landing page and an MVP do not answer the same question.
A landing page can test whether a specific audience understands and responds to a promise. An MVP can test whether users can complete a workflow and receive value.
The right first build depends on the uncertainty—not on which option is cheaper or more impressive.
Start With the Question
Choose the test that can answer your riskiest question.
| Question | Better first test |
|---|---|
| Do people understand the problem and promise? | Landing page |
| Can users complete the proposed workflow? | Prototype or MVP |
| Is the outcome useful enough to repeat? | Concierge or manual test |
| Can the uncertain technology work? | Proof of concept |
| Will people take a meaningful next action? | Landing page plus commitment test |
| Can the product deliver reliably to real users? | MVP or controlled pilot |
If you cannot name the question, you are not ready to choose the artefact.
Build a Landing Page First When
The message is uncertain
You know the problem but do not know which audience, outcome, or language creates interest.
A landing page can compare:
- Audience framing
- Problem statement
- Outcome promise
- Primary use case
- Next action
The product is expensive to build
Hardware, regulated workflows, complex integrations, and two-sided marketplaces can require significant effort before the first usable version. Test whether the intended user and promise deserve deeper work.
You need a qualified audience
A page can recruit interviews, pilot participants, or early users when it is honest about the product stage.
The first risk is distribution
If you cannot get relevant people to the page, building more product does not solve access.
Use the MVP landing-page guide to structure the page around audience, problem, promise, evidence, and one next action.
Build an MVP First When
The value depends on interaction
Some ideas cannot be evaluated from a description. Users need to upload data, configure a workflow, collaborate, receive an output, or complete a transaction.
The risk is usability
You need to learn whether users understand the sequence and can reach first value without constant help.
The technology is already feasible
The problem, user, and workflow are sufficiently understood, and the remaining risk is delivery.
Users have already committed
You have pilot access, data, time, introductions, or payment—and need to prove the product can deliver the promised outcome.
An MVP should still be narrow. Build one vertical journey, not a smaller version of every future feature.
Use a Prototype When the Flow Is the Risk
A clickable prototype is useful when you need to test:
- Information hierarchy
- Sequence
- Labels and instructions
- User expectations
- Handoffs between roles
It can expose design problems before code turns them into dependencies.
A prototype does not prove performance, reliability, data correctness, integration, or sustained use.
Use a Concierge Test When the Outcome Is the Risk
Deliver the result manually while presenting a consistent user experience.
For example:
- Manually prepare a report from submitted data
- Coordinate a service behind a simple interface
- Review and classify documents by hand
- Create a schedule or recommendation manually
This tests whether the outcome is useful before automation.
Be transparent about the manual process when it affects privacy, timing, quality, or user expectations.
Use a Fake Door Carefully
A fake door presents a possible feature or action before the full capability exists.
It can measure interest, but it can also damage trust.
Use it only when:
- The message after the click is honest
- No user loses important work
- No payment is taken for an unavailable capability
- The result leads to a useful next step, such as joining a pilot
A click validates interest in the label and context. It does not validate the completed workflow.
A Practical Decision Sequence
- Name the riskiest assumption. User, problem, message, access, behaviour, technology, or delivery.
- Choose the cheapest credible test. Interview, page, prototype, concierge, proof of concept, or MVP.
- Define the evidence before launching. What behaviour would change your decision?
- Run the test with the intended user. Not only friends or generic traffic.
- Make a decision. Build, narrow, change the message, run a stronger test, or stop.
Do Not Use a Landing Page to Avoid Talking to Users
Traffic data without context is easy to misread.
A weak response may mean:
- Wrong audience
- Weak promise
- Low-quality traffic
- Poor page comprehension
- No meaningful problem
Use conversations to explain the behaviour. The idea validation framework shows how to combine interviews, workarounds, access, and commitment.
Do Not Use an MVP to Manufacture Confidence
Building can feel like progress because the output is visible. It can also delay the uncomfortable discovery that nobody cares enough.
Choose the smallest artefact that can prove the next assumption wrong.
A landing page is enough when the message and access are uncertain. A prototype is enough when the flow is uncertain. A manual test is enough when the outcome is uncertain. Build the MVP when real use is the next thing you need to learn.