The blog post headline analyzer will score your overall headline quality and rate its ability to result in social shares, increased traffic, and SEO value.Test every headline before you publish. Try the Headline Analyzer »
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.
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:
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.
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.
— Garrett Moon (@garrett_moon) June 24, 2016
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?
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:
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.
There are usually only two rules for team lunch.
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.
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!
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.
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:
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.
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.
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:
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.
Plan content and automate publishing to save tons of time now.
Start your 14-day trial to get organized with CoSchedule today.