Direct answer
A startup should build the smallest credible product slice that tests its riskiest assumption about customer demand, workflow or technical feasibility. The MVP should produce evidence for a decision, not merely resemble the eventual product.
An MVP is a test of a business assumption, not a smaller version of the final product
A common mistake is to define a minimum viable product as a list of features with fewer items. That can still produce an expensive product that proves very little.
A useful MVP is the smallest credible way to test a high-risk assumption about a customer, workflow or business model. The product may need software, manual operations or integrations, but every component should serve the test.
Before deciding what to build, answer three questions:
- Who has the problem? Identify a specific user and the situation in which the problem occurs.
- What must change? State the behaviour or outcome that would demonstrate value.
- What is still uncertain? Separate assumptions about demand, workflow, data, technology, compliance and willingness to pay.
If the main uncertainty is whether customers will pay, a complex recommendation engine may be premature. If the uncertainty is whether a critical integration can work reliably, a clickable prototype will not answer it.
Prioritise assumptions by risk
| Assumption | Evidence to seek | Possible test |
|---|---|---|
| The problem is important | Users can describe recent examples and consequences | Structured customer interviews |
| The workflow is understood | The team can map normal and exceptional cases | Workflow walkthrough |
| Users will adopt the solution | Target users complete a realistic task | Prototype or concierge pilot |
| Required data is available | Data can be accessed, matched and used lawfully | Technical data spike |
| The solution is economically viable | Cost to build and operate is plausible | Lightweight cost model |
| The product can be delivered safely | Security, compliance and operational requirements are understood | Architecture and risk review |
Build in thin, testable slices
- Start
Customer problem
Risky assumption
Smallest useful experiment
Evidence
- Decision
What did we learn?
- Assumption supported→ step 6: Build the next slice
- Assumption rejected→ step 7: Change direction or stop
Build the next slice
↺ repeat from step 2
- Outcome
Change direction or stop
A thin slice should complete a real user task end to end, even if the initial scope is narrow. For example, an MVP for purchase approval might allow one user to submit a request, route it to an approver, record a decision and show the status. A dashboard with ten charts but no complete workflow may be less useful.
What should not be deferred blindly?
Some requirements are not optional merely because the product is early. Authentication, sensible authorisation, data protection, backups, basic observability and a safe deployment process may be necessary from the first release, depending on the product and its risks.
The right principle is not “build nothing until everything is known”. It is “keep the scope narrow while preserving the foundations required for a credible test”.
Define the MVP exit criteria
Before development begins, agree what evidence will determine the next decision. Examples include completion rate for a target workflow, user willingness to repeat the task, time required, data accuracy or a defined number of qualified pilot users. Avoid vanity measures that do not connect to the original assumption.
The Neuromotion perspective: product engineering should reduce uncertainty in a deliberate order. Discovery, technical validation and implementation should be connected, with each phase answering a clear question.
Next step: Write down the riskiest assumption behind the product idea. If the planned MVP cannot test it, revisit the scope before committing to the build.