Roadmap Planning – The “King Solomon”

If you think of your roadmap as an “artifact” that just needs to be presented at 2 p.m. on Thursday, you’re missing an opportunity and also setting yourself up for failure.  Done correctly, the “roadmap,” is actually a process that you should be thinking and working toward every workday of the year.  Done right, your roadmap process is something you can manage to keep your team focused on your company’s “true north.”

The goal of today’s post is to highlight another sign that might signify that your roadmap process is working against your true aim.  This one is subtle and seductive. When first posed as an option it sounds completely logical.  In fact, you might even feel foolish arguing against it.  I call it the “King Solomon.”

The product planning process is full of emotion.  Anytime you’re reviewing the roadmap, everyone involved is on high-alert concerning his or her top needs.  In other words, all of your stakeholders have their defenses up and are burrowed in.  Good luck!  Once you’ve been through two or three roadmap sessions with your top team, almost invariably, someone brings up and advocates the King Solomon approach.  It goes like this…

The product direction oversight team does not spend near the amount of time prioritizing new development initiatives as you do.  In fact, except for their own pains and pet projects, they basically ignore it until your Thursday 2 p.m. roadmap meeting.  Executives’ mission in life is to solve problems, and it is in their nature to “solve” your roadmap issues inside the ninety minutes you devoted to a review.  This is bad news for your goal of keeping the company on its path toward true north.

Undertaking roadmap-planning sessions takes time and stirs up lots of difficult decisions.  The management team involved, many of which aren’t as close to the actual building of software, starts to better understand that they can’t have everything.  Making trade-off decisions is hard! Sooner or later it happens, the “King Solomon.”  You remember the story; two women come before King Solomon, both claiming to be the mother of an infant.  With no way to determine the true mother, King Solomon declares that the only fair way is to divide the infant with a sword and give each woman half.  His wisdom, of course, is that the true mother’s love will cause her to forsake ownership to save the life of her beloved child.  Unfortunately for your roadmap, what gets proposed is dissection, minus the wisdom.

Here’s how it works.  Because members of senior management do not confront the competition for engineering recourses daily, the way you do, when they get into your roadmap meeting, their instinct is to simplify.  It might happen in your first roadmap meeting, or it may be in your second or third, but here is how it goes.  In an effort to optimize resources, someone proposes the following.  “Hey, let’s do this.  Because we’re releasing software several times through the year, let’s dedicate a percentage of capacity toward each of several categories of development.”

The proposal is that for each release “X” percent of resources go towards sales features.  “Y” percent of features go towards customers satisfaction (a.k.a. bug fixes), and “Z” percent go towards “the platform.”  It sounds perfectly logical.  In fact, you may feel like an ass fighting such magnanimous, straightforward thinking.  Surely this is the right and “fair,” way to make progress on multiple fronts.  Management, in all its wisdom (within a ninety minute meeting anyway) basically guesses what percentage of resources each category deserves.

I typically shy away from military and sports analogies in business communications, but I can’t help it this time.  Confronted with three hills he needs to take, what military commander would divvy up his forces into thirds and attack all three at the same time?  I’m no warlord, but my guess is only a poor one.  In product planning as in a battle, you want to concentrate your forces on specific goals.  “Peanut buttering” your engineering efforts across all needs is the same as abdicating product decisions.

If you agree to the King Solomon, if you allow this to be enacted, you’ve just given up the role of product manager.  You have ceded the control you’ve earned through customer knowledge and expertise to a blunt force formula.  Don’t get me wrong, it’s not an ego thing, but if prioritizing resources were as easy as this there would be no role known as product management

Rightly or wrongly, if there is a “cardinal sin” in Product Management, it is idle engineers.  Rather than being focused on productive throughput, most of our industry is blindly focused on engineering utilization.  One of the best new conversations on the block is the entire Lean Startup movement, whose focus on product/market fit advocates doing and testing the right thing, not just doing.  In the meantime, don’t allow your true north to be hijacked by the King Solomon.

Your roadmap is not just an artifact.  It can’t be.  In needs to be a process.  Your goal is not to “close” the team on the proposals of a single two-hour meeting.  Your goal needs to be an iterative process built on trust, and improved over time based on delivered results.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s