How business analysts can influence stakeholder decision-making during the discovery phase

In every software project, the discovery phase is the foundation. As the business analyst, this is your first opportunity to hear the story, read between the lines and make sense of processes, hidden expectations and politics. All at once. This is where the decisions are made that determine whether the solution you have created to help the stakeholder will actually work, or if it will simply exist.

As Steve Jobs famously said: "A lot of times, people don't know what they want until you show it to them." 

And so the focus is required not just on gathering requirements, but also on how we architect alignment and be the mirror that shows the business what it actually needs to succeed.

During the discovery process, we rarely hear one version of the truth, but rather various perspectives. This is a classic example of the Rashomon effect, whereby the same event is recounted in contradictory ways by different people.
 

• Sales wants zero friction.
• Marketing wants granular data attribution.
• Product wants meaningful insights. 
• Tech wants to avoid overengineering something that no one will use.
• Operations wants process discipline.

As a Business Analyst, your role is to identify the Pareto Principle (the 80/20 rule) in these conversations. Identify the 20% of features that will solve 80% of the collective pain points. By focusing the group of project stakeholders on this 'vital few', you can influence them to abandon low-value, high-complexity requests at an early stage. This translates fragmented experiences into one coherent operating model that the organisation can actually execute. And that requires influence.

Before you can influence decisions, you need to understand who actually makes them. A well-defined RACI (Responsible, Accountable, Consulted, Informed) matrix is not just a governance formality; it is a map of influence.
 

• Who is accountable when trade-offs are required?
• Who believes they are accountable, but technically are not?

If your RACI matrix is robust, you can reference it with confidence when alignment wavers: 'Based on our RACI, this decision sits with X. Let's align there.' Clarity reduces friction, which is the enemy of discovery.

To help stakeholders move from 'what I want' to 'what we need', use Amazon’s Working Backwards process. Rather than starting with a list of technical features, begin by considering the end customer experience.
Amazon uses a mock press release and frequently asked questions document to force clarity before a single line of code is written. In your discovery workshops, challenge stakeholders to describe the project's launch.
 

• What is the number one customer problem that we solved?
• What are the three most important benefits?

When a stakeholder pushes for a complex, niche feature, ask, 'Does this belong in the press release?' If not, the Working Backwards logic enables the group to self-correct and de-prioritise it, meaning you don't have to play the 'bad guy'. The feature will remain in the project backlog.

Not every stakeholder needs the same level of detail. Once your RACI is defined, tailor your communication plan:
 

• Executives want risk, value, and timeline clarity.
• Functional leads want process impact.
• Technical teams want feasibility and constraints.

And so, influence is rarely loud, but usually structured. When your updates reflect what matters to each specific audience, your credibility grows.

Alignment calls during the discovery process are your strategic moments. This is where you:
 

• Present synthesised findings.
• Call out conflicts between teams.
• Highlight dependencies and constraints.
• Propose options.

Influential business analysts don't just ask, 'What do you want to do?' They use Option-Based Framing. They say:
'To achieve the goal in our PR/FAQ, there are two options. Option A is faster, but it requires manual data entry. Option B is automated, but it delays the launch by a month. I recommend Option A to hit our Q3 targets. Does anyone see a blocker?'
By presenting the decision as a choice between defined trade-offs, you can lead stakeholders towards a logical conclusion rather than an emotional one.

Tensions are inevitable. Sales will hate new fields; Marketing will demand them. Instead of refereeing a fight, use a "Pre-Mortem"—a technique popularised by psychologist Gary Klein. Ask the group: "Imagine it’s six months from now and this project has failed because the data is useless. Why did that happen?" This forces stakeholders to stop protecting their turf and start protecting the outcome.

The Stockdale Paradox suggests you must retain faith that you will prevail in the end, while simultaneously confronting the most brutal facts of your current reality.
If a requirement is technically impossible within the budget, say so. Transparency during discovery is a trust deposit and stakeholders are far more willing to compromise when they feel informed rather than blindsided during User Acceptance Testing.

By the end of discovery, you handover a social contract disguised as a requirement document.  When this is achieved, your developer team receives requirements that are:
 

1. Vetted (The "Why" is clear).
2. Validated (The "Who" has signed off).
3. Feasible (The "How" is possible).

This is the difference between simply building a feature and delivering actual value. By anchoring discovery in logic and outcomes, you influence decision-making through structure rather than emotional hijacking.