Product Roadmaps
As the end of the year approaches quickly, some PM’s are going to be trying to creating roadmaps for upper management. It’s a fact of life, and sometimes it can’t be helped for whatever the circumstance. Ideally, you have a roadmap process you’ve been using throughout the year and nothing really changes for you.
I’ve got a pretty good method and format for creating these things now. After being bit in the ass one too many times, and really seeing how roadmaps can hurt organizations AND help them, I’ve found myself creating two types of roadmap: the internal and external. Before getting into the details of each of these, I’ll cover some general things.
I always prefer laying roadmaps out quarter by quarter. This is a broad view, and really defines that the roadmap is by no means a release plan. Release / iteration plans are derived from the content on the roadmap itself, so it can be more on the side of high-level.
The second major thing for me is, they change. Roadmaps are a critical part of the process, not the end result of some huge, year-long planning effort. They are liquid, and meant to be reviewed regularly. Obviously, if you have weekly management or product meetings, they aren’t coming out and getting changed that often…
Lastly is alignment. A great roadmap must be aligned from top-down. The business vision and objectives must be taken into account, along with all market data that has been gathered, and any new innovation steps the company feels is necessary to move the product and business forward by leaps and bounds.
The Internal
Essentially, this is for upper management, development, and maybe some members of the board, depending on their level of involvement and how comfortable the CEO is with providing this level of detail.
Creating this is relatively easy. Simply take a big block of the four quarters and put big squares in where the releases will (approximately) be. This will all be wrong, so just get it done. When you first start developing roadmaps, they really aren’t going to be right. They won’t probably be right even 6-8 months in, so you are much better off just getting the content down.
After you map out your release blocks throughout the year, check to ensure nothing looks wildly out of whack. Are you attempting to do 3 major releases in a single quarter, for example? Maybe 8 minor releases in a month? The reverse may also be true, depending on your situation - trying to do 1 minor release very other quarter, for example. These are all bad news, and indicate the roadmap should be re-evaluated.
After you have this down, for the internal version only, you’ll want to bullet out as many features (maybe all features) you have planned for each release blocked within the quarter columns. Remember, this isn’t a release plan or a requirements document so you can be more high-level. You really just want to offer a view of, “these are the features coming up.”
Remember, each feature you mark down will usually need more justification than, “I think it’s really neat!”
The External
On the external view of the roadmap, you want to stick to themes. No specific features really get mentioned within this stream - just prose-like descriptions of the releases you have mapped out. This affords you with the flexibility to send a roadmap out to Sales - it may even work work for board-level presentations.
The goal with this type of roadmap is to offer folks talking points and broad timelines about what the product will shape up to be throughout the year. It provides a great view, without going into detailed feature sets, about what “themes” you are looking to inject into the product(s).
Breaking into a Sprint
I just stepped through a session planning out the next couple of iterations on a product halo with a colleague of mine. The process we have taken to using is quite cool. I don’t proclaim it to be unique in any sense of the word, but definitely something I’m liking the feel of, and one I could see really developing and growing with the organization.
I started by writing out a set of bullet points, broken in to feature groups on the white board. This was our baseline. We talked through each point, made some revisions, removed some, added some others, and proceeded forward. This really allowed us to reset, and get in to what it was we were trying to accomplish.
We then proceeded to prioritize each bullet point. Since we have a lack of customer data, and some things are just obvious (especially when dealing with halo items), it was pretty easy to go through and assign low / med / high or 1 / 2 / 3 to each bullet we had written up there.
After the bullets were all prioritized, we then assigned gross hourly estimates to them - nothing under 2 hours allowed. Since the bullets weren’t full requirements, this kept things padded to a reasonable amount, allowing us to continue marching towards to goal (yes, details on what exactly what is forthcoming).
We then decided, right or wrong, that since these are halo items and not product “features” in the true definition of the word, we didn’t need to rev the version number at all, really. So it was just a matter of adding up all the gross estimates and then identifying sprint length and doing some simple division.
So, we landed on each sprint being 10 days in length for the project. With all the tasks grossly estimated, this ended up being something like 9 sprints total. We backlogged a few things, but couldn’t really get that gross-level estimate to budget too far, so we stuck with it.
My colleague now has the lucky job of fleshing out those bullets in VersionOne and assigning them to the correct sprints. And then of course, gathering up all of the materials that do already exist and attaching them to the right items, and then proceeding to execute on some key market research tasks that were identified.
Yeah, I guess I’ll help out at some point.
So, what did we end-up with? Well, a pretty common thing - a set of requirements, associated to a release project and sprints in our requirements / product management tool (VersionOne). “Big deal” you say? Well, it’s important to recognize that when you have a crap load of things to do (especially halo items, which can be convoluted), using a framework / brief / flexible process that helps get all that stuff that’s currently up in your head down on paper and in front of others, can be a huge weight off your shoulders.
Keep tweaking, keeping writing things down - but when you find you have it all up in your head, take a step back, get some people in the same room as you and start to write out bullet points and take it from there. Worst case you end-up with an empty head and an eased mind. Best case, you have developed a quick and dirty roadmap for the next several weeks that can be iterated on.
Roadmaps & Communication
I like creating roadmaps. Maybe it’s because I like planning to much.
There’s just something so rewarding to me about charting out where a product / products are going for the next couple of month / quarters. Now that we are closing in on the end of the year, I’m taking some steps back and evaluating where some things are going to go. It’s a fun exercise.
However, at the end of the day, even thought I love creating and sharing this type of stuff because it gets me excited, I’m still cautious to make sure that right knowledge is communicated in the right way to the appropriate people.
In a start-up, your plan will be one thing one day and something completely different the next. This is what makes them cool and exciting, but it can make product management quite difficult, since much of the job relies on working within the market & with customers and charting priorities based on the data you gather.
But, in start-up land you can’t ignore innovation & ideas - especially when you have fast release cycles, or lack of market data due to lack of users. I’ve found a good method when it comes to roadmapping in an environment like this is to write things out the way you would regardless, even if you know some thing will change tomorrow.
Doing it this way ensures that you have your head around where you want to take the product, and then you can present more easily to management, and others.
Back to the point on communication — much of what a product manager is dealing with is in unformed thoughts, especially when working with 4+ products. It’s not a matter of “hiding” data or information from people. A lot of PM’s will phrase things this way - especially when talking about Sales. I used to as well, but seem to be turning some kind of corner in my head.
The way I’m thinking about it is, everyone needs to eventually get the stuff you are working on, but it’s up to the PM to decide how that stuff is distributed most effectively for the team. This means that it’s not effective or productive to talk to Marketing about how long a feature you’re thinking about will take simply because that’s the realm of development. To follow that example though, it’s only when you know how long that feature will take AND how it relates to the larger product plan does it affect product marketing plans.
In the same token, Sales is not affected by things like, “we’re shooting to release 1.5 on the 15th of January” when it’s only February of the preceding year. Arguably, no one is affected by that type of information. However, it helps me to plan that way so I can see where things sit on a calendar and if we are crunching too much into too little time.
Again, to follow that example through, Sales would find information more valuable in the form of, “we’re looking to release 1.5 in Q1 of 07″ — and then when it gets down closer, you drop another layer of, “end of January”, and then eventually, “January 15th.” However, in a start-up environment, v1.5 probably wouldn’t be seen at all, as the product could be dropped halfway through a dev cycle to work on v1.0 of something else entirely.
Again, this is what makes them great.
This isn’t HIDING detail or information. This is forming a thought in as complete a way as possible. To me, this is centrally important especially when it comes to planning and strategizing. It’s much more effective to discuss a strategy or a roadmap once it’s fully formed in your head.
Share things with those that are working on it / contributing to it directly, because “slam dunks” are bad too, but everyone is going to benefit from having something more fully formed than they will getting tidbits of half-assed / half-worked thoughts.
