Product discovery & MVP design

Product discovery services: decide what your MVP must prove before you build it

A focused engagement that turns an idea into written decisions: what the first release has to learn, what it includes and leaves out, how the core flow works, what the technical risks are - and what it will take to build.

Prepare a discovery brief See what you receive

01When discovery is worth it

A product discovery service pays off when the first release is still an argument

If the scope is already small and everyone agrees what the first release must prove, skip it and go straight to MVP development. Otherwise, these are the usual signs.

  1. Scope is debated, not decided

    Every conversation adds features. Nobody can say which of them the product cannot launch without.

  2. Investors or leadership want a plan

    They ask what the first version does, what it costs and what you will know after launch - and the answers are still in your head.

  3. Several kinds of users

    Buyers, end users and administrators want different things. Choosing whom release 1 serves first is the core decision.

  4. A technical unknown

    An integration, a data source or an algorithm might not behave as hoped. Better to find out with a small spike than in the middle of the build.

02What you receive

Seven outputs, each tied to a decision

Discovery is judged by the decisions it makes possible. Each output below is a document you keep, and each one supports a specific choice.

  1. Problem and learning goals

    Who the first users are, the assumptions the product depends on, and the one or two this release must test - with the signals that would confirm them.

    Decision it supportsWhat the MVP is for, and how you will know it worked.

  2. Users and core journeys

    The roles involved and the journey each one takes through the core workflow, including what happens outside the product today.

    Decision it supportsWhich roles the first release must serve, and which your team can cover by hand.

  3. Story map with the release line

    Every candidate feature placed on the journey and ranked, with release 1 drawn across the whole map.

    Decision it supportsWhat is in, what is later and what is not planned.

  4. Clickable prototype

    The core flow at realistic fidelity, tested with prospective users when understanding the flow is itself a risk.

    Decision it supportsWhether the flow is clear before code is written.

  5. Acceptance criteria

    For each story in release 1: what must be true for it to count as done, including the cases that must not happen.

    Decision it supportsA shared definition of done for the build.

  6. Architecture notes and risks

    Data model sketch, sign-in and permissions, build-or-integrate choices, hosting and the technical unknowns, each with a proposed way to retire it.

    Decision it supportsWhether a proof of concept is needed first, and which foundations must be solid.

  7. Estimate and release plan

    Effort for release 1 broken into increments, with assumptions stated and the scope levers that change it.

    Decision it supportsBudget, timing, and the go / re-scope / stop decision.

03MVP scoping

Draw the release line across the whole journey

A story map lays the user's journey left to right and stacks candidate features under each step by priority. The release line is drawn across all of it, so the first version works end to end - thinly - instead of perfecting one step and leaving the rest unbuilt.

Story map: an approvals product, journey left to rightIllustrative

Sign up01

  • Email sign-in
  • Create team
  • Single sign-on
  • Team templates

Create request02

  • Request form
  • Attach a file
  • Request templates
  • Bulk import

Review03

  • Approval queue
  • Comment
  • Delegation rules

Approve04

  • Approve / reject
  • Email notice
  • Multi-step approval
  • Mobile push

Report05

  • CSV export
  • Dashboards
  • Scheduled reports
Every column keeps at least one story above the line, so release 1 covers the whole journey thinly rather than half of it in depth. Illustrative example.

  • Every step, at least once

    If a step has nothing above the line, users cannot finish the journey and the release cannot test anything.

  • One reason per story

    Each story above the line must trace to a learning goal. "Customers will expect it" is a later-release argument.

  • People before automation

    Where a step is rare, your team can do it by hand for the first users. The map records it so it is not forgotten.

04MVP design

MVP software design: full attention where users decide

Design effort follows the release line. The screens that carry the core workflow are designed and tested in full; secondary screens use a consistent component library and stay plain until usage says otherwise.

  • Core flow at full fidelity - content, states, errors and the moment of value.
  • Component starter - type, colour, spacing and common controls, so the build does not invent them screen by screen.
  • Prototype tests - short sessions with prospective users on the core flow, with notes on what changed.
  • Accessible from the start - contrast, focus order and labels cost little now and a lot later.

05How discovery runs

The stages of product discovery

Short, intense and mostly collaborative. The order is fixed; the depth of each stage depends on what you already know.

  1. 01Together

    Framing

    The problem, the users, the business goal and the assumptions behind them, ranked by risk.

  2. 02Together

    User & domain research

    Conversations with prospective users and a look at how the work is done today.

  3. 03Comtau

    Journeys & story map

    Roles, journeys and every candidate feature, with the release line drawn.

  4. 04Comtau + users

    Prototype & test

    The core flow made clickable and tested where understanding is a risk.

  5. 05Comtau

    Technical spike

    A proof of concept only where a technical unknown could change the plan.

  6. 06Decision

    Plan & estimate

    Release plan, estimate and a recommendation: build, re-scope or stop.

06Prototype or proof of concept

Which risk are you reducing?

Discovery uses the cheapest tool that answers the open question. Often that is neither - a conversation with five prospective users can settle more than a prototype.

Clickable prototype

Understanding

Choose it when

  • Users might not understand the flow or its value
  • Several stakeholders must agree on how the product works
  • You need something concrete to show investors or early customers

Proof of concept

Feasibility

Choose it when

  • An integration, data source or algorithm is unproven
  • Performance or accuracy decides whether the product works at all
  • A third-party platform's limits are unclear

The full prototype, proof of concept and MVP comparison shows what each one can and cannot prove.

07What discovery leads to

Three possible outcomes, all of them useful

Build the MVP Most common

The plan goes straight into the build, on the platform the learning goals call for:

Re-scope or stop Also a result

Discovery can show that a different user, a smaller workflow or a technical spike should come first - or that the idea is not ready for a build budget. You keep every document either way, and they remain usable with any team.

08Questions

Product discovery questions

Ready to build already? See MVP development services.

What do product discovery services include?

Discovery turns an idea into decisions you can act on: the learning goals for the first release, the users and journeys it serves, a story map with the release line drawn, a clickable prototype where it reduces risk, acceptance criteria for the core workflow, architecture notes with the main technical risks, and an estimate with a release plan.

Do we need discovery if we already have designs or a specification?

Possibly a short one. Existing designs and specifications usually describe the full product; discovery checks which parts the first release needs, what the riskiest assumption is and whether the architecture can support the plan. If your material already answers those questions, it can be very brief.

Is a clickable prototype the same as an MVP?

No. A prototype shows whether people understand a flow and find it worth using, with fake data and no backend. An MVP is a working product people use in their own work, which shows whether they adopt it. In discovery, a prototype is a tool for scoping the MVP, not a substitute for it. The prototype, PoC and MVP comparison explains the difference in detail.

Can we take the discovery results to another development team?

Yes. The outputs are written to be used by any team: learning goals, story map, prototype, acceptance criteria, architecture notes and estimate. That is deliberate - discovery should reduce your risk whether or not Comtau builds the MVP.

What happens if discovery shows the idea should change?

Then discovery has done its job early and cheaply. The recommendation may be to re-scope around a different user or workflow, to test a risky technical part with a proof of concept first, or not to build yet. You receive the reasoning in writing either way.

How involved do we need to be?

Closely, for a short time. Discovery needs the people who know the customers and the people who decide on scope and budget, mostly in working sessions and quick reviews of what was produced. Access to a few prospective users makes the results much stronger.

All MVP development services
Next step

Not sure what the first release should be?

Send us the idea and the assumption you are least sure about. We will suggest how much discovery it needs - sometimes the honest answer is very little.

Prepare a discovery brief
A useful brief says
  1. The problem, and who has it today
  2. The assumption you are least sure about
  3. What exists already
  4. Dates, budget range, data or compliance constraints