Product strategy & discovery
Research, prototypes, and a scope that can be priced.
What comes out is a backlog, the integrations it depends on, and an estimate with its assumptions written down, produced by the same team that would build it.
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.
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.
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.
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.
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.
Questions we get before the first call
Can we go straight to building?
Often, yes. If the product is understood, the integrations are known and someone has already tested the concept with the people who will use it, discovery would be paperwork. We’d rather say so than sell a phase that doesn’t change anything.Do we have to build it with you afterwards?
No. What comes out is yours: the backlog, the estimate, the prototype and the reasoning behind each priority. It’s written to be handed to whoever builds it, including your own team.How much research is enough?
Enough to change a decision that’s still open. A study that arrives after the decision was made, or that couldn’t have changed it either way, is a cost with no return, and it’s the reason research has the reputation it has inside product teams.What if we already know what we want to build?
Then the useful work isn’t validation, it’s sequencing and sizing: what goes first, what it depends on, and what it costs. That’s a shorter engagement and we’ll scope it as one.
Tell us what you’re about to spend it on.
In a 45-minute working session we’ll tell you whether this needs discovery at all, what we’d want to find out first, and what the answer would change. Bring the idea and the deadline attached to it.