What's In a Business Case

This morning, I read Jeff Gothelf's article (https://www.dhirubhai.net/pulse/what-should-included-business-case-jeff-gothelf/ ) with interest.

Business cases are one of those things that seem to mean different things to different people. Traditionally, they are used as an primary input to obtaining approval and funding to do something, most often a 'project' with a defined work product or deliverable. This, as I have written before, is eminently anti-agile.

A traditional business case contains analysis with an estimate of the size of the potential market and what penetration can be achieved with the anticipated product. This almost always falls somewhere between a pipe dream and a steaming load of crap. It should be viewed skeptically, if not ignored outright.

Ultimately, incorporating the flimsiest gossamer whisps of logic, the business case is proffered as the justification for investing some large amount of money and time in order to achieve nirvana. Occasionally, these dreams come true, but most often they go down in flames. it happens in established companies, it happens in younger companies, it happens in start-ups funded by early-stage investors and VCs.

Lean Startup thinking and product discovery practices are patterns intended to work within the context of available information while managing risks by making very small incremental investments. One thing that a company must do to maximize the value of this approach is to be very intentional about articulating questions, targeting and collecting information and developing customer insights before ramping up investments.

What must be done to incorporate them into our companies' product development approaches?

OKRs

OKR discipline must be employed. It is linked to the notion of user problems (or 'jobs to be done') as opportunities. Jeff rightfully asserts that the company should think about what customers will do differently if it introduces a successful new or enhanced product. One of the important things about OKR discipline is that it focuses on WHAT the company needs to achieve (e.g., market penetration based on helping customers do something better) and not so much HOW (e.g., product characteristics and pricing) it will achieve it. At this point in the ideation and planning process, it's likely that the company will not know much that will be required to define WHAT really needs to be built. It's very easy to assume WHAT and then begin focusing on HOW only to find later that you had the wrong WHAT. As I have said innumerable times: "When HOW precedes WHAT, disaster follows."

The sort of thing most often seen in traditional business cases goes something like this: "There are 100 million people that fit our target profile. 25 million already use our competitors' products, which leaves 75 million approachable customers. We should get 15% of them in the first year (How do we know this?) which implies revenue of some number. Therefore, we can afford to invest some number to develop and market the product, which will result in a first-year ROI of some percent and a five-year return of some other percent."

Whew! That is a steaming load! And . . . a really tenuous basis for investing money.

Opportunity Portfolio

The company should maintain a portfolio of 'opportunities' and invest in investigating and exploring them. This is important! The portfolio should not consist of products that the company may or may not build. Focusing on product at this stage closes the company's mind to alternatives and is apt to send it down unproductive pathways trying to justify premature investments in 'projects.' Clearly, some notion of size, scope, risks and potential return must be applied here. Adding a new feature to an existing SaaS offering should not be treated with the same level of rigor as a Mars expedition.

Also, the portfolio should not just grow ad infinitum. It's worth keeping some speculative opportunities in the portfolio because solutions for complications that have made them infeasible in the past may emerge, putting them back in play. On the other hand, the portfolio should be pruned regularly so as not to occlude focus. As marketers have learned, too many options only causes decision paralysis. If the enhancement that makes dialling a rotary land-line phone easier is still in your portfolio, you can safely drop it now.

All-in, portfolio management requires the information necessary to assess investment requirements; potential strategic impacts and returns; risks, assumptions, questions and hypotheses to be answered, confirmed or refuted and so on. It's your job to prioritize your opportunities and then acquire the information and perform analyses required to exploit them.

Opportunity Evaluation

You need to plan your opportunity evaluation and product discovery process to investigate, evaluate, review and revise iteratively. You must prioritize the questions you're going to attack to accelerate your ability to make go/no-go decisions as early as possible. This implies that deal-killers should be moved to the head of the line, if possible. You must be able to articulate how you will structure this process for your management. Rapidity and efficiency in doing this is what will enable the sort of agility that underlies true competitiveness.

Product Discovery and Product-Market Fit

Ultimately, your goal is to identify a product that will produce favorable answers to four questions posed by Cagan, Torres, Peri and others:

1. Value Risk: Will customers buy our product?
2. Usability Risk: Can we deliver it in a form such that they can figure out how to use it?
3. Feasibility Risk: Can we build and operate it with resources we have or can acquire?
4. Business Viability Risk: Does this business make sense for us?

So, what should go into the business case:

Business Strategy and OKR Framework

It should begin with reference to the strategy and outcomes defined at the top level of the organization: What outcome does this imitative address? What key results should we use to assess success of the initiative as it progresses.

Opportunity Identification and Qualification

What user problem are we addressing? Who do we believe has this problem and how will solving it for them make their life better? What do we think they might be willing to pay for a solution to their problem? What's the current market for this solution? Who else is in it and what market share do they already own? What are the major risk factors? Overall, how risky is this?

Analysis

What questions, assumptions and hypotheses must be addressed in the course product discovery? How long will it take and how much will we need to spend on this? What should we prioritize and how can we optimize the process? How will we manage and mitigate risks? What do we think the initial (or the next) sprint should cost and how long will it take?

This business case is very different than a traditional one. It is intended to win approval to start exploring an opportunity, not to fund a project to build a product. It will justify an investment of a small team of people for a few months at each (renewable or cancelable) iteration, so it does not need all the high-flying prognostication that is so often debunked only after a lot of time, effort and cash has been wasted.