(Adapted from my ProductCamp Austin presentation- “The (Road)map Warrior- Tactics for a Product Manager’s defining battle“)

The most important role of Product Management is to keep a company or business unit focused on it’s “True North.”  As the product manager, you may or may not be the person who set the vision, but it’s your job to “carry the flame,” of what it means to be going after a market opportunity.  It’s your job to “grok” the customers you are aiming to serve, and to continually course-correct the organization to the path that builds out that vision. Unfortunately, one of the processes most associated with Product Management frequently hijacks a PM’s primary purpose- Road mapping.

The Road map process is a double-edged sword for Product Mangers.  If treated as a continual process, it can be a fantastic tool for helping your organization make investment decisions.  If treated as an event that happens once a quarter, it’s a mine-field of potential problems for both your company and your job.  Roadmap meetings seem to creep up and attack product managers at the least convenient times.  Fortunately, there are some signs that might signal you want to perk up and be more proactive about your process.  In this post and the next I’ll highlight two of those signs.

The first sign is what I call the “Algo”rithm Method.  I think that most every Product Manager has used this plan of attack at one point or another.  It goes something like this.  You’re a new product manager or a product manager at a new job.  Everything is new.  New company, new market, new customers, new technologies, new (to you) codebase.  As you do your rounds of meet-and-greets across the organization, you quickly figure out that the product you’ve inherited has lots of baggage (see Your Baby is Ugly).  You quickly start to feel overwhelmed.  But it’s okay.  You went to business school (maybe), you’re analytical, you can handle this. So what do you do? You build a spreadsheet!

Up to this point where there’s no harm there’s no foul.  If writing down and grouping customer requests, major defects, and interesting sounding feature definition helps you get your head around the product, go for it!  Where your “true north” becomes imperiled is in the next step, the “algorithm.”

Okay, maybe not a real algorithm, but what happens is that Product Managers grasp for a way to use data to justify what to build next.  Not the wrong instinct at all, but in this case there’s a “gotcha.”   First come the categories.  Revenue, customer satisfaction, technical debt, engineering effort, etc. The categories differ by the person building the sheet, but the idea is that you then score each proposed feature in some way.  These scores are then put into a “special magic calculation” (sorry, it’s PM black magic, we can’t disclose the code to outsiders), which then spits out a ranked priority of all requests.  The proverbial “Voila!” And of course this is where you’ve just shot yourself in the foot.

There are several problems with the algorithm method, but the most glaring is that you have just ceded all of your control as a product manager to a spreadsheet.  The seductive, slippery slope is that you now are of the mind that Microsoft Excel can “tell” you what order to build things in.  However, what no Excel formula (at least none I’ve ever seen) can really account for is, “your true north.”  This point will be lost in the ensuing meetings.  What happens instead is that the product manager pulls out the spreadsheet in roadmap meetings to help sell his or her proposed plan of attack.

First they go after the categories.  “What do you mean by Customer Sat? Does that mean you’ll fix all P2’s and P3’s?”  Several rat-hole discussions ensue.  You’re thinking ahead to when they’ll question the how the scores are calculated, but you’re never going to make it that far.  Right about here your founder/CEO typically pipes up, “Why is line number four an engineering difficulty of seven?  When it was just me building the product I could code that in my sleep!”  (And of course, he’s right, it should be a two, but you can’t very well tell him that it’s now a seven because we now have to build it to work inside the shitty spaghetti code he knocked out years ago in his dorm room!) The feeding frenzy begins.  Even if you’ve pre-sold the each “score” to its corresponding stakeholder, you haven’t sold it to all of them. You have already lost.

Again, if you’re just up in your Product Management tree fort banging this around to help get your head around things, fine. But just like it’s long-lost cousin the “Rhythm Method,” if you’re practicing the (Algo)rithm method and it’s working… it’s because you’re lucky!

(Stay tuned for another bad sign, as well as more discussion on staying on course with your true north).