Jason 30 Jan 2006 — An email from a reader:
At every company I work at, I keep seeing product roadmaps with qtr by qtr delivery of different features – they typically go out 1-2 years. Of course the product roadmap is out-of-date almost immediately because knowledge is constantly gained from market analysis and interaction with customers. My question is do you guys do product roadmaps? If so, do you put times schedules around them? I’d love to see your comments on this stuff…
Our answer: Product roadmaps are dangerous. They close your eyes and often put you on the wrong path.
One of the tenets of the Getting Real process is the idea that the future should drive the future. When you let a product roadmap guide you you let the past drive the future. You’re saying “6 months ago I knew what 18 months from now would look like.” You’re saying “I’m not going to pay attention to now, I’m going to pay attention to then.” You’re saying “I should be working at the Psychic Friends Network.”
Instead of the roadmap, just look out a few weeks at a time. Work on the next most important thing. What’s the point of a long list when you can’t work on everything at once anyway? Finish what’s important now and then figure out what’s important next. One step at a time.
This doesn’t mean you can’t have ideas of where you think your product should go or future features you’d like to implement. This doesn’t mean you shouldn’t have a vision. It does mean that you need to pay attention to reality. Reality is where you’ll find the best answers. And you’re never closer to reality than right now. The further you get from now, the less you know. And the less you know, the worse your decisions will be.
The other problem with roadmaps is the expectations game. People expect you to deliver what you say you will in 4, 5, 6 months. And what if you have a better idea? What if there’s a shift in the market that you need to address? What if what you thought wasn’t what actually happened? Any change in the roadmap nullifies the roadmap. Then the map isn’t a map at all.
Try it. It’s liberating and certainly more satisfying than following a plan you know is outdated.
Andy Wagner
on 03 Jun 11I’ll be a bit contentious here. First off, if you’re using a roadmap as a schedule instead of a notional framework, you’re totally off-base. If you’re using it to map at the feature level on a short-term basis, you’re not using it right. My understanding is that a product roadmap is a long-term vision for the product or product family—and for a new product built on the existing market. It’s an opportunity to dream about what the future might look like so that as you make your day-to-day responses to the customer, you can do so consistent with building the future state. It emphatically should not be anything to be slave to, it should be dynamic and notional, not static and specific.
mknopf
on 03 Jun 11well said, there is definitely value in paying attention to what you are trying to accomplish right now instead of in the future.
Chad Burt
on 03 Jun 11Plans are worthless, but planning is everything
Don Schenck
on 03 Jun 11Plans are worthless, but planning is also worthless.
DOING is where it’s at. In this age of being able to knock out a decent website in a weekend, why plan? Think it up, knock it out, refine as and if necessary.
I may plan to make spicy shrimp and grits for dinner tonight, but when 6 PM I’ll actually MAKE dinner, and that might change.
Mike
on 03 Jun 11The danger of not having a vision is that you fall into a reactionary state of adding features based on ‘what customers want now’ and that’s a constantly changing target. A long-term vision is important to keep the consistency of your overall product. However, vision is not necessarily the same thing as a roadmap that has specific quarter by quarter features laid out in precise detail. There’s so much conflicting advice about this. On one hand, the ability to knock out a website in a weekend with no plan and hope for the best is why there are so many crappy half-baked websites out there. On the other hand, you have to listen to the customer and provide the product they want. The problem is, they might not know what they want, and who is they anyhow? There will be many different theys wanting different things. Without a strong vision, or a roadmap, you’ll end up with a wishy-washy product trying to please everyone and that seems counter to 37signals core credo of opinionated software. But to be fair, the post didn’t actually say that you shouldn’t have a vision or a high level plan, just that a feature by feature roadmap is dangerous.
Jeff
on 03 Jun 11If you consider the roadmap a plan you are doing it wrong. Actually I stopped using the roadmap word because it was so consistently misunderstood. I switched to “Product Forecast” as most everyone in the field facing organization understands the idea of a forecast. It directs everything to “we pretty much know now and a few weeks from now what we are doing but everything else is pretty much a guess”, a much more healthy way to maintain focus while still being flexible.
CRC
on 03 Jun 11@Andy Wagner: I think you nailed it.
@Mike: I think there are a couple of layers:
Vision is the highest layer with the least amount of detail. It is more broad and probably a bit vague about specific functionality: “We are going on a road trip to Washington, D.C. over the summer and plan to enjoy and celebrate the American heartland along the way.”
Road map is a rough idea or “plan” (very loosely) for getting there: “First we’ll hit Denver, then Chicago, then…” It might have some rough times (quarterly targets) as a guide but, as Andy said, this is emphatically not a concrete plan to be a slave to. Maybe you’ll decide to stay in Chicago a couple extra days (too much good food to pass up, weather is dicey for driving, etc.)
After road map things can get more detailed and concrete the closer the time horizon and the clearer the objective: The drive from Denver to Chicago is going to be on I-76 to I-80 and take about 18-20 hours. We’re planning to drive through it with stops only for some food and gas.
And so on…
Chuck
on 03 Jun 11Here is the rub. This concept is great for the creators. But it completely sucks for the end users.
A road map is necessary to communicate to the user base that you are both listening to their feedback and also that you have a vision for what trends are affecting the way that users will actually use the products now and into the future.
The “reality” of NOW is the software that is in use. If all you ever do is address the reality of now then you will constantly be behind the curve and some other company with vision will take your customers from you.
A road map gives a general direction of where you anticipate you have to go to keep up with what is needed going forward.
To continue to auto metaphor, people understand that there may be a flood, or road construction, detours, accidents, and traffic jams along the way. You may need to get off one road and take a different route Things change and you may have to change to adapt to them. I am currently working through that with a Cloud based company who was developing an offline solution using Gears. Google pulled the plug on that so they have to go somewhere else. No one expects them to continue to develop a gears based solution.
Without a road map that you communicate with your customers you are effectively putting them in the car, blindfolding them and telling them “I am taking you for a ride and trust us- you’ll like where we let you out”
Good luck with that.
CJ
on 03 Jun 11The purpose of a product roadmap is to help have a conversation about product plans. No roadmap makes it hard to have that conversation…
Random
on 04 Jun 11As always, it’s a matter of the type of the product and the size of the organization that builds it.
You think, Apple didn’t have a roadmap and just reacted to customer feedback? Think again. If you have a large organization that must work together, you need to influence behavior of people now, so that they are prepared for working together 6, 9 12 months from now and haven’t just ventured their own paths in the meantime. You need a roadmap for that.
So, product roadmaps may be dangerous … for smaller (software) companies. The bigger you get and the more physical your product is, not having a roadmap and a plan is stark raving mad…
Anonymous Coward
on 04 Jun 11Relying on roadmaps has lots of pitfalls. But on the other hand, incremental change is great, but you have to be aware of the risk of a local maximum. While it’s clear that complex structures can evolve incrementally (the eye debate on evolution is a great example), I believe that some kinds of breakthrough need a different approach (but funnily, having a roadmap doesn’t help here either).
More to the point, having a roadmap can help you write the future too. You can announce things before doing and see what kind of reaction you get. Done carefully it may be a great way to gauge things. I wouldn’t rely on it too much but is one more tool to be used.
Anonymous Coward
on 05 Jun 11A road map is necessary to communicate to the user base that you are both listening to their feedback and also that you have a vision for what trends are affecting the way that users will actually use the products now and into the future.
A roadmap doesn’t tell customers anything. Launching features and improvements tells customers everything. Execution matters, listening and regurgitating doesn’t.
Chuck
on 06 Jun 11@Anonymous Coward wrote:
“A road map is necessary to communicate to the user base that you are both listening to their feedback and also that you have a vision for what trends are affecting the way that users will actually use the products now and into the future.
A roadmap doesn’t tell customers anything. Launching features and improvements tells customers everything. Execution matters, listening and regurgitating doesn’t.”
Let’s say I use a SaaS app that AC built. It is missing a feature I feel is critical. From the posts in the user forums it is clear that other users feel this is critical too.
Everyone knows that it takes time to add a feature. But in order to add a feature someone has to decide to add it.
As a user I am more likely to stick with a company that acknowledges the interest and gives me and the rest of the users a general guideline on whether or not they will add it and what their goal is for adding it.
If the company does not acknowledge the interest or provide either a reason for denying or simply says nothing then I am more likely to jump ship.
At the end of the day it is the users – the marketplace – that determines whether or not a product is successful. The good designers and smart businesspeople are the ones that find a way to deliver products that are wanted/needed.
Frankly, ignoring the marketplace is insulting to the users. It tells them that they don’t know what they need/want and that you are smarter than they are.
I agree that the roadmap should NOT be the ultimate driver of product development or product improvement. But at the same time, it is a necessary tool for communicating with the users and potential users.
I also agree that if you fail to deliver products then a roadmap is nothing more than lip service. And all the lip service in the world is worthless.
Legal Alien
on 07 Jun 11Roadmaps are necessary. The stumbling block is that they keep being understood as a definite timeline by the users. ‘Forecast’ seems a better name to me. Thanks Jeff.
Greg Cooper
on 07 Jun 11I agree with this post entirely and I in fact am part of the team which builds Interstate (interstateapp.com). Interstate allows you to create and share development roadmaps with your team and users.
I would have to argue that roadmaps are great things when they are “current”. With Interstate we hope to get your users involved and almost make them more of a social function to help guide your product externally.
We already have some great names using the product before it has even left it’s private BETA period. They include DailyBooth, Seesmic, Virb, SquareSpace and Twitter.
In summary, I think product roadmaps are valuable but not in their current form.
This discussion is closed.