Every time you hear “the business wants this,” three things are almost certainly true: no single person owns the decision, the real trade-offs haven’t been surfaced, and the project is about to drift. In this episode of the Better Business Analyst Podcast, Benjamin Walsh unpacks why abstract language quietly destroys accountability — and what better BAs say instead.

Listen on Spotify — The Better Business Analyst Podcast

“The Business Wants This” — Why It’s Destroying Your Projects

“The business” is not a stakeholder. It’s not a decision maker. It’s not a source of truth. It’s a fog — a convenient hiding place people use when they don’t want to commit to specifics.

Which customer? Which revenue stream? Which risk are we accepting? The moment abstract language enters your requirements, your roadmap, or your strategic documents, you lose accountability, clarity, and decision speed.

As Benjamin puts it: “Abstract language feels safe. Specific language forces commitment. And that’s what BAs are for — providing clarity.”

A Real-World Example You’ll Recognise

Here’s a classic scenario from the episode — one you’ve almost certainly seen:

“The business needs a more flexible approval process.”

Sounds completely reasonable. It’s completely useless.

Dig deeper and you’ll find: Sales wants faster deal turnarounds. Finance wants tighter controls. Operations doesn’t want more exceptions. And nobody wants to own the trade-off.

The solution? A bloated workflow with 14 approval paths, 27 edge cases, and everyone hates it. Not because the BA failed — because the real tension was never surfaced.

The Pattern: How Abstract Language Creates Bad Solutions

Benjamin breaks down the failure pattern in four steps:

1. Abstract language enters early — “The business wants / needs.”
2. Real tension stays hidden — speed vs. control, growth vs. cost, experience vs. compliance.
3. Solutions become compromises — not deliberate choices, just attempts to satisfy everyone vaguely.
4. Everyone blames delivery — devs built the wrong thing, BAs wrote bad requirements, Agile didn’t work. But the problem was never properly surfaced.

This is why problem statements matter. This is why accountability on the “why” matters before anyone writes a requirement.

What a Better BA Does Instead

A strong BA doesn’t accept “the business” as an answer. They translate abstract language into decision language. When someone says “the business wants this feature,” you ask:

• Which customer segments does this benefit?
• Is this protecting revenue or growing it?
• What risk are we reducing — or are we actually increasing risk?

The goal is to force the shift from opinions and preferences to consequences and trade-offs. Every project has both. Surfacing them is uncomfortable — and that’s the point.

“Better makes things uncomfortable to provide clarity through consequences and trade-offs. If everyone agrees and everything seems fine, that’s usually the time to ask: have we missed something?”

— Benjamin Walsh, BBAI Podcast

Practical Language Swaps You Can Use in Workshops Today

Here are the direct reframes from the episode — language swaps that turn vague requests into accountable statements:

Abstract (avoid)	Specific (use instead)
“The business wants a dashboard”	“Operations wants daily visibility to reduce missed SLAs by 15%”
“The business wants flexibility”	“Sales wants fewer approval steps for deals under $50k to reduce churn”
“The business isn’t ready”	“We’re accepting delivery risk because training and change management weren’t funded”

Notice the pattern: each specific statement can be agreed with or disagreed with. Someone can own it. Someone can challenge it. Vague statements can’t be challenged — which is exactly why people use them.

Why Leaders Use Abstract Language (and Why You Should Push Back)

Leaders — particularly middle management — default to abstract language because it avoids conflict. It means not having to name winners and losers, not having to accept personal accountability for a decision.

The result? Vague strategy, bloated backlogs, and rework baked in before a single line of code is written.

The best BAs — the better BAs — don’t just document what’s said. They clarify what’s meant, even when it’s awkward, even at the leadership level. Benjamin shares a personal example: he produced analysis for leaders that surfaced real trade-offs, and the feedback wasn’t positive. But:

“At least I got a yardstick, a starting point. If you come out with vague promises and then need to deliver to someone’s expectations, you need to be very clear about what they want and don’t want.”

— Benjamin Walsh

The Three Questions That Stop Vague Language in Its Tracks

The next time someone says “the business wants,” stop the conversation and ask:

1. Which customer are we talking about?
2. Which revenue stream are we protecting or growing?
3. What risk are we trying to mitigate — or willing to accept?

If you can’t answer those three questions (customer, revenue, risk), you’re not solving a business problem. You’re building something that sounds safe. And safe is usually expensive.

Key Takeaways

• “The business wants” is a fog — it hides accountability and kills good analysis
• Abstract language leads to compromised solutions, not deliberate ones
• Better BAs translate vague requests into decision language: customer, revenue, risk
• Specific statements can be agreed with, disagreed with, and owned — vague ones can’t
• Pushback is uncomfortable by design — that discomfort is the BA doing their job

Subscribe to the Podcast

New episodes of the Better Business Analyst Podcast drop regularly — covering requirements, stakeholder management, Agile BA, and building a better BA career. Subscribe on Spotify or watch on YouTube.

Level Up Your Business Analysis Skills

If this episode resonated with you, our BA training courses go deeper on requirements language, stakeholder management, and how to handle difficult conversations with leaders. Start free — no credit card required.

Also worth reading: Stakeholder Management for Business Analysts | Requirements Gathering Techniques | BA Interview Questions Guide