The Roadmap Planning Process (RMP) in Product Management

Author: Martin, Entrepreneurial Insights (later Cleverism) · Published: April 12, 2015 · URL: http://www.entrepreneurial-insights.com/roadmap-planning-process-rmp-product-management/ (moved to cleverism.com)

One-line: A textbook-style walk through what a product roadmap is for, how to build one, and the strategy tools that feed it — notable for insisting that a roadmap is an intention, not a commitment.

Summary

The article sits in the genre of entrepreneurship-explainer content and is organized in three parts: what product roadmaps are, how to plan one, and tools for building one.

What roadmaps are. Business roadmaps come in four flavors: market-, technology-, objective- and product-oriented. A product roadmap combines market trends, customer segments and planned technology development into the path that “seems most plausible and profitable at the time of its making.” The central caveat is stated early: roadmaps “are not commitments firmly incorporated into company’s strategy,” because following one through regardless of market change “would probably result in failure at the least.” They are better treated as an annex to strategy and revised as the market moves. Their benefits run to every audience: customers want to know where a product is headed, investors read a good roadmap as proof of competence, employees who understand the end goal work more effectively, and short-term mistakes drop when everyone knows where they’re heading.

Planning. A roadmap ties together five elements — market segments, business problems, product requirements, technology and time. The strategic planning inputs are audience segmentation; finance, market and competition review, with a preference for less crowded parts of the market where differentiation is easier; technology insight from the engineers; and alignment with overall business strategy, “even though you might not completely (or at all) follow through.”

Five steps. (1) Gather that information. (2) Organize it chronologically — a 6-month, 1-year or 3-year span, broken down monthly, quarterly or annually, with themed releases. (3) Design it in a tool (Excel, PowerPoint, Accept, Feature Plan). (4) Keep a detailed internal version, owned by engineering, with every feature and date. (5) Publish a vaguer external version, owned by marketing and sales, that gives the effect of detail without handing competitors the plan, and carries a forward-looking-statements disclaimer so it reads as non-binding.

Two internal failure modes. Sales teams misuse roadmaps as commitments, selling features “as futures contracts” to the wrong segments in desperate moments. And product development dates slip because they depend on technology rather than the market — “sometimes things take more time than predicted.”

Tools. McKinsey’s Three Horizons model (split the roadmap by time and uncertainty), technology trend capitalization, Roman Pichler’s Product Canvas, technology theme investments, “Pictures of the Future” scenario extrapolation, market/technology alignment, the Kano model of customer satisfaction, compact QFD against competitors, and the technology S-curve for spotting dead ends. The close restates the thesis: because roadmaps “are not obligations but rather intentions,” they work best as a filter for ideas.

Full text

Archived privately against link rot: ../attachments/the-roadmap-planning-process-rmp-in-product-management/the-roadmap-planning-process-rmp-in-product-management.md

Connections

• Product Management — the conventional, process-heavy account of one of the PM’s core artifacts, a useful baseline against the product-led critiques collected there.
• Roadmaps are fake news — the counterpoint maxim. The article itself concedes most of the ground: a roadmap is a revisable intention, and treating it as a commitment is the failure mode.