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

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.