Product discovery: the two weeks before anyone opens Figma

Why skipping it costs more

Every expensive project we've been called in to rescue has the same origin story: the team started building before they'd agreed what they were building. Not out of laziness, out of momentum. There was budget, there was enthusiasm, someone knew a developer, and starting felt like progress.

Three months later, the product does six things adequately and none of them well, the founder can't say in one sentence who it's for, and every new feature request triggers an argument because there's no shared idea of what the product is not.

Discovery is the cheapest insurance against that. One to three weeks and a few thousand pounds up front, against months of build spent on the wrong thing. On a £50,000 MVP budget, a £6,000 discovery that removes even two misbuilt features has already paid for itself. The maths almost always favours doing it.

What discovery is not

It's not a research project. We're not going to spend weeks producing a sixty-page report you'll never open. It's not a workshop with sticky notes and no output. And it's not us telling you what to build. You know your market better than we do.

It's also not a delaying tactic or a way to pad an invoice. If we get two days in and conclude you're ready to design, we say so and we move. A good discovery can end early. It cannot end vague.

The five things it produces

Discovery deliverables tend to fall into four groups: business (who this is for and why it wins), UX (what the experience is), technical (how it gets built and what it connects to), and planning (phases, timeline, cost). The five artefacts below cover all four without drowning you in documents.

1. The one-sentence product definition

Who it's for, what job it does for them, and why they'd choose it over the alternative, including the alternative of doing nothing. If we can't get this to one clear sentence, the product isn't ready to design. That's a finding, not a failure.

2. The core flow, mapped end to end

The single most important thing a user does, drawn step by step, including the moments where things go wrong. Most scope blow-outs happen because nobody mapped the unhappy paths until an engineer hit them in week seven.

3. A prioritised feature list with a hard line through it

Everything that's been suggested, sorted into “MVP,” “next,” and “not now, and here's why.” The “not now” column is the valuable one. It's what lets you say no to a feature request in month two without re-litigating the whole product.

4. The riskiest assumption, named

Every product rests on something that might not be true: that people will pay this much, that they'll trust you with this data, that they'll switch from the tool they use now. We identify the one that would sink the product if it's wrong, and design the MVP to test it as early and cheaply as possible.

5. A build plan with a real number

Phases, rough timeline, an architecture outline, an integration list, and a cost range you can take to your board or your bank, grounded in the actual scope rather than a guess.

What we're doing each day

A typical two-week shape. Shorter engagements compress this; longer ones add user research.

We interview stakeholders separately on purpose. The disagreements are usually where the important decisions are hiding, and they do not come out in a group call.

User conversations are three to five people from your target market. Enough to challenge assumptions, not enough to call it statistically significant. We are listening for the moment a user describes the problem in words nobody on your side has used.

What we need from you

Discovery works when the client side shows up. Concretely, that means:

• One decision-maker who can be in every session and can say yes without a committee.
• Access to two or three real prospects or users for us to talk to. If you cannot find anyone willing to talk about this problem, that is itself a finding.
• Anything you've already written: pitch decks, notes, competitor logins, a spreadsheet of feature ideas. We would rather build on your thinking than restart it.
• Roughly two to four hours a week of your time for the fortnight. Less than that and the phase stretches.

When you can skip it

Discovery isn't mandatory. You can go straight to design if:

• The scope is genuinely small and single-purpose: a landing page, a calculator, one clearly-defined flow.
• You've done the thinking already and can hand us a real brief (the product definition, the priorities, the constraints) that survives a few hard questions.
• You're iterating on a product that already exists and has users, and the change is well understood.

If you're not sure whether you've done the thinking, that's usually a sign you haven't. That's fine. That's what the two weeks are for.

What it costs in 2026

For most first products, discovery runs £4,000 to £9,000 over one to three weeks, depending on how many stakeholders we need to align and how much user research the risk profile warrants. That is in line with the wider UK market, where discovery phases generally sit between £2,000 and £8,000 and last two to four weeks.

It's the smallest phase of any engagement and the one with the highest return, because every decision it locks down is a decision you're not paying to unpick during the build.

Common questions

What is a product discovery phase?

A short, structured phase at the start of a project that turns what you already know, plus targeted research, into decisions the whole team can build against. It produces a product definition, a mapped core flow, a prioritised feature list, the riskiest assumption, and a costed build plan.

How long does product discovery take?

Usually one to three weeks for a first product. A tightly scoped single flow can be done in a few days; a product with several stakeholders and real user research to do may take a month.

How much does a discovery phase cost in 2026?

For a UK agency, typically £4,000 to £9,000, with the wider market ranging from about £2,000 to £8,000. It is the cheapest phase of a build and the one that most reliably prevents expensive mistakes later.

Can I skip discovery and go straight to design?

Yes, if the scope is genuinely small and single-purpose, if you can hand over a brief that survives hard questions, or if you are iterating on an existing product with users and the change is well understood. If you are unsure whether you have done the thinking, you probably have not.

What deliverables do I get from discovery?

A one-sentence product definition, the core user flow mapped end to end including failure states, a prioritised feature list with a clear “not now” column, the single riskiest assumption named, and a build plan with phases, timeline, and a real cost range.

If you're weighing up a build and you're not certain you could write the brief yourself, start with a conversation. Half an hour will tell us, and you, whether you need the full two weeks or you're ready to go.