The Business Analyst’s Guide to Saying Yes — Always
In “The Business Analyst’s Guide to Saying No Without Saying No”, the author suggests tactful ways to decline requests.
Yet I’d argue that a Business Analyst (BA) should never say No at all.
Every stakeholder input — no matter how small or seemingly irrelevant — deserves to be acknowledged, documented, and made visible.
Why a BA Should Always Say Yes
A BA’s role isn’t to filter ideas at the gate — it’s to capture and contextualise them.
When a stakeholder proposes something, that statement carries business logic, pain points, or aspirations.
If it’s recorded, it becomes part of the collective intelligence.
If it’s dismissed, the insight is lost forever.
Yes First — Prioritise Later
“Yes” doesn’t mean immediate action. It means:
- “Yes, this is now part of our consideration set.”
- “Yes, it will sit in our backlog or options list.”
- “Yes, it will be prioritised along with others.”
Prioritisation — not conversation — is where No belongs.
“No” should only emerge after objective assessment, trade-off analysis, and consensus.
Every Input is a Data Point
Even the strangest suggestion might reveal an underlying pattern.
If 300 clients raise the same “unnecessary” feature, it’s no longer noise — it’s a signal.
But how would you know it’s the 300th if you rejected the first 299 and never documented them?
Visibility enables recognition, and recognition drives insight.
Keep It, Check It, Share It
A disciplined BA records every input, tags it, and shares it transparently.
It might never make it to delivery, but it remains traceable — a captured voice in the ecosystem of business needs.
In Summary
A professional BA doesn’t protect the project by saying No.
They protect it by saying Yes — then applying structured prioritisation to ensure that only appropriate Yeses turn into work.
Because every stakeholder insight is valuable until proven otherwise.