How To Plan Your Product Roadmap Like CoSchedule (+ Free Template)

We just completed our second ever product roadmap summit here at CoSchedule. This is where a group of us spends a full day locked in a conference room fighting relentlessly for the features that you need and deserve in your favorite editorial calendar. During this process, we review recent (and some older) feature requests, balance maintenance needs, and read through our ever-growing wish-list of features for CoSchedule. The goal? Decide what we're going to build over the next six months. It’s sort of like decide who we want to be when we grow up twice a year. For us, it follows a simple 6-6-6 framework. This covers planning in three timeframes after the day of the summit: 6 weeks, 6 months, and 6 years. We hold product roadmap summits twice per year and use them to think about our future (6 years), our next two quarters (6 months), and some of our immediate goals (6 weeks). So, why do we do this? If there is only one truth in business, it’s that there is never a shortage of ideas. Plus, our customers are awesome and send us a ton of ideas that we usually love and want to build immediately. But, alas, there are only 25 of us. We just can’t do it all. With so many inputs, it's important that we balance the things that we could do, to actually realize the things that we can do. And so, we have a product roadmap summit and pick a handful of things that will bring the most results. We all need a system for prioritizing our work. This is how we do it at CoSchedule.

Get Your Free Product Roadmap Template To Plan Now

This blog post walks you through the exercises that work for choosing the ultimate best features for you to plan into your project development roadmap. Get your free kit now to plan your roadmap as you read this post. Your kit includes:

• Product roadmap summit Word doc template to help you run an efficient planning session with your team.
• Product roadmap template Excel spreadsheet to help you prioritize the projects you choose to tackle in the next six weeks to six months.

Step #1: Establish Your BHAG (6-Year Goal)

BHAG stands for big, hairy, audacious goal. It’s an idea from the book, Built to Last by James Collins and Jerry Porras. According to Collins and Porras, a BHAG is a long-term goal that changes the very nature of a business' existence. At the beginning of every product roadmap summit, we start with this goal. We review the BHAG from the previous summit and do a few brainstorming exercises.

1. We allow for general team discussion about the goal. Does this still reflect where we want to go?
2. We brainstorm some of the big things that we will need to accomplish in order to reach our BHAG.
3. We list the threats that will prevent us from ever reaching our BHAG.

The entire goal here is to set the stage for our roadmap planning by considering where we want to go and working backward. It’s a favorite strategy of mine. https://twitter.com/garrett_moon/status/746169187169538049 The hope is that by bringing this goal to mind, we will continuously refer back to our BHAG as we do our planning. You should always be using your BHAG to evaluate the things you're doing in the present. Are you doing what you need to do to get there?

Step #2: Put It All On The Table

The next, and most exciting, portion of our product roadmap summit includes the airing of many grievances, err… feature requests! The goal here is to get everything on a Post-It note on the wall so you can see it together. We like to have one person from each of our core teams (product, marketing, and success) share a list of feature requests, customer comments, growth opportunities, and smart things that we could build. Here’s how it works:

• Lance from our customer success team shares the list of feature requests from our customers. This list is pre-sorted by the entire customer success team and should show us the key areas where our customer would like to see us improve.
• Next, we have Justin, our CTO, share a list of platform and maintenance projects that need to be completed in order to maintain the quality of service that our customers demand and deserve. This list usually includes foreign sounding things like database maintenance, spindle logs, and very excited engineers. We don’t always understand it, but we do love it.
• The third thing we cover is sales and marketing needs. These are usually covered by myself and usually include improvements that we want to make to our billing system, onboarding/first-run experience, or other areas that are related directly to our core business metrics like trial to paid conversions, user churn, and product growth.
• The fourth thing we like to cover is our feature backlog. This backlog is lengthy and includes a mixture of features that we want to see and ideas from one of our previous summits that had to go on the back burner.

During this phase, it's important that you don’t get carried away categorizing and prioritizing things. There will be time for that later. Just get it out there, let every idea be a good one, and move forward.

Step #3: Team Lunch

Next, lunch. There are usually only two rules for team lunch.

1. Leave the meeting room behind. We think it's important to get out of the building to clear our heads for a bit.
2. You don’t have to talk about business. It doesn’t mean you can’t, but we like to allow the conversation to take us wherever it goes. It’s a good way to break up a busy day.

Step #4: Prioritize

This is the hardest part of the process. This is when we take all of the ideas on the table, evaluate them against the BHAG, and prioritize them based on what we would like to accomplish in the next six months. We use several methods for breaking things down.

1. We break things down into roadmaps. Rather than trying to prioritize apples against oranges, we like to break things into a few different groups. For us, this means that we build three distinct roadmaps for our team: Features, Success, and Platform. Each of these roadmaps has their own goals. We are only trying to figure out what to build next in each of these categories.
2. We prioritize ideas based on potential customer value. We like to place each feature idea on a simple X/Y table that looks like this:

In this example, the Y axis represents the amount of value we believe that a feature or idea can bring our users. The X axis represents the total number of users, or percentage of users, who will be able to take advantage of the mentioned improvement. Plotting this out is usually the most taxing part of our entire day. For every single Post-It note, we debate and decide where the idea falls in the spectrum. We try not to overthink it, but it can still take awhile. The efforts always result in a ton of useful dialogue and debate across our team. This process also weeds out any “pet features” that someone on our team may have. The more we concentrate on user value, the less likely we are to make a call based on personal bias. When we are done, it will look something like this. In this case, one thing is for sure, the customer is always right!

Step #5: Assemble The Product Roadmap

Once everything is plotted out, we draw a (figurative) line across the X/Y axis. Anything that falls below or to the left of the line probably won’t get done. One thing that I want to emphasize is that this doesn’t mean those items aren’t important, or that they will never get built. It simply means that they aren’t important in relation to the other items on the list. We always re-review the cut ideas at the next product roadmap summit. At this point, we begin dividing things in to 6-week and 6-month groups. What things do we want to get done right now (six weeks), and what things needs to get done soon, but not right away (six months)? There is plenty of additional discussion at this point, but by and large, most of the team will be on the same page because of the previous exercise that ranked features by user value. While I am not going to go too far into it here, we also use a point system to define how large a feature is, or more importantly, how much time and resources it will require to develop. For us, this is a simple 1, 2, 3 point system. You could adapt them for your team as needed. And that’s how we plan features at CoSchedule! When it’s all said and done, we have a product roadmap, a happy team, and customers who are getting the features that will help them the most! Before I wrap things up, I want a cover a few additional things just in case you decide to try and hold your own roadmap summit.

Lessons Learned From Successful Product Roadmap Summits

Quick Tip #1: Our Roadmap Summit Has Some Rules

We use a few basic rules to ensure that we stay focused and on topic. You can add/remove as necessary, but here are the rules we use:

1. We are brainstorming projects of the purpose of the product team, no other team projects can/should be added.
2. All ideas are necessary for good brainstorming. Avoid shooting things down.
3. Keep laptops closed and phones down. No email, HipChat/Slack, or Snapchat allowed!
4. Someone should be designated to write things down.
5. Don’t get too deep into features. We’re not building them here.

Quick Tip #2: Everyone Has Veto Power

During roadmap planning, we give everyone veto power. If they are absolutely convinced that a feature should not be completed, or want to call shenanigans on the group, they can. While Justin and I tend to use this rule more than others (oops!), it applies to everyone on the team equally.

Quick Tip #3: Bring Snacks

We like to leave a few piles of red starbursts on the tables for added sugar, but we also provide fruit, snacks, and refreshing drinks to keep everyone going.

Quick Tip #4: Leave Time To Retro

The last two things that we do after any roadmap summit are related to review and reflection. First, we spend at least 10 minutes reviewing our newly formed product roadmap against our BHAG and our earlier discussions. This is designed to ensure that we will actually be executing against the goals that we outlined. Is everything on our roadmap necessary in order to reach our BHAG? Is it in alignment with where we want to go? If it isn’t, now is the right time to reflect and adjust our plan. The second thing we do is an immediate retrospective on the meeting itself. The goal here is to identify potential improvements that we can implement to make to the process better during the next summit. We like to cover three questions:

1. What went well?
2. What didn’t go so well?
3. What can we do to ensure things go (even) better next time?

Best of luck to you and your team at your own product roadmap summit! If you give it a try, please let us know how it goes in the comments.