How we rundiscovery.
Discovery is where the expensive decisions get made — usually quietly, often by accident. This is exactly how we run ours: what we ask, what we refuse to do, and what you're holding at the end of it.
There's a version of discovery that exists to make everyone feel responsible. Weeks of workshops, a wall of sticky notes photographed for the deck, an eighty-page findings document, and a project that proceeds exactly as it would have on day one. That isn't discovery. It's a permission slip with a methodology attached.
We run discovery for one reason: to reduce the odds that you build the wrong thing. Everything in the four weeks below either changes a decision or it doesn't happen. That single filter removes most of what makes discovery feel slow, and none of what makes it worth doing.
It's also the cheapest part of the whole engagement. A wrong assumption caught in week two costs a conversation. The same assumption caught after launch costs the roadmap, the budget, and somebody's credibility. Same mistake, wildly different price — and the only variable is when you find out.
Discovery is not a phase
Treating discovery as the thing you get through before the real work starts is what makes it worthless. The real work is deciding what to build. Design and engineering are how that decision becomes real — they aren't where it gets made.
So we don't run discovery to produce understanding in the abstract. We run it against a specific choice, on a specific timeline, with the people who can actually make that choice in the room. If we can't name the decision on day one, we say so before you've spent a month finding out.
The other thing we hold to: findings arrive as they happen. Nothing is saved for a reveal. If we learn in week two that the premise is shaky, you hear it in week two — while there's still time and money to do something about it.
Four weeks, in order
- Before we start
We ask for what already exists
Almost every organization already knows more than it thinks. Analytics, support tickets, sales objections, the last research deck, the roadmap nobody has revisited. We read it first so we never spend your week rediscovering something you already paid to learn.
- Analytics and search logs for the last twelve months
- Support and sales themes — the complaints that repeat
- Prior research, however old, and whatever was ignored
- The list of people whose sign-off can stop this
- Week one
Frame the decision, not the project
We start from the choice you are about to make and the risk you are trying to reduce. Not “understand our users” — that is a hobby. Something closer to: do we rebuild the platform or fix the checkout, and what would have to be true to justify either.
- Stakeholder conversations run as interviews, not status meetings
- The decision written in one sentence, agreed in the room
- The assumptions that would sink it if they were wrong, ranked
- A short list of what we would need to see to believe each one
- Week two
Go and get evidence
We chase the ranked assumptions, using the method that fits the question — customer interviews, a usability session on the thing you have now, a walk through the workflow on the floor, a technical spike where the risk is architectural.
- Five to eight well-chosen conversations per audience, not fifty rushed ones
- A look at the real system, not the diagram of the system
- Competitive and adjacent scans where they change the answer
- Findings shared as we get them — no surprise reveals in week four
- Week three
Turn it into options, with prices
Insight that arrives without a recommendation just moves the work to you. We synthesize into two or three real directions, each with an honest account of what it costs, what it forecloses, and what we still do not know.
- Two or three directions, described concretely enough to argue with
- What we observed kept separate from what we recommend
- Effort, risk and sequencing attached to each option
- The open questions we could not close, named out loud
- Week four
Make the call, then prove it small
You decide. We build the smallest real thing that tests the riskiest part of that decision — a working prototype, a flow, an architecture spike. Discovery that ends in a document ends. Discovery that ends in something running keeps paying.
- A decision, made by you, with the evidence attached
- A prototype or spike aimed at the riskiest assumption
- A sequenced plan for the first eight to twelve weeks of build
- A written record of what we would revisit and when
Every engagement is different — this is the shape, not a contract. Narrow decisions compress to two weeks. Genuinely complex workflows stretch to eight. What never changes is the order.
The questions we'll ask you
These come up in the first conversation, before any contract exists. If you want a head start, answer them for yourself — the arguments they start internally are usually more valuable than the answers.
- 01
What decision are you trying to make?
If the answer is “we just need to understand the space,” discovery has no finish line and no way to be judged.
- 02
What happens if you do nothing for a year?
The honest answer separates urgent problems from expensive habits. Sometimes nothing happens, and that is worth knowing before you spend.
- 03
Who can say no to this after it ships?
Late vetoes are the most common cause of rework. We would rather find that person in week one and put them in the room.
- 04
What do you believe that you have never checked?
Every organization runs on inherited assumptions. Naming them is most of the work; testing the top two is usually the rest.
- 05
Where does the current experience embarrass you?
People tell you the truth faster about shame than about strategy, and the answer is almost always specific and actionable.
- 06
What has been tried already, and why did it stall?
The graveyard is instructive. A direction that failed for political reasons will fail again for the same reasons if nothing changed.
- 07
How will you know in six months whether this worked?
If nobody can name the measure now, nobody will defend the investment later. We write it down while it is still cheap to argue about.
- 08
What are you unwilling to change?
Constraints are not failures. Knowing that the ERP stays, or the brand cannot move, saves weeks of designing things that were never going to happen.
What we won't do
- Run a workshop because the process says week two has a workshop
- Interview thirty stakeholders and synthesize none of it
- Build personas that no one will open again after the readout
- Deliver a findings document longer than the attention available to read it
- Save bad news for the final presentation
- Recommend the largest engagement we could plausibly justify
What you get
- The decision written down, with the evidence behind it attached
- Two or three costed directions, not one recommendation to rubber-stamp
- A working prototype or spike aimed at the riskiest assumption
- A sequenced plan for the first eight to twelve weeks of build
- The raw research — recordings, notes, synthesis — handed over, not summarized away
- An honest list of what we still don't know, and what it would take to find out
Who it's for
- Teams about to commit real money to a direction nobody has pressure-tested
- Enterprises where four departments each own a piece and no one owns the outcome
- Leaders who inherited a roadmap and want to know whether to keep it
- Product teams stuck arguing from opinion because there's no shared evidence
- Anyone who has been handed a rebuild proposal and isn't sure it's the real problem
Questions we get
- How long does discovery take?
- Four weeks is the shape we describe here, and it fits most engagements. We have run useful two-week versions when the decision was narrow and the evidence already existed, and eight-week versions where the workflow was genuinely complex or spread across regions. What does not change is the order: frame the decision, get evidence, produce options, decide.
- Can we skip discovery? We already know what we want to build.
- Sometimes, yes — and we will tell you so. If the decision is already made, the risk is understood, and the constraints are clear, discovery is a tax. What we will not do is run a four-week process to confirm something you already know, then hand you an invoice for it. If a two-day alignment session is what you actually need, that is what we will propose.
- Who from our side needs to be involved?
- Less time than you think, from more people than you expect. Roughly an hour each from the people who can stop the project, an hour each from the people who live in the current system, and a standing thirty minutes a week with whoever owns the decision. Availability of that last person is the single biggest predictor of whether discovery lands.
- What if discovery says the project should not happen?
- Then it did its job, and it was the cheapest four weeks you will spend this year. It is rare that the answer is a flat no — far more often the answer is “not this, and not yet, but here is the smaller thing that would actually move the number.” We will say that plainly, in writing, even when it shortens our own engagement.
- Do you hand over the raw research?
- Yes. Recordings where participants consented, notes, the synthesis, the boards, all of it. You deserve to check our reasoning rather than inherit our conclusions, and the material stays useful to your team long after we are gone.
Got a decision worth getting right?
Tell us what you're about to commit to and what you're unsure about. We'll tell you honestly whether discovery is the right way to find out — and how short it could be.