BA Bites - “The Business wants this......”

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 and institution presents the better business analysis podcast with change them. 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, world maps 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 in clarity, making things concise, accountability, likes the smart framework. So we need to start to move away from ever saying the business, okay, so it's basically an easy way out. I'll give you a real word 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 was saying, but the business needs this. It's completely reasonable, right? It's completely useless. You need to ask which approvals, for which customers wants broken today and eventually you'll find out sales wants faster deal 10 rounds, finance wants tighter controls, operations doesn't want more exception and no one wants to own the trade-off. So the solution becomes a 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, CR and R, so we can go into this now. Before we do that, why does I abstract language, the business, create bad solutions? I'll show you the pattern. One, abstract language, end of the early, the business wants, the business needs. All tension actually stays hidden, so speed versus control, growth versus cost, experience versus compliance, solutions become compromised instead of deliberate choices. Everyone blames delivery, devs build the wrong thing, BA is right, 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 connects to that journey as well. So the BA's real job here, what a strong BA better be able to do 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, like does a particular revenue, is it growing that revenue? What risks are we reducing, or are we increasing risk, right? And not just doing, or telling the business whether one's here, 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, a better BA makes things uncomfortable to be provide clarity through consequences and trade-off. And if everyone goes, "Everything is fine and done," then it's usually a time when you go, "If we miss it, why is this so easy?" So I'll give you some practical reframes that you can use immediately. Here are some language swaps, I guess you can use workshops and meetings, instead of saying the business wants a dashboard, you can say operations want daily visibility to reduce missed SLAs by 15%. You turn it basically into a smart objective, but the smart statement now, not just an objective, use the smart model for your statements. The business wants flexibility, no, sales want fewer approval steps for deals under maybe 20 or 50k to reduce June. The business isn't ready, not quite, we're accepting delivery risk, because training and change weren't funded. Do you see the difference, right, you've been really specific about the detail, you're actually telling the truth, the full truth, not showing it, you're not summarizing it. 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 isn't ready, then I go, "Oh, the business is ready, this team was," but if you say, "Well, we didn't do training and change," you said, "Oh, that's different, they went funded, so we didn't do that." But you're willing to accept the delivery risk and go live anyway? Yes, agree, they said someone can own the decision, someone can agree or disagree with it. It's like a statement of a team, you know, you can get it really clear, you can get 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 invoids conflict, they don't want to have conflict, they want to say everything's working fine and dandy, they want to void 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 lab. 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 BA's, the better BA's, don't just document what said they clarify what's meant, even when it's awkward, even at the allegedly, right? I mean, recently I just had some of my documentation given to leaders, I wasn't in the meeting that something I came up with that they wanted to see. And I heard the feedback wasn't 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 us, but now 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 starting point. And so if you come out with vague promises, sometimes when you need to 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 wants, stop the conversation, just say, hey, look, can I just clarify which customer we're talking about, which revenue streamer we're talking about, what risk are we trying to mitigate or are we willing to increase? Because if you can't answer those three questions, C-R-R, 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 a tie end of these vague requirements, or a leader who keeps saying the business. I'll see you after the break, had a great Christmas and holiday season. [MUSIC]