Creating a Compelling Product Business Case Q&A
By Jerry Rackley and Cindy F. Solomon
Demand Metric presented a webinar, Creating A Compelling Product Business Case, for the AIPMM Webinar Series. Thanks go out Cindy Solomon, the talented and gracious host for the event, and for all the folks who attended. We had a very engaged audience for this webinar judging by the number of questions we got. Since we weren’t able to answer them all during the session, we collaborated in an attempt to provide some answers here.
Q: Where can I access the Product Business Case template presented as a resource?
A: Join the AIPMM at Premium Membership Level to get the full set of Demand Metric and AIPMM ProdBOK approved productivity tools. Here’s a link to the full set of tools: http://www.demandmetric.com/aipmm-productivity-tools
Q: Where can I access this webinar?
A: Slides and information about replay will be available here.
Q: At what time of the product development should we have a solid business case? It looks like MRD and PRDs are already ready before we draft a business case…
A: Ideally, developing the Product Business Case happens during the “Idea Generation” stage of the product development process that occurs within the Conceive and Plan stages. The AIPMM 7 Phase Product Management Framework identifies actions, deliverables and milestones that the product travels through. The identified product lifecycle stages are Conceive, Plan, Develop, Qualify, Launch, Deliver and Retire.
Following AIPMM’s best practices and processes, MRDs and PRDs are generated for the same purpose and to capture the same information incorporated into the product business case – use them as input for the Product Business Case if they’re available. Otherwise the Product Business case serves the same, perhaps abbreviated, purpose and you can still craft a good one even if those documents don’t exist.
Q: How much time is typically invested in creating the Product Business Case?
A: Typically, it will take several weeks to do this, not because the document is so long, but because the process requires it. It takes time to thoroughly research a Product Business Case. As important, it takes time to make the process collaborative, because that is where the critical flaws are revealed and how buy-in is generated. Don’t try to shortcut either or you’ll end up with a sub-optimal Product Business Case.
Q: I was dropped into a project that had already been blessed and given the go ahead without a business case. Now that we are in the product specification phase, there are conflicts that would have been avoided with one. Is it ever too late to submit a business case?
A: No, it’s never too late to submit the Product Business Case! It’s not too late to do it now, and you’re actually in a good position as the newcomer to lead the team through creating a Product Business Case. The issue you’re likely to face is grumbling about the necessity of doing so, since the project is already approved. What you’ll need to do first is educate your project team on the value of the process. A good way to begin is by asking some fair but pointed questions that you know are answered in a Product Business Case, such as “what’s the profit and loss projection?” If you get quality answers to these questions, you can feel comfortable proceeding. But chances are you won’t, so you’ll have made your case for putting one together.
Q: Any tips on how to balance the research process while not giving out too much product/service information as you are flushing out the MRD?
A: I don’t know how to avoid this, but remember, by putting together a solid MRD, you have essentially completed a major section of your Product Business Case. You shouldn’t find yourself having to repeat the effort.
Q: Usually the Product Business Case is built considering the utopian world. How do we provide physical evidence? Does physical evidence mean some stats from Analysts?
A: Do NOT create the Product Business Case to reflect a utopian view, even if its held by top execs – use the opportunity to shed light on real world circumstances (refresh your resume if you’re obligated to justify an unrealistic vision)!
The document should be a fact-based business case that is ideally conservative, to provide threats and opportunities based on real world data. This is the key value that the product management professional brings to this process: circumvent the failure that follows limited resources wasted on unnecessary innovation or investment in building products unrelated to market needs. It’s okay to include a best-case “utopian” forecast for success in a SWOT analysis, but the worst-case scenario is also appropriate – even necessary to include. The purpose of going through the process to create the documented Product Business Case is to uncover unrealistic views and have data to arrive at contextually appropriate recommendations based on the case of the business for the product!
Regarding citing evidence, analyst opinions are helpful, as is most third party input, however the best data comes from the market, customers, buyers, users, and competitors in the space. Customer data that is both quantifiable and also narrative case studies are compelling, as well as information about competitive activity and positioning all provide excellent supporting evidence.
Q: How do you get your Product Business Case approved at the first go? Any tips?
A: Two things help accelerate the approval of a Product Business Case: the quality of the research and the degree of cross-disciplinary collaboration that went into creating it. A well-researched plan that is perceived as objective and had the involvement of all key stakeholders in its creation usually enjoys a fast-track approval.
Get buy-in for the process of creating the product business case from the beginning of the process, keep stake-holders included in the progress and don’t be afraid to grapple with disagreements on recommendations – this is a potentially political process which guarantees buy-in since all perspectives will have been explored prior to seeking approval.
Q: I would like to understand how to deal with opposing forces in the organization? Engineering is usually resistant to change.
A: This situation calls for bringing in the voice of the customer, any way you can. It’s much harder to resist change or say “no” when the customer is doing the talking and when the data is provided. It’s easy for Engineering to resist change when they operate in relative isolation. One of Marketing and Product Management’s jobs is to make sure this doesn’t occur by helping all parts of the organization, Engineering included, see their connection to the customer and hear their voice on a regular basis.
Including Engineering in the process of building the Product Business Case will gain their respect and buy-in for the changes being recommended. Only by listening to and understanding Engineer’s concerns and experience in previous product development projects gone wrong, as well as other internal stakeholders’ who may be resistant, will the product manager gain the respect and collaboration necessary to guarantee the success of the product once the Product Business Case is made.
Q: What are some suggestions for getting group buy-in prior to pitching the Product Business Case?
A: Ideally you will have group buy-in before pitching your Product Business Case, and this is generated through building the Product Business Case collaboratively. Never walk into a conference room to pitch your plan without doing due diligence and knowing in advance that you have the key stakeholders’ support.
Q: With collaboration there is often a loss of ownership. Since ownership is an important part of the process are there any recommendations on how to get contributors to buy in and not just contribute?
A: Yours is an excellent, if unfortunate, observation. Strong project management skills can help make sure ownership of the process and its components is not lost. Clearly setting expectations about ownership, contributions and deadlines will help. Even seemingly small gestures, like listing all the collaborators as co-authors of the plan can make a difference. In the end, you have to explicitly ask for what you’re seeking from your collaborators: “will you support the approval of this Product Business Case?” If you don’t get a firm “yes”, then you have to ask: “what will it take to get your support?”
Q: How do you get the CFO to sign off? (If the CFO is required to)
A: You have to speak the language of the CFO, which is financials. Ideally, someone from the CFO’s team has been a collaborator and will attest to the thoroughness of the research and projections in your plan.
Q: Is the product manager to run the product development process as a project manager? How would one advise on running an approved project without upper management support?
A: The answer depends on the resources available, size of your organization, product development process in place (Agile or Waterfall), type of product and defined requirements, as well as identified functional boundaries specific to your situation.
In terms of running an approved project without upper management support, the issue here is one of resources. In this situation, a successful outcome is quite achievable as long as the necessary resources are committed to the effort. If resources become an issue, then things can get ugly. If, when you say “without upper management support” you really mean involvement, then hopefully resource issues are resolved by bringing them to management’s attention. If on the other hand lack of upper management support really means resistance to the project, then your options to resolve resources conflicts are creativity, guile, partnerships or alliances.
Q: How do you go about defining and assessing the fit of a product in a wider portfolio, especially in cases where multiple products meet the same market need?
A: This is where positioning becomes very important. Products can certainly appear to overlap and have some redundancy. What’s necessary in this scenario is to know what differentiators exist for all products, how they’re perceived in the market and what different use cases exist for each of them. When these things are well understood, it then becomes a matter of supporting the differentiation with marketing communications that help the market understand the niche into which each product fits.
Q: I have a new product that will ultimately cannibalize a legacy product. It has a lower cost base but does not currently address all of the market requirements covered by its older sibling. Until we hit volume sales with the new product we will not be able to invest in treating it as a full replacement.
A: Your legacy product has entered the Retire phase of the product lifecycle – its necessary to develop a plan for how to address the business case for managing the product at this stage – going through the same steps to develop a Product Business Case for the legacy product will enable you to determine best approaches – do you recommend that the product be phased out, repositioned and/or outright replaced?
How will this be communicated after sales has abandoned it? What resources need to be identified to guarantee successful retirement of this product without sacrificing brand value, public perception, or creating a problem for customer support?
Q: If a product has multiple releases, does it require a separate business case for each release? What are the best practices in business case development/financials for a product spanning multiple releases?
A: A Product Business Case can certainly span a series of product releases, and in fact probably should. So, for example, if you launch version 1.0 of a product, your business case and release plan will probably cover versions 1.1, 1.2, 1.3, etc.
What really determines whether a new Product Business Case is needed is how disruptive or “breakthrough” a new release is. When the next release really has potential to produce a seismic shift in the product space, it probably merits a new Product Business Case.
Q: I see the value of a Product Business Case but do we always need one? I have used MRDs and PRDs to cover the elements that you discussed in your Product Business Case. Should there be a separate Product Business Case and how should that be kept different from an MRD and a PRD?
A: The value of the Product Business Case template and process as presented is the process it leads you through – no stone goes unturned. If your MRD and PRD development process is comprehensive and leads you to consider all the components of a good Product Business Case, then you don’t need to make extra work for yourself by creating a third plan that is essentially redundant.
Q: I’ve always considered the Product Business Case as a business plan applicable to a single product, what differences between a business plan and product business case do you see?
A: Your perception is correct – the Product Business Case is a specialized business plan, unique to a specific product. At the organizational level, there ideally is a business plan that describes how the organization will operate and create success that includes the vision and mission for accomplishing the vision. A critical success factor for most business plans identifies one or more product plans, or the plan for the portfolio of products. Given that products (which include services, software, physical & intangible) are how companies generate revenue, an organization must have both an overall business plan and supporting Product Business Cases that justify every product development, innovation and current portfolio of products.
Q: Does every product have to solve a problem or is it a need…a new experience?
A: Whether a product solves a problem, a need or offers a new solution or experience depends on your specific type of product and company context. What is your company in the business of delivering? How does it generate revenue? Are you justifying a new feature to an existing product, a new product line or a new product category? Developers, engineers, User experience and design professionals will respond differently, but it is up to the Product Business Case champion to establish the proof that there is a revenue generating opportunity to proceed with this product endeavor.
If you’re trying to build a Product Business Case for a breakthrough product for which no one is asking, understand how it changes the risk/reward equation. It’s likely to face higher barriers to acceptance internally, but provide greater payback if successful when compared to incremental product enhancements.
Q: I am part of R&D/Innovations team and we push concepts through the organization. I have people telling me we only develop products if we solve a problem. I disagree…we could improve a customer experience.
A: I completely agree with you, and I would add that improving the customer’s experience is solving a problem for them. It makes their work easier, less expensive, creates loyalty, etc. You can write a very strong Product Business Case on the basis of improving the customer’s experience.
Be very careful to define what is meant by “the customer experience”, “solving the problem” and even product development. Different disciplines and functions apply different definitions than product marketing and product strategy.
Q: How would you characterize a Product Business Case versus a solution business case–solution being a combination of products, components, to meet a specific problem in the market?
A: A product is defined as a good or service offered by an organization that affords benefits to the user in order to generate revenue.
In my opinion, there is no distinction in the process of building a business case for a tangible product or a service. It’s needed for both and you should apply the same rigor to building a business case, whether it’s for a product or service.
About The Authors
Jerry Rackley joined Demand Metric in October 2011 as Vice President of Marketing & Product Development. He began his 28-year marketing career at IBM, and his work record includes experience in the technology and financial services sectors. During his career, he has worked with companies ranging in size from startups to members of the global 1000, performing marketing, marketing communication, public relations and product management work. A graduate of Oklahoma State University, he is an adjunct Marketing faculty member in the Spears School of Business.
Cindy F. Solomon is the voice of product professionals! Listen weekly to Global Product Management Talk at http://www.blogtalkradio.com/prodmgmttalk Solomon hosts StartUPTalk Radio, produces Startup Product events, and created the ProdMgmtTalk mobile application. She is an innovator, early adopter, serial entrepreneur, product management evangelist, content marketing & social media strategist, and contributing author to several books, including “42 Rules of Product Marketing”. Solomon brings over 15 years of web development, services, and software product marketing and management at Apple, Vadem, NetObjects and start-ups in Silicon Valley. She holds CPM/CPMM certification. www.linkedin.com/in/cfsolomon