Why Discovery Shouldn’t Just Be a Tick-Box Exercise

“We’ll just do a quick discovery—tick the box, move on.”

Heard that one before? Me too. And every time, a small part of me wants to flip the meeting table.

Discovery is supposed to be the part of a project where we slow down and think. It’s the opportunity to get under the skin of a problem—to understand people, processes, and pain points before diving headfirst into solutions. But more often than not, it gets treated like admin: book a workshop, fill in the form, move on.

It’s not that people don’t believe in discovery. It’s just that delivery pressure creeps in. There’s often a sense that we need to “get moving” or show quick progress. The irony? Rushing discovery usually guarantees delays later on.

When discovery is reduced to a performative exercise—something to “get out of the way”—you end up with shaky foundations. That’s when you see scope creep, confused teams, missed requirements, and stakeholders quietly wondering if this is going to be yet another expensive disappointment.

For example, the discovery phase was squeezed into a single workshop on one project, largely because the client “just wanted to see something working.” A month later, the delivery team realised the solution wouldn’t support one of the core business processes—it was incompatible with legacy data formats that hadn’t been mentioned. Cue a full rebuild, delayed timelines, and a very red-faced project sponsor. A two-hour technical conversation during discovery would have saved six weeks of rework.

So what should discovery actually be? Let’s unpack that.

What Discovery Should Be

Discovery is about curiosity, not checklists. It’s not just a meeting. It’s a mindset.

Done properly, discovery gives you:

• A clear understanding of what problem you're trying to solve (and for whom)
• A shared view of success
• Clarity on constraints, blockers, and blind spots
• Early alignment across tech, business, and users
• Tangible artefacts like process maps, prioritised pain points, validated user personas, and even early architectural options

It’s your chance to ask better questions:

• What’s really driving this?
• What does success feel like to different stakeholders?
• Who’s missing from the conversation (and why)?
• What’s working well that we don’t want to break?

It’s also a chance to listen—properly. Not just to what people say, but how they say it. To pick up on hesitation, friction, or excitement. To notice when someone’s “requirement” is actually masking a fear or frustration.

And when discovery is collaborative—when clients and delivery teams sketch together, map processes, imagine futures—it builds trust. People feel heard. And that shows up later, when tough decisions need to be made.

As Solution Architects, this is our time to shine. We’re not just there to take notes—we’re there to translate ambiguity into clarity, to surface assumptions, and to connect the dots between business needs and technical reality. Discovery is where we lay the groundwork for everything that comes next.

The Hidden Costs of Skipping Real Discovery

But is it really necessary? Would it be so bad to skip right over Discovery? Here’s what usually happens when discovery is treated as a formality:

• Rework. Features get rebuilt because the initial requirements were vague or misunderstood.
• Misalignment. Delivery teams think they’re solving Problem A, while stakeholders are expecting a fix for Problem B.
• Scope bloat. With no clear “north star,” everything seems important. The backlog becomes a wishlist.
• Disengagement. When discovery isn’t meaningful, stakeholders tune out. By the time you hit delivery, no one’s paying attention—and getting decisions takes forever.

All of these issues are avoidable. But only if you take the time to understand the problem properly, together.

And yes—budget pressure is real. Sometimes it feels like every hour spent on discovery is an hour not spent “building.” But skipping it doesn’t save time. It just moves the cost downstream, where fixing things is harder, more public, and more expensive.

Signs You’re in a Tick-Box Discovery

Not all discovery efforts are created equal. Sometimes, what looks like a structured start is really just going through the motions. Here are a few telltale signs that your discovery might be more checkbox than catalyst:

• Stakeholders say, "Just show us the system."
• The discovery is a single workshop with no follow-up.
• You leave with a backlog, but no shared vision.
• Requirements are framed entirely in terms of features, not outcomes.
• Users are spoken about, not with.

If you see these signs, pause. You might be performing discovery, not doing it.

How to Make Discovery Meaningful

Once you’ve spotted the warning signs, the next step is knowing how to course-correct. Meaningful discovery isn’t about doing more—it’s about doing it with intent. Here’s how to turn it into something truly valuable:

• Ask better questions. Go beyond "what do you want?" Try "what would make your job easier?" or "what do you dread doing each day?"
• Focus on outcomes. Anchor the conversation in what success looks like—not just what’s being built.
• Use co-design methods. Map journeys. Sketch interfaces. Invite people to participate, not just observe.
• Keep it iterative. Discovery isn’t one-and-done. New questions will emerge. Make space for them.
• Leverage your toolkit. Use tools like stakeholder maps, service blueprints, low-fidelity prototypes, and early architectural diagrams to drive clarity.

Above all, approach discovery with humility. You’re there to learn, not prove.

Final Thoughts

Discovery isn’t just the first phase of a project. It’s the compass for the entire journey.

When done well, it unlocks clarity, trust, and momentum. When rushed or skipped, it sets traps that spring months later—when fixing things is harder, costlier, and messier.

If you're not investing in discovery, you're investing in rework. Choose wisely.

So don’t tick the box. Lift the lid. Get curious. And give discovery the space it deserves...It might just be the smartest hour you spend on the whole project.

But there's more....

In my next article, I’ll explore what makes discovery different when you’re working on the Microsoft Power Platform—why the pace, flexibility, and user proximity of low-code delivery demand a slightly different approach from traditional enterprise projects.