on roadmaps
I had a funny discussion about roadmaps recently.
Me: If you can't hit your dates, then you shouldn't distribute roadmaps.
Client: But we must distribute a roadmap to sales people.
M: And what happens when you do?
C: They give it to clients.
M: And what happens?
C: They attach the roadmap to a contract.
M: How's that working for you?
C: Well, we usually miss our dates.
M: If you can't hit your dates, then you shouldn't distribute roadmaps.
C: But we must distribute a roadmap to sales people.
M: And what happens when you do?...
In Don’t Build a Stupid Product Roadmap!, Scott Sehlhorst at Tyner Blain writes,
A product roadmap is the product manager’s equivalent of a project manager’s rolling wave planning. In a sound-bite, you provide short-term details (for the next release), and long term “broad brush” discussions. If you don’t plan your product to address the needs of a particular market, and then execute against that plan, the only way you will succeed is by luck.
That's it. A roadmap is a plan, not a commitment. It says, "here are our current plans. Our objectives may change and we'll change our roadmap accordingly."
As they say, If you don't know where you're going, how will you get there?
In our Roadmapping seminar, we provide five different tools for articulating product strategy. The roadmap is evidence that you actually do have a strategy. The roadmap is the tool of choice for communicating with executives, sales people, and clients. And in fact, seeing your product roadmap is often a legitimate request from your clients and your sales people.
However, and I've ranted about this before, things don't change nearly as quickly as everyone thinks. That is, market problems exist for years and years. It's your awareness of those problems that changes day-to-day. I'd prefer that your long-term roadmap focus on industry problems and persona goals. In talking with a client about product capabilities, this client's feature request becomes critical. Talking to another client results in another critical feature request. As you talk about features, you discover the delta between the problem and your current solution. But if product managers actually interviewed the clients instead of just reacting to sales demands, we would see these problems years in the future.
You don't hear problems with your mouth. You need to create an environment where you can hear problems... with your ears open and your mouth closed. Better yet, see the problems by observing your ideal persona in a working experience.
You can observe a lot by watching.--Yogi Berra



Reasons for roadmap changes
i.e. it is what we know today, and can plan for the future, but it is not 100% guaranteed as things can change the prediction.
Things that can change the roadmap include:
-- staffing/resource changes requiring changes in plan
-- significant market changes
-- changes in internal strategic direction
-- major sales driven requirements to close large deals
-- underestimating the effort required for roadmap items
-- our general inability to project into the future
etc...
Roadmaps cannot be set in stone. They should also never be used to in sales contracts. Those who do, are only asking for trouble.
I wrote a bit about roadmaps in the following post:
http://onproductmanagement.wordpress.com/category/business-topics/roadmaps/
Saeed