The creation of “business cases” and presenting them to stakeholders is often one of the most reviled parts of the job among product managers. Everybody knows they rarely reflect the end result accurately, and you always end up explaining “why it didn’t happen.” In the worst case, it can also result in setting too low ambitions or expectations. Many product managers think this part of the job is a waste of time.
To me, it is important to emphasize what a business case essentially is: primarily a useful communication tool towards stakeholders and a framework for my own thinking around the assumptions and logic of a product initiative.
- Thought Process: The process of creating the business case leads me through many useful thoughts, considerations, and market analysis, preparing me to defend product initiatives to stakeholders.
- Communication Framework: It is a highly useful communication framework that can lead to productive and concrete discussions with stakeholders, often resulting in adjustments to your assumptions or logic.
- Deep Thinking: The business case gives me a reason to think deeper and more structured about my assumptions, often leading to “aha” moments.
- Retrospective Learning: A good business case can retrospectively feed into your product discovery process. It provides a clear picture of your thinking at the time of creation, which can be compared to your current situation. This often reveals which assumptions or logic failed or were missing, providing important learnings.
By the way, I feel the same way about “prioritization frameworks.” Personally, I often use R.I.C.E., because it gives me a structured way of thinking about the realization of the product features we are planning. The intuition element will always play a big part in prioritization, but a good framework is a useful tool to both ponder and discuss priorities in a group setting.
Leave a Reply