The Ingredients for a Great Product Roadmap

hmm, I follow a different model which was explained here recently by Des Traynor in a brilliant, short talk: http://vimeo.com/81544164

map any feature in a graph that has people on the x axis and time on the y axis. farther to the right means more users, farther up means more often. concentrate on what most/all users would use most/all of the time. a lot of the other things are noise, added on by other entities, which over time dilutes and destroys your product.

you should map existing features as well and kill them off if they do maintain or increase reach and or frequency.

of course this is simplified, there is still a lot of balancing and reality wrangling to do, but as a guiding principle it really works. especially when you're getting the "oh come on, let's add this, just a few lines of code" type requests. any add has a long tail, from bugs, to documentation, etc.

my 2c.

Deciding to go for low-hanging high impact features is the obvious choice, and it's not the choice that makes developing product roadmaps complex. The trouble is always around technical debt.

Every company has technical debt. Stuff that:

a) Is architectural. Changing it impacts code all over. Think "preparing a database schema for sharding".

b) Is a looming ceiling on growth.

c) Is not in the immediate present nor is in the far too distant future.

When to tackle these is the usual war in my product roadmap meetings. My default rule is the classical 80/20. 80% of the time reserved for new features, 20% for technical debt. If no technical debt is evident, use the time for load testing and optimization.

So .. low effort & high impact features first .. Got it.

Am I the only one who found that article a bit light on substance?