The Five Things Discovery Actually Has to Answer

Discovery does not need to answer everything knowable about a project before requirements work begins. Trying to do so is exactly what turns a two-day exercise into a two-month one that quietly stalls everything sitting behind it. It needs to answer five specific things, honestly, and stopping there is a discipline in itself. Each one is a genuine question with a genuine answer, not a section to fill in for the sake of completeness.

Who Is Actually Affected

The obvious sponsor in the room is rarely the only person the project touches, and missing the less obvious ones is one of the most common and most expensive discovery gaps. A finance system change affects finance, obviously, and also whoever in operations reconciles against it monthly, whoever in customer service fields the calls when something looks wrong, and whoever in compliance has to sign off that the change meets a regulatory obligation nobody in the original conversation thought to mention. Discovery's job here is not to interview every person in the organisation. It is to ask, deliberately, who else touches this process before deciding the stakeholder list is complete, rather than assuming the people already in the room represent everyone who matters.

This connects directly to the problem covered a few weeks ago in this series: an approval step drawn in the wrong lane on a process map, because the person mapping it never asked who genuinely owns the decision. The same blind spot causes the same damage here, just earlier in the project, before a single requirement has been written.

The Problem, Stated as a Problem

What problem this is genuinely solving needs to be written as a problem, not a feature, and the difference between those two things is where most discovery documents quietly go wrong. A feature statement sounds like 'build a self-service portal'. A problem statement sounds like 'customers currently wait an average of four days for account changes that should take minutes, because every request routes through a single overloaded team'. The feature is one possible answer to the problem. Writing the problem down first, before anyone commits to the feature, leaves room to discover that a different answer might actually serve it better, and it gives the whole team a shared target to check any proposed solution against later.

What does Success look like Success needs the same specificity. What success actually looks like has to be concrete enough that, months later, a specific person could look at a specific number and say plainly whether it happened. 'Customers see it as easier' is not that, but 'average processing time drops from four days to under one hour' is. The vague version feels safer to write in the moment and is almost useless six months later, when someone genuinely needs to know whether the project delivered.

What is Fixed, What is Flexible,

What is fixed and cannot move, against what is flexible and can be negotiated, is the constraint conversation almost every project needs and almost none has explicitly, until a deadline crisis forces it out into the open under much worse conditions. A launch date tied to a regulatory deadline is fixed. A launch date chosen because it sounded like a reasonable quarter is flexible, whatever confidence it was stated with in the original kickoff meeting. Naming which is which before requirements work begins means a scope conversation later has an honest starting point rather than a fight about whether something was ever really fixed at all.

What is Genuinely Unknown

And what is still genuinely unknown deserves to be named honestly rather than quietly assumed away, which is the single hardest of the five to do well, because admitting uncertainty out loud in a planning meeting can feel like admitting the team is not ready. It is closer to the opposite. A team that names its real unknowns clearly is a team that can plan around them deliberately. A team that assumes them away is a team that will discover them anyway, later, at a worse moment, dressed up as a surprise rather than a known risk. Thursday's article covers exactly how to size and handle this category once it has been named.

It is worth being honest about how these questions actually get answered in practice, because the answer is rarely a single meeting where everyone politely agrees on all five in order. Real discovery is closer to a short series of focused conversations, sometimes with different combinations of people depending on which question is being tested, followed by the person running discovery pulling the answers together and checking them back against the group. The value is not in the meeting format. It is in making sure each of the five questions actually gets a specific, checkable answer rather than a vague nod that everyone assumes means agreement.

A useful habit here is to write a one-sentence draft answer to each of the five questions before the discovery conversation even starts, based on whatever you already know, then bring that draft into the room specifically to be challenged. A draft gives people something concrete to react to, which produces sharper, faster disagreement than an open question ever does. Most people find it far easier to say that's not quite right, here's what I'd change than to generate a full answer from nothing in front of a group, and the draft approach uses that tendency deliberately rather than fighting against it.

This is worth doing even when the answers feel obvious going in, which is exactly when the exercise tends to matter most. The projects that skip discovery entirely are rarely the ones where everyone admits confusion. They are the ones where everyone individually feels certain, and nobody has tested whether their separate certainties actually point at the same answer. Five short questions, each with a specific answer written down and checked against the room, is a small amount of friction against a failure mode that otherwise stays completely invisible until it is expensive.

None of these questions needs a perfect answer on the first pass, and waiting for perfection before writing anything down is its own quiet way of never finishing discovery at all. A reasonable draft, tested against the room and revised once, beats an unstarted attempt at a flawless one every time. The whole exercise is meant to move fast, not to produce a document nobody could ever improve on. Friday closes the week with exactly how these five answers turn into the brief that carries this work forward into requirements.

Go out and be successful.

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

TOMORROW

Framing the Problem Before the Solution

Catching the stakeholder who arrives with a solution already decided, and finding the actual problem underneath it.