The Roadmap Battle Royale
NAVIGATING THE NATURAL TENSION AMONG STAKEHOLDERS
This is the first in a series on product roadmaps. The first post describes why roadmaps matter and who relies upon them. The roadmap is much more than a directive document that tells teams what to do by when. It is ideally a galvanizing document to drive vision, bring teams into alignment and commitment, and lead them and your customers to your future, promised destination. The numerous parties to the roadmap have different motivations and needs which you as the PM must be weighing in order to achieve a higher success probability. The roadmap itself, however, is not an edifice to sit back and admire once built. It’s a map that is 85% drawn, with empty space that continues to grow ahead of you as you move forward. The further out towards the horizon you look, the hazier the fidelity of the map.
Battleground
The product roadmap. You own it, but many other teams are gunning to influence it daily. It’s a battle royale to keep your product on plan, on course, and on time while many other interested parties push to get their needs prioritized above others. Sometimes owning the roadmap feels like a survival competition.
If you’re new to product management you might not own a roadmap. Instead you have projects assigned to you by your manager. E.g. Research, define, and build feature X to deliver by December. That is, a roadmap may exist, but you don’t own it. This is normal if you’re in the associate product manager (APM), product manager (PM), and Sr. PM roles. As you progress in your career, you will begin to gain ownership of a set of product features, a product, or a product line. You will begin to prioritize multiple development choices against customer needs, resources, delivery dates, organizational goals, and outcomes within your area. Over time with seniority and success, you will become increasingly responsible for product vision, goal setting, and the product roadmap. For succinctness, I’m not including leadership, management, process, and coordination responsibilities which will also come with more senior roles.
The product roadmap is a critical, in-demand asset because so many people across your entire organization have a material stake in what it includes. These include:
- Engineering — What are they expected to build?
- Management — How do they need to staff?
- Sales — What new, valuable solution can they sell and when?
- Sales Engineering — How does this work and can they learn it quickly?
- Executives — Are you aligned to the goals of the company strategy?
- Marketing — Do they need to update the messaging?
- Partners — Can I make more money?
Defining the Product Roadmap
This roadmap is a document which defines your concrete product goals, usually on a feature or outcome basis, for a defined future time period. In most tech companies I’ve worked for, product teams plan one year at a time, divided into quarters.
A picture perfect roadmap will outline goals for a year. A picture perfect organization will deliver them on time in a year. In neither case have I seen this happen in 15 years. At best a roadmap is valid for six months and gets less certain beyond that. Plans suffer contact with reality, even with good preparation.
How you visualize the roadmap has flexibility, but it must be clear. Slides are popular because you will be sharing that roadmap often in meetings with your internal stakeholders and customers.
Don’t confuse the roadmap for a Gantt chart however. Your product goals and your project tracking are not the same thing, even when you have timelines defined for when you need them released. A good project manager, however, can help you achieve the outcomes of a roadmap.
The most important aspect of the roadmap for a PM is its function to drive shared understanding and agreement. You know your company strategy and high-level goals which were communicated from your leadership team. If you don’t know this, this needs to be resolved immediately as a first order issue. Without vision and goals, your roadmap will only be a collection of best guess or most-requested items which is far from ideal. Your roadmap must support the product vision and goals.
Let’s assume that in addition to good company-level direction, you’re in frequent touch with your customers and understand what they say they need, as well as your other stakeholders. You’ve synthesized it all and produced a roadmap. Guess what? You’re not even close to done. Next you need buy-in from all your stakeholders and some form of ratification. Ratification is either explicit confirmation to agree to the roadmap from the team, or minimally the tacit lack of objections from your key stakeholders. Not everyone must agree with every choice on the roadmap, but you’ll get nowhere if no one agrees and starts building to plan.
The roadmap, therefore, drives agreement to the following:
- Customer and internal outcome goals
- Shared understanding (or the basis on which to build it, and buy-in)
Of course, unsatisfied stakeholders will also let you know without reservation when they don’t like what they see. They’ll also hold you to account when items slip or disappear. To you the roadmap may be a plan. To them it is a promise and a commitment. Tread lightly on not meeting your commitments.
Stakeholder Friction
I refer to the roadmap as a battleground because it is hotly-contested territory among many stakeholders. PM owns the roadmap, but many others contribute to, and live and die by it. Under no circumstances have I ever seen apathy from any stakeholder who has something to gain or lose from the roadmap.
The reasons for this derive from the many stakeholders with differing needs.
- Product Manager: You have goals for your customers and product success. While you are empowered to drive roadmap definition, you ultimately don’t do it alone.
- Customers: They have things they believe are necessary for you to build. Perhaps they already bought your product and now they expect you to keep up with (whatever they think they need at that time). Perhaps they are considering buying your product but won’t do it without feature ‘xyz’. Maybe they’ve hit a bug they’re angry about and expect you to rapidly resolve it.
- Sales: They sell your product and need it to be compelling and solve customers’ pain points to do so. Customers rarely buy what they don’t need. Lipstick on a pig (making something of low quality look attractive) only works for a short while. You will eventually get caught if you do this.
- CEO: Making your numbers to the Street requires you to sell product. If the product is holding back sales, the executive team will have strong opinions on the roadmap. Your CEO has the authority to override your roadmap if necessary. See HiPPO decision-making. The road map must be driving outcomes valuable to the business.
- Support: Think you can only ship new features? Sorry Charlie. Support needs quality and the same engineers that build product also fix product. If you don’t ship quality you soon won’t be shipping at all. Enterprise customers require support. While ‘support’ isn’t on the roadmap as a feature, a percentage of your engineering team is always dedicated to support and maintenance.
- Engineering: This team wants to ship valuable features that matter, but they also need to reserve a portion of development time for technical debt and work on things like infrastructure that customers won’t directly see.
The other reasons for this war zone come from externalities to your product.
- Internal Competition: Given the importance to stakeholders for the features on the roadmap, you will find that there is competition for people outside of PM to get their features on your roadmap. These can come from any of the teams listed above, or may include many others too.
- Time: Your competition in the market is willing, motivated, and may be under the existential threat of death to try and eat your lunch. Life, love, and relationships are not zero sum games, but capitalistic markets are. The enterprise customer with a $2M budget to spend on infrastructure (or insert any product) by June 30th isn’t buying it twice from two vendors. You have time pressure to get to market with viable product, and to do it before your competition gets that customer budget in a PO and locks you out.
- Politics: I won’t dwell on this, but not everyone has your best interests in mind. That can cause bad behavior and can be another zero-sum game.
Roadmap Decay Rate
Conventional wisdom says you will know your market, your customers, and your product needs, which then inform your roadmap. You present this roadmap to your organization, they buy off on it (often after some negotiation), and it becomes a ratified document against which your organization gracefully works toward for a year. This is the textbook scenario.
In reality, the moment your four-quarter roadmap is published and ratified, it begins to decay. Your roadmap items may be correct, but daily friction with reality which will blur its fidelity over time as you reach your third, and especially your fourth quarter. I.e. Add time, internal and external pressures, and your end of year plan will start to fray. The decay rate can vary depending on your organization size, maturity, and product complexity.
Here are a few real-world examples of issues you can run into. I can painfully attest to hitting many of these myself, many times over.
- A critical engineering resource takes a 3-week vacation you were unaware of, starting next Monday.
- Your largest competitor just bought a company that changes customer perceptions, causing a strategic rethink.
- Unplanned attrition means the person building your feature is now gone, and no one else can take up that work anytime soon.
- Your team (and probably you too) have done a poor job of dependency analysis, and now you have something mandatory that was unplanned for, but requires three months to do.
- A layoff takes out a team resource. Now you will be handling this yourself with no timeline changes. Goodbye Saturday.
- Sales inked a deal for a feature that’s only in beta and finance has a revenue recognition SOX compliance issue? That’s now your number one feature regardless of its original priority.
- Your largest customer won’t buy again without feature ‘xyz’? That’s not a strategic way to run a product, but you will feel this pressure.
- A partner team decides to reprioritize and defund two people from a component you needed by June. Your project manager has an updated release date for you.
Some of these are extreme examples. Others are mundane and all too common. Yes, you will experience these and more.
Your roadmap is constantly evolving, like it or not. At best the roadmap remains unchanged but the delivery dates slide out. Of course you can get in front of some issues and plan for some eventualities. All too often however, you have little recourse when three weeks before a final delivery date someone in engineering says, ‘There’s no way we can deliver by that date. Maybe in three months.’ Of course you say, ‘But I’ve been in constant touch with them so this won’t happen.’ People don’t like to disappoint, but it will happen. When the floor drops out with a big, unplanned surprise, your roadmap and product take a hit.
In part two of this series, we’ll discuss how to get started building a roadmap, what goes into that process, and how to get started in practical terms.
ABOUT LUKE
Luke Congdon is a career product manager living and working in Silicon Valley since 2000. His areas of focus include enterprise software, virtualization, and cloud computing. He has built and brought numerous products to market including start-up MVPs and billion-dollar product lines. Luke currently lives in San Francisco. To contact, connect via luke@lukecongdon.com or https://www.linkedin.com/in/lukecongdon/.
Originally published at http://lukecongdon.com.
