The #1 question every business case should answer

When you frame your recommendation in a way that gets heard, you increase the chances it gets adopted. Here's how.

Feb 21, 2024

👋 Hey, it’s Wes. Welcome to my weekly newsletter where I share frameworks for becoming a sharper operator, rooted in my experience as an a16z-backed founder.

If you’re interested in sponsoring this newsletter to reach 30,000+ thoughtful operators, fill out this form and I’ll share more.

Read time: 8 minutes

Intelligent people can be shockingly bad at pitching their ideas.

A few years ago, one of my direct reports said, “I’m so frustrated. I flagged an issue to the CTO, but he didn’t care. I can barely keep it together and want to scream into a pillow. I don’t know what to do. Could you share how to get him to listen?”

This was the first time my team member (let’s call him Evan) mentioned this issue, but he had clearly been frustrated for a while.

I said, “First, I’m glad you brought this up because I never want you to suffer in silence—please speak up even sooner next time. Second, the CTO is usually pretty open to hearing about problems. It doesn’t sound like him to just ignore you.”

So I did what I usually do in situations where I’m curious and need more information: I asked for primary data.

“Could you share the doc you sent?”

It turns out, Evan had written a two-page Google Doc describing the issue, but the doc was terrible. It was too detailed in the wrong ways, but not detailed enough in the right ways. It wasn’t clear what the problem was, or what he wanted the reader to do.

If I had read it, I probably would have dismissed it too.

When I talked to the CTO, he said, “I had no idea the issue was this bad. I don’t really remember him bringing this up, much less saying no to his request.”

Evan tried to make a business case, but his write-up was lacking. How do you speak up so your manager or colleagues will listen?

Every week, we make business cases at work. I’m defining a business case as any recommendation to pursue a business opportunity or solve a problem. A business case can be a 5-page document, 5 sentences in Slack, or a 5-minute phone call. The larger the project, the more you may need to make a comprehensive business case. But the underlying premise is the same:

If you don’t explain why a problem matters, your colleagues won’t have the necessary information to decide how to support you.

“How will this save money or make money?”

While your circumstances may be unique, the underlying question driving all business cases is the same: How will this save money or make money?

Businesses exist to make money by creating value for customers. The closer you are to generating revenue for your organization, the more leverage you have. Addressing this can be the difference between your idea being labeled as tactical vs strategic.

If you play out the logic behind your recommendation, it’s very likely that your idea already makes or saves the company money. That’s great news. But you have to make this connection explicit. Ideally, you can quantify the impact, but even if you can’t, try to make the connection as concrete as possible.

There are other incarnations of this underlying question “how will your idea save money or make money for the company?” I’ll share a few other forms of this because they might spark different ideas for you:

“How will this drive the business?” “Driving the business” is another way to say “making money for the business.” Not every tactic needs to be one step away from revenue, but you should be able to show clear logic for how an idea will eventually lead to revenue or increased leverage for the business.

“How much is this costing the business?” Money is the most obvious cost, but wasted time, lost brand equity, lower team morale, decrease in customer satisfaction, etc—all those lead to losing money.

“What’s the frequency and magnitude of this problem?” If the problem happens every day and each time, the business almost collapses, it’s clearly worth handling. If it happens once in a while and is a minor irritation each time, it’s less important. Most problems are somewhere in between. If you think a problem is important to address, share how often the problem happens and the severity of the impact each time it happens.

“What bad things happen if we don’t do this? What good things happen if we do?” I call this framework “Bad Things / Good Things.” It’s one of my favorites and I use it often. Some people are more compelled by fear of loss and want to mitigate downside risk, while others care more about new gains and upside. The great thing about this framework is it addresses both, so you’re covered regardless.

“Why now?” Not all problems are worth solving. Businesses are basically one problem after another. When you solve a problem and reach a new level, you unlock new problems. Because you have limited resources and never-ending problems, you need to focus on solving the most important problems first. The question isn’t “Is this a problem?” but rather, “Why now with solving this problem?”

“Why is the juice worth the squeeze?” This is about upside and ROI, and why it's worth (or not worth) spending effort and resources. For example, I’ve said no to many ideas that seemed good on the surface, but were too much effort for not enough payoff. For example, your startup hosting an in-person event (like Dreamforce or WWDC) might make sense in the future. But early on, there are probably a dozen ideas that are higher ROI for attracting customers, developers, or building community.

“How does this make our customer’s life better?” When you only frame in terms of dollars gained or lost for the company, it can sound a bit Machiavellian. Talking about how you improve the customer’s life is more customer-centric, less company-centric. Happier customers will stay around and continue buying from you, which means growing the business.

“How does this get us closer to our team or company goal?” Frame your idea as a means to an end for achieving the growth goals.

Putting it all together, here’s an example of what a business case could look like for flagging a problem and how much it’s costing the company:

“I’d like to propose building an internal feature that allows the marketing team to pull sales data more efficiently. We need to pull sales data every morning Monday through Friday, and the process takes 3 hours per day because we’re doing it manually. That’s a whopping 15 hours per week spent on pulling data alone, which is not sustainable.
Before, we had a low volume of customers so it was manageable. But now, we have a higher volume so sorting the data takes much longer. Going forward, we expect to 10x the business, so having accurate and timely data will become even more important.
If we build an internal feature, getting data will only take a few minutes every morning. If we don’t find a solution, going forward we will need to potentially cut back on x and y projects to allocate bandwidth for these data pulls.
I’m happy to do any heavy lifting to make this as seamless as possible for the eng team.

To be clear, you shouldn’t only address how your idea will save or make money. But if you don’t do this, you’re dead in the water. To create a compelling business case, you’ll also need to share your rationale and paint a picture of why your idea matters. To do this, check out my list of questions to prompt rigorous thinking.

Phrases to show how a problem is costing money

Don’t only say “this costs us money.” Share evidence about HOW a problem is costing money, including quantifying the amount or painting a picture of why the problem is expensive.

Here are phrases to help your audience feel the pain:

Makes us more prone to human error
Exposes us to risk
Slows us down
Customers are complaining about this
Customers haven’t complained yet, but I can tell they’re not pleased because
Will get more expensive over time
Will only get worse with time
Other companies in our position have already done this or are currently doing this
Is affecting team morale
Is time we could spend doing something more highly leveraged, such as X
Doesn’t allow us to have accurate insights in real-time
We’re making decisions using old data
This could erode our brand equity in the minds of customers
This makes us look spammy, low-value, and amateur
This would be a turn-off for our ideal customer
This would attract the wrong kind of customer
This used to be okay, but it doesn’t work anymore because
This isolated incident doesn’t seem like much, but it compounds over months
This is happening more often than you might think
Each time this happens, it’s worse than you might realize
This could make us look bad to employees
This could make us look bad to other teams
This could make us look bad to customers
This could make us look bad to the public

Each example above leads to costing the company money.

Share your logic, evidence, and rationale

When you share your thought process, you allow your colleagues to discuss and debate an idea with more specificity. If you are vague, your audience doesn’t have enough information to validate what you’re saying. They may toss out your entire idea, when actually, 80% of your underlying insight was solid and can be explored through a different tactic.

Flagging a problem you believe is worth addressing:

🚫 Lazy thinking: “Hey boss, x is a problem. [silence]”

✅ Rigorous thinking: "Hey boss, x is a problem because [why this is a problem and what it’s costing the company]. I’m not 100% sure what to do yet, but my initial hunch is we should do ____ because [your logic and rationale].”

Proposing an idea you believe is worth pursuing:

🚫 Lazy thinking: “Hey boss, can we do [random idea]?”

✅ Rigorous thinking: "Hey boss, given our goal of ___, I recommend we do [this idea] because [insight about the market, customers, category]. It's likely to work and is worth the time/budget because ___. The potential risks and reasons not to do this are ___. But we can minimize the risk with a small experiment by doing ___.”

Satisfying the stranger reading your recommendation

Remember my direct report, Evan? His original lackluster business case wasn’t due to his ability or intelligence—he was a bit too close to the issue to be able to zoom out, and more importantly, he didn’t know how to explain the situation so someone else could easily understand. Once he used the frameworks above, he got the CTO to take action and discuss next steps.

When we pitch our ideas, we often forget that other people are not us—they haven’t lived this problem, thought about the solution over time, or been immersed in the context.

We state our recommendation, then expect the rightness of our recommendation to be obvious. I love this quote from Paul Graham on why it’s hard to put our ideas into words:

“You have to pretend to be a neutral reader who knows nothing of what's in your head, only what you wrote. When he reads what you wrote, does it seem correct? Does it seem complete? If you make an effort, you can read your writing as if you were a complete stranger, and when you do the news is usually bad. It takes me many cycles before I can get an essay past the stranger. But the stranger is rational, so you always can, if you ask him what he needs. If he's not satisfied because you failed to mention x or didn't qualify some sentence sufficiently, then you mention x or add more qualifications… You just have to make them as good as you can and still satisfy the stranger.”

Of the things you think are super obvious in your own head, more often than not, it’s not that obvious to other people. Remember: It’s up to you to connect the dots. When you do, you’ll reap the benefits of faster buy-in, fewer obstacles, and more ease with getting heard.

I’d love to get your help growing our community of thoughtful, rigorous operators. If you enjoyed this post, consider taking a moment to: