Of telling stories and writing business cases

Most product people I know understand telling stories and having a great business case is critical for any product leader.

In my experience both are necessary conditions for a product’s success (of course its almost impossible to list out necessary and sufficient conditions). First telling stories. We’ve all been told countless number of times how stories really make ideas stick, or how people remember a story in presentations even if they don’t remember statistics, mock ups etc. presented. There is an obvious reason for it, we are hardwired that way. Stories just stick with us.

However, most product people I know don’t take the time to tell them well. Why is that then, if it is so clear that good stories matter? I attribute that to a combination of things: telling good stories takes effort. It is not something you think you’ll need, since the obviousness of your idea is so plainly visible (to anyone who has spent as much time thinking about it as the product leader) — therefore, high effort+low percieved need = no go.

However, taking the time to understand what context people in the room have, how it differs and what the least common denominator is ends up being critical. If your story does not make sense to some people, they are likely to ask basic questions. That is bound to make the others feel a little annoyed and will make you wonder why you didn’t syndicate this with that group separately. Countless times I’ve seen as an engineer, a management consultant and as product manager, how things start breaking if you don’t have a good story to lead with. This can wreck havoc on the most well planned meetings. So the lesson here is, take the time to craft a good story, it’s certainly worth it, and almost necessary if you want to succeed.

Now, the business case. Equally important, often thought of as more boring and worthless than telling stories. Likely also the only real defence you have against detractors. Funnily, the less you prepare your stories and business cases, the more detractors you seem to get. Its a loop and not a virtuous one.

Too many times, product leaders think the need for they are building is so great, and the problem so difficult that no one else will challenge the need for it or have parallel/competing ideas/plans. Its never fun to find out someone has already thought of a better solution, after you’ve spent a week on a problem. Worse is when people ask if this is really the biggest problem we should be focusing on (unless of course its not the biggest problem you should be allocating resources to :))

So how do you ensure 1. You are the only one focusing on the problem 2. It is indeed a worthy problem 3. How do you craft that story

The answer to these questions, is writing a business case. Start typing out in text editor of choice the key questions, hypothesis and peer analysis. Who has faced this challenge, how did they solve it, what was gained, what can your team gain, why now and what are the numbers assocaited with these analyses. Make useful charts to illustrate points, have clear titles with ‘so whats’ and make sure your numbers tie from page to page — basic sanity checks. This exercise will be very helpful. It’ll answer most of the questions outlined above and will serve as solid collateral to take to meetings or send around. So dont wait, its an iterative process. Start today.