The Three Pillars of Roadmap Building

I’m in the middle of a roadmap exercise at the moment and it occurs to me that this is the most important project any product manager will ever do.  Sure, it’s important to write requirements and PRD’s, but those are side effects of your roadmap.  There will never be a more important task than deciding the high level projects your team will work on and the order in which you’ll bring them to life.

So what the heck does a roadmap need to do anyway?

Support Company Goals

Do you even know what those goals are?  Maybe it’s time for a little heart to heart with your CEO or general manager because you need to know in detail what the goals are or else your roadmap won’t support them.  Are you looking to get acquired?  Increase ASP?  Reduce churn?  Go after market share?  Increase profitability?  It’s probably some combination of these things but you and your CEO need to clearly articulate what your goals are for the quarter, year or multi year period for which you are building a roadmap.

Goals should be the first slide in your roadmap deck, with methods to achieve those goals being the second.  After all, a roadmap is meaningless without an explanation of why you’re planning the things you’re putting in these slides.

Address Revenue Killers

Revenue killers come in all shapes in sizes.  They could be that killer feature that the competition has and you don’t.  They could be a persistent source of customer complaint like slow performance that’s causing customers to churn.  They could even be things like a lack of an ecosystem or poor API’s that’s causing some of your deals to not close. 

Best source for these are going to be your sales people and your support people.  They’re the one who know why current deals aren’t closing and why current customers are thinking about leaving.  The problem is one of perspective.  Sales and support people are going to give you a lot of tactical detail “this customer left because they didn’t like feature A” or “this deal closed because competitor Z talked to them about feature 1”.  It’s going to be up to you to collect all this information so you can see the trends.

This is probably not a slide unless you have a very open minded management team and board of directors.  No one wants you to air dirty laundry in public and putting slides with titles like “why we lose deals” is a guaranteed way to start a really bad conversation.  However, even if you’re not going to put this on a slide, you should still have the information.  It’s going to come up when people ask you “why are we doing project A?” and the best way to answer that question is with solid data.  “Because we lost 20% of our deals last year to competitor 2 as a direct result of not having project A in place and I have the numbers and details here to show you if you’re interested” ends the conversation right there.

Provide The Next Big Thing

Addressing revenue killers is nice and all, but roadmaps are meant to be visionary.  They’re supposed to excite people and get them oriented behind a shared vision.  For that, you need more than just “we’re going to fix feature A and put in place feature B which our competitors already have”.  You need fresh new ideas and they need to be exciting.

What are those ideas?  That’s the part I can’t help you with.  These are different per industry.  Just remember that an exciting idea doesn’t have to be a huge project.  Sometimes little projects can still be exciting.  It all depends on how you position them and this is where you need to get your mind out of the engineering mindset and into the world of marketing.

Go talk to your marketing team.  Chat with them about market trends, announcements they’re seeing and press releases other companies are putting out.  Take a look at unrelated industries and what they’re talking about.  Read magazines and see what society in general is talking and what the hot topics of the moment are.  This is where your big ideas are going to come from, not from any bug or feature request tracking software you may have in house.

Sooner or later, you’re going to have that Eureka moment where you think to yourself “oh! what is we could…” and in fact, it may even be “wait!  We could do that and it would actually be really is if…” and that’s your big idea right there.

When you have those, put them in your roadmap in the same section as all those projects you have to address revenue killers.  However, the big new thing (or things) is what should have top billing.  It’s like a newspaper where the top story gets most of the page and the big picture.  The big new thing is the top story, everything else is a sideline.  Also, don’t get hung up in features.  Tell people enough so they understand what you’re building.  The rest can be found in the PRD.

The Big Picture

A roadmap really is a set of instructions for how to get from point A to point B.  The product manager’s job is to know where point A is, identify where point B should be and then draw a line between them.  Everything else is details.

Forecasting In An Agile Environment

One of the most common issues at Agile shops is planning and forecasting. Agile shops aren’t like waterfall shops where you plan a 9 month release in advance. In a waterfall shop, it’s very clear what you’re planning to release in 9 months (which is a bit untrue because I’ve never worked at a waterfall shop that actually forecasted accurately but at least they had a forecast!) Which means that product managers at an Agile shop are unable to plan out releases or build a detailed roadmap.

What I’m about to describe is a way to solve this problem through a bit of spreadsheet magic.

(Note – If you want to see an example of what I’m about to discuss, check out this Google spreadsheet)

First, Write Your PRD

PRD’s are your bread and butter. They describe the project you intend to build, the business problem it will solve and the functionality you intend to deliver. Every project that involves more than 1 or 2 stories should have a PRD. No exceptions! Yah, I know, you’re an agile shop and you just work with individual stories. Sorry, being agile is no excuse for doing a poor job as a product manager. Your devs might worry about individual stories but you need to worry about the project (or epic) as a whole. For that, you need a PRD.

Second, Write Your Place Holder Stories

Each PRD should include the stories you’re going to deliver. These need to be broken up into the smallest possible chunk of functionality that still provides value. So if you’re doing a project that will allow users to authenticate through a social channel then you need to have one story that says “User can authenticate through Facebook”, another for Twitter, another for Google+ auth, another for “user sees error message if they try to authenticate a channel already used by another user” and so on. Break it down! This is your job as a PM and it will make the devs job a lot easier.  Don’t just write a single story called “User needs to authenticate through social channels”.  That’s pointless.  You’ve told the devs nothing about what they need to build, you’ve told your stakeholders nothing about what you intend to deliver and you’ve made your forecasting job impossible.

Third, figure out your velocity

Velocity is a measure of how many stories you can complete each week (or whatever your release cycle is). Some companies measure velocity in points and each story could have a different point value depending on complexity, but the idea is still the same. You’re trying to measure how many units of productivity your dev team can produce in a given time period. Other companies will choose not to include bugs in velocity calculation or to exclude chores. That’s fine, I don’t really care what specific system you use as long as you use it consistently.

Fourth, figure out the average value of a story

Remember those units of productivity you measured in step 3? Now you need to figure out how many units of productivity an average story is. If you’re not pointing stories then this is easy, it’s 1. If you are pointing stories, just look at your last 100 stories and come up with the average point value.

So what do we have?

  1. A PRD that represents a project
  2. The number of stories in that PRD
  3. The average number of units of productivity your team can produce in a given release cycle.
  4. The average number of units of productivity an average story costs

Multiply 2 by 4 and you have the total value of this project. Divide by 3 and you have the number of release cycles this project will take. Now do this for every project you have in your queue and you can build a really accurate roadmap.

Pro Tips!

  • Estimate velocity by engineer (or by pair if you’re a paired development shop) – Doing this will let you accurately factor in things like hiring. Just make number of devs a variable which is multiplied by velocity per dev to get total velocity.
  • Split projects into done, in progress and remaining stories – This will give you a good feel for when a product will be complete and how much progress you’re making.


  • How should I use this model with my ENG dept? First, let me answer how you SHOULDN’T use it. You shouldn’t use it as a stick to hold over their head and say “this is what you guys promised me! Where is it?!?” That’s a very quick way to make enemies which is something you don’t want in the ENG dept. You should make sure they see this as their shield. This is the tool that will let them explain to the rest of the executive team why it’s impossible to just “add a small feature that the CEO wants” or why it’s better to start with a small project as opposed to writing every possible story that a customer ever requested. This is their tool to show what happens when you don’t pay off tech debt and velocity per week starts dropping because it’s harder to write code. This is their tool to show people what they could do if they could get more engineers. For a smart head of ENG, this spreadsheet should be their best friend.
  • How should I use this with management? I would share all of this with management and be very open about what this means. They need to understand what features are in the queue and when they will be delivered. They also need to understand what levers they have to make things show up quicker.
  • Why do you have a 20% buffer built into this? Because stuff happens. You have a week with a lot of bugs, you have a minor unexpected feature request that you just HAVE to deliver this week, you have an engineer out on vacation. That buffer is your protection against the unexpected. Be very careful about eliminating it.
  • Can I use this model? Of course. The only credit I want is that you call it “The Wave Model”
  • Why wave model? What wave is it measuring? No wave. It’s just that my name, Gal, means Wave in Hebrew and I have a huge ego that I am trying to make less than obvious so I didn’t want to call this the “Gal Model”.

Note – Copy of spreadsheet is provided by permission from my current employer, SocialChorus – SocialChorus website

SocialChorus® powers tens of thousands of brand advocates – employees, consumers and bloggers – to experience, create and share authentic content about brands they love. We call this new marketing category Advocate Marketing.

Our award-winning Advocate Experience™ solution makes Advocate Marketing performance easy. We combine a comprehensive SaaS platform with a dedicated, expert team and best practices to deliver measurable social engagement with millions of people every month.

Leaders in every industry, including consumer packaged goods, retail, technology, telecommunications, travel, automotive and financial services have chosen SocialChorus, the recognized leader in Advocate Marketing.

Where Do Good Features Come From?

It’s interesting to think about where most people get ideas for new product features. The usual answer I get when I ask Product Manager candidates about this is “I would talk to my customers”. Which is fine, except for the fact that these people are already your customers. That is, they’ve already given you money for your product. Why are you still building features for them? Of course, there are some very valid reasons such as:

  • I want to keep them happy
  • I want to keep them from going to a competitor who just introduced a new feature
  • I want to charge them even more money

Sure, very valid reasons. However, they’re also a bit of a copout. They’re good reasons because they focus on the bottom line, money. New development should equal more money and these reasons all claim to follow that line of reasoning. They’re a copout because they only claim to focus on the bottom line. The truth is that a lot of customers will tell you that :you MUST build this feature for me” and “you SHOULD add this option for me or else they’ll…” well, they’ll do something! However, for the most part, that can be solved through good customer management as opposed to new features. So a product owner who focuses on existing customers is mostly doing it because it’s the easy place to find new feature ideas.

A better place to look is customers who don’t have your product yet, or even better, customers who looked at but then decided not to buy your product. These are the real moneymakers. These are the folks who would have given you money if you had developed feature X or given them function Y. Of course, these are also the people who are hardest to reach exactly because they’re not your customers. So how the heck do we know what they do? [Read more…]