Let's stop pretending we can skip project discovery phases

We’ve seen it happen too many times. You’ve invested in a new app or website for your business. The team is excited and everyone’s ready to launch. Then six months in, your budget has been blown, key features don’t work the way users need them to, and the project that was supposed to transform your business is now back down at the foot of the mountain.

But the problem isn’t bad design or poor code. It’s much simpler: you started building before you knew what to build.

Back in the early 2000s, we did the same thing. We’d come out of a client meeting and jump straight into design and development. We’d ask all the obvious questions, “who’s your target audience?”, “what does success look like?”, but we were only skimming the surface. We weren’t really digging into what their users actually needed. We had no idea what problems we needed to solve.

Our clients loved what we delivered. But a few months down the line, they began to realise what features their users actually wanted. And adding these in post-launch would cost them more money. The smiles turned to frustration. The excitement turned to firefighting.

It was time to take a step back and change our approach. Instead of jumping into design and build, we slowed down to understand. We asked tougher questions. We mapped out future needs. We analysed data. We did our research. We stopped treating discovery phases as a nice-to-have and started treating it like an insurance our clients had to have.

Around 70% of digital products fail to hit their desired targets according to research from McKinsey. Companies wasted tens of thousands of pounds designing and building features that their users simply didn’t want. And the cost of fixing those problems post-launch can be up to 100 times more expensive.

This isn’t about adding time to projects. It’s about not wasting the time you’ve already got. So let’s talk about why discovery phases aren’t just valuable. They are a must-have.

Skipping discovery phases is an industry-wide problem, affecting projects big and small. And it’s leaving some interesting stories in its wake.

Remember Quibi? You’ve probably never heard of them. And that’s exactly the point. In 2020, former Disney Chairman Jeffrey Katzenberg and Meg Whitman, former HP CEO, launched a mobile-first streaming platform for premium short-form video. They had around $1.75 billion in funding, and an impressive list of A-List celebrities like Dwayne Johnson, Chrissy Teigen, and Steven Spielberg behind them to create the content.

But six months later, they shut down.

Quibi didn’t fail because of bad execution or poor timing. They failed because they didn’t validate that anyone wanted what they were building. They spent over $1 billion creating content before even asking their audience a single question. They assumed users would pay for paywalled videos when YouTube and TikTok were already delivering free, sharable content. By the time they realised their users wanted social features rather than premium isolation, they had already burned through nearly $2 billion.

Another example is Google Wave, an ambitious project launched back in 2009 that survived just over a year before being shut down. Why? Because Google didn’t figure out what users needed. Wave was billed as a groundbreaking new communication platform that would reimagine email by combining real-time collaboration, instant messaging, and document editing in one place.

But Google skipped the vital discovery project phase and brought a product to the market with no foundation to give users the answers to their problems and no clear value proposition. They made assumptions without validating them with users, which resulted in a product that users simply didn’t need. And, as it turns out, users don’t want a platform that merges all their communications into one place.

One last example is Panels, an app from YouTuber Marques Brownlee. The app was built on a simple idea – premium subscription phone wallpapers, and launched in September 2024. The app was born from comments on his videos, often pointing out how nice his wallpapers were.

Are comments on videos enough information to warrant building an app? No. In a world where background images are readily available for free on platforms like Unsplash and Pexels, it turns out nobody wanted to pay $50 a year for a subscription to get “premium” ones regularly.

Panels closed down in December 2025, and it ultimately boils down to skipping that key discovery phase. If the Panels team had conducted proper user research, they would have found out before even starting to write a line of code that there was simply no market for a premium subscription wallpaper app.

It’s easy to sit here and analyse failed digital product launches, but why does it keep happening? And to projects funded by big and small companies?

Pressure to move quickly

Key stakeholders are driven by results. They want to see tangible output from their investment. Discovery can feel like standing around when everyone wants to sprint. So teams often skip it and dive straight to design and build, only to discover six months in that they’re building the wrong thing. And what they end up missing is the key foundational information that underpins the entire project.

Discovery gets mistaken for delay

Nobody wants project delays. And stakeholders can be sensitive to this. They often see the research phase as a stalling tactic rather than essential groundwork. This is a dangerous misconception. Skipping discovery phases isn’t efficient; it’s a false economy that compounds into blown budgets and wasted time.

Activity gets confused with progress

Wireframes feel like progress. Code feels like progress. Research? That just feels like more meetings. Stakeholders confuse visible activity with actual value, ignoring the fact that building the wrong thing quickly is worse than building the right thing thoughtfully.

The result? Teams rush into execution, only to spend months, and tens of thousands, correcting avoidable mistakes.

The most obvious cost of skipping a discovery phase is the failure of the project. But that’s not the case with most teams. There are more discreet, invisible costs involved. Most teams finish their project, but they finish with something that cost them twice as much, took significantly longer than it needed to, and doesn’t actually solve all their users’ problems.

These are the invisible costs. The ones that don't show up until you're deep in development. And by then, they've already compounded.

Stakeholder misalignment

Everyone thinks they're on the same page. They're usually not. The managing director has one vision, the project manager another, and the development team a different vision again. And these differences all stay hidden during the honeymoon phase of the project, the phase where everyone’s excited and inspired. But when real decisions need to be made, everything explodes. You’re three months in, the budget half spent, and stakeholders are arguing over features that should have been agreed on from day one.

Research backs this. Lack of senior management involvement in projects is the primary reason that 33% of projects fail. And 78% of project managers say they want stakeholders to be more involved and engaged. A clear sign that plenty of projects suffer from a lack of alignment.

Technical surprises

When you skip discovery phases, you fail to uncover the technical landmines until it’s too late. That seemingly easy integration you thought would be a quick win? It needs bespoke middleware to work. That feature the client requested? It doesn’t work with the platform architecture. These kinds of discoveries when a project is in full motion mean more than just delays; they force costly reworks and scope creep.

Fixing these kinds of issues during development phases can cost up to six times more than catching them during a discovery phase. 15 times more during that testing phase. And post-launch? Up to 100 times the cost.

Unvalidated users need

Around 80% of software features are rarely or never used. Why? Because teams build in functionality they assume the user wants based on internal logic and stakeholder preference, not actual user research. And this results in bloated products full of features that nobody asked for. As for the things users genuinely need, these get deprioritised or forgotten completely.

If you’re a startup, this can have detrimental effects on the business. Around 42% of startups fail because of “no market need”. It’s the number one cause of failures according to CB Insights’ report, which analyses nearly 4,000 failed startups. Teams assume, users needs aren’t met, and money gets wasted.

Scope creep

Requirements are often vague without a discovery phase. And vague requirements mean endless clarification needs during build. Every clarification then opens a door to a new idea, which in turn shifts priorities and even “while we’re at it” additions. Before you know it, your project has ballooned into a bloated mess that’s missed the deadline and blown the budget.

Research from PMI suggests that organisations can avoid budget loss and project failure by investing in communication and alignment work upfront, which is exactly what discovery phases provide.

The real cost

These issues each feed into one another. Misaligned stakeholders result in woolly requirements. Woolly requirements create scope creep. Scope creep leads to technical limitations. Technical limitations force rework. Rework burns through budget. Suddenly, your project is 45% over budget. Research from McKinsey shows this to be the average budget overrun on large-scale digital projects.

While discovery phases don’t mitigate all the problems, they do help to surface them before they get expensive. And that’s the difference between a successful project and one that can barely make it across the finish line.

Agencies all work in different ways, ask different questions, and present their findings differently. So how do you know if yours is doing it properly? Let’s break it down:

A proper workshop, not just a kick-off call

A good discovery workshop shouldn’t feel like a glorified briefing session. It’s where your agency digs into the detail, like your business goals, your users, your constraints, and any assumptions you have. By the end of it, they should understand your problem as well as you do. If they’re not asking uncomfortable questions, they’re simply not going deep enough.

Research that goes beyond your brief

Your agency should be doing the heavy lifting you have time for. That means market research, competitor analysis, and most importantly, user research. This is where assumptions are validated or killed. If your agency is skipping straight ahead to a solution without speaking to real users, that’s a huge red flag.

Analysis that rules things out

Proper discovery doesn’t just generate ideas, it eliminates them, too. By the time your agency comes to present their findings, they should be able to confidently tell you what will and won’t work and why. If everything is still on the table, the analysis hasn’t been rigorous enough.

Evidence-backed solutions

Any proposed solutions should be connected to and backed by the research. Every feature, design decision, and technical choice should have a valid reason behind it. If your agency can’t explain why something’s included, it probably shouldn’t be.

Genuine alignment, not just sign-off

Discovery works if everyone’s genuinely on the same page, not just nodding along. This is the time to discuss disagreements, clarify priorities, and make sure leadership, and stakeholders, project managers, and delivery teams share the same vision. Skipping this step is how you end up with arguments three months in.

Measurable success metrics

Success needs to be measurable. Not vague goals like “better user experience”, but real numbers. Conversion rates, task completion times, order values, support ticket reductions. If you can’t measure it, you can’t prove the project worked.

That's the theory. Here's what it looks like in practice.

Let’s look at Wightlink, an award-winning ferry service connecting over 4.3 million passengers a year between the Isle of Wight and Hampshire.

Their website is enormous. It features complex booking functionality, multiple user types, time-sensitive travel decisions, and a user base with varied needs. From daily commuters to holidaymakers. A project of this scale can’t afford assumptions.

So, we didn’t assume anything

Before we even opened Figma or started writing a single line of code, we ran an in-depth discovery phase with the team at Wightlink. We also ran workshops during actual ferry crossings to understand how their customers interacted with the service. We asked what we thought were obvious questions: does this page layout work? Is the price displayed clearly? Are booking tools prominent enough? Turns out the answers weren’t so obvious after all.

What we discovered was invaluable

We discovered different user groups had very different needs. Daily commuters needed speed. Holidaymakers needed reassurance and detail. Staff needed CMS functionality that streamlined their workflow. None of this was insight we could have guessed. It came from asking and listening.

Our research directly informed both our UX decisions and technical architecture. We validated every feature to ensure it was there for a reason, not because we thought it was needed. Every design decision connected back to real user insight and behaviour, not our own assumptions. The outcome is a website that actually serves users properly because we knew what their users needed before we started design and build.

It’s easy to say in hindsight, but we know if we’d skipped the discovery phase and gone straight into design, we would have built a website that wasn’t what users wanted or needed. And the project would have become another expensive statistic.

Instead, it’s a case study in what happens when you invest in discovery upfront.

You can read more about how we helped Wightlink.

Ensuring discovery phases happen, and happen properly, can be a bit daunting. It’s often difficult to justify the expenditure, so here are some tips for getting it across the line:

Pitching discovery to leadership

Most projects run aground here. Key stakeholders and decision-makers see discovery phases as a delay, not an investment. To make it smoother:

• Make sure you position the discovery phase as risk mitigation, not just research. Leadership tends to understand the value of insurance.
• Throw stats their way. Tell them fixing the problems post-launch could cost up to 100x more than catching them during discovery. And use case studies like Quibi and Panels to demonstrate the value of user research and insight.

When budgets are tight

The luxury of a discovery phase isn’t an option for everyone, especially when it comes to project budgets. If you’re worried about budget:

• Opt for a minimum viable discovery. This should cover a stakeholder alignment workshop and at least one round of user validation. This helps to reduce the risk when budgets don’t allow for a full-blown discovery phase.
• Prioritise the riskiest assumptions first. If you know you’re assuming key features, validate those before anything else. You can shut down unfounded ideas before they get too set in.
• Approach discovery proportionately. Cut your cloth to suit, and carry out a discovery phase that both fits your budget and your project needs.

Red flags to watch out for

Keep an eye on any red flags as you work through the project. Self-diagnose as your project progresses if you start to see:

• Disagreements between stakeholders relating to priorities three months in.
• Knee-jerk requests, and “while we’re at it” asks becoming constant.
• Unanticipated technical blockers, like platforms that don’t support what your users need.
• Features built on opinion rather than evidence.

Get outside help

If you find your project going off the rails, it’s time to get external help. This is key when:

• Internal teams are too close to the problem to be able to work out a solution.
• You need specialist skills and insight that you don’t have in-house.
• An external perspective on the problem can challenge assumptions that internal politics won’t allow.

Settling into basecamp before starting the climb is key to a project’s success. Putting the time, effort, and investment into the discovery phase is insurance. You, your team, and your stakeholders can work through your project knowing you’re creating a product that’s going to meet your users’ needs, as well as the business’s own goals and KPIs.

Discovery isn’t a nice-to-have or a box-ticking exercise. It’s the difference between a project that gets stuck halfway up the mountain and a project that reaches the summit. So, before you get stuck into your next big build, take a step back. Make sure the groundwork has been done properly. No corner cutting, no holding back. And if you’re unsure whether your agency is carrying out a thorough discovery phase, download our free checklist to see what they are or aren't doing right.