Research, prototypes, and a scope that can be priced.

What you have at the end

Five things, and each one is an object somebody can use, not a description of what we did.

• A release order

  What gets built first, and the reason it goes first. Usually that reason is risk in the integrations rather than what looks finished soonest.

• An estimate, with its assumptions

  What the first release costs in time and money, and the list of things that would change that number if they turn out differently.

• A backlog

  Epics and stories at the level that can actually be estimated, rather than a feature list that has to be re-derived later.

• The integration map

  Which systems the product has to read from and write into, what each one can already do, and which of them nobody has checked yet.

• A prototype people have used

  Clickable, end to end, put in front of the people who would use it, not a walkthrough shown to the people who commissioned it.

Three answers this can give, and one of them costs us the build

A discovery that can only end one way isn’t a discovery. It’s the first invoice of a project that was already decided.

1. 01

   Build it, and here’s the order

   The concept holds, the integrations are reachable, and the work can start. What discovery adds is the sequence: which release goes first, what it depends on, and what the first one costs.

   The usual case, and the one everyone plans for.

2. 02

   Build less of it

   Sometimes a piece of what was asked for already exists as a mature product, and integrating it costs a fraction of building it. Sometimes the first release only needs a third of the scope to be worth shipping. Both answers make the engagement smaller.

   On a patient platform that needed video consultations, we recommended integrating a specialised provider rather than building it from scratch.

3. 03

   Not yet

   The idea is clear to the people who have it and untested with the people who would use it. Then the honest output is a prototype and a set of findings, and the build waits until those come back.

   mEMR came to us with a physician-led product concept. We ran the research and built high-fidelity prototypes to test it with physicians and patients before a line of code was written.

When this is worth doing

Three situations where the cost of finding out later is much higher than the cost of finding out now.

• The people who would use it haven’t seen it

  A concept can be clear to the founders and wrong about the workflow it has to fit into. When the users are physicians, or inspectors, or anyone whose day the product has to survive, the gap between a well-argued idea and a usable one is where budgets disappear.

  This is what a prototype is for: not a demo, an instrument for finding that out early.

• It has to connect to systems nobody has opened in years

  The integration layer is where these projects are decided. What a system can already expose, what it cannot, and who has to approve the connection are questions with long answers, and finding them during a build turns a schedule into a negotiation.

  Discovery is where those questions get asked, while the answers can still change the plan.

• The first release has to be defensible to someone who wasn’t in the room

  In institutions, scope is approved by people who weren’t part of the conversation that produced it. A backlog with a reason attached to each priority survives that meeting; a list of features doesn’t.

  That reason is the deliverable. Without it, the meeting re-opens decisions that were already made.