Happy Holidays!
Hoping everyone has a great break and is getting refreshed for what’s sure to be a whirlwind year in 2008! I will be at CES again this year, and will post more details about the schedule / location as we get closer to the date.
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).
Makes Me Wonder
There is a recent article up on Marketing Profs that I’d like to briefly discuss. Particularly, this quote:
The product manager is generally responsible for ensuring that a product gets created, tested, and shipped on schedule and that it meets the specifications. This function is primarily internally focused, bridging Marketing and Development. This person generally has excellent technical expertise but rarely has the marketing expertise needed to bring a product to market.
While I do fall into the “technically savvy” group, this is a complete disregard of what product management is, when done true to form. Aside from the fact that it requires far more than “marketing expertise” to bring a product to market. This may be a bastardization of titles, or a lack of understanding - but I’m not sure.
The key thing missing here is that it’s the PM’s responsibility to gather feedback, parse it, craft a roadmap and execute that roadmap. The thing angering me most here is saying, essentially, product manager’s are nothing more than development managers.
The second thing completely wrong is saying that a PM is only there to “bridge the gap between marketing and development.” What is that about? A real PM knows it’s their job to pivot between Sales, Engineering, Marketing, Services, Management, Support, etc….
Why is this the case? Because a real PM understands they can’t be perfect at everything, and that people need information, and that good ideas can come from anywhere. They know their strengths within these functional areas, and will ensure they understand each group, at least, conceptually.
So, let’s be clear: a real, fundamental product manager does much more than take what geeks say and turn it into something copywriters can understand and fluff up. Bringing products to market requires a complete cross-functional effort, and a product manager or a product marketing manager should never believe that they alone have the full set of expertise required to do it all.
My personal philosophy is that a product manager acts as the proxy to the market. A product marketing manager speaks to the market, while a product manager listens to it. And I’m not the only one that thinks this.
