
The Ingredients for a Great Product Roadmap - versusdotcom
http://berlinvc.com/2014/01/08/the-ingredients-for-a-great-product-roadmap/
======
pinaceae
hmm, I follow a different model which was explained here recently by Des
Traynor in a brilliant, short talk:
[http://vimeo.com/81544164](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.

------
sergiosgc
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.

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

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

