Every Business Analyst has been in the blank canvas discovery session. You schedule the kickoff, open a fresh document, and ask the foundational question: what do you need this system to do? The response is usually a mix of contradictory feature requests, vague aspirations — "we need it to be intuitive and scalable" — or the honest admission: "I'll know it when I see it."
The mistake is expecting something different. Stakeholders almost never arrive knowing what they want, and treating that as a failure of preparation misses the point. They know their pain points, their daily frustrations, and their operational goals. They don't know how to translate those human realities into structured software requirements. That translation is the BA's job — and it starts with asking different questions.
Treat Feature Requests as Symptoms
When stakeholders don't have a clear picture of what they need, they tend to reach for what they've seen elsewhere. "We need a dashboard with AI-powered analytics." "We need something like what [competitor] built." These aren't requirements — they're guesses at solutions to problems they haven't fully articulated yet.
The more productive move is to treat every feature request as a symptom and work backwards to the underlying condition. When someone says they need a custom reporting tool, the useful question isn't "what should the report look like?" It's "what decision are you trying to make that you currently can't?" When they say the system needs to be faster, the useful question is "where specifically are you losing time, and what does that cost you?"
This reframe — from feature inventory to friction mapping — keeps the early conversation anchored in real operational pain rather than in imagined solutions. Features proposed without a grounding problem tend to expand scope without adding value. Friction documented precisely tends to produce requirements that are smaller and more accurate than the features that were originally requested.
Deconstruct Yesterday, Not the Abstract Process
People are poor at summarising abstract processes and excellent at describing specific things that happened. When a stakeholder struggles to articulate how a workflow operates, the fastest path to clarity is usually to stop asking about the process and start asking about yesterday.
Walk them through a real transaction from the previous day. Have them share their screen and complete a task live. This shift from description to demonstration surfaces things that never appear in a formal process walkthrough: the manual steps that "everyone just knows," the spreadsheet open in a second browser tab because the system doesn't track a particular field, the email sent at the end of every cycle to compensate for something the software doesn't do automatically.
These workarounds — what I think of as Shadow IT — are where the real requirements live. A sticky note with login steps for a system that should have SSO. A shared Excel file that pre-processes data before it's entered into the official tool. A recurring manual email that exists because a trigger nobody built. Each one is a requirement that the stakeholder hasn't thought to mention because they've stopped noticing it. Watching someone actually do the work makes it visible.
Start Ugly on Purpose
"I'll know it when I see it" is a psychologically honest response, not an evasion. People react to concrete visuals in a way they simply can't react to abstract descriptions. The instinct to show stakeholders something early is correct — the mistake is showing them something polished.
A high-fidelity mockup that looks finished invites the wrong kind of feedback. Stakeholders focus on colours, fonts, and labels rather than on whether the workflow logic is right. A rough wireframe — blocky, grey, clearly not designed — signals that the content is provisional, which frees people to engage with the underlying structure rather than the surface presentation.
The most reliable technique I've found is to present a workflow with something deliberately missing or slightly wrong. Stakeholders who were completely silent during a text-based review will immediately speak up to correct a visual error. Reaction is faster than reflection. A wireframe they can push back against generates more useful signal in ten minutes than a requirements document they read and approve in thirty.
Build Scope Discipline into the Discovery Process
Ambiguity in stakeholders produces a predictable second problem: scope inflation. When people aren't sure what they need, they tend to want everything, framed as "just in case." A useful discovery process doesn't just capture requirements — it creates the conditions for prioritisation decisions that would otherwise be deferred until they're much more expensive to make.
The most effective intervention is to introduce trade-off conversations early. When a new requirement surfaces, mapping it against what it would displace — "if adding this delays the core workflow by three weeks, is it still a day-one priority?" — forces a decision that abstract priority ratings never do. Letting stakeholders mark every item as high priority is the same as having no priorities at all. Forced ranking, where no two items can share a position, produces uncomfortable conversations, and those conversations are precisely the ones that prevent a six-month project from becoming a twelve-month one.
The Investigative Posture
Discovery done well is not passive. It is not transcribing a wishlist or facilitating a brainstorm and hoping something coherent emerges. It is an active, investigative process — closer to diagnosis than to note-taking.
The shift from order-taker to guide happens when you stop asking stakeholders what they want and start leading them through an analysis of what they actually do. The ambiguity doesn't evaporate because stakeholders suddenly become clearer. It evaporates because the right questions, asked in the right sequence, make clarity inevitable. That's the work — and it's the part of the BA role that no template or tool replaces.
