Product Management Tips: Have a Rational Road Map Commitment Process

How is YOUR product road map managed?

1. The charismatic but mercurial CEO reinvents the product road map through his or her own alleged genius every 30-90 days. Product management has to sort out the details and make the results appear rational to outside observers.
2. Joe in sales tells the VP of Sales that he’s “just gotta have this one feature RIGHT NOW and customer XYZ is SURE TO CLOSE THIS QUARTER!” VP of Sales wants a new Porsche so he or she visits product manager’s cubicle (or worse, goes straight to the CEO) and demands a commitment. Repeat three times per quarter per sales rep. (Guess how many of those deals actually close?)
3. Product management gathers requests from all sources and runs a rational process by which pending road map requests are periodically reviewed as a group against existing commitments and company priorities and an achievable amount of the highest priority work is committed for the next 3-12 months, with the full understanding by all that doing one thing in a given timeframe usually means not doing something else.

Unfortunately, approach #1 and #2 are quite common. They aren’t guaranteed to ruin a company, but you can make good money betting that they will.

If your product road map is dictated through strokes of alleged genius by a mercurial, charismatic CEO, you may be OK if the CEO is truly a genius, but you’re doomed if he or she is not. Unfortunately, most CEOs, like most people, are not geniuses. (Not all CEOs realize this.) Moreover, a typical CEO who is busy with fund raising, board meetings, hiring key staff, helping close key sales, giving interviews, and managing the whole business is unlikely to have the grasp of critical functional requirements and feature and technical details that is necessary to transform a vision into a doable plan and a successful implementation. (That’s why CEOs hire product, engineering, and QA managers.) This means that CEO estimates of time required to do particular work are likely to be overoptimistic, and it will be hard for the company to deliver features in the timeframes the CEO expects. Plus, if the CEO frequently changes their mind, lots of development team time will be wasted starting initiatives that are never completed at all or well enough to deliver the intended results.

If your product road map is dictated by whatever a customer said in the most recent sales call, your product development organization will be constantly jerked around, function very inefficiently, and suffer from poor morale and retention. Plus, a single sales rep will pitch to multiple customers in a quarter, leading to conflicting input; sales reps typically overestimate the probability and speed that their accounts will close, leading to wasted effort on accounts that don’t produce revenue; and you probably have multiple sales reps who will be giving conflicting input.

The good news is that if you’re in situation #1 or #2, the company’s probably not doing well and everyone knows it, and rational people (not necessarily including the CEO or the VP of  Sales) will be eager for change. What are some of the elements of a rational road map commitment process?

• Document the company mission statement and the strategy for pursuing it.
• Document the current road map so you know what your existing commitments are.
• Prioritize target market segments.
• Research on an ongoing basis, in an Agile fashion, what the company must do to offer a compelling value proposition in those target market segments.
• Identify any specific major prospects or customers that it’s important to close or satisfy (if you’re elephant hunting rather than fishing).
• Gather requests for product enhancements and bug fixes from all sources. Make everyone aware that road map planning is underway and give everyone the opportunity to participate in the process.
• Roughly estimate the order-of-magnitude effort for the major initiatives so you will be able to demonstrate when asked that the company can’t afford to go to the moon, cure cancer, AND green the deserts in the next nine months.
• Come up with a road map update proposal that you think is the best approach, along with any alternatives that deserve consideration. (The company may have to place a strategic bet on one of two or more mutually exclusive alternative paths, and reasonable people can disagree about the best way forward.)
• Informally review the proposal with key stakeholders such as engineering, QA, and sales to make sure you have accurately captured their input.
• Schedule an executive staff meeting where key stakeholders (which at a small company would include the CEO, the CTO, and the VPs of Engineering, Sales, Product, Marketing, and Operations) can discuss the alternatives and make a high-level decision.
• Communicate the results back to the product development team and start the work of transforming the high-level product road map vision into user stories and plans for sprints. Use Agile project management to execute against the high-level road map, with all parties recognizing that initial estimates were for the purpose of planning tradeoffs only and that actual delivery dates will vary.
• Ensure that any communication about the road map to customers or prospects clearly differentiates between what is and is not committed and provides appropriate buffering around any release date estimates so that you have the ability to be Agile on an ongoing basis and accommodate surprises. (You can’t predict what the surprises will be, but you can predict that you will be surprised.)

If you can put a rational road map management process in place, your company has a chance of success. If you can’t, start updating your resume.