Business cases that work Part 1/2
There is a time in the life of a product manager where a justification is needed to start a new product, prove its value or expand its capabilities. As a product manager, you are competing against other company resources and a business case is a great opportunity to demonstrate to the company your judgment and strategic mind, as well as your analytical and presentation skills.
Call it a business case or an MRD – every organization seems to be doing this differently. Some organizations require the use of a pre-formatted template that may or may not fit the need of your product, others need a 2-pager. In this 2-part post, we will be discussing 12 tips that will make your life easier and improve your chances of success, irrespective of the format required.
- Budget at least 90 days for a medium to large business case. If someone asks you for a business case in less than 90 days, they are setting you up for failure. If you don’t have 90 days, reduce the scope of the business case to something that can be written in 90 days (or break it into multiple phases Your execs will remember the end result only, not the circumstances of the effort. Why 90 days? You will need to speak to many parts of your organization to determine potential revenues and costs and not everyone is readily available. It will take time to compile the information. Count at least 30 days for the review process: your management will request to review the document before it goes out, and when it is final, you should distribute it at least a week in advance of the presentation.
- Organize your effort. What information do you need from others, who can provide it and in which timeframe? Who will review your drafts? Tell your reviewers when the first draft will be available and establish strict deadlines for the review process. Schedule appointments with whomever you need to speak with as soon as you can. Put together a mini-project plan that includes what you plan to accomplish and when. Add some slack and get support from your manager.
- Make it short. In such an exercise, there is a temptation to be exhaustive and bring up as many details as possible in order to demonstrate your mastery of the situation. The truth is that no one reads long documents anymore. Keep it to 10 pages and include the 1-page executive summary. That’s what most people will read. You can always compile your backup information in support slides or in a separate document.
- Include a “business risk” and a “business assumptions” sections. These are the most important parts of the business case: what are the market assumptions that you make? How will the competition react? What could go wrong? In these sections, you can truly demonstrate your strategic talent and clear understanding of the situation. Limit the number of risks and assumptions to 10-15 each and make sure the list is prioritized. Run that list to a few people you trust. These sections will increase the trust in your document as your audience will notice that you left no stones unturned.
- Do not write your business case in isolation. Work with your fellow product managers. How does your new initiative relate to your company’s overall strategy? How can you leverage your fellow product managers’ effort and how will they be able to leverage yours? Were the last business cases presented successful? Why? What was the executive management feedback? How can you include that feedback in your effort?
- Outsource the number-crunching to Finance. Or at least get their endorsement of your math. Even if you are a science major, if one person finds one single error in your spreadsheet, your entire business case has lost its credibility. Do not let that happen to you and work closely with finance to work out the costs, taxes, run rate and proper amortization techniques. That way you can be certain that your CFO will be behind you and no one will attack your numbers.
Barry Paquet (3)
mark (3)
David Locke (2)
Greg Strosaker (2)
kk (2)
[...] I’ll not discuss how should be done, I just have some remarks in regards to this subject and a post on a blog that I have just [...]
Like or Dislike:
0 
0
Hello, Thank you for your comment. You have a great blog. As for the 30 days, I am sure one can pull this off, depending the size of the investment and the type of company. However, if you want to gather information from withing the company, talk to analysts and customers, produce not only a document, but also a presentation as well as getting the consensus to have a reasonable chance of getting a go ahead, 30 days seems way short.
Please continue to provide feedback. Thanks
Like or Dislike:
0 
0
Many times decisions are made before the business case is presented. You are often in discussions and meetings cioncerning the project before the real presentation. It is necessary to have a consitency in these discussions. When numbers and estimations change rapidly and extensively the project/product manager’s credibility is decreased.
One way of doing it is to work with scenarios or to make a small simulation program (in excel) for others to work with. This will also identify critical succes factors.
Magnus Billgren
Product Manager Specialist
Like or Dislike:
0 
0
Hello Magnus. I love Sweden and the islands when you approach Stockholm from the sea…
You are absolutely right. When everything changes, it is the role of the PM to lead the discussion and limit the number of assumptions or estimate changes.
Your comment is a great into to my next posts which will deal with Monte-Carlo, sensitivity and break-even analysis.
Like or Dislike:
0 
0
I am increasingly returning to your blog. Good work.
I could argue on the specifications a but but agree. As for pre-made business decisions: I would state that there is always questions and justifications that occur throughout a lifecycle, even if the business decision has been made prior to life. You often (if not always need) a guiding principle document/collection that becomes the common mantra and solid justification that is needed to help guide it through.
Like or Dislike:
0 
0
Thank you for the compliment Mike.
In the case of pre-made decision, I would argue that the role of the PM is then to point out the risks, issues and assumptions of the business case. Documentation work as you state, but also trying to communicate the most important issues to the executive committee: “you want me to do this, Great but this is what I need to be successful and this is why”.
However I have found that this crowd often changes or has a selective memory!
Like or Dislike:
0 
0
Thierry:
Great post!
90 days – in most case would be a luxury, the “carve-outs” are important – management in some cases believe this should happen over night “after all they came up with the idea in only a short time” you should be able to quantify just as fast
Make it short – critical and with only the key stuff, use a file of working papers to back up recommendations and conclusions, similar to audit working papers
Don’t do it in a vacuum: Getting sign-off is key but in the finally analysis only the perception of audience matters (company execs, customers, etc.)- so much for sign-off
Risks and assumption – definitely critical but should the powers that be have already made a decision and fail to accept rationally derived fact based recommendation se le vie – if things don’t go well the product manager usually gets “shot” despite this CYA
Hope this is not too skeptical but I have practical experience to support it.
Cheers
Rob
Like or Dislike:
0 
0
Thank you for your comments and compliment.
I want to stick to my 90 days, because if it takes less time, costs figures will be an approximation at best. Depending of the level of investment and the size of the company 60-90 days is what you need to get figures and approvals. If your management is not willing to give you the time, they don’t think your business case will make a difference. Then why do it?
Regarding your last comment, it seems that both of us have felt a lot of pain on this topic. I place my personal integrity above everything else and the assumptions/risk sections are what keeps everyone honest. If management decides to ignore those, it is not in the control of the Product Manager, bu it is their loss. Plan for the worst and hope for the best!
Like or Dislike:
0 
0