From Discovery to a Requirements

Discovery that never turns into a shared, written document is just a set of good conversations that nobody downstream can actually act on, however clarifying those conversations felt in the room at the time. The brief that closes out discovery does not need to be long, and making it long is one of the more common ways teams quietly undermine their own good work. It needs to answer, in writing, the five things covered earlier this week: who is actually affected, what problem this genuinely solves, what success looks like in specific enough terms to check later, what is fixed against what is flexible, and what is still honestly unknown, including what any time-boxed spike actually found once it ran.

Why One Page Is Usually Enough

The point of the brief is not thoroughness for its own sake, and a long document is not automatically a more useful one. A one-page brief that clearly states the five answers gives the requirements phase a foundation solid enough that it stops re-litigating decisions discovery already settled. Without it, requirements sessions drift back into the same problem-framing arguments that discovery was supposed to have already resolved, because nothing was ever written down for anyone to point back to.

This is also where discovery hands off cleanly into the prioritisation work covered a few weeks earlier in this series. A brief that states clearly what is fixed and what is flexible gives the MoSCoW conversation a genuine starting point, rather than a blank page everyone fills in from memory and instinct. A brief that names the real success criteria gives the eventual Kano conversation about which features matter and why something concrete to test against, instead of a vague sense of what customers might appreciate.

Getting Real Sign-Off, Not Just a Skim

The sign-off moment on this brief matters more than it looks, and treating it as a formality is where a lot of otherwise good discovery work quietly loses its value. A stakeholder who has genuinely read and agreed to a written problem statement in week one is a very different conversation partner three months later from one who only discovers, deep into requirements or even development, that their own understanding of the goal was never actually the one the team had been building toward.

Getting real engagement rather than a rubber stamp usually means asking one direct, specific question rather than simply circulating the document and hoping for a reply. Something close to, 'if I asked you right now to describe the problem this project solves in one sentence, using only what's in this brief, would that sentence match what you'd have said before we started discovery? A genuine yes is worth having on record. A hesitant answer, or a version that reveals a gap, is exactly the kind of thing worth surfacing now, in a brief that costs almost nothing to revise, rather than three months from now inside a requirements document that everyone has already built work on top of.

This is the same discipline covered in the Managing Up series a few weeks back, applied at the start of a project rather than partway through one. Surfacing a real disagreement early, while it is still cheap to resolve, protects trust far more than discovering it late ever could, and it is a far easier conversation to have than the one that happens after a stakeholder has quietly watched a project head somewhere they never actually agreed to.

Where This Week Leaves You

• On Monday, we named the actual cost of skipping discovery, and the trap of believing a project's problem is already settled just because a solution feels obvious.
• Tuesday gave you the five things a real discovery phase has to answer, no more and no less.
• Wednesday covered walking a stakeholder back from a proposed solution to the real problem underneath it, without ever making them feel dismissed.
• Thursday gave you a way to handle genuine unknowns honestly, through a time-boxed spike, rather than guessing or stalling.

And today closes the loop: none of that work matters unless it becomes a written brief that stakeholders have genuinely agreed to before requirements work begins.

The next time a project starts with someone saying we already know what we need, let's just get building; this week's toolkit is the answer worth having ready. Not a lecture about process for its own sake, a short, specific set of questions that costs a few days now and protects months of work later.

It is worth being realistic about how this actually lands the first few times you try it inside an organisation that has never run discovery this deliberately before. Some stakeholders will find the extra step genuinely useful immediately, particularly the ones who have personally lived through a project that failed for exactly the reasons this week described. Others will experience it as friction, a delay in front of the building they actually want to see happen, and that reaction is worth meeting with patience rather than defensiveness. The case for discovery is not made by insisting on it. It is made the first time a two-day discovery conversation catches a disagreement that would otherwise have cost two months, and that moment tends to convert sceptics far more effectively than any explanation of the framework ever could.

Keep the brief itself simple enough that writing one stops feeling like a burden. A template with five short headings, filled in honestly, does more good sitting in front of a stakeholder for sign-off than an elaborate document that takes a week to produce and that nobody outside the project team ever fully reads. The goal was never the document. It was always the shared understanding the document exists to capture and protect.

Finally, I understand that a five-day series can make a process sound heavier than it actually needs to be in practice. So, strip this week down to its smallest useful version and it comes down to a handful of habits: ask who else is affected before assuming the room is complete, write the problem down as a problem rather than a feature, walk back a proposed solution with one grounding question before accepting it, time-box the genuine unknowns instead of guessing at them, and get a real, specific yes on a short written brief before requirements work begins. None of that requires new software, new authority, or permission from anyone. It requires deciding to do it, on the next project, before the building starts.

Go out and be successful.

Oluwatosin Ogunkoya  ·  Flotog BA Insights  ·  1:1 mentoring and coaching for BAs at every career stage  ·  www.flotogbainsights.com

NEXT WEEK

Facilitation Skills: Running a Workshop That Actually Produces Decisions - Turning a room full of stakeholders into a room that leaves with real, committed decisions.