It’s incredibly tempting to create a road map when you’re driving a software product. You get to reap the glory of announcing desired features without even a downpayment of work. It takes no design, no consideration, or even discipline to respond to feature requests by making them a bullet point on a road map. It’s like buying goodwill on credit, but what you don’t pay for now, you’ll pay for later with interest.
Like functional specs earlier in the development phase, product road maps are fraught with trouble. The due diligence process is usually twice as shallow, which means that you’ll inevitably end up promoting illusions of agreement. When all we have to agree on is a slogan, like “Meetings Tab, 4th Quarter”, it becomes an empty imagination box that’ll fit wildly different expectations. Disappointment, however, is sure to ensue when only one set of expectations can actually be met.
Even worse than mismatched expectations, though, is the slippery slope of selling tomorrow over today. When you sell the software that you actually have, there’s a limited amount of wriggle room to cajole prospects. Customers has to make real decisions about whether the current state of your software is a good fit for them. Some times it’s not. That’s okay.
It’s better to turn customers away than to placate their instincts and lure them in with vague promises. It’s incredibly rare that a single feature will truly make or break your chance with a customer. If your software is a good enough fit, most people can make do without that one or two things that they’d like to see.
If your software is not really a good fit, it’s very easy for customers to convince themselves that it will be, if you greet them with an illusion of agreement over a few “deal breakers”. But when you finally do deliver, you’ll also burst that illusion and end up with disillusioned customers who thinks you suckered them into buying a cow and then gave them a goat.
And worse, while it might seem free at first to win customers by promising them gold at the end of the road map rainbow, it’s not. Accepting new entries to the product road map carries very real development debt. This debt will shrink your degrees of freedom. Your ability to pursue new great ideas as they arise will be seriously dampened when you’ve already committed to a tall stack of requests eagerly awaiting implementation.
Builders bound by the guesswork of yesterday are not going to be happy troopers. It’s demoralizing to be forced to work on something not because it’s the right thing to do at the time, but merely because the promise note is up.
But try avade and you’ll soon hope that it was merely your mob-connected bookie you were trying to dodge. Customers do not forget your promises — especially not the ones that were won over specifically because of the promises of a road map.
Walt Kania
on 09 Nov 07I’m not exactly in the software business, so maybe I’m naive.
But why isn’t ALL software developed this way?
Or all products, for that matter?
Dave’s case seems airtight to me. How could you possibly know what customers will want after using your software for a year?
David Andersen
on 09 Nov 07Superb writing.
aw
on 09 Nov 07Hey David! Thanks for the post – loved it!
Most companies don’t actually share the road map with their customers do they? Also – companies like Apple consciously have product road maps (that are as secret as SSN), yet use it as a means to define a general direction (with the a lot of room to adjust), organize, prioritize, and staff their projects accordingly.
Subsequently – you didn’t challenge that in your assertion, thus are you suggesting product roadmaps are inherently useless or they the way companies today use them are useless.
old guy
on 09 Nov 07this is getting old. Same arguments of we-dont-need-anything-to-build-great-software mentality. this is absurd.
DHH
on 09 Nov 07aw, that’s a good point. I think product road maps make a lot of sense when you’re trying to coordinate supertankers like Apple because the iCal.app team needs to have an idea of when Leopard is shipping. And the iTunes team needs to know when the iPods are getting updated.
But actually, I think calling that a product road map is stretching it’s generally accepted definition. That’s more of a company coordination map.
A road map for an individual product that doesn’t have strong dependencies to other releases is a lot more questionable in value. What exactly are you getting out of deciding 3, 9, 18 months in advance what to work on? What extra powers are you gaining? I’d say very little.
On the other hand, I think you give up a lot. First, you succumb to the belief that you actually know where you’re going that far out in the future. Which is likely to give you blinders on for where you could be going, opportunities you could be pursuing.
Old guy is right in a sense. No functional specs, no product road maps, all these artifacts are about trying to pin down the future by elevating guesswork and fingers in the air to “science”. I think that’s an unfortunate, and mostly unnecessary, way to drive product development. So we push back against this fortune teller-driven approach in all it’s shapes and forms.
Rob
on 09 Nov 07Clearly it isn’t an absurd suggestion.
However what can often happen is the roadmap is used by salespeople to help persuade people to buy a product (so the sales folk get their commission) then it’s over to the development/consultancy team to bear the brunt of the yelling when they don’t develop what was promised.
David Andersen
on 09 Nov 07To me the post is about the significant disadvantages to using a roadmap as a commitment/sales document, not about having an internal list of development priorities.
Ade
on 09 Nov 07I’m baffled at the conclusion made here. You make a lot of assumptions about how product road maps are used, and while I agree that they can be misused, I don’t see how they’re all bad.
I formed a longer response at http://www.recursivefunction.com/blog/2007/11/09/you-need-a-product-road-map/
JF
on 09 Nov 07Maybe we weren’t clear in the post, but our thinking is that publishing a road map is a bad idea. A road map isn’t a prediction, it’s a promise. It’s a promise that locks you in to a vision you had yesterday, not today and not tomorrow. It sets expectations and lead to disappointment when one person’s idea of a future feature doesn’t map to what you “promised” you’d deliver sometime in the future.
Vicky
on 09 Nov 07This is a great post.
I agree with the last three posts from DHH, Rob, and David Anderson. I think it’s about sales too and I love the line about promising a cow and getting a goat.
I also think it’s about agility too. I mean what you think was the next best thing six months ago is a lot different than how you feel today. With technology it is so often the case that not all technologies catch on with the masses. I think sometimes the customer may think they want a cow, but in six months maybe they’ll really want a goat and not want the cow they thought they desperately needed.
Customers are also fickle and their needs change too.
Again, great post.
Andrew Crow
on 09 Nov 07I agree that using a list of future features as a lure for sales opportunities is asinine. You’re correct in that if things change, or that promised feature ends up not being the right thing to do, then it puts in you an awkward position of backing out, or explaining to your customers why you’ve decided not to give them this.
However, when you sell a service as a subscription, being aware that your users expect the service to evolve with their needs is important. Needs change over time, which is precisely why many people upgrade software. Now, some features in upgrades are not ever needed, but I digress.
My point is that in order to maintain a decent relationship over time with your customers, there are advantages to letting them know what you plan on delivering so that they can know that their evolving needs are important to you, the provider. And, customers often want to prepare for any kind of workflow change.
While snake oil and glossy feature sheets are never helpful in the long term, having a dialog about future thoughts with your customers is. Responses like “if you don’t like that, then maybe this isn’t for you” is equally useless. Simply providing a product that works today, without any open dialog, is not enough anymore.
DHH
on 09 Nov 07Andrew, I think that conversation is very important, but I also think it’s better carried out by delivering rather than promising. Show that you’re paying attention to your customers by launching new features that serve their needs (rather than merely their requests).
PWills
on 09 Nov 07If your ‘product’ is a ‘platform’, then you do need a public roadmap.
I wouldn’t want someone from say, Facebook or Salesforce.com to read this post and think “Oh great! DHH says we can dump our roadmap!”.
When thousands of people are pegging their success on your product’s features, then roadmaps are vital.
I’m sure that the 37s guys agree (Rails has a roadmap) but just want to make sure that point isn’t lost.
Edmundo
on 09 Nov 07I’m still a n00b in the “real world” but so far I’ve gotten enough experience with announcing dates when things are going to be available and completely missing them followed by long apologies and last minute repairs with cut features to hopefully get it out the door ASAP. So I agree that making public promises without being 100% confident that you will make it (e.g. Leopard is coming out on October 2007), then you’re just going to let people down.
However, what would you call it when you have all these necessary features you want to build before the product’s release (e.g. messages, milestones, and to-do lists in Basecamp) and you put them in a specific timeline-based order as milestones. Is that not a road map? Or is that just a schedule? what’s the difference? Don’t you have to make some sort of estimate based on how much time you have and how long things are going to take to build to a decent state?
DHH
on 09 Nov 07PWills, I don’t agree and Rails doesn’t have a road map :). What we DO have though, as do Facebook and Salesforce.com, is a commitment to pay attention to backwards compatibility. That’s really what’s important when you have a platform.
You can’t go changing all the underpinnings every five minutes and expect people to enjoy the ride. So you must take a lot more care in migrating old APIs to new forms than if you weren’t working with a platform. That’s why certain deprecated APIs in Rails have been around for years.
In fact, we actually face somewhat of the same problem with the Basecamp API. The API relies on some techniques that we’d like to move beyond. But before we can do that, we need to have a proper transition period/layer in place. We haven’t spent the time to do that yet, so we haven’t made the changes yet.
But I really think that it’s a separate issue from the road map. Backwards compatibility is about what’s known, it’s about the past, and that’s pretty easy to come to terms with. You can reason with great sophistication on that what is. But you can’t do so with nearly the same accuracy about that which will come to be.
DHH
on 09 Nov 07Emundo, I define the road map as a plan for the future of an existing product. Not as a pre-release development tool.
Seth
on 09 Nov 07I disagree with this one… Running a service, I constantly get questions about features that I’ve talked about over email plenty of times before.
It gets tedious to repeat the same support email every other day. My resources are limited.
I find posting a Feature Roadmap has cut down my questions considerably about what’s coming with the software down the line – especially if that roadmap is in the same place where people go to request a feature.
Now, I might sneak in some other changes or fixes before some of those features get done, and perhaps I’ll delete some features from the list – but as long as you make it known that your list is fluid I don’t see a problem with it.
Seth
on 09 Nov 07...As a followup – of course you do need to deliver on major items in your feature list.
I’ve not had a problem with doing that so far. Hopefully that trend continues :)
Anonymous Coward
on 09 Nov 07Call it what you will, but you still have a product road map. You just don’t make yours known to the public.
DHH
on 09 Nov 07AC, you must have a very loose definition of the term road map, then. We certainly have ideas of stuff we’d like to get done in the future, but we never schedule more than a few weeks of work and we rarely even bother writing ideas further out in the future down. I don’t think that qualifies as a road map.
10 in 2 people
on 09 Nov 07David is once again summarily dismissing reality as being ‘overrated’. We hear you, David, you don’t like the real world with all its constraints, and you prefer to live in your little unconstrained fantasy world.
Hence, no product road map. Instead, simply stir up some shit as you go.
Well, some of us think differently. Some of us think that having a little bit of a backbone is not necessarily a losing proposition. Having a backbone and showing it, publishing it, is an ethical thing to do. And so we tell our customers and prospects, in no uncertain terms, what is it that they can expect from us down the road.
And yes, we’re in it for the long haul, and yes, we have the vision to make the road map and publish it and stick to it.
DHH
on 09 Nov 07The irony of claiming the moral high ground while hiding behind an alias and seeking comfort in fantasy crowds like “some of us” is priceless. You made my day, 10 in 2. Absolutely priceless.
Micah Calabrese
on 09 Nov 0710 in 2 people, Keeping your word is definitely honorable but promising something, later realizing that thing is not the best course of action and stubbornly doing it anyway is not good for anyone.
Having a backbone is doing what you know is right even in the face of a thousand misguiding voices.
PWills
on 10 Nov 07http://dev.rubyonrails.org/roadmap
Rails needs a roadmap, because it’s a platform on which other applications depend. I can go to the above URI and see that the features of v2.0 are 96% complete, and plan my development accordingly.
Jeff Lash
on 10 Nov 07Reading this reminds me of Jakob Nielsen’s “Flash is 99% bad” nonsense.
A road map isn’t bad in and of itself—it can be used well or used poorly.
For example, saying “A road map isn’t a prediction, it’s a promise” is an example of using it poorly. It should be used as a planning tool for moving forward.
Saying that “It’s a promise that locks you in to a vision you had yesterday, not today and not tomorrow” is an example of using it poorly. It shouldn’t be laminated, put on a wall, and never updated—it should be a living document that is used in conjunction with the right stakeholders (internal and/or external).
Saying that “It sets expectations and lead to disappointment when one person’s idea of a future feature doesn’t map to what you “promised” you’d deliver sometime in the future” is an example of using it poorly. If someone is “dissapointed” because something in your roadmap doesn’t come true, then you didn’t a good job when you created and communicated the content, context, and purpose of your road map—any halfway-decent product manager knows that.
Maybe you don’t need a roadmap when you are a small company with a few people, but what about when you have several thousand employees and hundreds of products? How does senior management know where to direct funding? How do you plan your resource allocation for the next quarter? How do you identify dependencies across products and technologies?
A road map is a tool. Like any tool, it can be used well or it can be used poorly. Saying that it’s a useless tool because some people misuse it is shortsighted and irresponsible.
I think 37signals has done a lot of great work and has a lot of admirable ideas, but lately the posts here seem more geared towards posturing and driving traffic than anything else.
Tristan Juricek
on 10 Nov 07Well, how do you coordinate and share your vision for a product/project without something like a product road map?
A room with 5 people will often have 5 wildly different directions of things to do. A product road map, properly written, can bring a bit more “why” into a vision by saying “we are going to not be servicing these customers which means I want do build foo instead of bar”. It can coordinate well; but hard commitments would be bad, yes.
I just haven’t met a CEO/Leader/Grand Poombah who could bring their fuzzy words into reality without something like a road map.
Jon Nichols
on 10 Nov 07Most who object to this post seem to be suggesting that a roadmap is just a guide that helps the team make decisions now about what to do next. And in this regard, a roadmap makes some sense.
However, in every single team that I’ve worked, it took no longer than about 15 minutes from the time we published a roadmap for a salesperson to be using it as the basis for promises to customers.
Of course they shouldn’t be doing it. But they just can’t resist. It allows them to make promises that get their customers excited, and still have the ability to blame the engineers when things don’t turn out that way.
Marko Yakov
on 10 Nov 07I agree that Publishing a road map may not be a great idea but that’s not an excuse for actually not improving your software.
A roadmap at least puts some pressure on the development team because clients have expectations. One could even update the road map when the feature is almost finished.
I don’t think anyone BUYS software hoping for “Future features” That suggestion is ludicrus and if there are people who do they are a minority.
My problem is that i feel that your software starts out great with wonderful prospects and quotations from the NY times but by after six months when you are busy releasing your new product and no updates have been made i would like to see a roadmap.
The newest product highrise is ridiculously expensive. 37 signals is known for ease of use, good coding and good pricing. Now we have good coding, ease of use and terrible pricing with the promise that the software is probably never going to get a big feature update.
Sounds like the customers are being sold a lemon and all the new customers for the new products are also buying in on “future potential”
Note how many quotations by reviewers for 37 signals say, in one way or another, that 37 signals has potential. What they don’t realize is that the software (when released) is probably as good as it’s going to get forever.
Rob Grady
on 11 Nov 07Roadmaps can certainly be considered a broken promise if it isn’t met but accurately developed roadmaps with a business framework can be an effective tool for managing business prioritization as well as communicating and managing multiple stakeholders. Roadmaps (depending on the definition) can be a great tool to capture, evaluate, prioritize and assign features to a release plan as well as provide a forum for discussion. Depending on the organization there are generally many stakeholders vying for feature prioritization. A roadmap that connects features to business objectives as well as illustrating effort and impact is powerful tool for prioritization, decision making and communication. A PowerPoint slide that shows features over time without the backup is worthless and likely to disappoint.
Nathan Youngman
on 11 Nov 07“In preparing for battle, I have always found that plans are useless but planning is indispensable.” – Dwight D. Eisenhower
“For which one of you, when he wants to build a tower, does not first sit down and calculate the cost to see if he has enough to complete it? Otherwise, when he has laid a foundation and is not able to finish, all who observe it begin to ridicule him” – Jesus
What I’ve gathered is to A. keep your internal plans flexible, and B. don’t make empty promises in order to please your clients, be realistic with what you can deliver on.
Mark Gladding
on 12 Nov 07I’ve taken a different approach for my software product. Instead of publishing a roadmap I’ve published a Product Vision. This simply states a set of design goals that were used during development and a pledge to refine the product over time to better meet these goals.
My hope is that by sharing my design goals, potential customers can get an idea of what I consider important and hence where the product is likely to go in the future.
Olivier
on 13 Nov 07I tried to produce a french translation for this article.
Let’s have a look a don’t be afraid to give me your comments !
Dougiefresh
on 13 Nov 07Product roadmaps are as useful as they are allowed to be. For me, a longtime producer, I’ve used roadmaps as much as a ‘what it isn’t’ document as a ‘what it will be’ document.
In the pinch point between engineering and product/marketing I’ve found that both sides have widely varied senses of what the product will be at any given point in its evolution. A road map document protects engineers from feeling like the product will never be finished, and it helps product people understand that we’re going to ship this thing, and it will get better over time.
At the end of the day the roadmap is just another communication vehicle that if used correctly, can be very helpful.
This discussion is closed.