Amine 30 Jan 06

“What�s the point of a long list when you can�t work on everything at once anyway?” .. But what does Build half a product mean ??
Ref: http://www.37signals.com/svn/archives2/coming_soon_getting_real_the_book.php

Dutch Rapley 30 Jan 06

As usual, you guys never fail to give great advice!

Is this the start of a new column? Ask an Entrepreneur?

Bill R 30 Jan 06

I have to respectfully disagree. I understand and appreciate your agruement. I however find that the information that a 6 month road map provides to your customers vastly out weighs the negatives that you stated above.

Providing road maps are just as much for your customers (or potentially even better, future customers) as it is for yourself.

Not to start a flame war but this is exactly why many people feel that Microsoft provides superior development tools than that of Apple. This is because Microsoft tells everyone what they are currently working on whereas Apple does not.

I speak on this topic with first hand experience since I work for an applicaiton development house who produces products specifically for the Mac. Apple has killed developers in recent years with the transition to OS X and now to Intel. This is not to say that OS X and now Intel are not great moves. Apple is just giving us NO time to react because of a lack of a road map.

Just my 2 cents and rant.

mm 30 Jan 06

what kind of “products” are we talking about? software? the only software projects that take 18-24 months are ones that actually do need some planning. games often take about that long, and they often plan things somewhat carefully, mostly just to satisfy the game publishers who are funding development and want reassurance that they have a reasonable chance of making back their investment.

but obviously trying to predict what will happen N months from now for all natural numbers N is unreasonable.

Matt 30 Jan 06

I might disagree with this article as well. I'm just now thinking about the open source projects that don't have a simple 6 month road map, nearly all of which seem to be significantly behind those projects that have one.

BradM 30 Jan 06

I think they’re just focusing on what works best for them and not really what’s best for everyone.

Prophetess 30 Jan 06

I understand the underlying messages of “ditch roadmaps” and “eschew meetings”. You’re trying to tear down the entrenched structures of business-as-usual, and take a look at the problems those structures were built to solve with fresh eyes.

But I think your message is getting lost in translation. From the perspective of someone who’s *been* in the trenches with a half-a-dozen hardheaded strong-willed programmers all intent on implementing *their* baby feature, “ditch roadmaps” is a short step from “load the company in a minivan and drive it off a cliff”.

Of course, slavish devotion to an out-of-date sketch for your company’s products is not feasible. But neither is coding into the wild blue yonder, and not having the first idea what the final product will look like.

JF 30 Jan 06

Prophetess, take whatever value you find and leave the rest behind.

pwb 30 Jan 06

Chandler is a *perfect* example of what’s wrong with roadmapping. For starters, Chandler has yet to deliver anything of value after several years. And, it’s roadmap is very “yesterday”.

Chandler would be much, much better off rolling out value today and incrementing based on a loose vision.

Kyle 30 Jan 06

Agreed with Bill and Jeremy. A roadmap done properly is still a useful tool, because it avoid the pitfalls implicit in Jason’s post: that the roadmap is a static or infrequently changing document.

Within our organization, we publish product roadmaps using a wiki (Confluence). The low barrier of entry for editing a wiki means the roadmap can be updated as we have meetings with our business users. Said business users can place a watch on the road map to get e-mail notification when it changes.

Consequently our roadmap is a dynamic, flexible document that ensures IS and the business are on the same track in regards to development of a particular app.

Kevin 30 Jan 06

Any updates as to when Getting Real the book will be available?

mm 30 Jan 06

any desktop software that takes two minutes to load better make me lose weight and get me laid or something spectacular like that. chandler is ridiculous.

Rahul 30 Jan 06

Just in case someone missed it, this whole post is basically a rewording of the same 37signals/getting real core statement: get something done today, go home, sleep, get up, and get something else done. Repeat. As long as you keep getting things done, you’re achieving more than if you follow a really awesome roadmap for a year but still haven’t launched your product, satisfied your clients, or - more importantly - satisfied yourself.

Unless satisfying your clients involves doing nothing for a long time, in which case I say: get new clients. Or if satisfying yourself involves doing nothing for a long time, in which case you’re a procrastinator/sadomasochist and should probably get a different job.

Arne Gleason 30 Jan 06

I think product roadmaps are a great place to put the features you really, really could have used today (sometimes I can use more than I can get). Driving that road with your eyes closed is an all together different problem.

Hank 30 Jan 06

What I prefer is something like is a hybrid between a roadmap and a feature list (without dates).

Netvibes.com seems to do this well with their “Feautres in the Works” list of what they plan to release without givng a time frame.

http://www.netvibes.com/blog/

It benefits both developers to give them an idea of what to work on and the customer so that we know what’s going on.

Dont’ forget, it’s all about “singals” that you want to send to your customers and internally.

Brad 30 Jan 06

I totally agree with Jason.

Too many of you are stuck in a different paradigm. Not wrong, just not in the same space as 37s.

You get so caught up in the semantic mumblings that you miss the simple truth. Just because something doesn’t or won’t work for you, doesn’t mean it isn’t true. Just because something does work for 37s doesn’t make it universal.

37s preaches pragmatism and many responses simply react to the outworking of their pragmatic approach. They don’t hold meetings because in their experience, meetings waste time. They don’t write functional specs because for them functional specifications don’t work. They don’t develop roadmaps, because for them, roadmaps deter innovation and spontaneity.

These ‘things’, the meetings, the functional specifications, the roadmaps, the “whatever else gets posted and flamed”, are all just tools in the development lifecycle. Obviously 37s communicate with each other during the development process; they just don’t �meet�. Obviously 37s envision the products potential and capabilities before they develop; they just don’t use functional specifications. Obviously 37s have ideas for where their products can, could and will go, they just don’t write and release roadmaps.

Don’t get so tied into the processes that work for you that you can’t step outside and see that a. you could improve your own process, b. there are other ways and c. 37s is hugely successful so something they are doing is obviously working. JF never says there is only one way, he simply and generously offers insights into his way. And his way works.

I�m all for discussion, but to say, �I disagree, you need (fill in the blank - _meetings_, _functional specifications_, _roadmaps_, etc) in order to be successful.� just makes you look stupid because obviously just because you may need those things, not everybody does.

Michal Migurski 30 Jan 06

Sometimes I wonder whether “Getting Real” is a 37Signals plot to eliminate competition through unqualified absolutes masquerading as business advice.

“Why bother with that frumpy old cow, when you can have these magic beans?”

Doug 30 Jan 06

Well put, Brad.

Michal, how is it unqualified? 37s is a successful software development company. Their success is the qualification!

Fredrick 30 Jan 06

Does anyone find this somewhat ironic. What we are telling ourselves is that we should develop products without a clear roadmap, without dates (“it will get done when it’s done”), and only talk about new features when they are ready for production.

Now, this sounds great in all but is it really what we want?

Take for example Microsoft. They have essentially done exactly that. They have removed any roadmaps they had (e.g. WinFS etc). They have now pulled anyway from any committed release dates and even now scrapped offical Beta releases. And guess what? Everyone thinks they are behind schedule and not “working” on anything.

People think this because Microsoft isn’t giving the “signals” (like a previous committor alluded too), as they once did to their user community

Michal Migurski 30 Jan 06

Doug: I mean the absolutes are unqualified, as in “Don’t have meetings” or “Road maps are dangerous.” It’s no accident that most aphorisms come in pairs: “Many hands make light work”, but “Too many cooks spoil the broth.” Knowing how to balance competing constraints is hard.

I’ll admit I’ve never attended at Getting Real seminar, but I have seen the material presented live and I don’t recall it ever progressing past the superficial “Do This, Don’t Do That” level.

gwg 30 Jan 06

JF, will you please put your quote “take whatever value you find and leave the rest behind” in the SVN header or footer?

I enjoy this sort of thought provoking post; they’re small insights into a different way of appraoching projects.

Anonymous Coward 30 Jan 06

Michael Suter: I took a test drive of your demo of PushCRM and was reminded of the 37svn article, "Your site�s got 1/20th of a second to make a first impression".

Because wow - I was immediately unimpressed. Maybe you should create a roadmap to Improve the UI!

joelfinkle 30 Jan 06

I’m another dissenter. We’re stuck with long-term planning, and it hurts us in many ways.

I work for a company that makes software for the Biotech/Pharmaceutical industry, and much of it (more than is really necessary) is subject to federal inspection regulations, which requires the dirty v-word: Validation. Our customers can’t install new versions every two weeks, because it can be a six-week qualification period just to get a software installation up and running (I’ve seen it go to six months!). There’s sandbox environments, validation scripts, approvals, etc. etc.

So our releases have to be ‘chunky’: a whole slough of features all added at once, with only ‘emergency’ bug fixes in between. That means that customers will (aarrghh) wait six months before deciding to upgrade, and then maybe decide to wait for the release after that, to get the *next* batch of features.

You’d think that ‘less’ might help here: componentize the products, sell them piecemeal, easy testing and validation. No dice. It’s the ‘system’ (human, machine and software) that is validated. Change one element, and you’ve got to document that the whole system performs as expected.

Rob Sanheim 30 Jan 06

I’m sure any such note would lost on those who take these postings to be absolutes to apply to every one in every context.

Rob Sanheim 30 Jan 06

…that last msg was directed to gwg, btw.

Jeff 30 Jan 06

Has anyone ever consider that the process of creating the roadmap is more important than the roadmap itself?

PJ Hyett 30 Jan 06

The internet is unpredictable. What you may think is a good idea turns out to suck and the best ideas can be completely unexpected. No thanks on a roadmap, I’ll just keep delivering new features when the inspiration strikes.

Absconditus 30 Jan 06

What I’m hearing is “we like inaccurate road maps such as the ones provided by MS because we want to pretend we have an understanding of what is coming up”. Did anyone have any idea what .Net was for the first couple years that MS hyped it? Has MS ever hit a scheduled release date? Do you seriously start planning work based on development products/technologies/buzzwords that aren’t even available yet? Do such roadmaps really serve any purpose other than filling some psychological need to know about the bleeding edge?

Apple may not provide a several year roadmap, but they certainly announce new items of interest to developers long before they are available to end users. When they announce something, such as the switch to Intel chips, they actually have the something available to begin development and testing on. How did knowing about .Net years before it was even defined let alone available help anyone?

A company such as 37signals has the advantage of having a lot of direct communication with their clients. While even MS developers are easier to contact now they certainly aren’t going to let you know about some feature that MS hasn’t authorized communication about. Jason *is* 37signals. Presumably Jason seeks concensus when necessary, but he doesn’t have to wait for 37signals legal, public relations and executive permission before letting users know about something that is coming up.

Steve 30 Jan 06

Deep question: if 37S doesn’t believe in roadmaps, why does Basecamp have milestones?

JF 30 Jan 06

An hour or so into it: 20 seats sold, 40 remain.

Dutch Rapley 30 Jan 06

Jason has never said “Everyone follows a two year roadmap,” “My techniques are superior to yours,” “You should dump your management style in favor of mine,” “If you don’t do what I say, your projects will fail,” etc.

It almost sounds like the critics are critiquing Jason’s analogies and writing style more than his wisdom. After reading some of the comments in this thread, I can understand why Jason & Co. turned off comments a while back. Jason offers wisdom based on facts from personal experience.

For those of you who want to critique Jason and the 37signals team (for whatever reason), I believe the best place for that is your own blog. Once you have tried Jason�s techniques and decide that they don�t work for you, it is then proper to come back here and blast what he preaches and practices. If you are currently successful without applying Jason�s techniques, then you have no reason to change your management style and the way you do software development, but that also doesn�t give you any reason to disagree with Jason.

What, I believe, Jason is saying is that roadmaps shouldn�t completely decide the fate of your development cycle. When you base current tasks off decisions that were made 6,8,12 months ago, it could potentially harm your project by preventing you from addressing new opportunities that may have arisen between then and now. The world of building web applications on an ever-changing landscape is a very fast-paced one. By adhering strictly to a roadmap, you may destination could easily change and you end up where you wanted to, not where you could have actually gone.

37signals also has another tool that allows for them to throw away roadmaps, Rails. Since they use Rails in building hosted applications, they have the flexibility of releasing new features on the fly, while not worrying about how it will affect current functionality. The power behind that isn�t Rails itself, but the MVC architecture that Rails enforces. Instead of using a roadmap to drive your development, consider using a queue where you prioritize your features, roll them out one at a time. Sometimes you will add to, remove from, and re-order the list. I know this method won�t work with client applications, but you can�t beat the process for hosted web applications built with Rails.

Jason�s voice is a voice of hope for those who are building hosted applications with small development teams and even smaller deadlines. When the 37signals team offers advice, take from it what you will and leave the rest behind, but please don�t discourage it.

David Bond 30 Jan 06

In the high tech industry, the product roadmap is your strategy. It is the medium-long term description of where you are going. It guides and is constrained by investment and the generation of shareholder value, communicates and serves as a negotiating point with customers and determines vendor decisions.

The assumption made in this piece is that the product roadmap is OLD. If that is so, it is next to useless. But as a living document (as with any other) it is the business lynchpin that everyone can read, understand, define and through which they can add value.

This piece advocates almost total short-termism. Good luck with explaining that to your finanical, vendor and customer stakeholders guys.

Darrel 30 Jan 06

The problem of not having a road map is defining when you’re done. I find a roadmap is one of those ‘good constraints’ to have. If the roadmap is kept relatively broad, it can stay fairly up to date as well.

For better or worse, Roadmaps are often less about the developers and more about the management of manager’s expectations.

Allen 30 Jan 06

Isn’t BASECAMP nothing other than a tool for roadmaps?

Just think about it for a second. Creating “To-Do” lists, and certainly “Milestones” is what essentially a roadmap is!

BC 30 Jan 06

Sure, you can use Basecamp to make a roadmap if you’d like. Doesn’t mean it’s a roadmap tool.

Nick 30 Jan 06

Allen: That's a great point and I have never thought about it that way. You are absolutely right, BaseCamp as well as any other project management tool essentially allows people to create roadmaps.

So, I find it somewhat ironic that a company that creates a project management tool is in away telling you that you don't need to use their product.

Jason G 30 Jan 06

Nick & Allen. I can't stop laughing (seriously).

Can anyone say that 37signals might be biting the hand that's feeding it

Dan 30 Jan 06

I agree to a point. Getting locked down to a roadmap usually means there is a disconnect between the customers and the product team.

On the same note, having a loose feature list that speaks in general terms about what you are planning to deliver can also help sales/adoptions of your tools/products.

We are working on a soultion that our partner is also planning to deploy in Europe, so plans for internationalization etc. needed to be accounted for in some way, including timelines.

I agree with the comment above saying “Has anyone ever consider that the process of creating the roadmap is more important than the roadmap itself?”. I think one of the most important items to convey from the product team to the development team (keeping in mind earlier comments in the ‘what VCs look for blog’ in that we all like to have engineers that are also good product people) is some idea of where the product is going. You want the development team to build in some concepts into your product to account for where you are going, but not over-engineering it to the point you never get v1 out the door. Having a great prodcut team is equally important as having a good development team. Just my 2 cents

JF 30 Jan 06

So, I find it somewhat ironic that a company that creates a project management tool is in away telling you that you don’t need to use their product.

Uhh, what?

What does a long term product roadmap have to do with Basecamp? For example, we use Basecamp for very short term planning and discussion. Others may use it for long term planning.

It’s totally up to whoever uses it to use it how they want (and there’s no wrong way to use it), but there’s nothing inherent in Basecamp that says “MAKE A LONG TERM ROADMAP.”

Michael 30 Jan 06

They can also be depressing. If you do have the freedom to innovate, and build features that are needed, and do new features that no one expected, you should feel good.

However then you go and look at the road map and you have only met a few of the items on it. Sure, it may be irrelevant now but it does actually get you down.

The only thing they are good for is marketing where that is important, but you want to make sure you don’t over promise. Or else have one of those flashy things from men in black.

Prophetess 30 Jan 06

Like it or not, 37signals reaches a large group of people, and is influential within that scope. That gives the writers a lot of reason to consider their words and the effect they will have on the assorted readers. I do like a lot of what I read here, and my purpose in commenting is often to present data gleaned from my own experience that contrasts with the writers’ viewpoints. Keep up the good work.

David Heinemeier Hansson 30 Jan 06

Jason G: You must be new here. Signals vs Noise has and will never be a place where we tell our customers how beautiful and sexy they are (though I’m sure several of them are just that!).

It’s a place where we share our thoughts on “design, customer experience, entertainment, politics, Basecamp, products we like, small business, ourselves, and more”. If such sharing never provoked, or even upset, some of our customers, it would be a very boring place indeed. We have no trouble telling people, customers or not, that we don’t agree or that we think they’re wrong.

If your hand got bitten, feel free to retract it.

RobG 30 Jan 06

I agree with Kyle and Brad. Roadmaps are tools (such as project plans) which can be potentially be harmful if they are not updated regularly to reflect the changing needs of the client or market. In my experience, roadmaps can provide a good focus for feature prioritization as well as provide visibility for constituents. Ultimately it is a tool that you can choose to use (or not) based on your product(s) AND team structure. The ‘emergent’ methodology can be a challenge for larger teams that require extended planning.

Rimantas 31 Jan 06

In short, successful company:
has core values which never change
has a vision for a few years ahead
plans only for the next 3-6 months. More does not make sense.

Was it Semler who asked, why is this so - all the good things happen in the second half of the year’s plan?

Brandon 31 Jan 06

I’m disappointed. And they may not put it as bluntly as I’m about to, but I agree with Bill R and Frederick. This is about keeping customers in the loop, and allowing them to be a part of the process, not just a beneficiary.

Notions like “Forget feature requests…” and “Roadmaps are dangerous…” both put the developer as owner and the customer like a lapdog. I suppose there’s something positive that comes with being so narcisisstic, but you’re sending the message of “you’ll get what I give you,” and “I always know best,” to customers and prospects.

Good luck to the rest of you working for companies, developing killer, innovative solutions, who think you can get away with treating customers coldly. You don’t have the marketing “buzz” or momentum 37Signals has right now. They can skim through their customers’ opinions and thoughts and go about their week-by-week gameplan. But nearly the entirety of the real business world doesn’t work that way. And can’t, without repercussions.

Having said all that, it’s their blog. We’re all just commenting.

JF 31 Jan 06

I�m disappointed. And they may not put it as bluntly as I�m about to, but I agree with Bill R and Frederick. This is about keeping customers in the loop, and allowing them to be a part of the process, not just a beneficiary.

Our customers are very much a part of the loop. A huge part. Just about everything we do originates in a customer request.

We just don’t set false expectations. We prefer the expectation to be “We’re going to continue to make this tool better for you by paying close attention to how people use it all the time” instead of “Here are the 12 new features we’re going to add this year no matter what happens” because of some assumptions and ideas we had last year.

We see our method as being far more customer friendly and far more based on customer needs than the other way. And so far our customers are thrilled with the results.

Tim 01 Feb 06

You get a fair number of cancellations too. I was one when I found out that issue tracking wasn’t on your roadmap and would never be (which I dug out of a forum post JF made).

I think the need for roadmaps depends a lot on how small and agile you are, and how small and agile your customers are. Large distributed development teams need more upfront planning. Some customers value predictability very highly, and devalue rapid change. If you work in that space, roadmaps are very helpful.

Ashish 02 Feb 06

Product roadmaps are NOT dangerous:

I work for one of the Mega guys as a Product Roadmapper. They help us improve time to market, eliminate redundant projects and improve efficiency by automating planning practices as cross-Business units product roadmapping, portfolio selection and technology foresight.

FooBear 02 Feb 06

Fire is dangerous too.

greg 13 Feb 06

Having a roadmap does not interfere with any of the reasons you state for why roadmaps should be avoided. Specifically you write:

“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.”

As long as you have ideas about the future and the confidence to share your vision, you should have a roadmap. This is how you align internal and external constituents, from development, sales, support, VARs, and customers. My co-workers and customers have always wanted to know how today’s release fits into the larger picture and understand the priorties.

A roadmap is not a contract. It can always be modified. Everyone knows markets, technologies, and priorities change. You can update your vision and your roadmap at anytime.

debhart 20 May 06

A map is something I follow, carefully, so I don’t get lost.

Why on earth would I follow a software development plan created 2004? If I won’t follow it, let’s not call it a map.

Maps trace the past. Our products are in the future. We need a different word that shows that this “map” is really our vision of one possible future - among many.

deb
editor, Agile InfoQ community
www.infoq.com