When it is a good fit
This fits a product idea with significant uncertainties when you want to inform the next investment. You can involve intended users and are prepared to change direction or stop if observations contradict the assumption.
OXIAE / SOFTWARE DEVELOPMENT
Build an MVP around the most important product assumption.
Test your product idea with a first version that addresses the most important assumption.
Discuss your projectUNDERSTAND THE SERVICE
Which product assumption should an MVP test?
A working MVP lets a limited group of users access the core function of a first product version. Its scope centres on one important product assumption. The uncertainty may concern needs, usability, technology or willingness to pay; these questions call for different experiments. A prototype or manual experiment may be enough first. Oxiae helps define the learning goal and scope, then chooses what needs to be built. For a SaaS product, the wider platform comes into scope when the first experiment gives a reason to pursue it.
When to take a different approach
Is the problem already clear and the main task reliable execution of a known process? Consider custom software development. If the audience and problem are too vague to choose a focused experiment, start by researching the current way of working.
PRACTICAL DECISION GUIDE
An MVP should test one important assumption
An MVP is useful when its first version reduces a clear uncertainty. That could be whether users complete a request independently or understand a new sequence of work. We select the smallest complete user journey that can test the question and explicitly define what remains outside scope. [1]
Building small still requires basic access, data and recovery provisions. The first version gets measurements for the chosen task and a way to collect user feedback. Later features follow from findings rather than simply from the number of ideas generated during development. [2]
Questions to settle first
- Which assumption can this user journey support or challenge?
- Which outcome means continuing, adjusting or stopping?
Make acceptance measurable
- A bounded user journey with a measurable task outcome and review date.
- A transferable version with basic access and data handling controls.
ILLUSTRATIVE VALIDATION PLAN
Example: compare supplier quotes without another spreadsheet
This fictional product idea is not a customer case or a research result. The assumption: purchasing staff can use one comparison to decide which supplier quote needs clarification, without building another spreadsheet themselves.
Bound the question
Investigate comparing quotes for one product category. Sending requests, ordering and payment are outside this experiment. Discuss how participants currently compare quotes.
Choose the smallest useful experiment
Start with a manually prepared comparison. Tell participants which preparation is manual. This does not yet test automated document extraction or API integrations.
Use recognisable differences
Involve people who do this work. Use agreed purchasing requirements and permitted, representative quote data with different units, additional charges and a missing required delivery date. Make any test data explicit.
Observe without suggesting the answer
Ask the participant to choose a next step. Record which data they use, what information is missing, when help is needed and the effort required to prepare the comparison.
Choose a limited next step
If the participant overlooks missing information or needs substantial explanation, change the comparison first. If they independently choose a well-supported follow-up question, test whether they use the comparison for a subsequent task too. If the problem is not recognised, revisit the audience and need or stop this experiment.
What the process delivers
The plan provides a bounded experiment and a way to connect findings to a follow-up decision. It contains no measured outcome yet. Whether purchasing staff keep using the service or pay for it requires separate investigation.
How to test this example
- Agree before the experiment which observations prompt changes, stopping or further investigation; do not silently revise those criteria after seeing the outcome.
- Check that independent action can be distinguished from facilitator assistance and manual work behind the scenes.
- Keep original observations alongside their interpretation, including unclear and contradictory findings.
Compare your options
Choose based on the task, the people involved and what you can maintain.
| Approach | Useful when | What to consider |
|---|---|---|
| Clickable prototype | The question is whether users understand the proposed steps and can complete a task. | Useful for observing interaction; does not establish that processing works with real data or people will pay. |
| Manual experiment | You want to explore whether the offered outcome is useful before automating its delivery. | Make manual work explicit and record the effort required. A useful outcome does not establish profitability or scalability. |
| Narrow working version | The assumption requires working software processing, a technical integration or use that a manual experiment cannot investigate. | Limit features, but agree data protection, permissions, recovery and support. These remain necessary for a small user group. |
What I need to start
- One testable assumption with an audience, current alternative and the uncertainty to reduce first. Agree in advance which observations justify continuing, changing or stopping.
- Intended users and representative tasks and data, including difficult cases. State what is simulated and what the experiment consequently cannot establish.
- A scope with a core flow, deferred features and explicit manual steps. If an integration is the uncertain factor, the experiment needs to investigate that dependency.
- An owner for observations and product decisions. For actual use: agreements on access, retention, support and closing or handing over the experiment.
How to assess the result
- Assess technical delivery and learning separately: does the agreed version work, and what do observations indicate about the assumption?
- Record what users do independently, where they get stuck and what assistance or manual processing is needed. Abandoned tasks and contradictory reactions count too.
- Limit conclusions to the users, data and conditions investigated. A completed task or positive conversation alone does not establish willingness to pay or market demand.
- Finish with a product decision, its rationale and remaining uncertainties. The outcome may be a new experiment, focused further development or stopping.
SCOPE & INVESTMENT
What determines the cost?
A useful estimate starts with the scope. I distinguish development work from recurring usage and operating costs. These are the main drivers:
- The chosen experiment and necessary technical dependencies determine development work. An integration, multiple roles or real data use can change the scope.
- Finding users, preparing research, recording observations and performing manual processing also take time. Include that effort in the estimate.
- Actual use adds hosting, external services, support and operations. Discuss separately which parts can be reused and what will need replacement later.
APPLICATION AND SCOPE
Your challenge.
A practical application.
Illustrative scenario; not a published client case.
An idea is too large to build fully before knowing whether people will use it.
An MVP limits the first version to what is needed to test a product assumption. For a SaaS product, that may be one customer group or user flow. During further custom software development, additional features are planned once the need and technical foundation have been assessed.
THE QUESTION I ASK FIRST
Which assumption should the first version test?
Agree the first step
Use the prerequisites, acceptance checks and cost factors above to define your assignment. Agree who can approve the outcome and who will maintain the solution. The project approach explains discovery, delivery and handover.
Read the project approachQUESTIONS ABOUT THIS SERVICE
Your questions.
Clear answers.
When is a prototype enough before a working MVP?
Not every uncertainty requires a working MVP immediately. A prototype can first investigate interaction; a manual experiment can explore the offered outcome. An assumption about software processing or a technical integration needs a bounded working component. I make clear in advance what the chosen experiment does and does not investigate.
Which features belong in the first version?
Include features needed to test the chosen assumption and let users participate responsibly. Explicitly defer the others. Testing one user flow does not automatically require multiple subscription plans, for example, but actual data still requires access and recovery arrangements.
How can I tell whether users will pay for the product?
A completed task, compliment or stated price preference is insufficient. Willingness to pay needs its own research question and an appropriate, clear offer to the intended audience. Record what someone actually chooses or commits to and under which conditions, without confusing that with realised revenue.
Can the MVP be developed further later?
Sometimes. Determine which code, data and technical choices can be retained and which limitations were deliberate. A prototype or manual processing may need replacement. For larger dependencies, a software architect can assess the next step and maintainability.
Sources and technical basis
These primary sources explain the technical principles behind this guide. The project recommendations are OXIAE’s interpretation; they do not imply endorsement by the publishers. Product documentation applies to the named platform.
- Secure Software Development Framework, SP 800-218NIST
Security practices remain relevant with a limited product scope.
Link and relevance checked: - Web Content Accessibility Guidelines (WCAG) 2.2W3C
Testable foundations for accessible web interaction.
Link and relevance checked:
YOUR NEXT STEP
Prepare your project conversation.
Exploring MVP development? Use the project checklist to describe your task, systems and intended outcome. Collect open questions and download a brief for your conversation.
Create your project brief