At Roadmunk, we believe that the product roadmap is a statement of intent. This definition frames the roadmap as a living document that can change as the product and the company evolve.
This core definition extends to every part of a roadmap, including its more granular elements: the milestones. They’re often the underused and misunderstood parts of a product roadmap. Some PMs don’t even think they need them.
On the other end of the spectrum, some product managers are too liberal with their milestones. In the absolute worst case scenario, they treat milestones as inflexible commands manufactured to create a sense of urgency around tasks (shivers).
Here’s our case for why you should reconsider your approach to milestones.
Ready to start roadmapping? Learn everything you need to know by reading our 2020 guide to product roadmaps.
What are product roadmap milestones?
Milestones are used to call out high-level dates that are important to your product team. They're there to spotlight internal and external goals. You can use some of our app’s suggested milestones like trade shows, conferences, achievements and releases. But as a PM, it’s up to you to define what makes a worthy milestone.
If your product roadmap is a statement of intent (like our definition states), you have to leave room for flexibility and the possibility of change. That flexibility extends to your milestones.
If you’re a team that uses dates to build software, milestones should be a key element of your product roadmap because they add a sense of purpose to your team’s efforts. They are the visual points of reference that let everyone know what the high-level achievements will be.
For product managers, these time-based markers are also super important for company-wide alignment. Some examples of these markers include wrapping up market research and launching an email campaign.
At a more granular level, milestones are used to rally your team around a date. Seeing a visual representation of these valuable, high-level intentions is motivating for everyone involved (and it falls in line with the type of roadmap planning we call information design).
But milestones are more than just a pretty addition to your roadmap. They also operate under two different functions.
External vs internal milestones
You probably know this, especially if you’re a more seasoned PM who’s seen some shit, but milestones fulfill two very important functions on your roadmap:
1. The internal milestone: This is your traditional milestone. The one that marks the points in the roadmap where the efforts of the team are getting closer to the end goal. They are the more significant events on your roadmap and the drivers of the gritty action, like getting design approval on a product feature.
2. The external milestone: These milestones are events that take place independently from the items on your milestone (for example, an industry event where you’re planning to present what your organization has achieved). External milestones add another layer of context to your efforts—they don’t get as much visual emphasis as your internal milestones, and they’re not meant to steer the team’s attention away from the internal milestones.
You can use both if you need to, but approach them from a functional point of view. We appreciate the optimism behind using a ton of milestone markers on your product roadmap. You’re rallying your team and stakeholders to get excited about a big event or achievement! But keep in mind that the visual significance of your milestone markers becomes forgettable when you overuse them.
Consider the concept of key dates as a way to go easy on the number of milestones you stick onto your product roadmap (which we also have as a feature in our roadmaps, wink wink).
What’s the difference between milestones and key dates?
While milestones operate at the macro-level of decision-making and overall company direction, key dates get more into the micro side of things. Key dates are better for marking item-specific phases rather than phases that affect multiple initiatives. In fact, one common way milestones are misused is when they’re dependent on a single item—like making milestones called “dev complete” or “design complete”.
Key dates are part of your item—they’re granular and they provide a more broken down view of what progress is being benchmarked for your team. Milestones, on the other hand, stand on their own and exist outside of the items on a roadmap.
So, consider this: before you go gung-ho on littering your roadmap with milestones for every predicted achievement, replace them with key dates. Key dates nurture alignment around the expected completion of each task that you itemized on your roadmap.
Think of it like a triathlon. Your milestones are the transition areas where your athletes change gears for the next stage of the race. Your key dates are the fueling stations, the cheering audiences, and anyone who fosters a sense of motivation towards a finish line.
Use case 1: Milestones as feature launch markers
Using milestones to mark feature or product launches is very common, and the most straightforward use for milestones on your roadmap. It’s also the best way to use this feature on the timeline view.
Think about it: you have your feature or product launch checklist, and now you’re ready to incorporate it into your snazzy roadmap. This is where you take each point in the list and stick a little milestone marker on it.
Milestones are ideal for noting feature launch markers. They’re perfect for marking actions and events that mark a significant stage in your product or feature release when the milestone affects multiple items or teams at one period of time (as opposed to making them dependent to a single item).
The best way you can optimize the way you use your milestones is by asking yourself: how can I be as effective as possible when I use these progress markers? How can I apply one milestone to multiple interdependent items on my roadmap? When you answer those questions, you’ll end up with a much more valuable and useful roadmap.
On top of that, milestones can be exported, unlike key dates—they’re meant to be shared! This makes them perfect if you need to rally or align your team around a date.
Check out one of our product roadmap templates to see what those milestones and key dates look like in action ?.
Use Case 2: Milestones as quarterly reminders of the business outcomes that matter
Another use case for milestones is using them as reminders of what outcomes matter to your company. Ask yourself these questions and answer them in three-month blocks, for example, if you’re working in quarters:
- Where do we want the product to be at the end of each quarter? How will I effectively use my milestones to drive the action towards that ideal outcome?
- What are our big goals and vision for the company, and how are you making sure that your milestones reflect that?
By answering that before you even get to your OKRs, PMs identify the problems they want to solve in those three months. You’re then able to specify those milestones knowing you’re tying them back to the overall plan for the quarter.
For example, if one of your objectives in the product development process is to collect quantitative research of what your users think about your product, your milestones could be:
- To complete 50 interviews with key and churned accounts (achievement),
- To deliver the results of three user testing sessions by the end of the quarter (deadline).
Your milestones should tie directly into the overall goals for your product, so you want to make sure you’re approaching them wisely.
"You need to get buy-in from everyone, even for your milestones, because if you start going rogue, people will notice right quick. For example, a good milestone would be to establish when a certain functionality should be live by. That kind of milestone can’t come from a vacuum; it needs to be discussed with everyone in the organization and the company needs to be aligned on what the outcome will be."
Adil Chaudhry, one of our PMs at Roadmunk.
You need to be able to explain the intrinsic value of each milestone. They should reflect outcomes that matter to the business, the customers and your stakeholders.
Adil used the example of sprint planning meetings to illustrate this. During a sprint planning meeting, each member of the team (Engineering, Design, Product) should answer the questions: what OKRs do we want to hit with this sprint? What are our dream outcomes? To illustrate this, one of the dream outcomes can be that customers will be able to have feature X by the end of the sprint.
By asking each member of your team what they think the outcomes should be, and by reminding everyone that there should be a direct line between the milestone and the overall business goals, you’ll ensure buy-in for every aspect of your product roadmap—including your milestones. (In case you interested in leveling up your product roadmap tool game, check out our free guide on finding the right roadmapping tools for your product management needs.)
Looking for a way to create and share beautiful roadmaps with cool-looking milestones and key dates? Give Roadmunk a test drive by signing up for our 14-day trial.