Ingredients of a Roadmap
Like Cookies, You Need Some Key Elements
We loved baking cookies as kids. We’d make chocolate chip cookies all the time. Sometimes just to eat the dough. But whatever dough was left, we’d make into cookies.
Of course, when it comes to baking, the right ingredients are key. Even the small ones, which I remember learning early on.
As we made one batch, we thought we did everything perfectly, as usual. After we had eaten our fill of the dough, we scooped it onto the cookie sheets, and into the oven it went.
But then, something strange happened. The cookies started to spread, and spread, and spread some more, until they were more like flat, sad little discs than the plump cookies we were used to. At first we thought we had accidentally used butter instead of shortening (something that we accidentally did before we were taught that we didn’t use butter for cookies in our house).
So we retraced our steps through the recipe, and then it dawned on us. We'd forgotten the baking soda. We had no idea what baking soda was for at the time, but it is the silent hero of the cookie world, the little ingredient that gives cookies their lift and spread, that makes them fluffy and soft instead of flat and crispy.
Our cookies were missing a key ingredient. Without it, they did not become cookies. At least not the good cookies we were expecting.
This works the other way too. You can add too many ingredients to cookies and they aren’t chocolate chip cookies anymore. For example, for some reason, our parents always liked nuts in their chocolate chip cookies. So they’d separate out some dough and add nuts to it. Ruining, in our opinion, the chocolate chip cookies.
Like cookies, product roadmaps need the right ingredients (check out that segue, right?) Without certain ingredients, they aren’t roadmaps. But with too much, they lose their goodness as well.
I was recently discussing product roadmaps with another person. In their mind, the roadmap was the project plan for executing everything we’d be doing for the next quarter and the next year. So we needed to have all the details from every team in order to create it, including technical requirements, designs, etc.
Of course, that led to a (hopefully) educational conversation of roadmaps vs. project plans. The roadmap isn’t the project plan, as we’ve discussed before:
A product roadmap is a strategic document that describes the future direction of our product. It serves as a guide (or roadmap!) that outlines the vision, direction, and priorities. A well-structured product roadmap can help align the stakeholders and the development team, facilitate communication, and manage expectations.
Like a good batch of cookies, a product roadmap needs certain key elements. That includes:
This is the guiding principle of the roadmap, outlining the long-term goal of the product. It should be broad and inspirational, setting the direction for the product's future.
For our products, we need to understand where we’re going if we’re going to create a roadmap to get there. This vision is the destination we want to get to and it should guide everything we’re doing on the roadmap in order to achieve our goals. The roadmap is part of our strategy to achieve the vision.
These are specific outcomes that the team aims to achieve. They should align with the product vision and be measurable, so progress can be tracked over time.
Our goals and objectives are about why we are doing what we’re doing. It is easy to focus on what we’re building, and that is typically where we see too many companies and teams focus. But good product roadmaps include the why in the form of goals or objectives.
These are high-level efforts or projects that will help achieve the goals. Initiatives may span several releases or product versions.
I’ve called these themes at some companies and initiatives at other companies. However you want to brand them or think about them, they are the high level units of work you are focusing on to achieve your goals. The big stuff.
Now we’re getting into the details, but not too far into the details. Ideas and features are specific functionalities or capabilities that we will add to the product. We typically tie features to specific initiatives.
In the short-term, we can typically be more confident about the features we’re building or planning. As we move further out, those features take the form of ideas. We’re not as confident and need everyone to understand that we may or may not build certain features (or ideas) depending on what we learn.
Finally, we need timeframes. These give a rough estimate of when we plan to tackle each goal or initiative.
In most companies, this takes the form of quarters, since we often do business planning in quarters. And that’s fine. Some companies are open to a more flexible approach like “now, next, later” which doesn’t put specific dates on the timeframe, which can often be even better. Regardless, you’ll need to include timeframes for your stakeholders and teams.
Like we love to say, a roadmap is not the project plan. It won’t include all the technical details for the next year. Nor should it. There is a time and place for those, but it is not the roadmap. Just like there is a time and place for nuts, but it is not in chocolate chip cookies.