When I work on a product, I think about it all day long.
I obsess over it.
I love exploring the long view. What will this product look like next year? Five years from now? Ten years from now?
I love the challenge of identifying the very next step on that path. What should the engineers build this week?
I love how the path wanders and evolves and the vision gets stronger over time.
I bet you do too. It’s what makes building products so much fun.
It’s impossible to know which way the path will wind and that’s exciting.
Not Everyone Is On That Path With You
For many of us, even if the path ahead is shrouded in clouds, we know which direction we are headed and what the next few steps are. We know how to keep moving.
But for many of the people that we work with, that’s not the case. To them, it’s not even clear there is a path, let alone a direction or a next step. It can feel like you are stumbling in the dark.
I’m talking about your sales team, your customer service team, your account management team. And sometimes your management and marketing teams.
They don’t think about the product all day, everyday. Nor should they. They need to think about their own jobs and their own responsibilities.
When it comes to product, it’s our job to make it clear which direction we are going and how we plan to get there.
As product leaders, we need to manage the uncertainty and the unknowns for our team. – Tweet This
They need to know what’s coming, when, and why. They need to be able to make their own plans, set expectations with customers, and adjust and respond as we make product changes.
But how do we do this when nothing about building products is certain?
I can’t tell you when we will release something. Estimates aren’t reliable. Problems grow in scope.
I can’t tell you what will work and what won’t before we test it.
I can’t predict when someone will have a genius idea that dramatically simplifies the problem at a hand.
How can anybody working in a startup expect certainty and clear answers? – Tweet This
You Do Need To Provide a Map
But if I’ve learned anything about managing product expectations in startups, it’s this. It’s our job to deal with the uncertainty. It’s our job to find the right path.
And it’s also our job to help our teammates feel like we are on a path that will lead to success. They have their own uncertainty to manage. They don’t need ours as well.
We need to provide them with a map. A map that clearly communicates this is where we are going and this is how we will get there.
Some of you might be thinking, of course, this is why we create product roadmaps. But I’ve been on record saying that I hate roadmaps. Am I now contradicting that?
Drop Feature-Based Product Roadmaps
A product roadmap typically refers to a document created annually that outlines what will get built when. It’s more or less a list of features with release dates.
This type of roadmap does more harm than good.
Yes, it does create a sense of certainty. It does tell the rest of the team what you are releasing and when, allowing them to plan their activities and set expectations with customers.
But it does this based on a foundation of lies. (See what Buddy the Elf has to say about this.)
How often do you actually release features on the dates indicated on your roadmap? If you are like most teams, not very often.
Rather than creating certainty for the rest of your team, you are creating chaos. You are setting expectations and then trampling all over them.
Roadmaps are exercises in futility. Teams put time and energy into a document that is immediately out of date and often ignored.
The creation process is often a political game that allows stakeholders to argue over their own interests, rather than putting customers or users first.
At best, it’s a waste of time. At worst, it sets the wrong expectations and puts the product team in a position of having to always defend their deviations from the plan.
Stop putting features on your roadmap. Building products isn’t about features anyway. – Tweet This
We need to let go of the idea that we can enumerate a list of features that represents what we’ll do in the future. This idea is absurd.
Communicate Your Vision and Your Process
Rather than sharing feature lists with the rest of the company, we should be communicating how we will make decisions.
Everyone in the company needs to understand what it takes to drive success for your user or customer, as defined by your success funnel.
Everyone in the company needs to understand how you are driving growth, as defined by your growth funnel.
Everyone needs to understand the trade-offs of improving one step of the funnel versus another and where your current point of leverage is. They need to know how much progress you have made towards your goal and what else you are doing to get there. These are the conversations we should be having with our teams.
Some of you might be thinking, what do we tell our customers? Don’t they need to know what features are coming when?
It depends. Most teams err on the side of telling their customers way too much about what is coming and when.
Stop talking to your customers about features and start talking to them about benefits instead. – Tweet This
You’ll have much better conversations. You’ll learn more. And you’ll do a better job of setting expectations that you can actually deliver on.
You do need to tell your team and your customers what is coming next. As in your next release. But you don’t need to tell them what’s coming next quarter or the quarter after that. Most of the time they won’t care. And the times when they do, if you set wrong expectations, you’ll do far more harm than good.
Remember, you think about your product all day every day. Both your team and your customers only think about your product to the extent that it helps them get done what they need to get done. Their view of the future when it comes to your product is much shorter than yours. That’s a good thing. Use it to your advantage and stop setting expectations that you can’t keep.
Up next, we’ll explore how to communicate what’s happening in the near future: upcoming release announcements, educating your internal team and your customers about what is changing. Don’t miss it. Subscribe to the Product Talk mailing list.
Anthony Green (@anthonycgreen) says
“product roadmaps should be lists of questions, not lists of features”
– Kent Beck
Gojko Adzic makes the observation that most product roadmaps aren’t like road maps at all, but tunnels:
https://skillsmatter.com/skillscasts/4498-keynote-gojko-adzic
Nilanjan says
It would be interesting to know what product /environment you work on (for context).
I think features often are important from the point of view of the market/competition.
Teresa Torres says
I’ve worked in a variety of industries, both consumer and enterprise, including search, e-commerce, recruiting, community platforms, online publishing, and have consulted with clients in many more areas.
Of course, features are important. And your position in the market relative to competition is very important. These things aren’t mutually exclusive with not including features on your roadmap.
Olaf Kowalik (@OlafKowalik) says
Great advice on including the success funnel and growth funnel when building a roadmap. Do you have any examples of what this type of roadmap looks like visually? Thanks!
Teresa Torres says
Hi Olaf,
Great question! Unfortunately, most documents I have created are proprietary to the company and can’t be shared. However, I can describe the process.
I typically identify 2-3 milestones for the upcoming year. They represent what I think are our biggest points of leverage. For a company that has little site traffic, a milestone might be, grow user acquisition efforts of a specific audience by x%. For a company that gets plenty of traffic but has little return visits, a milestone might be increase retention for a specific audience by y%.
The roadmap then becomes a list of milestones. Depending on how hard these milestones are to reach, your roadmap might reflect improving one step of your funnel:
– Improve retention in population A by x%
– Improve retention in population B by x%
– Improve retention in population C by x%
Or it might be a series of milestones that improve successive steps of the funnel:
– Grow monthly active users by x%
– Grow retention by y%
– Improve referrals by z%
This allows you to still paint a clear picture of what your top priorities are and allows you to update progress against the current milestone. But notice that there are no dates. Instead, you want to communicate, we will keep working until we hit this milestone and then we will move on to the next one.
I usually also add, these are some of the things that we will try along the way – but only for the first milestone. Anything further into the future than that is unknowable at this point. So the roadmap might look like this:
– Improve retention in population A by x%
— Improve open rates of weekly digests
— Improve click rates of weekly digests
— Experiment with daily digests
– Improve retention in population B by x%
– Improve retention in population C by x%
This helps to build confidence that we have a path forward but it doesn’t over communicate things we can’t deliver on. In other words, it doesn’t say, we are releasing daily digests in two weeks. Daily digests may not work, in which case we won’t release them.
olaf2013 says
Thanks, Teresa!
Mona Rakibe says
Great Article and fantastic example in the comments.. thanks for sharing
Teresa Torres says
Mona, I’m glad you found it helpful.
David Fradin says
There are about a dozen traditional roadmaps but they are all feature based. You concept is a good one and others like value based, outcome based, problem solved based might be useful exercises to see which ones work best for different types of product and services.
PJ says
How do you convince the board to agree to a value based approach when you have restricted budget and no live customers? They want to know when product will be finished and how much it will cost.