The merits of roadmaps in closed development

To provide a bit of context as to where this question/discussion is coming from... We're working on ContentBlocks 1.2. Some time ago, we made some priorities and came up with a roadmap that featured a couple of new features and refactoring that we think are important and want to make available. This roadmap is available from our website to give people a bit of an idea what we're thinking off.

Now, looking at the time since 1.1 was released and what we've actually been developing recently, we've diverged from the roadmap and built some other really cool features instead.

Now what? Should we defer a release until we finished what we published on the roadmap, or do we pretend the roadmap wasn't there and release the cool features we already have ready today? We still want to work on the features we originally wanted to provide for 1.2 but that could take quite some time, in which people can't use the awesome stuff we already have.

That led to me wondering how much value public roadmaps really have or should have, in particular for closed development like ContentBlocks.

Personally I consider roadmaps really important for open source projects as it provides contributors some sense of direction where they can focus their energy. But for closed development we don't have outside contributors providing code. Is there still a point to having a public roadmap then at all?

Before posting this I asked the question on twitter as well.. responses so far

@chrischerrett: @mark_hamstra interesting question. Been wondering the same thing for Workflow.

https://twitter.com/chrischerrett/status/519162136602607616

@jkenters: @mark_hamstra very important; they "guarantee" the product will be around for some time. Too many great products get discontinued without.

https://twitter.com/jkenters/status/519163076130914304

@jaygilmore: @jkenters @mark_hamstra Roadmaps are no guarantee of future existence. They are a single cue that a project is intended to have a future.
@jaygilmore: @jkenters @mark_hamstra In my opinion, roadmaps for proprietary software is debatable. For OS they are good for rallying contribs.

https://twitter.com/JayGilmore/status/519169482686996480 https://twitter.com/JayGilmore/status/519169775822716928

@jkenters: @JayGilmore @mark_hamstra cue is the word I was looking for. That's why I added the "s around guarantee. It's better than nothing at all.

https://twitter.com/jkenters/status/519170658614673408

Hi Mark,

Great question, I think this will spark some interesting discussions. At least I find the subject appealing.
My first reaction to your post was: hmm, this makes me think of the *cough* MODX roadmap. The MODX project itself is probably much more mission-critical than content-blocks, so these are two different contexts. However, in the case of a mission-critical system I think:

1. The roadmap is a great tool for customers/users, it allows them to plan for the future with less uncertainty (future planning is always an uncertain thing, but these guidelines help reduce it).
2. The expected roadmap release cycle should be biblical, in that what is expected should be released as advertised, anything extra is extra candy.
3. The roadmap itself should be limited as to not lock-down the development team into a rigid process. Creativity is extremely important in software development and an extremely detailed and strict roadmap would just kill motivation (my opinion...)

Now if we look at content-blocks, which is an awesome tool, extremely helpful, but less mission-critical, I think a roadmap is administrative overhead and a mistake. Why?

1. You create expectation, which is prone to dissapointment. You're better off "surprising" people than risking ruined expectations.
2. It adds a moral/psychological pressure to your development efforts. While a roadmap is not binding, it sure feels like it is.
3. Most of the time it's just not necessary. (Let me put some emphasis on this term: necessary: what really matters.)

How would I go about it?
Well, tbh, I have no experience in managing public roadmaps, my only experience is be subjected to public roadmaps
In a project like content-blocks I would create a "major change" roadmap: early notifications on things that will BREAK or CHANGE considerably with a new release. Otherwise, keep quite. Got a groovy new feature? Use it to pitch your product, attract people, create vibe. use it as a surprise, a news element, what ever. Non-breaking new features are great for that, people can appreciate it greatly and can rarely be dissapointed: it's a surprise, it's candy.

Hi Mark,

This is a topic which is of great interest to me as I am using MODX to create a specific type of application. In the context of trying to break into a market, you inevitably come across questions like, "Does your application have feature X?" "Can it do Y?"

In a large endeavor, you can't do everything at once, and marking out the roadmap lets people know:
1) Yes, we plan on having that feature, and
2) When you can approximately can expect it, barring changes in the roadmap or priorities

When someone says, "I would love to use [insert your product here], but it doesn't have A, B or C" it gives you an idea where you should be focusing your efforts. In addition, it demonstrates you've given the future some thought. Finally, it gives you a chance to engage potential customers to say, "Do you agree with this roadmap?" If we get to this point, are you willing to give this a shot?

That all being said, a roadmap should be flexible enough so that when you realize you should be exploring something else instead, you can always come up with a good reason for changing the roadmap. If there are those who feel impacted, there's always the chance to negotiate.

Regards,
Tom

I've never taken roadmaps very seriously and I don't think I've ever published one. Sometimes very cool features that are not on the roadmap turn out to be very easy to implement. OTOH, sometimes trivial features that few people want go on the roadmap because you thought would be easy and then turn out to require a complete architectural refactoring. Public roadmaps do make it look like you're planning ahead, but that's really only valuable from a marketing standpoint. For yourself and for the project, a private roadmap would be just as good.

I question their value even in Open Source projects. When I see one, I think: Is this a list of things I might contribute myself, is it a list of things I shouldn't work on because someone else is already doing them, or is it just something the Marketing department came up with based on customer surveys.

A much more valuable tool of OS projects, imo, would be a list of things being considered for upcoming versions with the option to help prioritize them, discuss how they'd be implemented, etc., followed up by a list of who was working on what and which features had no one working on them (along with some architectural guidelines for them).

I think it's important to look ahead and reach for the horizon, but an outdated roadmap could do more harm than good so I have mixed feelings as well.

It seems for opensource project, the trend is towards a Contribution Guide rather than a roadmap. With a contribution it's more about informing contributors *how to submit* code rather than *what to submit*.

A much more valuable tool of OS projects, imo, would be a list of things being considered for upcoming versions with the option to help prioritize them, discuss how they'd be implemented, etc., followed up by a list of who was working on what and which features had no one working on them (along with some architectural guidelines for them).

This made me think of some agile PM tools like PivotalTracker that focus on equating a task with a number of "points" rather than hours. Each point represents a given amount of development cycles.