product management business case

A critical responsibility of product management is to drive revenue through new products.  Unfortunately, business cases are usually required to secure the funding needed.  Google can help a bit – there are 1.4 billion Google Search results for “Product Management Business Cases”.  Regrettably, after about 30 search results Google kind of craps out.  In spite of insistence on formal business cases, over 90% of new products in 2020 failed according to Harvard professor Clayton Christensen.  Harvard Business School lecturer Shikhar Ghosh says in a WSJ article that 75% of venture-backed companies never return cash to investors and in 30-40% of the cases, investors lose their whole initial investment (he works with a dataset of 2000 venture-backed startups).  If even the most sophisticated VC firms have such a high failure rate, product managers face equally daunting odds of getting their new product ideas funded.  Experience has shown that the process of building a product management business case is as important as the models it contains.

A Typical Product Management Business Case Story

The Backstory

Jack is a senior product manager for FashGen – a $50 million private equity-based online apparel retailer.  FashGen made its mark in the industry by being the premier destination for iconic millennial brands like Hollister and Fashion Nova.  After five years, FashGen’s revenue growth rate has declined precipitously.  Jack has an idea for a product extension that could drive significant incremental revenue.

Jack’s idea is to add Bitcoin and Ether as payment options in addition to the many credit cards and Paypal that FashGen currently offers.  Consumers age 18 to 34 are the largest adopters of cryptocurrencies and are a core target market for FashGen.  Jack envisions using a payment gateway like Bitfinex.  The development effort would be ‘minimal’ since they already had a payment API infrastructure.  A significant investment in marketing to crypto enthusiasts would be required, but the net new customers they could attract would drive significant new revenue for FashGen.

One of Jack’s friends, Sameer, is a senior developer for FashGen and is very active in the crypto world.  Over a long weekend, Jack and Sameer had a mini-hackathon to explore Bitfinex’s API and walked away convinced that the software engineering effort to integrate into FashGen’s core platform was doable.

On Tuesday after the mini-hackathon, Jack pitched the idea to his director and VP.  They both expressed interest and told Jack to put together a business case for presentation at the next executive staff meeting in a week.  Jack was excited and dusted off the notes from a 280 Group product management training class he’s taken a year ago.  Jack worked tirelessly all week and followed the format recommended in the class.  His report included:

  • Executive summary
  • Problem and Market landscape
  • Competitive landscape
  • Financial and impact analysis
  • Risk analysis
  • Assumptions
  • Open issues
  • Conclusions and recommendations

What Should Have Been a Good Idea

The final document was 30 pages long.  Jack decided to try something he had read about – the infamous Amazon 6 Pager. The 6 Pager is a narrative document that Amazon uses for planning purposes.  As Conor Neill described in Amazon Staff Meetings: “No Powerpoint”

“We have study hall at the beginning of our meetings.” says Jeff Bezos.
Staff meetings at Amazon begin with 30 minutes of silent reading.

Powerpoint is easy for presenter, hard for audience.  Jeff Bezos of Amazon.

“The traditional kind of corporate meeting starts with a presentation. Somebody gets up in front of the room and presents with a PowerPoint presentation, some type of slide show.  In our view you get very little information, you get bullet points.  This is easy for the presenter, but difficult for the audience.  And so instead, all of our meetings are structured around a 6-page narrative memo.”

Amazon Staff Meetings: “No Powerpoint”

Amazon was widely admired at FashGen and Jack thought by introducing one of their best practices he had a better shot at getting his idea funded.

The Big Meeting

The Big Day arrived and Jack convinced the executive team to give his Amazon 6 Pager a try. After 25 minutes of reading the CEO asked “So what do you think?”  The VP of Development started “The estimates to build and launch the API integration is off by a factor of two or three.”  The VP of Finance said “the revenue estimates are on a cash basis, not consistent with how we recognize revenue for ASC 606.  The labor cost estimates do not include burden costs.  I don’t know if Bitfinex charges some type of licensing or usage fee.”  The Chief Revenue Officer said “Our goal this year is to grow top-line revenue by 20% or $10 million.  I can’t see this adding more than a million dollars, at best.  Also, none of our main competitors accept cryptocurrencies – why should we do it now?”  The Operations VP said “Would the investment in this project slow down our infrastructure investments for eliminating SPOFs (Single Points of Failure).  We agreed in this year’s plan to fund the elimination of 75% of the SPOFs”  Finally, the General Counsel noted, “This new product will force us to redo a lot of work for our SOC 2 audit and slow that down by at least four months.”  These kinds of discussions continued for another half hour.  Eventually, the CEO brought the meeting to a close.  He said to Jack “Thanks for putting this together but it seems now is not the best time to move forward with this project.  Next time take a look at what the VP Operations prepared for his proposal to eliminate SPOFs in this year’s budget cycle.”

What Went Wrong

After the meeting, Jack and Sameer had a cup of coffee.  Jack said “What the hell went wrong?  This project is a no-brainer!”  Sameer said “we’ll have to wait until next year I guess.  They just don’t get how important the crypto world is.”

In reality, there was not much wrong with Jack’s idea, Amazon-style 6 Pager, or even the core parts of his 30-page business case.  The challenges Jack faced included:

FashGen Historical Practices.  Jack did not understand how traditionally FashGen had made major investment decisions.  His use of the Amazon 6 Pager was innovative but foreign to the executive team.  He had not researched how other major investments had gotten funded.

Timing.  Jack did not understand that FashGen’s annual business planning process, which was required by their private equity owners started in October and resulted in a finalized annual plan by the end of November.  There was no precedent for making a major investment that was not included in the plan and ultimately approved by the private equity investors.

Socialization.  Jack had not socialized the business case with any of the other departments.  He had not asked for subject matter experts in Development, Sales, Marketing, Operations, or Finance to participate and approve the relevant parts of the business case.  In the ‘Big Meeting’, the executives easily pointed out the flaws from their perspectives.  They certainly did not see how the proposal advanced their agendas for their organization.

Validation.  Jack had not done any internal or external validation of his core idea – offering cryptocurrency methods of payment would drive a multi-million increase in sales.  He had not consulted with the sales or business teams, he had not run the idea past some real customers, and he had not sought opinions from industry analysts or influencers.

Investment Alternatives.  Jack did not know about what other major projects were seeking investment too.  He did not articulate why investing in his idea would bring more benefits to the company than the other ideas that were being pitched.

Product Management Business Case Process

There is no one definitive process for building a product management business case.  You need to tailor your efforts to meet the unique needs of your organization.

The following is a guide to the principles you need to consider for your business case.  An effective process should encompass the following activities:

product management business case process



The process begins with coming up with a new product idea.  It can be as simple as a brainstorm that happened in the shower.  Or it can be the result of a more structured process like Design Thinking.   Christina Gkofa provided an excellent overview of ideation techniques in her article entitled Techniques for Product Ideation: Generation, Selection, and Implementation.  Some techniques she discusses include:

  • Brainstorming
  • Mindmapping
  • Storyboarding
  • Sketching
  • Focus Groups
  • SCAMPER (Substitute, Combine, Adapt, Modify, Put to another use, Eliminate, Reverse
  • Reverse Thinking

Regardless of how you come up with your idea, you need to find a way to succinctly communicate it to others.  A VC-style elevator pitch is a good strategy.  An elevator pitch is a short description of an idea, product, or company that explains the concept in a way such that any listener can understand it in a short time. This description typically explains who the thing is for, what it does, why it is needed, and how it will get done.  You need to describe the tangible potential benefits your product idea could bring your company.  Your elevator pitch will be critical in the future steps of the process.


In the next step of the process, you socialize your idea with key constituencies inside your company.  The goal of this process is to gather feedback and learn about potential objections before you invest too much time and energy in the project.  You should identify a potential influencer in each critical part of your organization – Development, Marketing, Sales, Operations, Customer Support, and Finance.  Use your elevator pitch to explain your product idea.  Solicit feedback, listen carefully, and do not ‘sell’ your idea.  After completing an initial round of pitches, sit down and refine your pitch based on the feedback you have received.  Ask your VP to help arrange a short meeting with each of his/her peers.  Leverage the influencer you initially briefed if necessary.  If you can’t get your VP’s support, you will not stand a chance of getting your proposal ever approved.

Before meeting with the other executives you need to develop an understanding of how they are compensated and rewarded for success.  Almost all executives have some type of bonus plan.  While they may vary by department (Sales is very different than Development), they usually have the same basic components and targets (Revenue, Revenue Growth, EBITDA, Operating Profit, Cash Flow, etc.)  Ask your VP about the basic structure of the executive compensation plan.  This information will be very helpful.

When you have a meeting with each executive your goal is to listen, not sell.  Deliver your elevator pitch and solicit their feedback.  They are not going to commit to support your idea at this stage.  Listen carefully to their objections and concerns.  Ask them if they see how your idea could help or hinder them in achieving their objectives.  The issues they raise at this early stage are generally going to be the ones they care about the most.  Assuming they are not opposed to your idea, ask them for a resource from their organization to assist you in fleshing out the business case.  This way you will get a subject matter expert to help, and the executive will have some ‘eyes and ears’ inside your project to let him/her know what is going on. 


The next step is to obtain some external and internal validation of your idea.  To begin, you need some more definition/example of your idea than an elevator pitch.   If you are a serious Agile organization you would build a Minimum Viable Product (MVP).  Coined by Frank Robinson in 2001, and popularized by Eric Ries, author of The Lean Startup, first used the term, he described it as:

A Minimum Viable Product is that version of a new product that allows a team to collect the maximum amount of validated learning about customers with the least effort.

As Tommi Raivisto noted in What Is Wrong with Minimum Viable Product (MVP)?

“When you choose to do an MVP, you choose to build your product for early adopters instead of the broader market.”

If you are not an Agile shop or are AINO (Agile in Name Only), you need some type of artifact that you can share with people.  It could be a storyboard, a wireframe, barebones prototype.  You should not spend a ton of effort on it at this stage, you just need something that can help people visualize what you are talking about.

External Validation

Ideally, you would like to talk to 10-15 existing/prospective/customers.  You want to get a sense of if your idea solves a problem they have in a way they would consider to be valuable.  You could solicit people from your company’s customer advisory board or user group.  You could also ask the influencer from Customer Support you recruited earlier for suggestions. 

If you have a good relationship with some industry analysts like Gartner, Forrester, or Ovum -Informa, you can ask them for their initial reactions.  The same holds for partners like solution providers, resellers, or consultants.

Internal Validation

Armed with the feedback from your discussions with external parties revise your product definition artifact.  Then solicit feedback from the various organizations inside your company.  The goal of these discussions is to discover flaws in your thinking and objections that could be raised.  Try and get feedback from at least two additional people per department, in addition to the influencer you recruited early in the project.


The next step in the process is to create a project plan to manage to build the business case. In addition to the plan, you need to secure commitments from everyone involved to meet the project’s milestones.

Understand Organizational Investment Timing

Your first step is to understand when your organization makes decisions about major investments.  So companies have formal annual/quarterly planning processes.  These planning processes are where large investment decisions are made.  If this occurs once a year, you need to determine if your initiative can fit into that process otherwise you will need to seek guidance on how and when you can pitch your idea.

Recruit Participants

The first step is to recruit people from each impacted organization by your idea.  This is critical.  For your business case to be credible, its components must be supported by each functional area in the company.  The VP of Sales is not going to commit to a revenue plan developed by a product manager.  Hopefully, you can leverage the influencers you recruited earlier, but you should seek a representative from marketing, sales, development, operations, customer service, professional services, and especially finance.

Draft Project Plan

 You should create a work breakdown structure that lists the tasks, estimated duration, participants, and deliverables.  Next, develop an initial calendar.  A typical participant should be required for no more than 8 to 12 hours during the project.  As the business case owner, you will be investing significantly more time.

Briefing & Commitment

Hold a short briefing for all of the project’s participants.  Circulate the plan in advance so that people can bring their objections and concerns to the briefing.  Revise the plan in real-time during the meeting and ask the participants to commit to the plan.


 This step is the core activity of the business case process.  It is here that you create all of the elements of your business case.  The process is pretty straightforward:

Design Business Case Format

To start, design the structure and format of your business case.  It is extremely important for you to reuse the formats that historically have been used at your company.  Each company generally has its approach.  A company that embraces the Scale Agile Framework (SAFe) has a fundamentally different approach to business cases than a private equity-funded laggard company that expects a discounted cash flow analysis and a three-year pro forma P&L, balance sheet, and cash flow statement.  Now is not the time to try and pioneer a new format that your executives are not familiar with.  You need to leverage what is known and has worked in the past.

All business cases should address:

  • A description of what your solution will do
  • A description of the target market and customers
  • A description of how this initiative aligns with your company’s existing strategies, tactics, goals, and objectives?
  • A description of how your solution will be implemented.  What coding languages and infrastructure will be required (databases, security, high availability, etc.)?  Will new capital expenditures be required or will your solution operate in your existing infrastructure?  How many development resources be needed?  QA? Tech Pubs? Operations?  How will customer support and implementations be handled?  Will more support reps be required?
  • How will the solution be marketed to prospective customers?  What marketing expenditures be required for demand generation?
  • What is the sales plan for the product?  Will it be sold by your existing sales force or will new reps be required?  What will the sales compensation plan be and does it conflict with the existing plan?  Will new sales quotas be required or will
  • What is the revenue plan for the product?  How much revenue and when will it come?  What is your confidence in the projections?
  • What is the expense plan for the product?  Is this an incremental expense or will it be repurposing existing resources and spend?  What impact will this have on existing and already approved plans?
  • What is the cash flow plan?  How much is required and when is it needed?  How does the project impact existing cash flow plans?
  • A description of the tangible benefits your solution will bring to the company.  What quantifiable and qualitative benefits will it bring to the company?
  • How will your initiative help or hinder the executives from achieving their goals, objectives, and comp plan targets?
  • How will your proposal impact the enterprise value of your company?

Draft Business Case Components

In this step, you draft a version of each component of your business plan.  You can approach this in several ways.  As a product manager, you can develop a draft of each component and then review/revise it with the subject matter expert that joined your business case development team.  Or you can have the subject matter expert draft the component and then review it with you.  Securing each department’s participation and approval is critical.  If someone is not consulted or disagrees with your recommendations they can ultimately block the approval of your proposal.

Once the components are completed and initially approved by the subject matter experts it is your job as a product manager to assemble them into a single, coherent business case.  You should prepare a one-page executive summary, a presentation, and a business case document.  In terms of the presentation, I suggest you use Guy Kawasaki’s The 10/20/30 Rule of PowerPoint. 10 slides, delivered in 20vminutes using no less than 30 point font. You will have the business case document if you need to refer to some specific details.  It is not unusual to discover conflicts or inconsistencies during this process.  You still have time to go back to the subject matter experts and resolve them before taking the business case to a larger audience.


The next step is to conduct one-on-one briefings with the executives of each department.  The goal of these briefings.  You should be joined by the subject matter expert(s) that helped you to build the business case.  Hopefully, they will have briefed the executive in advance of the meeting.  Send the detailed business case document in advance and use the short Kawasaki-style presentation.  The goal of this meeting is to answer any questions they may have and to surface any critical objections, Commit to incorporating their feedback into the final work product.

After the briefing ask for their commitment to support your proposal.  It is better to learn of their opposition in advance of the meeting with the entire executive team.  A ‘No’ is not necessarily fatal to your initiative.  Unless their vote is the deciding one, you still can win over the other execs.  If you sincerely incorporate their feedback you might be able to turn their ‘No’ into a ‘Yes’.


The penultimate event of the project is your presentation to the executive team.  Distribute the revised version of the business plan document in advance of the meeting.  Use the 10/20/30 PowerPoint.  Hopefully, by this point, you have done all of the groundwork required to obtain approval of your initiative.


Regardless of the outcome, you should conduct an Agile-style Retrospective meeting.  The goal of the retrospective is to learn how you can improve your product management business case development process to be more effective in the future.  Invite your entire product management team to participate so that everyone can learn from your experiences.

Remember, You’re Competing Against Ideas

It is important to remember that you are competing against other projects that want to get funded as well.  You need to show at, both a micro and macro level, why your project should get funded NOW.

One way to show the benefits of funding your project is to discuss how it could impact your company’s enterprise value:

Enterprise value is perhaps the most common metric used to describe the value of a company. Enterprise Value is the primary metric used to describe the value of a tech company. Valuations are often expressed using ratios such as Enterprise Value/Revenue or Enterprise Value/EBITDA.

The formula for enterprise value is pretty straightforward:

Enterprise Value Formula =

+ common equity at market value (this line item is also known as “market cap”)
+ debt at market value (here debt refers to interest-bearing liabilities, both long-term and short-term)
– cash and cash equivalents
+ minority interest at market value, if any
+ preferred equity at market value (preferred shares/liquidation preferences)
+ unfunded pension liabilities and other debt-deemed provisions
– value of associate companies

Most major stock reporting services will calculate Enterprise Value automatically for public companies. Here is Google (Alphabet)’s enterprise value:

Google enterprise value

Google enterprise value

Enterprise Value is different than a stock’s market capitalization. Market cap is the value of a company’s equity or stock. Market cap only addresses a part of the value of a company. It is equal to the number of outstanding shares multiplied by the current share price. While Google’s market cap is $839.8 billion, its’ enterprise value is $765.91 billion since they carry $3.9 billion in debt and they have $102.25 billion in cash.

Market Cap, cash, and debt are the most common metrics in Enterprise Value. The other components (preferred equity, minority interests, unfunded pension liabilities, value of associate companies) occur, but not as frequently.


Calculating the enterprise value of a private company is a little harder, but not impossible.  Since private companies do not publish their financials, you have to be a little creative.  Check out How to Calculate the Enterprise Value of a Private Company for some tips.

The biggest influences on enterprise value are revenues, profitability (EBITDA), and the multiple the market assigns to those values.  The bigger the revenues, EBITDA, and multiple are, the larger the enterprise value will be.  Different market segments have different multiples.  Consider this report from the Software Equity Group which regularly publishes data about SaaS company valuations:

SEG Q3 2020 Saas Valuation Segment Metrics

Software Equity Group

Once you determine what your company’s enterprise value is, you can assess how your new product could impact its enterprise value.  Will you increase revenue, EBITDA, or growth rates?  Would you be entitled to a higher multiple?  Product managers should focus their efforts on growing their company’s enterprise value.


Every company has its approach to handling investments in new product ideas.  Companies that embrace the Lean Startup philosophy have one approach.  A private equity-backed firm may have a significantly different approach.  Regardless of the format of a business case document, the process to create a product management business case is more important.  You can have the best business case and presentation.  If you haven’t collaborated with all of the impacted organizations, your chances of getting your idea approved are slim.

Also published on Medium.

By John Mecke

John is a 25 year veteran of the enterprise technology market. He has led six global product management organizations for three public companies and three private equity-backed firms. He played a key role in delivering a $115 million dividend for his private equity backers – a 2.8x return in less than three years. He has led five acquisitions for a total consideration of over $175 million. He has led eight divestitures for a total consideration of $24.5 million in cash. John regularly blogs about product management and mergers/acquisitions.