How to Structure a Two-Week Pre-Build Discovery That Earns Its Fee

A client came to us with a property development project, a concierge app for high-rise residential buildings. They arrived with a suggested budget, a detailed feature list, and a clear sense of what they wanted built. What they were looking for, really, was someone to validate the plan and start building. What they got instead was a proper two-week discovery, including focus groups and user workshops, and it changed everything. The product they eventually launched was significantly simpler than the one they had imagined. Many planned features were dropped entirely. The focus shifted away from replacing existing building systems and towards creating a genuine human connection with the product. The result was better, and it cost less.

A well-structured discovery phase gives everyone a defensible reason for every decision that follows.

That is what a well-structured discovery phase does. It does not just ask questions and produce documents. It changes the shape of what gets built, sometimes dramatically, and it gives everyone in the room a defensible reason for every decision that follows. Two weeks is enough to do that properly, if you use them correctly.

The question most clients ask is whether discovery is worth its fee. The better question is what it costs to skip it.

What a Defensible Discovery Actually Delivers

Discovery is the process of building a shared, evidence-based understanding of the problem before anyone writes a line of code or designs a single screen. Without it, decisions rest on assumptions, usually the loudest person's assumptions, and those assumptions compound through every sprint that follows.

A defensible discovery delivers four things. First, a clear and agreed problem statement, one that the whole team can point to when a scope argument breaks out six weeks later. Second, a user profile that is specific enough to be useful, not "adults aged 25 to 45" but a set of real people with real behaviour patterns and real frustrations. Third, a competitive read that goes beyond feature lists to examine how people feel about the products they currently use. Fourth, a prioritised set of recommendations that the client can act on immediately.

We ask, on every project, what need the product will fill and how people are currently meeting that need without it. Crucially, we also ask how people feel about their current process. If users are reasonably content with a manual approach, there is no compelling reason to build a technical solution. A discovery that does not ask that question is incomplete, however thorough it looks on paper.

Week One, Day by Day: Orientation, Research, and Problem Framing

Days One and Two: Establish the ground

The first two days are about orientation. We run a stakeholder kickoff that goes well beyond a standard briefing session. We want to understand what the client wants to build, why they believe this problem exists, what assumptions they are carrying, and what success looks like to them commercially. We also run the dinner party exercise here, asking the team to picture the product as a person at a social gathering, how they dress, how they speak, whether they are the loudest voice in the room or the quiet one listening carefully. It gives us a concrete human benchmark to measure every subsequent design and copy decision against.

Days Three to Five: Research in the field

Days three to five are for primary research. This means user interviews, competitor walkthroughs, and in some cases focus groups. We are not looking to confirm what the client already believes. We are looking for the gap between what people say they want and how they actually behave. According to AppTweak, when users are asked whether they would use an app, 60 to 80 per cent typically respond positively, but actual usage is often only 10 to 20 per cent. That gap is exactly what week one is designed to surface before it becomes a post-launch problem.

Week Two, Day by Day: Synthesis, Validation, and Recommendation

Days Six and Seven: Synthesis

The first two days of week two are for synthesis. This is where the research stops and the thinking starts. We map what we found against the business goals established in day one, looking for alignment and, more usefully, for contradictions. We use an effort versus impact matrix to sort features and ideas: what should be worked on first, what should come later, and what should be dropped entirely. This is also where we weight the feedback we collected, not every user is equally relevant to every feature, and a synthesis that treats all responses as equal will produce muddled priorities.

Days Eight to Ten: Validation and Recommendation

Days eight and nine are for validation. Where findings are significant, we run targeted quantitative checks to confirm that qualitative patterns are not outliers. By day ten, we have a recommendation document. This is a prioritised set of decisions with the reasoning behind each one, written so that a developer, a designer, or a board member can all read it and understand what to build and why.

Discovery is about finding the gap between stated intent and actual behaviour.

The deliverable from week two is the brief that build teams actually need, not the one the client walked in with.

Run the dinner party exercise in day one, not week two. The brand personality baseline it produces should shape how you frame research questions and how you read competitor products, leaving it until synthesis wastes its full value.

The Artefacts: What You Should Have in Your Hands at the End

At the end of a two-week discovery, the client should be holding a set of documents they can use immediately and refer back to throughout the build. The list below is not exhaustive, but anything missing from it is a gap worth questioning.

• A problem statement, one paragraph, agreed by all stakeholders
• User profiles with behaviour patterns and emotional context, not just demographics
• A competitive landscape summary focused on user sentiment, not just feature parity
• A prioritised feature list with effort versus impact reasoning documented
• A brand personality baseline, grounded in the dinner party exercise output
• A recommendation document covering what to build, what to defer, and what to drop

The property developer concierge app is a useful reference here. Before discovery, the client had a long feature list and a belief that they needed to replace most of the building's existing systems. After discovery, they had a much shorter list and a clear understanding that residents wanted to feel looked after by the product, not managed by it. Those are very different design briefs, and only one of them produces a product people actually use.

The recommendation document should be written so that someone who was not in the room can read it and understand every decision. If it requires context to make sense, it has not been written clearly enough.

The Decisions a Good Discovery Enables

A discovery that works well does not just tell you what to build. It tells you what not to build, and that is often the more valuable output. Every feature that gets dropped before build saves more than its own development cost, it saves the complexity it would have added to every other feature around it.

Good discovery enables four categories of decision. The first is scope: what is in and what is out, with reasons that hold up to scrutiny. The second is sequencing: what gets built first and why. The third is tone and personality: how the product communicates, grounded in a defined brand character rather than personal preference. The fourth, and often the most uncomfortable, is feasibility: whether the product as imagined is the right solution to the problem that actually exists.

We regularly ask teams to examine whether users are genuinely frustrated by their current approach to a problem. If they are not, a product that solves it technically may not solve it meaningfully. A discovery that surfaces this finding before build is worth several times its fee. A build that surfaces it after launch is simply expensive.

How to Tell a Substantive Discovery from a Performative One

Performative discovery looks busy. It produces slide decks with frameworks and diagrams. It references research methods and includes well-formatted persona cards. What it does not do is change anything. The client walks in with a view, and they walk out with the same view, now decorated with evidence that was selected to support it.

The clearest sign of a performative discovery is that nobody on the client side was uncomfortable at any point during it. Genuine discovery surfaces things people did not already know, and some of those things are inconvenient. If a founder's favourite feature consistently confused users in testing, that finding needs to be in the report and discussed directly, not softened into a footnote.

We have worked with founders who had very strong pre-existing views about how their product should work. When the research process becomes a box-ticking exercise and there is no genuine intention of acting on the findings, the discovery has failed regardless of how thorough the methodology was. We have seen a product launch a year after we raised those concerns, largely unchanged from what the research flagged as problematic, and it did not succeed.

What Happens When Discovery Is Skipped or Shortened

We worked on a dating app built around verified profiles and the prevention of bots and fake accounts. The onboarding process received rigorous discovery attention. The messaging component did not, the client chose to skip that phase and focus purely on onboarding. The consequence was direct: the messaging feature was built generically, and it allowed the automated and fake messages that the onboarding had been designed to prevent. The verification work and the messaging system directly contradicted each other.

Fixing it required a complete rewrite of the messaging section. That cost approximately £15,000 in additional budget and two months of additional work. The £15,000 did not buy anything new. It bought back the ground that had been lost by skipping a process that would have cost a fraction of that to run properly at the start.

This is the pattern we see when discovery is treated as optional for parts of a product. The sections that received discovery hold together. The sections that did not create contradictions that eventually need resolving, and resolving them mid-build or post-launch is always more expensive than preventing them. According to Nielsen Norman Group, investing more time in discovery reduces the risk of project failure by 75 per cent. The dating app rewrite illustrates exactly what that risk looks like when it materialises.

If a client wants to reduce the scope of discovery, ask which components they want to skip and map out the dependencies. Often the skipped component connects directly to the one they care most about, and making that visible changes the conversation.

When Discovery Changes the Brief Entirely

The property developer concierge app came to us with a pre-formed idea and a budget framing that treated discovery as a formality before build. The focus groups and user workshops changed everything. What we found was that residents did not want a product that replaced building systems. They wanted something that made them feel looked after. The functional complexity the client had planned was not just unnecessary, it would have made the product feel impersonal in exactly the context where warmth mattered most.

The revised brief was simpler, narrower, and better. Features were dropped. The tone shifted. The design priorities changed. None of that would have happened without a discovery phase that was genuinely open to finding something the client had not expected.

We navigate this carefully. When a client believes they already have clarity but the questions we ask reveal something different, we do not challenge their assumptions head-on. We ask the questions that open up more detail, and let the evidence do the work. Even when that process leads to a significant pivot, or in some cases to advising a client not to proceed with a product at all, it is done collaboratively, with a shared goal of building something that actually works.

Why Some Agencies Walk Away If You Refuse Discovery

We walked away from a project involving a social product because the client wanted to move directly to redesigns. They were not willing to engage with our emotionally led, user-centred discovery phase. The product was not unusually complex. The brief was reasonably clear. But without discovery, we would have been executing someone else's assumptions rather than building from evidence, and the result would have been ours to carry regardless.

Discovery is the process that makes the rest of the work coherent. Agencies that skip it at a client's request take on a specific kind of risk: the risk of building the wrong thing well. That risk does not sit only with the client.

Simon draws a clear lesson from a sports club app project where resistance to iterative methodology and MVP thinking in favour of launching everything at once contributed to serious delays. Working with the process rather than against it is the difference between a product that ships and one that does not. Discovery is where that working relationship is either established or not, and when it is not, the consequences run through the entire engagement.

Conclusion

Two weeks of structured discovery changes the shape of what gets built. It does not guarantee a successful product, nothing does, but it produces a set of decisions that are grounded in evidence rather than assumption, and that is a meaningfully different starting point for everything that follows.

The concierge app delivered a simpler product at a lower cost. The dating app paid £15,000 and two months to learn a lesson that discovery would have surfaced in the first week. The founder who treated research as a formality launched a product the evidence had already told him would not land. These are what happens, and they happen for predictable reasons.

A two-week discovery earns its fee when it changes something, when a feature gets dropped, a brief gets reframed, or a build sequence gets reordered because of what the research found. If nothing changes, the discovery was not discovery. It was preparation for a decision that had already been made.

The question at the start of any engagement is not whether you can afford to run a proper discovery phase. The question is whether you can afford the version of the project that skips it. If you are working out which applies to yours, let's talk about your project.

Frequently Asked Questions