A roadmap is a marathon
"Everything Starts Out Looking Like a Toy" #95
Hi, I’m Greg 👋! I publish this newsletter on finding data products and interesting data observations with the goal of finding patterns and future product insights. (Also, it’s fun.) If you need a background on how we got here, check out What is Data Operations?
This week’s toy: HTTP responses that are cats. Why shouldn’t sysadmins have more fun? Edition 95 of this newsletter is here - it’s May 30, 2022.
The Big Idea
A short long-form essay about data things
⚙️ A Roadmap is a marathon
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.
Links for Reading and Sharing
These are links that caught my 👀
1/ Recasting features with personal appeal - This essay on growth design details how LinkedIn was able to increase the opt-in for notification. What’s interesting about the story and the improvement is that they are both based on the idea of contextualizing the ask we are making of users so that the choice to opt-in feels personal. It answers the question: “What’s in it for me?”
2/ Is an “analyst” job harder than a technical job? Benn Stancil makes the case that analyst work might be just as hard as technical work. We have a bias for thinking that anything technical is more difficult than work that requires so-called “soft skills” at its core. But Benn points out that the ambiguity required to find structure and meaning outside of a technical challenge presents a unique and unappreciated challenge.
3/ Managing up, down, and across - these prompts from First Round of questions managers should ask themselves regularly apply to more than just managers. Anyone at any level in an organization will find these questions useful, especially when trying to understand why someone in a different role made decisions that they did. Do I know what is important to my boss right now? is always a good question to ask, whether you are thinking about your immediate supervisor, your big boss, or your board of directors.
What to do next
Hit reply if you’ve got links to share, data stories, or want to say hello.
I’m grateful you read this far. Thank you. If you found this useful, consider sharing with a friend.
Want more essays? Read on Data Operations or other writings at gregmeyer.com.
The next big thing always starts out being dismissed as a “toy.” - Chris Dixon