What We Learned Walking Away From a Project That Wouldn't Do Discovery

A client came to us with a social product that needed redesigning. The brief was fairly standard, the timeline was reasonable, and the budget was there. On paper, it was a straightforward project. We walked away from it.

When discovery gets skipped, the cost lands somewhere, and it is usually larger and later than anyone planned for.

The reason was not the product, the timeline, or the budget. It was that the client refused to do discovery. They wanted to go straight into redesigns, skipping the emotionally led, user-centred phase that sits at the start of everything we do. We explained our position. They held theirs. So we declined the work and moved on.

We do not make that decision lightly. Turning down paid work is a real cost, and it is one we absorb every time we hold the line on this. But we have seen, repeatedly, what happens when this phase gets skipped, rushed, or treated as optional. The cost lands somewhere, and it is usually larger and later than anyone anticipated.

This article is about what that decision taught us and what it protects, for us and for the clients who do engage properly with the process. It is also about the specific, measurable consequences of skipping discovery, drawn from projects we have worked on directly.

What the Client Wanted and Why We Said No

The client who came to us with the social product had a clear idea of what they wanted. They had looked at the product, decided it needed a visual overhaul, and wanted design work to begin as quickly as possible. Discovery, in their view, was a delay. They had already formed their conclusions about what needed to change, and they wanted those conclusions executed.

This is a pattern we recognise. Clients come in with a suggested budget and, sometimes, a suggested process to fit that budget. The impulse is understandable. Discovery costs time and money, and if you already believe you know the answer, spending resources to ask the question feels wasteful.

Our position is that this framing is the wrong way around. Discovery is the process that tells you whether your assumptions are correct before you spend significant money acting on them. Skipping it does not save the cost of discovery, it transfers that cost into rework, misdirected build time, and in some cases, a product that misses its market entirely.

With this particular client, we made our case clearly. The product was a social tool, and social products live or die on how people actually behave inside them. Without understanding that behaviour, any redesign is an educated guess at best. The client disagreed and wanted to proceed without the phase. We said no and walked away.

What Discovery Actually Is (and What It Is Not)

Discovery, as we practise it, is the work that determines whether there is a sound basis for everything that follows. Those things have value, but they are not what we mean.

Our discovery phase is emotionally led and user-centred. We are trying to understand the psychology behind a product and a brand. Who is this brand as a person? What is this product as a person? How does it actually interact with the people who use it? Those are not questions a brief can answer. They require real conversation with real users, and they require a team willing to act on what they find rather than just collect it.

The distinction matters because the typical failure mode is research that was done but not used. We worked with a founder who had deep industry experience and very strong views about how their product should work. The discovery process happened, but it was more of a box-ticking exercise from the start. When we presented compelling evidence that a large portion of their target users did not want certain features and preferred alternatives, the founder did not move. The product launched a year later, largely unchanged from the original assumptions, and by all accounts went nowhere. The research had flagged exactly the reasons why. It had simply not been used.

Discovery that changes nothing is a process done for appearances.

What Happens When You Skip It on Just One Part of a Product

A subtler and more common problem than skipping discovery entirely is skipping it on one component of a product while investing heavily in another. The assumption is that the well-researched parts will carry the product. They do not. Products are systems, and a weak component can undermine every strong one connected to it.

We worked on a dating app built around verified profiles. The core proposition was trust: real people, no bots, no fake accounts. The client put real effort into the onboarding and verification process, and that work was strong. But they chose to skip discovery on the messaging component, deciding it was secondary and that a generic messaging feature would do.

A generic messaging feature directly contradicted the product's entire premise of verified, trustworthy connection.

What we built, without discovery to guide it, was a messaging system that allowed automated and fake messages. The very behaviour the onboarding was designed to prevent was enabled the moment a user got past verification. Simon's own words on this are exact: "Even though we'd put so much emphasis on the onboarding and validation and verification, that didn't then stack up with the other parts of the product, particularly around the messaging side of things."

Product coherence requires discovery across all interconnected components, not just the ones the client considers primary. When those components pull in opposite directions, the whole product suffers.

Before agreeing to scope discovery for part of a product, map out every component that interacts with it. If discovery on one component is skipped, the assumptions built into that component will be whatever the team guesses, and those assumptions will travel through every touchpoint it connects to.

The £15,000 Lesson: When Skipping Discovery Has a Receipt

The messaging problem on the dating app was not just a design issue. It had a price. The entire messaging section had to be rewritten from scratch, which cost approximately £15,000 in additional budget and two months of additional work. That figure represents the concrete, measurable cost of one decision to skip discovery on one component of one product.

It is worth pausing on that. The client had declined discovery to save time and money. The consequence was a cost larger than most discovery phases, and a delay longer than a discovery phase would have taken.

This is not an isolated pattern. According to Devtimate, projects that skip discovery are three to five times more likely to fail or exceed budget. The arithmetic on that is straightforward. A discovery phase that costs £5,000 and is skipped to save money creates the conditions for a £15,000 rewrite. The saving was nominal. The exposure was real.

What makes the dating app case instructive is that the failure was entirely predictable. A messaging system built without understanding the emotional and behavioural context of a trust-based product was almost certain to contradict that context. Discovery would have surfaced that contradiction early and cheaply. Without it, the contradiction was built in and fixed late and expensively.

When a client pushes back on the cost of discovery, compare it directly to the cost of a rewrite. A concrete number, like £15,000 and two months, carries more weight in that conversation than a principle.

What Refusing Discovery Costs the Client

The cost to the client is rarely just money, though the money is real enough. The deeper cost is the mismatch between what the client believes their product does and what it actually does for the people using it.

We worked with a property developer building a concierge app for high-rise properties. They came to us with a pre-formed idea and a suggested budget, wanting confirmation more than discovery. We convinced them to run the full process, including focus groups and user workshops. What those sessions revealed was that the product needed to be far simpler than anyone had envisaged. Features the client had considered central were dropped. The focus shifted entirely towards creating a human connection with the product rather than replacing systems that already existed in the building.

The result was a better product at a lower cost than the original plan. But the insight that made it possible only came from the discovery phase. The client's instinct about what to build was not wrong because they were careless. It was wrong because they had not yet spoken properly to the people who would use it.

We also worked on a product aimed at expats living abroad. The scope looked straightforward on paper. After the discovery phase, it became clear that what the market actually needed was very far from what the client had assumed. That realisation came early and cheaply. Building on the original assumptions would have produced something the market did not want, and the correction would have come much later and at much greater cost.

What Accepting Undiscovered Work Would Cost Us

There is a version of this argument that is purely about client outcomes, and then there is the version that is about us. They are both true, and it is worth being honest about both.

When we take on a project without discovery, we are agreeing to design and build against assumptions we have not tested. If those assumptions are wrong, which they sometimes are, we are the people who produced work that does not perform. The client may or may not understand why. The product that sits in the market carries no footnote explaining the conditions under which it was built.

On the grassroots football club app we worked on, the client insisted on combining several different apps into one product rather than launching a limited feature set and iterating. We warned early on that the budget would spiral and that they risked exhausting their funding before anything reached the app store. Those warnings were noted and set aside. The project ended with the entire budget spent, no product published, and the engagement concluded. The consequence of not following the advice was entirely predictable, and it was predicted.

Accepting work where we know the conditions make a good outcome unlikely is not neutrally professional. It puts our name on a result we did not have the conditions to achieve. Walking away from the social product was also, in part, protecting what we produce and what our name stands for.

If a client refuses discovery and you still want to find a way to work with them, be explicit in writing about what assumptions you are designing against and what the risk of those assumptions being wrong looks like. This does not replace discovery but it does clarify where responsibility sits if those assumptions prove incorrect.

When Research Becomes a Box-Ticking Exercise

The most difficult version of this problem is the client who agrees to discovery but has no genuine intention of acting on what it reveals.

The founder we worked with, the one with very strong pre-existing views about their product, agreed to the research process. They sat in on sessions, reviewed findings, and received our recommendations. But it was clear, early on, that the process was being treated as a formality. The founder's convictions about the product were formed before the research started, and those convictions did not shift when the evidence pointed elsewhere.

When we showed findings indicating that large numbers of their potential users did not want particular features and actively preferred alternatives, the founder dismissed the data. There was no hostile rejection. There was simply no movement. The findings were received and set aside.

We eventually walked away from that engagement. The product launched a year later, built substantially in line with the founder's original vision, and by all accounts did not find its market. The reasons the research had flagged were the reasons the product struggled.

Research done without genuine openness to its findings is a performance of due diligence. The cost is the same as skipping it, with the added cost of the time and resources spent on a process nobody intended to use.

What Walking Away Protects on Both Sides

Walking away from a project is a direct financial cost to us and, if the client finds another agency willing to proceed without discovery, it may produce no better outcome for them either.

But there is something the refusal protects that is harder to quantify. When we work on a product, we are putting our understanding of human psychology and emotional design into that product. That understanding only works when we have actually conducted the process that gives us the information we need. Without it, we are applying frameworks to a context we do not understand, and the result is unlikely to be the kind of work we produce at our best.

The table below sets out what each party protects when the discovery conversation is handled well, and what is at risk when it is not.

The genetics wellness app we audited illustrates the client side of this clearly. The brand promise was sound. The narrative of giving users a real inside look at how their body works, how it is ageing, and how they can improve, was compelling and well-constructed. But the product had been built primarily by developers who had stripped out the storytelling and narrative in favour of functional delivery. Users were not connecting emotionally with their data, and retention suffered.

The audit forced the decision to reintroduce narrative and give users a sense of identity within the product. The brand promise did not need to change. The product needed to catch up with it. Discovery at the start would have flagged this before it was built.

Conclusion

The project we walked away from was not unusual. The client was not careless or unreasonable. They had a product, a budget, and a clear idea of what they wanted to do with it. What they did not want was the phase that would have told them whether that idea was right.

Across the projects described in this article, the pattern is consistent. Discovery done well produces better products at lower costs than the original plan. Discovery skipped or performed without genuine intent produces rework, budget overruns, and in some cases products that never reach their market. The £15,000 rewrite on the dating app messaging system is the clearest single figure, but it is representative of a broader dynamic that plays out every time the process is shortcut.

According to Nielsen Norman Group, investing more time in discovery reduces the risk of project failure by 75%. That figure aligns with what we see across our own work. The projects that go wrong almost always involve some version of assumptions that were never tested before becoming the foundation of a build.

Walking away from the social product cost us a contract. Staying without the right conditions would have cost more, in time, in reputation, and in the quality of what we produced. The decision was not comfortable. It was correct. If you are about to start a product build and the question of discovery has not been settled properly, let's talk about your product before you begin.

Frequently Asked Questions