Start with what you need to learn
An MVP is not a miniature version of your entire roadmap. We look for the shortest journey that lets a target user solve their problem and your team observe what happens.
Before selecting features, we state the assumptions: who will use the product, why, when and what they use today. The first release should help test those assumptions in practice.
Prototype or working product?
An interactive prototype may be enough to test whether people understand a journey. A working product becomes necessary when the question involves actual use, an integration or repeated behaviour.
We choose the level of implementation according to the decision you need to make. That avoids building an entire infrastructure to answer an interface question, or presenting a mockup as operational software.
Deliverables for the first cycle
The exact scope of the engagement is agreed during discovery.
- A documented audience, problem and priority journey.
- An explicit list of included and deferred features.
- A prototype or working release, depending on the objective.
- Acceptance criteria and a plan for gathering feedback.
- A summary of the decisions needed for the next phase.
Planning the budget and the next step
Schedule and budget depend on scope, dependencies and the availability of decision-makers. We clarify them after discovery instead of promising every project the same timeline.
At the end of the cycle, you can continue, adjust the product or stop exploring an idea. We plan the next step around observations rather than assuming that every idea needs to become a complete platform.
Before we start
Do I need a specification already?
No. A description of the problem, the users and the constraints is enough to start. Discovery turns those elements into an actionable scope.
Can the MVP evolve?
We aim for a maintainable foundation. Some exploratory elements may need replacing; we discuss those trade-offs openly.