If you’ve managed a product, you’ve probably heard this a few times: “where is that feature on the roadmap?” Depending upon the context of the question, your teammate or customer or boss might be asking when the product will have certain capabilities, when a highly desired feature will release, or simply want acknowledgment that the idea they have is valuable within the context of the problem you’re trying to solve as a business.
What’s a roadmap?
A “roadmap” is a way to describe the work we’re committing to as an engineering team. If we’re doing our jobs right, the work that we are doing right now in engineering aligns with the next set of features and capabilities we’re working on and the pillars in our longer-term strategic vision. Roadmaps comprise a story about the features and capabilities we want to create, how we align them with our strategy and mission as a business, and how we deliver those on a schedule.
The mission and vision are the top level explanation of how we want to bring value to the market. By setting an objective that is relevant for us and (we hope) for our ideal customer profile, we are creating a place for the organization to go.
A mission statement defines the organization’s business, its objectives, and how it will reach these objectives. A vision statement details where the organization aspires to go.
–Atlassian
In this narrative, features are the way the user engages with the product and gets immediate value. Capabilities are outcomes the system or product is able to deliver as part of its function when used as part of an expected feature. Over time, the ultimate vision of the product should get clearer.
There’s a metaphor for this in the way that we approach individual feature development as well. If you think of a “cone of uncertainty” representing the difference of opinion between team members, we should be able to reduce this over time. The solution that we find to individual problems in feature development make it easier for team members to work together.
Except when this process doesn’t work the way you expect. There are also constraints. Time. Money. Resources. It’s impossible to get all of the stuff done in the available time. Some people are better at tasks than others. Sometimes you are working on many projects at the same time. There is no perfect mix, and there will always be trade-offs.
How do you answer: “when will that feature be done”?
A roadmap is the physical manifestation of the mission, taking the organization toward its vision. Features are part of the strategy (the how) of getting from square one to the goal as stated in the vision. But a roadmap is a paradox, a little like Zeno’s famous paradox of Achilles and the tortoise. No matter how much progress you make against the roadmap, the ultimate vision will be a bit out of reach.
This means we are perpetually working on a marathon (the backlog, market expectations, imposter syndrome, team members leaving, a new competitor enters the chat) while preparing for a marathon in the midst of sprints.
What’s a Product Manager to do?
So here’s the basic problem. No matter what your priorities are, the work and the jobs to be done are implemented in features and sprints, while the work to align the roadmap with the strategy and vision happens more slowly. If you understand your product and the alignment of that product with your roadmap, you will be able to take a call on where you are in the cone of uncertainty for any individual feature or request.
Ideally, when the customer, co-worker, or boss asks you about that feature and where it is in the roadmap, you are able to answer using this context:
Does the ideal customer expect this feature?
When thinking about a new feature, can you envision the way a customer would use it, and how would you answer these questions?
-
Is this the kind of feature our ideal customer expects from us, and what would they do if it didn’t exist?
-
What job does this customer expect the feature to do, and how would they know if we did it?
-
Is this kind of thing “table stakes”, that is, would our customer be surprised if we didn’t have it?
Does this feature fit our mission, and is it “our kind of feature”?
Is this a feature that feels congruent with our product? For example, if we never had video recording before, and a customer comes up with an idea to introduce video recording because they believe it solves need, is this a feature other customers would care about?
-
Deciding if it’s “our kind of feature” means knowing pretty well what place we play in the marketplace and how we deliver unique value
-
Simply copying the feature of another company might not fit our mission
-
Does fixing or improving this feature make it more likely that a customer would be wildly happy with our product, even if only a few customers are that happy?
Is the money we will spend on development time strategic?
All development costs money. Doing this feature takes money and resource and time away from other things we might consider doing. Why is this feature more strategic than others?
-
Does this new idea fit in with existing features to create a more complementary whole?
-
Does building this new idea open a new category of ideas that will now be possible and potentially extend our total addressable market?
-
Does this help take us where we want to go?
How hard is this, really?
If you are thinking about something brand new that you’ve never done before (and that no one else has done before) and most people agree that thing is really hard, you might want to pause before attempting. Keep poking at the edges of this thing until you can find the smallest big version of it that you can do.
Limiting technological and product risk is important, especially when:
-
there is only one person on your team who can figure this out
-
it’s breaking new ground
On the other hand, if that person can build a bridge to the new idea for multiple people on your team, one feature could not only unlock product capability but people capability and customer happiness.
Roadmaps are an educated guess
Ultimately, roadmaps are our best guess at the moment. While the individual assessment of features gets better over time, it’s possible that your roadmap might look quite different over time depending upon the choices you make to adjust it. Roadmaps are the implementation of individual ideas that follow a theme, reinforce capabilities, and help the product align with the strategy, mission, and jobs to be done.
They’re not perfect, and they do give you a pretty solid framework to respond to your co-worker when they ask you if that preferred feature is in the roadmap. If it’s not there yet, just tell them. And then if it sounds like a good idea, ask, “why should it be there? I’d love to hear more.”
What’s the takeaway? A product roadmap is a living document. As items get closer to development, the details get stronger and the alignment gets better if the team is doing a good and continual job matching the roadmap to the short-term and long-term strategy of the company. Roadmaps don’t answer everyone’s question but give strong clues to the company’s DNA and how they solve problems.
