BA Playbook
Everyone Wants Something Different. What's the Actual Requirement?
Four stakeholders, four answers, one team waiting to build. Don't find the middle — find the requirement underneath their positions.
Surya · August 15, 2026 · 7 min read · 8 practices
For Business Analysts sitting in a room where every stakeholder wants something different, BAs tempted to average four positions into one watered-down requirement, Delivery leads who need a decision, not another round of consensus-chasing and Anyone who's heard four different answers to "what are we building?" in the same meeting.
You are in a requirements meeting.
Sales says:
“We need more flexibility.”
Operations says:
“We need tighter controls.”
Compliance says:
“We need fewer exceptions.”
Technology finally asks:
“Can someone just tell us what to build?”
Everyone looks at the BA.
This is not necessarily a bad meeting.
It may simply mean each stakeholder is protecting something different.
Your job is not to find the sentence everyone dislikes equally.
Your job is to discover:
What outcome are we trying to achieve, what constraints are real, and what trade-offs are we willing to make?
Here’s the situation
Imagine an e-commerce company changing its refund process.
Sales wants agents to approve refunds quickly.
Operations wants controls because refund mistakes are expensive.
Risk wants large refunds reviewed.
Technology wants one clear workflow.
So what is the requirement?
“Make refunds flexible”? “Require approval”? “Reduce exceptions”?
None of those is enough.
They are stakeholder positions.
The actual requirement sits underneath them.
1. LISTEN — what is each stakeholder really protecting?
Start by understanding each perspective.
Ask Sales: “What problem does more flexibility solve?” Maybe customers wait two days for simple refunds.
Ask Operations: “What risk are the controls protecting us from?” Maybe agents sometimes refund the wrong amount.
Ask Risk: “Which refunds actually need additional review?” Maybe only refunds above a certain amount.
Now the disagreement becomes more precise.
Sales may not want no controls. Operations may not want approval on everything.
Those were positions. The underlying needs may actually be compatible.
2. SEPARATE — need or proposed solution?
Stakeholders often describe solutions as requirements.
“Add an approval screen.”
“Give managers an override button.”
“Make everything automatic.”
Before accepting the solution, ask:
“What problem would that solve?”
Maybe “approval screen” really means: high-value refunds need independent review.
Maybe “override button” means: urgent cases need an exception path.
Maybe “automate everything” means: low-risk refunds should not wait for manual review.
Now you can design around the need, not the first solution someone suggested.
3. CONFLICT — where do the needs genuinely clash?
Write the needs plainly.
Sales: reduce customer waiting time.
Operations: reduce refund mistakes.
Risk: control high-value exposure.
Technology: keep the workflow maintainable.
Then ask:
“Where do these needs actually conflict?”
Perhaps everyone agrees refunds below a low threshold should be fast.
The disagreement exists only above that threshold.
A four-way argument just became one decision.
That’s BA work.
4. CONSTRAINTS — what cannot be negotiated away?
Some preferences are flexible. Some constraints aren’t.
Look for:
- regulation
- policy
- contractual commitments
- security
- budget
- architecture
- data availability
- delivery dates
- operational capacity
Suppose Risk says large refunds require independent approval because of company policy.
That is different from:
“We prefer managers to approve them.”
Make constraints explicit. Otherwise teams debate options that were never viable.
5. PRIORITISE — what matters most?
When everything is “critical,” nothing is.
Ask:
What is must-have? What creates the most business value? What prevents the biggest risk? What can wait? What happens if we don’t do this?
Rank outcomes rather than stakeholder seniority. For example:
- Prevent unauthorized high-value refunds.
- Reduce customer wait for low-risk refunds.
- Reduce manual work.
- Improve reporting.
Now design decisions have something to anchor to.
6. TRADE-OFFS — show what each option buys and costs
Don’t ask:
“Which option do you like?”
Show the consequences.
| Option | Gain | Cost |
|---|---|---|
| A — Approval for every refund | Strongest control. | Slower customer experience and more operational work. |
| B — No approval | Fastest process. | Higher error and fraud exposure. |
| C — Risk-based approval | Speed where risk is low, control where risk is high. | Below a low threshold → automatic. Middle band → agent approval. Above a high threshold → manager review. |
Now the team isn’t arguing about opinions.
It is choosing a trade-off.
7. DECIDE — don’t chase perfect consensus
A common BA trap is trying to make everyone completely happy.
Sometimes that isn’t possible.
The goal is not:
Everyone gets everything.
The goal is:
The right decision is made with the trade-offs understood.
If stakeholders cannot agree, identify the decision owner. Present:
problem → options → constraints → impact → recommendation
Then get a decision.
Consensus is useful.
Decision is essential.
8. DOCUMENT — turn the decision into buildable behaviour
Suppose the team chooses risk-based approval. Now make it precise.
Refunds below the low threshold may be processed by an authorized service agent without additional approval.
Refunds in the middle band require agent confirmation and reason capture.
Refunds above the high threshold require manager approval before processing.
Then define:
- user roles
- thresholds
- exceptions
- error behaviour
- audit requirements
- notifications
- reporting
- acceptance criteria
And don’t send:
“Please review the requirements.”
Send:
“We agreed on risk-based approval. Please confirm these thresholds, roles and exception rules.”
Specific confirmation produces better feedback.
What if the most senior stakeholder disagrees?
Seniority may determine decision rights. It does not remove the need to show consequences.
If the decision-maker chooses approval for every refund, document the impact:
Approval on every refund increases control but is expected to increase handling time and operational workload.
Your job isn’t to overrule the decision-maker.
It’s to make sure they can see what they’re choosing.
What if everyone is right?
Often they are.
Sales is right about customer experience. Operations is right about control. Risk is right about exposure. Technology is right about complexity.
The answer may not be picking one winner.
It may be:
thresholds · different flows · permissions · exceptions · phased delivery · configurable rules
Conflicting needs sometimes need better design, not compromise.
Common traps
Taking sides
“Business wants this, so Tech needs to build it.”
You become a messenger, not an analyst.
Jumping to solutions
“Let’s add an approval button.”
You may solve the wrong problem.
Agreeing to everything
Every stakeholder request becomes scope. The product becomes expensive and contradictory.
Ignoring assumptions
Everyone thinks they agreed because nobody stated what they assumed.
Chasing consensus forever
Meetings continue because nobody identifies the decision owner.
Forgetting the trade-off
Three months later:
“Why did we choose this?”
Nobody remembers.
Before you close the meeting
Ten checks
- The underlying business problem is clear.
- Each stakeholder's real need is understood.
- Proposed solutions are separated from needs.
- Genuine conflicts are visible.
- Constraints are documented.
- Must-haves are separated from preferences.
- Options and trade-offs are understood.
- The decision owner is clear.
- The chosen approach is documented.
- Requirements and acceptance criteria reflect the decision.
If you have ten yeses, Technology should no longer need to ask: “So… what exactly are we building?”
The takeaway
Stakeholder disagreement is often where the real requirement is hiding.
When Sales asks for flexibility, Operations asks for control, and Risk asks for fewer exceptions, don’t immediately compromise.
Ask what each person is trying to protect. Expose the real conflict. Make constraints visible.
Show the trade-offs. Get the decision.
The BA’s job isn’t to find the middle. It’s to find the requirement that best serves the outcome within the real constraints.
A good BA doesn’t make everyone agree.
A good BA makes sure everyone understands what was decided — and why.
A good BA doesn't make everyone agree.
A good BA makes sure everyone understands what was decided — and why.
Next time four stakeholders want four different things, don't look for the sentence everyone dislikes equally. Ask what each one is protecting, expose where the needs actually clash, make the constraints explicit, show the trade-offs — then get the decision made and written down.
Take this with you
Stakeholder Alignment & Trade-off Sheet
STAKEHOLDER ALIGNMENT & TRADE-OFF SHEET 1. OUTCOME What business problem or outcome are we trying to solve? 2. NEEDS For each stakeholder — what are they actually trying to achieve or protect? 3. CONFLICT Where do those needs genuinely clash? Don't confuse different wording with a real conflict. 4. CONSTRAINTS Non-negotiables: regulation, policy, security, budget, architecture, data, timeline, capacity. 5. PRIORITIES Rank must-haves and business outcomes. What happens if each need is not met? 6. OPTIONS / TRADE-OFFS Option A — Value: Cost / risk: Constraint fit: Option B — Value: Cost / risk: Constraint fit: Option C — Value: Cost / risk: Constraint fit: 7. DECISION Chosen option: Decision owner: Why this option: 8. MAKE IT BUILDABLE Translate the decision into rules, roles, thresholds, exceptions, data, audit needs and acceptance criteria. BEFORE YOU CLOSE THE MEETING [ ] Underlying problem is clear [ ] Needs are separated from proposed solutions [ ] Conflicts and constraints are explicit [ ] Priorities and trade-offs are understood [ ] Decision owner is clear [ ] Decision is translated into testable requirements
Get new playbooks first.