An MVP is an experiment, not a smaller final product
The purpose of an MVP is to learn whether a venture assumption survives contact with real behaviour. It is not a reward for completing a business plan, and it is not necessarily an application. A manual service, clickable prototype, landing page, concierge workflow or paid pilot can sometimes produce the needed evidence faster.
Start by writing the decision the MVP must inform: continue, change segment, redesign the value proposition, test another channel, prepare the operating model or stop. If the team cannot state what evidence would change that decision, the build scope is premature.
Agartha separates discovery evidence from build output. The goal is not to remove uncertainty; it is to reduce the most expensive uncertainty before creating the next irreversible cost.
The six questions that must become testable
There is no universal interview count or validation score. Evidence quality depends on the decision, the market, the buying process and the cost of being wrong. The six gates below make the missing proof visible.
| Gate | Question | Stronger evidence |
|---|---|---|
| Problem | Who experiences which painful situation, when and why? | Observed behaviour, recurring workaround and consequence |
| Demand | Will a defined buyer give time, data, access or money? | Pre-order, paid test, signed pilot or qualified commitment |
| Alternative | What do people do today and why is it tolerated? | Current cost, switching friction and decision criteria |
| Solution | Which mechanism must work for value to exist? | Prototype task completion or concierge result |
| Channel | Can the team repeatedly reach the buyer and user? | Named route, conversion steps and acquisition constraint |
| Economics | Can the venture deliver value without hiding core costs? | Price test, direct cost, capacity and margin direction |
Listen for behaviour, then ask for commitment
Market research should combine existing evidence with direct research. The U.S. Small Business Administration distinguishes existing sources from direct methods such as surveys, questionnaires, focus groups and in-depth interviews. For a founder, the useful question is not whether people like an idea; it is what they do today, what the problem costs and what would make them change.
A positive interview is weak evidence when no behaviour changes. Stronger signals require something scarce: time from a decision-maker, access to a workflow, permission to observe data, a pre-order, a paid experiment or a signed pilot. A letter of intent can clarify intent but remains non-binding unless the document says otherwise.
- Interview users, buyers and prescribers separately when they are different people.
- Ask about the last real occurrence, not a hypothetical future preference.
- Record current alternatives, workarounds, switching costs and budget ownership.
- Distinguish enthusiasm, qualified intent, contractual commitment and payment.
Test the riskiest mechanism before the full experience
A feature list mixes assumptions about desirability, usability, technical feasibility and operating capacity. Rank those assumptions by consequence and uncertainty, then design the cheapest credible test of the first one.
A prototype can test comprehension and task flow. A concierge test can test whether the promised outcome matters. A technical spike can test a difficult integration. A paid pilot can test the buying process and delivery conditions. None of these alone proves product-market fit; each resolves a narrower question.
The build brief should include the target user, triggering situation, single core job, excluded features, data boundaries, acceptance criteria, instrumentation, support route, test population, budget and decision date.
Validate access, feasibility and economic direction
A promising prototype can still fail because the buyer is unreachable, implementation is too heavy, regulated data cannot be used, integrations are unavailable or the price cannot cover direct delivery. These are venture risks, not details for after launch.
Before coding, map the buyer, approver, user and blocker; the channel required to reach them; the direct and third-party costs; the human work hidden behind the interface; and any legal, data, security or sector review. Model a range rather than a single optimistic forecast.
| Model line | Minimum question | Do not assume |
|---|---|---|
| Price | What has a qualified buyer accepted or rejected? | Stated willingness equals payment |
| Direct cost | What increases with each customer or transaction? | Founder labour is free forever |
| Capacity | How many customers can the current process serve? | Software removes every manual step |
| Acquisition | How does a buyer discover, evaluate and approve? | A large market creates a channel |
| Retention | Which recurring event brings the user back? | Early curiosity becomes habit |
| Compliance | Which review is actually required for this context? | Incorporation or hosting proves compliance |
Use a build gate with explicit exclusions
Proceed when the team can name the segment and situation, show credible problem evidence, identify the payer and channel, isolate the riskiest mechanism, access the inputs required for the test and define the decision the MVP will support.
Choose PREPARE when one missing dependency can be closed through research, access or technical work. Choose REDESIGN when the scope is too broad or the proposed product does not test the riskiest assumption. Choose STOP when the evidence no longer justifies the expected cost, risk or founder time.
A build decision does not guarantee traction, fundraising, regulatory approval or commercial success. It authorises only a bounded experiment with a responsible owner, budget, timeline and review gate.