Jen Handler, Product Manager at Pivotal in Atlanta, offers a new metric to consider making part of your next business case submission
Prior to joining Pivotal, most of my career had been spent working for large enterprise companies where I participated in long, complex budget planning processes. Every year, I’d have to submit elaborate business cases for complex projects in order to get money to pay for them. I’d have to answer questions like: What’s the solution we’re building? What are the key features? What kind of money or cost savings do we expect to see as a result this year — and over the next five years? What’s the Net Present Value? How quickly will this depreciate? Etc. We’d throw our business cases together as fast as possible, then suffer through several rounds of reviews and scrutiny to invariably get less money than requested.
For anyone who is even a little responsible with money, this kind of process can be nerve-wracking and downright painful. We’d always make lots of assumptions to get this money, some of them riskier than others — and by risky, I mean, if we were wrong, the business case would fall apart. We’d have to note these somewhere in our request. But the only thing we’d need to report back on, post-project, was the impact we had on our success metrics. Typically these were cost and/or revenue-driving metrics like audience growth rate, churn, or avg. cost per acquisition. Metrics that would take a long time — and sometimes, forever — to impact because of our assumptions.
My belief that there was a better way to address and manage risk in the earliest stages of product development is part of what drove me to Pivotal, where we make identifying and testing the riskiest assumptions a top priority throughout the software development process.
But for my thousands of former colleagues, and anyone who’s struggling with the same kind of budgeting process but wants to find a better way, I offer a new metric to consider making a part of your next business case submission: Time to Truth.
Time to Truth isn’t directly about cost savings or revenue. Instead, it’s the time it’ll take to validate, or invalidate, the riskiest hypotheses underlying your business case. By “riskiest hypotheses,” I mean the ones that’ll break your business if you’re wrong.
The next time you’re building an elaborate business case, be the first to really scrutinize your assumptions. Consider: Do you have them all listed out? Think about every box of the Lean Canvas. Are you making assumptions in each box? Get out your sticky notes, and list one per note.
Next, rank these across two axes: (top to bottom) Urgent/Not Urgent, and (left to right) Not Important/Important.
Finally, take the ones in your upper right (Urgent/Important) quadrant. Urgent and Important assumptions are those that present the most risk to the business case if you’re wrong.
These become the first “truths” to validate — or invalidate. You’ll want to work on these quickly, too. Set goals for just how quickly, and see if you can beat them. Just by setting a goal that’s a tiny bit aggressive, you’ll create some motivation to take action — and with that action, you’ll be derisking your project.
We did something like this for my last project with Pivotal Labs. Our project team realized very early on — in the first two weeks — that we were making some huge, problematic assumptions about the very platform with which we would have to integrate. We started by listing these out as a team, then sized the amount of risk they presented to our success if we were wrong. Once we had our riskiest assumptions identified, we devised ways to test them quickly via the delivery of small features.
Once we had our riskiest assumptions identified, we devised ways to test them quickly via the delivery of small features.
The work doesn’t end after validation/invalidation of an assumption. Ideally, you’ll be able to modify your budget based on learnings along the way. If, say, you invalidate a key assumption but then find some new piece of information in the process that gets you closer to developing a sustainable business — but one that requires some additional money to fund — ideally you’ll be able to get it.
This kind of process change is big, it takes time. But by baking Time to Truth metrics into your business case and product development process in the first place, you’ll start to influence that kind of change — and your business will be better for it.
Change is the only constant, so individuals, institutions, and businesses must be Built to Adapt. At Pivotal, we believe change should be expected, embraced and incorporated continuously through development and innovation, because good software is never finished.
The Risk Reduction KPI: Time to Truth was originally published in Built to Adapt on Medium, where people are continuing the conversation by highlighting and responding to this story.
