The Many Faces of Business Cases
When to use the business case as go/no-go decision?
If you are working in product management sooner or later you’ll be asked to make a business case. When you take any course in management or business one of the topics on the agenda certainly is ‘how to create a business case’. Searching for the term business case in Google gives billions of results. So, if you’re being asked to make a business case, where do you start?
Can you make a business case for that?
In this article, I’d like to share my experiences with creating business cases and reflect on the different roles they have played in the organization. In the 5+ years that I’ve been involved with, or working in Product Management I’ve seen a fair share of business cases.
Furthermore, I’ve created multiple business cases for different companies and create business cases for job interviews I’ve done. After reading this article — and someone asks you to make a business case — you’ll be able to ask follow-up questions to understand what they are actually asking you to investigate.
Overall we’ll look at business cases as:
- a (project) deliverable to support a go/no-go decision
- a method for prioritization
- a process for communication
- a way of presenting
The business case as a go/no-go (project) deliverable
The first association that most people have with the term business case is that it is a spreadsheet with numbers and figures for business investment. Within the traditional Project Management methodologies, such as Prince2, the business case is part of the delivery flow. In this form, the business case is a method to decide whether to proceed with a project or not.
With the business case completed the team decides whether a project has a positive return on investment and should therefore proceed
The traditional form of a business case attempts to estimate as realistically as possible the costs in order to engineer and deliver the product, and the revenue that this will bring. (For example: In my spare time I develop board games. If I ever want to release a board game, I’ll make a business case to decide whether I want to invest my personal money into it)
Based on the history of the company and the experience in the specific market segment you will typically have more data available to improve your estimations.
Within Philips Hue we could leverage the many years of experience of selling lighting products globally, so we knew exactly what uplifts we should calculate for different countries and regions. Even the engineering department had their own tooling to estimate with about 90% accuracy the cost-price of a product from the different suppliers.
The result was a complicated spreadsheet that contained many sheets with variables to be completed at the start of a project. The spreadsheet was so complicated that it required several hours of training from a financial expert to be able to complete it. The result would be a highly detailed and complete understanding of the investment and the return on the investment.
This form of the business casing is worth the effort because the upfront investment was high because the majority of the projects contained hardware development. For hardware projects, the largest part of your investment is in engineering, tooling, and samples. There is little room to correct mistakes later on in the project.
However, as Philips Hue does not only develop hardware products, but also software solutions we oftentimes struggled to capture those developments in these traditional business cases.
It’s extremely difficult to attribute certain sales to a specific feature of your app. However, that specific feature of course needs to have a development team to create it and it needs maintenance to continue to offer that feature. In such a model the traditional investment versus return on investment is difficult.
When to use the business case as go/no-go decision?
If you find yourself in one of the following situations you can create a business case to support your go/no-go decision:
- for a hardware product, you have to decide a selling price and a first-order quantity
- for a project you have to decide on a buy or make strategy
- you have a (brilliant) idea for a new product and want to assess its viability (my board game example)
The business case as a method of prioritization
For software products, any team that I’ve worked with uses the agile methodology, mostly in the form of scrum. In order to plan software developments most agile frameworks use (a variant of) a ‘Lean’ business case (example). Those business cases are less focused on a go/no-go decision. Instead, this business case supports a decision-making process to prioritize features against each other.
These business cases are less focused on the actual investment needed and the expected return on investment. A lean business case aims to make a ‘close-enough’ estimation of the development time required and the anticipated benefits for the user of the system.
You can also see this in the methodology being used: you will enter rough estimations of development hours, versus actual invested euros.
It’s also understandable when you think about the revenue model for software-based companies: As most software solutions have a form of a subscription model, rather than a one-time purchase model, the focus is less on a direct return on investment. You can earn back your investment in smaller chunks.
This means that many key metrics for software companies focus on customer satisfaction and customer retention. Also consider that your features compound: you can develop on top of it again. This means that it is more important to decide in which order to develop features. Features with the largest compounding effect should be prioritized first.
In (LEAN) business cases features are compared to each other: feature A requires a development time of X and we expect that it will bring benefits 1, 2, 3 to the users of the system. Compare to feature B that requires a development time of Y and brings the benefits 4, 5 to the user. The (management) team can then decide which feature to prioritize over the other.
In another article, I’ve described a method to support this prioritization process. With this methodology, you can easily compare the various features on your backlog to each other.
When to use the business case as a prioritization?
If you find yourself in one of the following situations you can use a business case to prioritize:
- There are two features on your backlog that at first glance could be equally important
- You need to decide whether a custom implementation for a customer is more important than a new feature for all customers
- You want to request additional developers for a project so you can deliver faster
The business case as a process for communication
In the two cases discussed above the business case creation is primarily an exercise that is done by one person, or by a small project group. However, the business case typically also serves a purpose with a larger team, or within an organization. In that situation that business case can play a pivotal role in communication.
The beauty of a business case is that it provides a structure for everyone involved. Since you can’t predict the exact outcome of an investment you have to derive key metrics and criteria to assess product development upfront. The business case essentially describes which key components are essential to your business and how they relate to each other.
By enforcing a business case format or template within the organization a project or product is always evaluated and assessed in the same way.
Although it may not feel like that, it creates an equal playing field for all projects. That means you can get rid of HiPPO decisions that can cause frustration among employees.
For example, if everyone has to report on the estimated development hours invested multiplied by a global hourly rate you can easily structure the cost-component of various projects. In the same way, you can also structure the expected gains for the organization.
Think about: additional revenue, increase in margin, reduction in cost, increasing the addressable market, must-do maintenance, increasing user satisfaction, up-selling or cross-selling to existing customers, etc. This list can be tailored to the needs of your business.
In this situation, the exact outcome of the business case is just as important as the discussion around each business case. If you ask a group of people to plot all their projects and features in a standardized business case format they will have to make assumptions.
For example, if one of the key evaluation criteria is ‘the impact on existing customers’, you have to make an assumption on how a certain feature impacts the existing customer base.
The team as a whole needs to review and agree on the assumptions made. For example: if we create feature A then we can up-sell this to 3% of our top-tier customers. Which should then be followed by an explanation of how you get to that 3%.
It is important to understand that this is a difficult exercise. I’ve had this experience in all the companies I worked for: Discussing business cases and comparing them to each other always risks the “my feature is better than yours” assessment.
Since people are typically evaluated on their contribution to the business (especially product managers), there is a large risk that pet-peeve projects have inflated business cases to make sure they end up high in the prioritization.
Furthermore, in situations where a group of people is asking for resources from a limited pool, this can easily lead to frustration, disappointment, and resentment. It’s important that all of the parties involved at least understand why they are asked to fit their business case in a standardized format, and that they have the opportunity to present their assumptions.
When to use the business case as a method of communication?
If you find yourself in one of the following situations you can use a business case as a methodology to stimulate communication:
- you need to decide how resources are allocated across teams
- it feels that not all parts of the company equally contribute to the company goals
- you need to align roadmaps and feature priority in a group of a product leader
The business case as a way of presenting
Last, but certainly not least, is the role that business cases play as a way of telling a story. You’ve probably seen more presentations of business cases than you might know. Essentially a business case is nothing more than any (or all) of the above three reasons:
- What’s to gain? Is it economically viable to deliver this product or service?
- What else could we do? Should we invest in this product/feature, or in something else?
- Are your assumptions correct? Are you looking at the right components to make the best prediction?
If you wrap this into a story you can make a convincing and compelling case for your product. Actually…you can almost present anything along these lines! And you know what. You should! Consider for example how presentations in television programs such as ‘Dragon’s Den’ are done. These are all proposals, ideas that are presented in such a way that people are (quite literally) buying into it.
When you are interviewing for a product (management) job companies will typically check whether you are capable of presenting your ideas in the form of a business case. It is a practical and concrete method to evaluate the skills that someone has. In order to build a business case and present it, you will need to showcase the following skills:
- analysis: can you split a market, customer, product into measurable chunks, and get the right information?
- business modeling: can you show where there are opportunities to extract value for the business and do you understand how your product is delivered to market?
- sanity-check: do you have any sense of reality, and are you self-critical enough to challenge your own assumptions?
- presentation: are you able to tell a story convincingly and bring a complex idea or product down to an understandable level?
- confidence: can you confidently answer questions and defend your assumptions and opinions
This is why the presentation of a business case is a simple way to verify someone’s capabilities.
Many people in a product development position will be asked to contribute to or create a business case. Based on my experience this question can be asked for various reasons. In this article, I’ve shown you ways that business cases can be used in companies.
- Business cases can be used to predict the return on investment for a new product and support a go/no-go decision
- Business cases can be used to compare the relative value of features in order to prioritize what to develop first
- Business cases can be used to facilitate discussion within a team or organization
- Business cases are a structure to give a presentation, and an easy way to check someone’s business savyness.
I would love to hear your experiences with business cases in the responses.
Father, Huisband and board game enthousiast. Designer by education, product manager by profession. Passionate about innovation, technology and space travel.