Counting the Cost

There's a set of verses in Luke (14:28-30) that are critically important for most things, but especially relevant when building software. Here's the way it is translated in The Message.

“Is there anyone here who, planning to build a new house, doesn’t first sit down and figure the cost so you’ll know if you can complete it? If you only get the foundation laid and then run out of money, you’re going to look pretty foolish. Everyone passing by will poke fun at you: ‘He started something he couldn’t finish.’

In the world of software R&D, we try not to let the cost burden our thinking and exploration (or else no R&D would be done). But when trying to turn innovation into products, it is important.

Want to know where it's even more important? Right before you decide to turn any new research or new ideas into products. Because it's likely that you have more than one idea. More than one concept.

When you're trying to take a set of ideas and figure out which one (or which few) you'll invest in, you need a method for portfolio management.

In other words, how do you decide, of many great ideas, which ones to spend your finite effort, energy and resources on?

The Journey is as Important as the Destination

Let's first assume that every person who has an idea is smart, passionate, and moving in the right direction (towards your goals). That eliminates the simple stuff like kill all the dumb ideas, or eliminate the ideas that take you off-mission.

What you're left with is several viable concepts to pursue. And that's when your portfolio management is critical.

What you don't want is a popularity contest. Whether it's because the "right" person shares an idea, or the idea is one liked by the most senior leader, these approaches won't lead you to make the most useful decisions about your investments.

Instead, what I've found helpful, is to engage everyone in a set of questions - questions that don't change as new ideas come up (we're not moving the goal posts). More importantly, the questions drive greater collaborative agreement across an organization so that there's an ever-increasing sense of alignment.

That's why I think the journey ends up paying dividends, regardless of which ideas get "funded" for further effort.

Core Questions to Evaluate

When everyone is huddled together, there are a set of 10 questions I find helpful. I've used these same questions consistently over the last 15 years to help teams build software.

1. How big is the potential market for this idea?
2. Will it allow us to easily deliver it back to our base (existing customers)?
3. Will this open up adjacent markets for long term growth?
4. How competitive is the existing landscape?
5. Will this have the potential to eliminate a competitor?
6. How technically feasible is this?
7. Is this something we're going to do or need to do anyway?
8. What kind of staff will this require? Will we need to hire?
9. How fast will we see a return on this investment?
10. How big are the risks and how well do we understand them?

As you can imagine, the answers aren't nearly as important as the dialogue that takes place. And more important than the answer of any single question for any single idea, is the comparative value of the answer across all the ideas.

In other words, you're comparing ideas against each other on the same criteria or scale. When I lead teams thru this exercise, I invite them to score every idea, against each question / criteria with a score from 1 to 10. (Of course I weigh the different questions differently.)

What I'm trying to do is not only count the cost, but compare the costs across projects. And by bringing the team together every quarter to do this exercise, we also start to notice that scores change over time.

Nothing is Ever Really Static

As you pick the top projects to invest in, you'll spend more energy and resources there. But that investment won't necessarily be perfect or keep your assessments the same. Sometimes you'll note that some projects, which seemed amazing when you didn't know as much about them, turn more complicated and costly as you spend a quarter working on it.

Nothing stays static.

The more time and energy you spend on something, the more you learn about it. And that can either raise its score or lower it. Which is why we come back to the scoring on a quarterly basis.

It also can serve to protect us from the sunk cost fallacy.

Counting the Cost

When we're dealing with innovation, there's rarely a clean price tag associated with converting R&D into products. So it's hard to count the cost. But you don't want to end up with a poured foundation and not enough money to build the rest of the house.

So along with this scoring method to pick the best ideas, I also strongly suggest keeping initial scopes small. But that's a whole separate topic for another post.