The Roadmap Less Traveled

Every tech start-up struggles to create a roadmap: that short set of PowerPoint slides which defines the next six quarters of updates, minor releases and important advances. Since product managers strive for clarity, having a product roadmap is a critical communications tool. However…

• Sales is constantly pressing for roadmaps that show what today’s customer requires, including a committed delivery date. “Once we close the deal, we can figure out how to build what’s missing.”
• Yet Engineering uses the roadmap as a target for product deliveries. Everything on the chart is a hoped-for objective; anything missing has been definitively dropped.

Therefore, we are talking about two distinct roadmaps with non-overlapping uses. Referring to both as “the product roadmap” creates endless confusion.

What’s in a Name?

The (less traveled) road to clarity starts with precise nomenclature, so let’s first consider the “engineering roadmap.” You may have also called this beast the “release plan” or the “internal schedule” or the “development calendar.” Fundamentally, it captures our technical aspirations: what we hope will happen.

This engineering roadmap is for internal use only. It’s designed to help the technical team fit each project into an overall release process – coding, QA, beta testing and customer shipment – and drive staff assignments. Every work item must be included; otherwise it will be dropped, de-emphasized, or assumed away. Engineering managers need to show sustaining tasks as well, to justify headcount and budgets within the development group.

None of this would matter if most technical projects finished on time. Sadly, ‘taint so. (In 1995, I brought out a software product on time, on budget, and on spec. Never before and never since.) What happens when things are late? Engineering managers dance through a complex series of postponements, reduced features, QA shrinkages, shortened betas, and redefinitions of success. In other words, the current engineering roadmap is always the high water mark. Things will never again be as good as they are today.

Along the Other Path…

Customers, of course, believe in product planning. They will hold your sales person at invoice-point and demand to see your current roadmap. (Here, we mean something completely different: the “public roadmap” or “customer NDA plan” or “analyst briefing chart.”)

Knowing that dates shift and specific functions are always at risk, a Product Champion should craft a public roadmap that is long on vision and light on details. Near-term projects will have much more precision than next year’s SWAGs. Delivery dates should be a quarter later than engineering dates, anticipating slippage.

Enterprise customers should understand (but please don’t tell them during an important meeting) that all projects more than 6 months away are subject to change. “Time-from-now” is a good measure of speculative risk. Still, you need a multi-year story about product directions to appear strategic. Keep it light and simple! When you can, avoid customizing roadmaps for several key prospects along incompatible dimensions. The smart ones will keep copies of your presentation, and ask very pointed questions as their favorite items fail to ship.

Tell Them What They Want to Hear?

In my experience, some softly phrased honesty nourishes relationships with serious customers. (“That’s a great suggestion, but it would have a lot of implementation risk. Let me tell you why, and explore other ways that we might address your business requirements.”) Often, savvy customers demand a face-to-face roadmap discussion with product managers to get closer to R&D’s reality, and sidestep your sales team’s natural optimism. An hour with someone who can explain tough trade-offs is a way for thoughtful customers to make informed decisions.

How can you say “no” to a customer? Take a note from our Japanese colleagues, who have perfected the fine art of gentle discouragement. In Tokyo, an audible breath through the teeth and “that could be very difficult” is one polite way of refusing a request. Here in the US, product champions might say “that’s on our roadmap, but we are still working on scheduling and priorities.” Another favorite placeholder is “that’s a great idea! Let me review it with our architects and see where it will fit in our plan.”

Engineering roadmaps and public release plans are related — but are not the same item. When you hear that “we need a roadmap slide,” consider responding with a brief interrogation: internal or external? NDA or public presentation? Major deal closer or just fishing?

SoundBytes

I’d consider two or three distinct (and distinctly named) documents: a public roadmap for use with press, analysts and prospects; a Key Customer roadmap, used strictly under NDA when Product Management is present; and a Development calendar for staffing, planning and executive buy-in. Getting agreement and maintaining these is hard work.