Skip to content

Product launch

Product discovery

What exactly gets built and in what order: user scenarios, the boundary of the first version, screens and the links between them, estimates by stage.

Reply to your brief
within 24 hours
First call
30 minutes, no commitment
First working version
in a week

Process

What happens, and when

The work is split into stages, and each one has a named result. You see it yourself rather than reading about it in a report.

  1. Days 1–3

    Domain and constraints

    We talk to the people who know the domain from the inside: who the user is, what they do today without your product and where that costs them time. A separate list holds what is not up for discussion — the deadline, the ceiling on the budget, the external systems you have to live with.

    You get — What users do today and the fixed constraints

  2. Days 4–7

    Map and boundary

    We draw the map: screens, the moves between them, and the data somebody has to store. The boundary of the first version runs across that map — every feature gets an answer, “in the first one” or “later”, with the reason beside it rather than a tick.

    You get — A map of screens with the first-version line

  3. Days 8–11

    Sizing and order

    The map turns into an estimate by stage: every screen and every link gets a size and a place in the queue. Written out separately is where the estimate is provisional — usually external APIs, whose behaviour nobody knows until the first request.

    You get — An estimate by stage and its provisional parts

  4. Days 12–14

    Walkthrough and handover

    We go through the result out loud, screen by screen, with the people who will build it and the people who will pay for it. The document is written so that any team can work from it, not only its authors — otherwise it is not discovery, it is a pitch for the contract.

    You get — A document any team can build from

  5. Once the build starts

    Map against reality

    The map lives until its first meeting with reality. Once the build has started and something turns out different from the drawing, the map is corrected too, not only the code: a gap between the plan and the product costs more than half a day of redrawing.

    You get — A map that still matches the product

What the work covers

  • How the work runs today

    who takes part in it, what gets done without your product, and where the time goes

  • The constraints

    the deadline, the ceiling on the budget and the outside systems you have to live with — the part that is not up for discussion

  • A map of screens and data

    the screens, the moves between them, and the entities somebody has to store

  • Where version one ends

    every feature gets “in the first one” or “later”, with the reason beside it rather than a tick

  • An estimate by stage

    a size for every screen and link, the order of the work, and a separate list of the places where the estimate is provisional

  • A document you can hand on

    the scenarios, the map and the estimate in one file, written so that any team can work from it, not only its authors

What we need from you

  • People who know the domain from the inside, and their time for a conversation in the first days of the work
  • A named deadline, a ceiling on the budget, and the list of outside systems the product has to live with
  • The person who can decide what stays out of the first version, and who is ready to decide it before discovery ends

What people usually ask

Contact

Send a description of the task

A reply with the scope, the timeline and a budget estimate comes within 24 hours.

The first call is 30 minutes, with no commitment on your side.

  1. 01

    You describe the task

    Five questions in the form, or a plain email — whichever suits you.

  2. 02

    We answer within a day

    With the scope, the timeline and a budget estimate, based on what you told us.

  3. 03

    We talk for 30 minutes

    To clear up whatever is unclear. It commits you to nothing.