(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)
Friday, March 10, 2006
Roadmaps: Don't go there!
In the Wikipedia entry for Windows Vista, I found this gem:
Windows Vista was originally expected to ship sometime late in 2003 as a minor step between Windows XP and Windows "Vienna", formerly known as "Blackcomb". Gradually, Vista assimilated many important new features and technologies of "Vienna", and so the date of release was pushed back to first quarter of 2006.
That sounds familiar. How about the entry for Apple's Pink:
The OS developers had a meeting in which they decided what they should be doing in the future, and started writing down their ideas on index cards. Ideas that were simple and could be included in a new version of the existing software were written on blue colored cards, those that were more "far out" were written on pink cards.
And lo and behold, "Blue" grew and grew as it assimilated features and engineers from "Pink." Blue eventually shipped, late and bloated, as System 7. Pink was spun out and died as Taligent.
Both OS efforts started with a reasonable idea: focus on an achievable medium-term goal while simultaneously building towards a more aggressive long-term vision to follow.
The trouble with this strategy is that business pressures conspire to move features from the 'long-term' plan into the medium-term plan. People are inspired and want to ship good stuff as soon as possible. Competitors won't wait for your schedule and announce or even ship products with the features you planned to delay.
And customers want all that good stuff immediately. Why shouldn't they? By announcing your roadmap for the future you told them that they need those features!
My observation is that whenever a team or company announces a multi-version roadmap for the future, they end up pushing everything of substance into the immediate release, bloating what could have been an agile, achievable objective into a death march.
Joel Spolsky wrote an interesting essay about forcing competitors to react. He called this strategy "fire and motion." When you announce your own roadmap, you're firing at yourself! You've taken the decision for what to do and when to do it out of your own hands and given it to the marketplace.
Perhaps you didn't intend to aim at your own foot. But you certainly drew a bull's eye on your forehead, then walked down the street giving away ammunition, dressed as a target. With the deepest respect to my colleagues in Product Management, I suggest you do not announce a long term roadmap. It will bite you where you usually sit.
Some companies routinely get away with saying nothing or very little about the future. Right now, I'm thinking about Apple and Google.
Roadmaps. Don't go there.
post scriptum:
Another guy blathering about how to run a billion dollar company. But we need to ship software, how will this help?
Good point, here's what to do: scale this whole thing down to your world. Are you in the habit of promising stuff to your boss or colleagues? Focus on promising what your team can deliver in the next two-four weeks, tops. Everything else can be 'prioritized later'. Because if you say you can deliver A this week, B this month, and C this quarter, do not be surprised if you wind up trying to deliver A, B, and C this month.
In the Wikipedia entry for Windows Vista, I found this gem:
Windows Vista was originally expected to ship sometime late in 2003 as a minor step between Windows XP and Windows "Vienna", formerly known as "Blackcomb". Gradually, Vista assimilated many important new features and technologies of "Vienna", and so the date of release was pushed back to first quarter of 2006.
That sounds familiar. How about the entry for Apple's Pink:
The OS developers had a meeting in which they decided what they should be doing in the future, and started writing down their ideas on index cards. Ideas that were simple and could be included in a new version of the existing software were written on blue colored cards, those that were more "far out" were written on pink cards.
And lo and behold, "Blue" grew and grew as it assimilated features and engineers from "Pink." Blue eventually shipped, late and bloated, as System 7. Pink was spun out and died as Taligent.
Both OS efforts started with a reasonable idea: focus on an achievable medium-term goal while simultaneously building towards a more aggressive long-term vision to follow.
The trouble with this strategy is that business pressures conspire to move features from the 'long-term' plan into the medium-term plan. People are inspired and want to ship good stuff as soon as possible. Competitors won't wait for your schedule and announce or even ship products with the features you planned to delay.
And customers want all that good stuff immediately. Why shouldn't they? By announcing your roadmap for the future you told them that they need those features!
My observation is that whenever a team or company announces a multi-version roadmap for the future, they end up pushing everything of substance into the immediate release, bloating what could have been an agile, achievable objective into a death march.
Joel Spolsky wrote an interesting essay about forcing competitors to react. He called this strategy "fire and motion." When you announce your own roadmap, you're firing at yourself! You've taken the decision for what to do and when to do it out of your own hands and given it to the marketplace.
Perhaps you didn't intend to aim at your own foot. But you certainly drew a bull's eye on your forehead, then walked down the street giving away ammunition, dressed as a target. With the deepest respect to my colleagues in Product Management, I suggest you do not announce a long term roadmap. It will bite you where you usually sit.
Some companies routinely get away with saying nothing or very little about the future. Right now, I'm thinking about Apple and Google.
Apple is an interesting case. They had to reveal their plans for Intel to get developers to port their binaries, so they had to open the kimono. But notice how they only really talked about what was next, not a multi-year schedule? And then they delivered way ahead of schedule, proving that they were actually discussing something they had already finished.If you cannot get away with saying nothing about your future plans, I recommend obfuscating as much as possible. Talk in generalities, talk about "spaces" and "partnerships," learn how to say absolutely nothing with flair. Do not show a mock up, do not leak a code name.
That is very different from discussing something that won't ship for a year or more. No matter how much customers bark about wanting stuff now, you can always hold them off for 60-90 days. Or release what you have now and start working on what they want.
Roadmaps. Don't go there.
post scriptum:
Another guy blathering about how to run a billion dollar company. But we need to ship software, how will this help?
Good point, here's what to do: scale this whole thing down to your world. Are you in the habit of promising stuff to your boss or colleagues? Focus on promising what your team can deliver in the next two-four weeks, tops. Everything else can be 'prioritized later'. Because if you say you can deliver A this week, B this month, and C this quarter, do not be surprised if you wind up trying to deliver A, B, and C this month.
