The Better Business Analyst Podcast · 2025-12-17 · 11 min
Key moments - from our scoring
Substance score
31 / 100
Five dimensions, 20 points each
Benjamin Walsh tackles a pervasive problem in business analysis: the phrase 'the business wants this' and how it destroys project accountability. Walsh argues that 'the business' is abstract fog that masks real trade-offs between customers, revenue streams, and risk - allowing stakeholders to avoid naming winners, losers, and consequences. When this vague language enters requirements and roadmaps, projects drift, solutions become bloated compromises, and everyone blames delivery instead of addressing hidden tension (speed vs. control, growth vs. cost, experience vs. compliance). Strong BAs translate 'the business wants' into specific decision language using three questions: Which customer segments benefit? What revenue impact (protect or grow)? What risks do we reduce or increase? Walsh provides practical reframes - replacing 'the business wants a dashboard' with 'Operations wants daily visibility to reduce missed SLAs by 15%' - and explains why middle management gravitates toward abstract language to avoid conflict. This episode is essential for BAs tired of vague requirements and leaders who use 'the business' as a hiding place for hard choices.
'The business' is abstract fog that masks real trade-offs and decision ownership. It allows stakeholders to avoid naming which customer, revenue stream, or risk they're prioritizing, leading to hidden tension, bloated solutions, project drift, and loss of accountability and decision speed.
Which customer segments does this benefit? What revenue does it protect or grow? What risks are we reducing or increasing? If you can't answer these three questions (CRR framework), you're not solving a business problem - you're just building something that sounds safe.
Translate abstract statements into SMART objectives with named stakeholders and measurable consequences. For example, replace 'the business wants flexibility' with 'Sales wants fewer approval steps for deals under 50k to reduce churn' or 'we're accepting delivery risk because training and change management weren't funded.'
Abstract language avoids conflict and personal accountability. Leaders use it to avoid naming winners and losers, creating vague strategy, bloated backlogs, and guaranteed rework. It feels safe but is usually expensive.
Stakeholders can actually own the decision and agree or disagree with specifics. Vague statements like 'the business is ready' can't be owned, but specific ones like 'we didn't fund training and change management, so we're accepting delivery risk' create a yardstick for accountability.
Our reviewer’s read on each dimension, with quotes from the episode.
The episode carries one genuinely useful central argument - vague organisational language hides accountability and produces bloated solutions - but the same point is restated multiple times with filler and rhetorical padding rather than layered with additional ideas. The practical reframes are the densest section but occupy only a fraction of the runtime.
The business is not a stakeholder, a decision maker, a source of truth. It's actually a fog.
Abstract language feels safe. Specific language focuses commitment.
The core critique of vague requirements language is well-trodden territory in BA and product circles; the episode offers no genuinely contrarian or counterintuitive angle. Leaning on the SMART framework as a reframe is a recycled move, and the CRR (customers, revenue, risk) lens is simple rather than fresh.
it's like the smart framework. So we need to start to move away from ever saying the business.
better BA makes things uncomfortable to be provide clarity through consequences and trade off
This is a solo monologue with no guest whatsoever; the host references personal practitioner experience but provides almost no evidence of operating at meaningful scale, seniority, or domain breadth. A single vague anecdote about documentation feedback is the only first-hand credential offered.
recently I just had some of my documentation given to leaders. I wasn't in the meeting, but, uh, something I came up with that they wanted to see. And I heard the feedback wasn't that great on one area of it.
The illustrative numbers (14 approval paths, 27 edge cases, 15% SLA reduction) are useful for concreteness but are clearly fabricated teaching examples rather than real data; the hedged 'maybe 20 or 50k' figure undercuts credibility. No named companies, actual projects, or sourced metrics appear.
The solution becomes a, uh, bloated workflow. 14 approval paths, 27 edge cases, and everyone hates it.
sales want fewer approval steps for deals under maybe 20 or 50k to reduce churn
As a solo monologue there is no interviewing, no follow-up, and no pushback dynamic to evaluate; the host's own delivery is marred by frequent filler, incomplete sentences, and self-correction mid-thought, which reduces the clarity and authority that a structured monologue format demands.
Clear clarity, uh, um, making things concise. Accountability. You know, it's like the smart framework.
Not sugar voting it. You're not summarizing.
Computed from the transcript - who did the talking, and the words that came up most.
But “the business” isn’t a person. It doesn’t make decisions. And it certainly doesn’t own the consequences. In this episode, Benjamen breaks down why abstract language like “the business needs” quietly destroys accountability, hides real trade-offs, and leads to bloated, expensive solutions. You’ll learn: Why vague language is a red flag in analysis and strategy How “the business” masks customer impact, revenue decisions, and risk The real role of a Business Analyst as a decision enabler - not a note taker Practical language shifts that instantly improve clarity and outcomes If you’re tired of unclear requirements, endless compromise, and projects that drift, this episode will change how you listen in meetings - and how you respond. Because great analysis doesn’t start with what the business wants . It starts with customers, revenue, and risk.
Transcribed and scored by The B2B Podcast Index.
Speaker A: I want to start with a phrase that sounds harmless but quietly destroys accountability on projects. The business wants this. No, it doesn't. Customers want things, Revenue depends on things, risk increases or decreases because of things. But the business, that's just a convenient hiding place. The Better Business Analysis Institute presents the Better Business Analysis Podcast with Benjamin Walsh. Welcome back to the Better Business Analysis Podcast. I'm your host, Benjamin Walsh. Merry Christmas, welcome to a festive time of year. And this will be the last podcast of 2025, and I'll see you in early 2026. Now, our topic today is about the fact that every time I hear the business wants, I know there are three things that are probably true. One, no single person owns the decision. Two, the real trade offs haven't been discussed. Three, the project is about to drift. Today I want to have a conversation with you and myself about why abstract language kills good analysis, how it leads to terrible solutions, and what BAs and leaders should say instead. What the business actually means and why it's a problem. Let's be blunt. The business is not a stakeholder, a decision maker, a source of truth. It's actually a fog. People use it when they don't want to say which customer, which revenue stream, which risk we're accepting. And the moment that you allow that language into requirements, roadmaps, or even strategic documents, you lose accountability, clarity, decision speed. Abstract language feels safe. Specific language focuses commitment. And that's what BAs are about. Providing clarity. Right? Clear clarity, uh, um, making things concise. Accountability. You know, it's like the smart framework. So we need to start to move away from ever saying the business. Okay. Uh, it's basically an easy way out. I'll give you a real world example that I've seen. Here's a classic one that you may be able to reflect on or you may have heard before. The business needs a more flexible approval process. There might be finance who's doing something and we're saying, but the business needs this sounds completely reasonable, right? It's completely useless. You need to ask which approvals for which customers, what's broken today? And eventually you'll find out. Sales wants faster deal turnarounds, Finance wants tighter controls. Operations doesn't want more exceptions, and no one wants to own the trade off. So the solution becomes a, uh, bloated workflow. 14 approval paths, 27 edge cases, and everyone hates it. Not because the BA failed, because no one forced the conversation back to the customers. Revenue and risk, C, R and R. So we're going to go into this now before we do that. Why does abstract language the business create bad solutions? Uh, I'll show you the pattern. 1. Abstract language enters early. The business wants the business needs real tension actually stays hidden. So speed versus control, growth versus cost, experience versus compliance. Solutions become uh, compromised instead of deliberate choices. Everyone blames delivery. Divs build the wrong thing. BAS wrote the bad requirements. Agile didn't work. No. The problem was never surfaced properly. And that's why we do problem statements. Right. And we have accountability on that. So this, this connects to that journey as well. So the BA's real job here, what a strong BA, a better BA does is they don't accept the business as an answer. They translate it into decision language. Instead of the business wants this feature, you ask, but which customer segments does this benefit? What revenue does this project, uh, like? Does it protecting revenue? Is it growing that revenue? What risks are we reducing or are we increasing risk? Right. And not just doing or telling business what they want to hear. I just said the business not telling stakeholders what they want to hear. Everyone wants to reduce risk. This may increase risk. You need to force the shift from opinions to consequences and there's preferences but really there are trade offs. And every project has consequences and trade offs. This is uncomfortable and that's the point. Okay, uh, better BA makes things uncomfortable to be provide clarity through consequences and trade off. And if everyone goes, everything is fine. And Dan, then it's usually a time where you go have we missed? Why is this so easy? So I'll give you some practical reframes that you can use immediately. Here are uh, some language swaps I guess you can use in workshops and meetings. Instead of saying the business wants a dashboard, you can say operations wants daily visibility to reduce missed SLAs by 15%. You turn it basically into a smart objective. But it's a smart statement now, not just an objective. Use the smart model for your statements. The business wants flexibility. No. Smart sales want fewer approval steps for deals under maybe 20 or 50k to reduce churn. The business isn't ready. Mhm, not quite. We're accepting delivery risk because training and change weren't funded. Do you see the difference? Right, you're being really specific about the details. You're actually telling the truth, the full truth. You're not sugar voting it. You're not summarizing. Now someone can agree and disagree or own the decision. If those statements are written the way that they should be properly. They can't agree or disagree with the business. Ready they might go, well the business is ready. This team was but if you say, well, we didn't do training and change, they said, oh, that's different. They weren't funded, so we didn't do that. But you're willing to accept the delivery risk and go live anyway? Yes. Agree. Someone can own the decision, someone can agree or disagree with it. And that's good analysis. Right. It's like a statement of a team. You know, you can, you can get it really clear. You can get, um, approvals at that level. And why do you think leaders love the business and why you should push back? Leaders use abstract language because it avoids conflict. They don't want to have conflict. They want to say everything's working fine and dandy. They want to avoid naming winners and losers and they want to avoid personal accountability. And when I say leaders here, this could be middle management. Usually I find the exec is not so bad at this, but this happens usually in the middle management layer. And that model or that desire to avoid things, it creates vague strategy, bloated black logs. And it actually guarantees rework from the start before you've done anything. 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. Right. I mean, recently I just had some of my documentation given to leaders. I wasn't in the meeting, but, uh, something I came up with that they wanted to see. And I heard the feedback wasn't that great on one area of it. And for me, I looked at it and said, oh, well, I don't know why they could disagree with this, but now I was, I put things in there that they could disagree with. Right. I didn't make it vague and tell them what they wanted to hear. Now, I know there's more analysis that needs to be done and more expectations that need to be met, but at least I've got a yardstick, a starting point. And so if you come out with vague promises, um, sometimes when you need to, um, deliver to someone's expectations, you need to be very, very clear about what they want and what they don't want. So the next time someone says the business want, stop the conversation. Just say, hey, look, can I just clarify, which customer are we talking about? Which revenue stream are we talking about? What risk are we trying to mitigate or are we willing to increase? Because if you can't answer those three questions, crr, uh, uh, you're not solving a business problem. You're actually just building something that sounds safe. And safe is usually expensive. And if this resonated with you, please share it with other bas who are, uh, tired of these vague requirements or a leader who keeps saying the business. I'll see you after the break. Have a great Christmas and holiday season, Sam.
Other episodes covering the same guests and topics, from across The B2B Podcast Index.
Kevin Pannell on the project management, the fundamentals of leadership, and balance | The Dev is in the Details #15The Dev is in the Details · on SMART objectives81 / 100
How to manage the priorities between the executive team and the investorThe Private Equity Podcast, by Raw Selection · on Accountability72 / 100
S1:E20 The Trust Gap New Executives Must CloseThe Velocity Executive · on Trade-off analysis65 / 100
Decoding AQ with Ross Thornley Feat. Rhett Power - CEO of Accountability Inc.DECODING AQ · on Accountability65 / 100
Fearless Fundamentals: How Language, Bravery, and Trust Shape Great Product TeamsPractical Product Management · on problem statements59 / 100
Silence in Meetings: Why People Aren't SpeakingThe Career Refresh with Jill Griffin: Leadership Strategy for Senior Professionals · on Accountability55 / 100
The Business Case Is Dead. Long Live the Opportunity Canvas.49 / 100The Brutal Truth: How Business Analysts Should Approach a Custom ERP Implementation51 / 100BA Bites - How Business Analysts Should Approach a Salesforce Implementation75 / 100BA Bites - From 5G to Smart Cities: Finding Business Opportunities in Connected Data and Processes56 / 100BA Bites - When Human-Centred Design Isn’t What It Seems: From Users to Customers and True Innovation