ANODA Discuss your product

Product Discovery Services

Find out what your first release has to prove — with real users and a tested prototype — before a large budget goes into design and development.

Discuss your product Explore our work
A steel robotic arm hanging from a ceiling plate plants an orange flag on the highest plateau of a white ceramic terrain model.
For a new product or area
Before design and development commit
Custom scope
Fixed or phased, set in the proposal
A tested prototype
Tried with the people it is for
A first-release scope
With the reason for every item

In short

Know what to build first, before you pay to build it.

What's included

  • Assumption map
  • User interviews
  • Prototype tests
  • First-release scope
  • Decision record

Answers you'll have before development

  • Is the problem real for the people you picked?
  • Which belief could sink the product?
  • What must the first release do, and what can wait?

Where it stops

UX Research

Explains how people behave today.

Product Discovery

Decides what a new product's first release should be.

Not included

  • Market size or statistically proven demand
  • Full design or development — scoped separately

From what you believe to what you will build

Four pieces, each built on the one before.

Discuss your product
  • A white ceramic plate split into four quadrants by steel rods, three graphite tiles in one corner.

    Discovery plan

    The decision at stake, the riskiest beliefs and how each gets tested.
  • White ceramic speech bubbles sorted into two steel trays, one bubble graphite.

    Evidence from users

    Interviews and sessions, sorted into what held and what did not.
  • A ceramic wireframe phone on a round steel-rimmed plate, a clipboard beside it with three task rows ticked, the last tick graphite.

    A tested prototype

    The core journey, tried with the people it is for.
  • A steel frame encloses the first ceramic blocks in a row, the rest wait outside it.

    First-release scope

    In priority order, with the reason and evidence for every item.

You receive

  • A written decision record
  • The tested prototype
  • A walkthrough for design and engineering

Start with the decision, not the backlog.

The product discovery phase names the choice the investment depends on, then finds the cheapest honest way to test each belief behind it.

  • What does the business already know, and what is it only assuming?

    Method: A product discovery workshop Founders, product, sales and support, with your research and data

    Why this method: It gathers what the team knows in one place and shows which beliefs carry the most risk.

  • Do people have this problem, and how do they deal with it now?

    Method: User interviews Target users from your customers or leads, or screened participants

    Why this method: Today's workarounds show what a new product has to beat, and in whose words.

  • Will they use what we plan to build?

    Method: Prototype sessions The same target users, working through the core journey

    Why this method: What people do with a prototype says more than what they say they would do.

  • Can the first release be built within budget?

    Method: A technical check Your engineers or technical partner

    Why this method: A feature people want can still be too costly to build first.

  • Which beliefs held, and what goes into the first release?

    Method: Synthesis and a decision review Everything above, reviewed with the people who decide

    Why this method: Every item in the scope traces back to evidence, or is marked as an assumption still to test.

Limits and confidence. A handful of interviews explains why people act as they do, not how many will. The decision record says which findings rest on few sessions, what the study cannot establish, and which questions remain open.

When discovery is the right start

It fits when you can name the opportunity but not yet what to build. Four signs it is the right step now.

  • The idea is clear, the product is not

    You know the opportunity and roughly who it is for, but not which features belong in the first release and which can wait.

  • A wrong guess would be expensive

    A build is about to start while key beliefs about users, value or feasibility are still untested. Finding out after launch costs a release.

  • The team wants different things

    Stakeholders disagree on what comes first. Discovery gives them shared evidence instead of another round of opinions.

  • Someone can decide

    A founder or product owner will join the sessions and act on what discovery finds, even when it changes the plan.

A different starting point

Let's find out what your first release must prove

Tell us about the product and the decision in front of you. We will come back with a discovery scope and a realistic start.

Discuss your product Explore our work

Scope, access and who does what

Methods, deliverables and the review rhythm are agreed before we start.

Scope
Custom fixed or phased, set in the proposal
Timeline
Agreed after scope, access and dependencies
Discuss your product

  1. You provide

    The idea
    What you want to build, for whom, and the business goal behind it.
    What you know
    Research, data, sales or support notes, and anything tried before.
    Access to users
    Customers or leads we can talk to, or a profile we can recruit against.
    Decisions
    A product owner who reviews each step and signs off the scope.

  2. Who does what

    ANODA
    Plans and runs the research, builds and tests the prototype, and writes the scope and the decision record.
    Your team
    Shares context, helps reach users, joins the sessions and makes the product decisions.

  3. Boundaries

    Outside discovery
    Full product design, development, market sizing and statistical surveys.
    After discovery
    Design and build can follow with us or your own team, scoped separately.

Related services

What must your first release get right?

Tell us what you are building, for whom, and what you are least sure about.

What do you need? *
Project budget (USD) *

What is your product, who uses it, and what would you like us to do?

    Within 15 minutes, we’ll reply with initial feedback and follow-up questions.

    Read more about product discovery

    All articles

    Product Discovery: common questions

    What should we know before we commit to development?

    Whether the problem is real for the people you are building for, which of your beliefs carry the most risk and whether they held up, what the first release must do and what can wait, and which questions are still open. Each point should rest on evidence or be clearly marked as an assumption.

    Who should run discovery for a complex product?

    A team that has researched, designed and handed products over to engineers, so the scope it writes is one a team can actually build. Ask how they choose methods, how they report what they could not prove, and who on their team will run the sessions.

    What do product discovery services at ANODA include?

    A product discovery workshop to frame the decision, a map of your assumptions ranked by risk, interviews with target users, a prototype of the core journey tested with them, and a first-release scope in priority order. It ends with a written decision record and a walkthrough for the people who design and build next.

    Should we start with discovery, research or an audit?

    Start with discovery when you are defining a new product, a large new area or a first release. If a product is already live and something is not working, a UX Audit finds the problems. If the question is how people behave today, UX Research answers it. If the evidence is in and the team needs one direction, Product Strategy fits better.

    What do you need from us to start?

    The idea and the business goal behind it, anything you already know — research, data, sales or support notes — access to customers or leads, or a profile we can recruit against, and a product owner who can review each step and sign off the scope.

    What do we get at the end?

    A written decision record, the tested prototype, the evidence from users sorted into what held and what did not, and a first-release scope in priority order with the reason for every item. We walk your designers and engineers through it, and it is yours to use with any team.

    How are scope, timing and price set?

    By how many open questions matter, how many user groups need hearing, how easy they are to reach, and how much evidence already exists. We set a custom scope and estimate in the proposal, fixed or phased, and agree the timeline once scope, access and dependencies are clear.

    What is not included?

    Full product design, development, market sizing and statistical surveys. Discovery shows why people act as they do and what to build first; it cannot prove how many people will buy. Design and build can follow with us or your own team, scoped separately.