Not every business case needs to be a 40-page behemoth
Kim was responsible for $500m of IT investment at her company. That meant reviewing 250 business cases each year.
Some teams would spend weeks building out 40+ page business cases, trying to anticipate every question, objection, and challenge along the way. When leadership told them that wasn’t a target investment area, they were crushed.
Other teams came in with well-written 2-page documents that got approved for seed money. The team would explore the new idea and come back with more information to gain full investment approval.
The big-document teams were getting stuck in a terminology trap. They were told to write a business case. Most people use the term “business case” to describe massive documents with a wealth of data. We lack the language to talk about other activities we do to evaluate the return on investment (ROI) of opportunities.
In reality, business cases come in many sizes. There’s an appropriate sized business case for every size investment being requested.
Business cases come in many shapes and sizes
Every product person should be doing business cases constantly. This doesn’t mean the 40-page document that Kim was receiving; business cases take many shapes and forms, including:
- The Slack message asking for funding to attend a conference or take a course
- Justifying why we should invest in a tool to solve a problem your product team is encountering
- Making the case for why we should build out a feature that will reduce customer support calls
- Explaining why we should develop a greenfield new product line to go after a completely different market
- Pitching for funding for your Series A round
The challenge is we use the same word to describe all these different activities. They each take a different level of effort and commitment.
I was describing my upcoming Business Case Bootcamp course to a product leader. He said his PMs didn’t need it because they were never the ones asking for upwards of $250k of investment at the company. When I explained that my course was thinking about small investment decisions as business cases, his face lit up. He did a full 360 and asked if we could explore a private cohort for his team to train them in how to become more financially-focused PMs.Business cases are really a spectrum. A framework I use to create them is the progressive business case.
The four types of business cases
Each of the different kinds of investment requests I mentioned above corresponds to a different archetype of a business case. Some take minutes and others might take weeks to construct. In order of most lightweight to robust, they are:
- Back-of-the-napkin
- P&L sketch
- Pilot proposal
- Full analysis
I’ll walk you though each of them and when you’ll know that you’ve reached the right level for your particular investment opportunity. For each of them, we’ll evaluate the following criteria:
- Research investment: How much research and time do you need to invest in order to construct the business case?
- Confidence level: What level of confidence do you have that the ROI projections will be accurate?
- Cross-functional involvement: Who else needs to be involved in adding data and further evidence to flesh out the business case?
- Investment threshold: At what point does this type of business case suffice to make an investment decision?
For the investment threshold, while I talk about it here in terms of dollars, it might actually be the amount of time or people working on an initiative.
| Research investment | Confidence Level | Cross-Functional Involvement | Investment Threshold | |
| Back-of-the-napkin | Minimal | Very low | None | Minimal |
| P&L sketch | A few hours. | Low | Minimal | Low |
| Pilot proposal | A few days to a few weeks | Medium | Moderate | Medium |
| Full analysis | Intense | High | High | High |
Start with the most lightweight business case type and progressively evolve towards a more involved one.
In Kim’s story, the successful proposals used a more lightweight business case for their initial seed funding; they then enhanced their business case with additional data and research to secure more funding later.
Here we’ll walk through the four different types of business cases and when each of them should be used in more detail.
Back-of-the-napkin: The beginning of an idea
A back-of-the-napkin (BOTN) business case is a sketch of an idea with some sanity checks. In work, it often shows up as a Slack message or an email outlining an idea. It usually only takes into account two or three line items – for a feature, potential revenue and one or two expenses; for a purchase, benefit and cost.
The goal of a BOTN is to gut-check the idea and see if it’s absolutely ridiculous or if there might be something worth exploring.
Since the proposal is at its earliest stage, it doesn’t require much research. BOTNs are generally supported by an internet search or a few thought exercises based on past knowledge.
Similarly, since so little went into the research, a BOTN business case is likely to have quite a few incorrect assumptions, usually trending towards overly optimistic.
A BOTN might get external support via a quick chat with a peer, but there is no expectation or requirement of outside collaboration.
From a development side, these business cases are useful for prioritizing smaller features that align with pre-determined goals and fit within a sprint or two. Even something as simple as “we expect this layout change to increase conversion by 1.5%, worth about $x annually” constitutes a BOTN analysis.
Because the cost is small or you’re seeking approval for something that has already been budgeted for (like a flight, course, or team event), the analysis can be lightweight. Once you move from a quick few lines of text into a spreadsheet with multiple columns, you’ve started doing a P&L Sketch.
P&L sketch: Identifying high-risk assumptions
The P&L sketch is when the business case becomes more than three or four line items and the ROI impact becomes a primary focus.
For building a new product, a P&L sketch might need to take into account multiple assumptions around revenue, such as new user growth, churn, or pricing tiers. On the expense side there might be multiple expenses around building and maintaining the product. It’s often accompanied by a page or two of narrative.
When justifying a purchase, the benefit might be broken down across different roles and responsibilities. The expenses will include the cost of the purchase plus implementation.
The goal of the P&L sketch is to identify the highest-risk assumptions that need further investigation. Sometimes the largest risks are around customer willingness to pay, other times the risks are around unexpected development delays. Each of these would require different research and next steps.
Each line item will need its own investigation. That might include more detailed internet research, some user research, calls with various vendors, and discussions with other departments to get their estimates.
While a P&L sketch has much more included in it than BOTN, it’s still not robust enough to base major decisions off of it. The expectation of accuracy should be low.
The P&L sketch would be the point at which there might be some quick help from other people throughout the organization to build it. Engineering might help estimate development costs, for instance. Sales might provide insight into willingness to pay or the amount of demand for the feature. As you engage people across the organization, you can also use it as a tool for understanding the level of stakeholder interest in an initiative.
The P&L sketch is likely sufficient when it doesn’t require outside approval for the decision. This might be a tool that costs below the manager’s discretionary budget or a more complicated feature that will be built out by one product team independently.
Once the approvals and coordination costs increase, however, a P&L sketch may no longer be sufficient. That’s when a pilot proposal comes into the picture.
Pilot proposals: Testing high-stakes assumptions
The pilot proposal is when it’s time to get some initial resources (people, time, money) approved to explore a big idea with some initial investment. Likely this involves a proof of concept (POC) designed to (in)validate the most sensitive assumptions identified in the P&L sketch.
Different companies will have different thresholds at which a pilot proposal is required. The pilot proposal is where a P&L sketch gets fleshed out further – it isn’t much different in terms of format, but is much more robust in terms of the amount of research that went into it.
Research would likely include deeper user and market research, perhaps a few hours to a day or two of engineering time, and many conversations with internal stakeholders.
It’s highly likely that the pilot will fail, so confidence is still not that high. The additional research improves the signal over less advanced business case techniques, but business cases are always high-uncertainty artifacts.
Everyone who will be involved in executing the pilot needs to be involved in the creation of the pilot proposal. It’s unlikely that a product manager or product team can complete a pilot independently. Depending on your organizational dynamics, a pilot proposal will potentially require an executive sponsor.
Sometimes the POC will simply be a time-bound version of the full proposal – for instance, a POC might just mean a 90 day trial of a tool with a few teams before rolling it out to everyone. In other cases, the pilot truly is a trial rollout of a larger initiative. For those, a full analysis will eventually be required.
Full analysis: the comprehensive business case
Finally, we reach the many-page document with supporting evidence that most people term the “business case”. The good news is that if you’ve been going through the progressive business case process, you have done a meaningful amount of the work already.
In terms of research required, your pilot results will contribute much of the data. In addition, some people will reach out to a market research firm or subject matter experts to further validate assumptions.
The full analysis has the highest confidence level of any type of business case. Which doesn’t mean that it’s guaranteed. You’re still attempting to predict the future, but at least you have the data to back it up.
As you can guess, this is where the cross-functional involvement will likely hit every level of the organization. It’s likely to need senior leadership approval to get the go-ahead.
Whether exploring a new line of business or upgrading a major tool in your company’s tech stack, business cases like this support those times when the stakes are high, the impact is long-term, and it’s very hard to change course once this decision is made.
Progressive business cases are a mindset
Business cases aren’t a one-size-fits-all: they’re a spectrum of different deliverables that help companies make valuable resource allocation decisions.
Strong business cases, using the right type at the right time, can make you a more influential person within your organization.
Writing progressive business cases requires a mindset shift – the business case is not something that gets put together in one fell swoop. Instead, just like a product idea, it is refined and enhanced with more research and experimentation.
If you always begin your journey with a BOTN analysis and move up the ladder step-by-step, you will find the right complexity of business case to fit the decision. For many companies, that will look like:
- Back-of-the-napkin. Small expenses that an individual can make themselves.
- P&L sketch. Medium initiatives that require several teams to execute.
- Pilot proposal. Large investments that touch most of the company.
- Full analysis. Transformative opportunities that require the highest level of scrutiny.
The most common mistake with business cases is not using one at all. The second most common mistake is jumping to a higher rung of the business case ladder without doing the lightweight steps first.
Kim noticed this pattern and began coaching teams to start by building out a 90-second pitch with 1-2 slides. She encouraged them to ask for just enough to get started, and then come back once they knew more. With that new process, more projects got exploratory funding and fewer teams wasted weeks on building out major documents.
A product leader who can construct a clear and effective business case for the decision at hand will be able to garner the support of stakeholders across the organization, maximize successful product launches, and demonstrate their value to the company.
My course, Business Case Bootcamp: Craft, Model, and Pitch Winning Product Ideas, helps advance your skills in building out the financial model behind a P&L sketch or a pilot proposal. It includes a prompt library and templates for both the spreadsheet and narrative document to help you feel more confident presenting your ideas to company leadership.
Take a look at the decisions you made over the last quarter. Which ones of them would have been better served with a business case and of what size? Next time a similar decision comes up, take the time to build out the financial case alongside the user-centric one and watch how your influence grows.
Thank you to my amazing reviewers Shivam Malhotra and Kimberly Birdsell #OpenToWork. They lent me their stories, ideas, and suggestions to tighten up this article extensively.
