Process and Tools8-minute read

Crafting a Strong Product Business Case

More than half of IT projects and products fail. The biggest causes of these failures are resource misallocation and misalignment with business goals. Expertly crafted product business cases can help to mitigate both of these problems.


Toptalauthors are vetted experts in their fields and write on topics in which they have demonstrated experience. All of our content is peer reviewed and validated by Toptal experts in the same field.

More than half of IT projects and products fail. The biggest causes of these failures are resource misallocation and misalignment with business goals. Expertly crafted product business cases can help to mitigate both of these problems.


Toptalauthors are vetted experts in their fields and write on topics in which they have demonstrated experience. All of our content is peer reviewed and validated by Toptal experts in the same field.
Greg Prickril
Verified Expert in Product Management

Greg is a product strategy consultant and trainer with 20 years of experience shipping digital enterprise products at IBM, Microsoft, and SAP.

Previously At

Microsoft
Share

Listen to the audio version of this article

According to an annual Project and Portfolio Management Survey, more than half of IT projects and products fail. The biggest causes of these failures are resource misallocation and misalignment with business goals. Expertly crafted product business cases can help to mitigate both of these problems.

Product managers are sometimes referred to as mini-CEOs. While the responsibilities of a product manager can have varying similarities compared to that of a CEO, there is definitely a skill overlap when creating business cases. Corporate CEOs have to present expansion plans to shareholders and startups CEOs have to pitch their visions to venture capitalists. In both of these situations, the CEOs have to create compelling business cases to convince investors. The same is true for new or existing internal products that require non-trivial investment to grow and capture markets. In this context, the product manager needs to create a product business case and present it to decision-makers in the company to secure funding.

What Is a Business Case?

A business case provides the justification for investment. It can be an investment in a new business, stocks, bonds, a project, or a product. Business cases are often captured in an artifact or set of artifacts like word processing documents, spreadsheets, and presentations.

Product management business cases justify investment in non-trivial material investments in products. They are as relevant to established products as they are for those being newly developed. A business case for a new product allows decision-makers to compare alternatives and choose those that are most likely to generate the best business outcomes. In theory, all product organizations should have competency around crafting and evaluating product business cases; in practice, not all do.

Product managers should be accountable for creating a business case for their product. Other departments should contribute as necessary, but the product manager should drive the content, the creation process, and the presentation. Assigning accountability for business case development to other departments can undermine product managers’ authority and decrease their motivation to execute the underlying plan.

Business Case Structure

Product business case structure

A product manager’s business case can be thought of as having two elements: the business context and financials. The financials project the likely performance of the product in financial terms over a given investment horizon, elaborating what must be invested and expected returns on those investments. There is a tendency for people to think of these figures alone as the business case. However, optimal decision-making requires a second element: business context. If the financials show what we hope to achieve, business context provides the minimal set of information needed to understand why we want to achieve it and some insight into what we will do to achieve it.

Element 1: Business Context

Although the required business context varies depending on factors such as organizational expectations and a product’s place in the life-cycle, we can define core elements that should likely be included in all business cases.

Business context of a product business case

Elevator Pitch

Boil down your entire business case into a 60-second pitch. Forcing yourself to be so concise will make sure only critical information is included and positioned in a compelling way.

Problem Analysis

Before jumping to the solution you propose, demonstrate that you have a clear understanding of the problem that needs to be solved, including its key stakeholders and the economic opportunity related to solving it.

Solution Description

Provide a brief description of the solution, primarily from a functional perspective. This section of the product business case may also include an animated representation of a “happy path” scenario so people better understand how the solution works in the real world.

Market Information

This section can also be called “market insight”. Rather than listing dry statistics, clearly analyze how the size and growth of the market will create a compelling opportunity for the segments of the market that have been prioritized. Pricing options can also be discussed in this section. Cut through the complexity and ambiguity surrounding the competitive landscape, convincing decision-makers that your product has what it takes to come out on top.

Strategic Alignment

In this section, summarize the organizational strategy and demonstrate how the vision, goals, objectives, and strategy bolster it. Rather than focusing solely on what they would like to achieve, product managers should demonstrate to decision-makers how the business case will make the organization more successful, i.e., how the product manager will make decision-makers successful.

Risks and Assumptions

Who would invest in any endeavor without understanding risks that could compromise or obviate success as well as key assumptions that underlie the financials? Risks and assumptions are often confused although they are fundamentally different. Risks are things that might happen which would compromise success; assumptions are things that are expected to happen. All assumptions bear some risk - what is expected may not happen. Critical assumptions, those that would have a significant effect on business performance if they don’t come to pass, will be used in the Financials section of the product business case to do sensitivity analysis.

Product Roadmap

A product roadmap describes how a product organization will deliver value to the market based on its strategy. Very few product decision-makers will invest based on a representation of a single release; they want to know where the product is headed in the future, beyond the immediate investment horizon.

Element 2: Financials

The Financials section should provide a reasonable model representing what must be invested to generate expected returns. Often, organizations have standard templates with varying levels of detail. These templates, referred to as “financial models”, are often created in an electronic spreadsheet, breaking down expected revenues and costs over an investment horizon that is often multi-year. Once expected revenues and costs have been captured, there is a small set of investment metrics that are often used to assess the relative attractiveness of the endeavor described in the business case. The table below enumerates the most common investment metrics.

MetricDescriptionProsCons
Return on Investment (ROI)Ratio of profit to funds invested. Higher is better.Simple calculationDisregards time value of money
Payback PeriodNumber of periods required to recoup investment. Lower is better.Simple calculationDisregards time value of money Disregards benefits after payback period
Net Present Value (NPV)Present value of net cash flows over investment horizon based on a "discount rate". Higher is better.Fair comparison across investments Recognizes time value of moneyRequires dedicated tools to calculate Requires a priori discount rate Requires understanding of time value of money
Internal Rate of Return (IRR)Discount rate generating NPV of 0. Higher is better.Precise rate of return on investmentDoesn’t reflect total economic impact (investment/revenue) Negative cash flows produce multiple IRRs

The financial model should be designed so that the impact of changes in key assumptions can be evaluated. Using spreadsheet formulas, the impact of various levels of existing customer adoption can be simulated, for example. Changes to sets of assumptions can be modeled as “cases” or “scenarios,” e.g., best case, worst case, and likely case. Generally, organizations look for investment opportunities that even in the worst case are unlikely to generate financial losses.

The Product Business Case Development Process

Now that we have an idea of the proper content of a product business case, we’ll address a topic that has historically gotten too little attention: the process of creating a product business case. Just as a recipe containing ingredients with no preparation instructions is of minimal use to a cook, knowing what goes into a product business case without knowing how to assemble and present it is a questionable use to product owners.

Creating a business case is knowledge work, which means the process cannot be reduced to a set of strictly repeatable steps. Each product business case example will be a little different and the process must be highly flexible and adaptable. The following table list these high-level phases, enumerating some of the most important activities in each.

Product business case development phases

Preparation

The preparation phase ensures the minimal amount of planning is done to ensure the timely and efficient creation of the business plan. A core team that will create the business case is identified and key stakeholders are analyzed. A schedule is also drafted that the core team and stakeholders commit to. Great business cases rarely reflect the heroic efforts of a single person like a product manager; they are the result of intelligent, well-planned teamwork.

Construction

The product business case is iteratively defined in the construction phase. The team gathers information and engages with key stakeholders to collect the business context and build the financial model. It is critical for the product manager and team to continuously seek feedback on their work, adjusting the content as necessary. The construction phase may consume over half of the business case creation practice.

Validation

The validation phase represents a change in focus from content creation to content validation with stakeholders. In this phase, the business case as a whole is shared with stakeholders to ensure it is complete, consistent and that they will support it when it is presented to decision-makers.

Presentation

The presentation phase comprises of various rehearsals, at least one dry-run, and the presentation to decision-makers. Prior to the presentation, it is critical for the presenter to rehearse, making sure the presentation flows well. It’s helpful to invite people to the rehearsals who can simulate the reaction and anticipate the questions of key decision-makers. The team should hold at least one dry-run, which is treated like the actual presentation, ideally held in the venue where the presentation will be held. Hopefully, the presentation phase results in a decision regarding the execution of the product business plan.

Follow-up

In the follow-up phase, any action items from the presentation are addressed. Product managers should do a retrospective with the core team and key stakeholders so that the practice of creating product business cases can be continuously improved.

Summary: Strong Business Cases Lead to Investments

Product business cases are created to justify non-trivial investments in product development. The two main elements of a product business case are:

  1. Business Context
  2. Financials

Business context provides the minimal set of information needed to understand why and how we want to achieve the business case. It consists of:

  1. Elevator Pitch
  2. Problem Analysis
  3. Solution Description
  4. Market Information
  5. Strategic Alignment
  6. Risks and Assumptions
  7. Product Roadmap

Product managers should be accountable for the product business case creation process. The most important phases in crafting it are:

  1. Preparation - assemble a team with the required competencies and analyze stakeholders.
  2. Construction - research the business context, create financial models and put all of it in a presentation.
  3. Validation - get feedback from main stakeholders.
  4. Presentation - present the business case to decision-makers.
  5. Follow-up - address any points that were raised during the presentation.

Investing time into creating a strong product development business case will pay off during the execution stage. Having a clear vision and the financials to back it up will keep the team focused and reduce risks that could derail product implementation.

Understanding the basics

  • What is included in a business case?

    A business case includes two main elements. Business context provides the minimal set of information needed to understand why the business case exists. Financial data shows how this business case will be achieved.

  • A business case document provides all the necessary information for decision-makers to help them decide if they want to invest or direct funds towards the business case.

  • You can write a business case by firstly identifying the relevant business context and putting that into a presentation. Secondly, you have to create a financial model that will show how the business case will be executed and what will be the expected returns.

Hire a Toptal expert on this topic.
Hire Now
Greg Prickril

Greg Prickril

Verified Expert in Product Management

Heidelberg, Germany

Member since November 16, 2018

About the author

Greg is a product strategy consultant and trainer with 20 years of experience shipping digital enterprise products at IBM, Microsoft, and SAP.

authors are vetted experts in their fields and write on topics in which they have demonstrated experience. All of our content is peer reviewed and validated by Toptal experts in the same field.

PREVIOUSLY AT

Microsoft

World-class articles, delivered weekly.

By entering your email, you are agreeing to our privacy policy.

World-class articles, delivered weekly.

By entering your email, you are agreeing to our privacy policy.

Join the Toptal® community.