When you think of the role and responsibilities of a product manager, two things probably come to mind – prioritization and roadmaps. But should prioritization and roadmaps be the responsibility of product managers alone? I don’t think so.
Roadmaps are a prioritized to-do list that, when done well, create alignment around what is most important to build. If finding the most impactful items to work on, and getting the team to agree on those things is what’s most important, it follows that the responsibility for building a roadmap lies not on the Product Manager alone, but on the wider product team too.
(Note: for the purposes of this article, I’m assuming the Product Manager is aligned with leadership and company objectives – how to do that is an article for another day 😉)
Why your product roadmap should be bottom up, not top down
It goes without saying that to build a roadmap, product managers need to collect a lot of information. For example, here are some of the inputs that Product Managers at Intercom regularly gather:
Feature requests from customers.
Feature gaps that are blocking sales deals.
Common user workflows that have been discovered through customer research.
Overall product strategy of the organization.
Feasibility of solutions.
Product debt analysis.
Competitive analysis.
Now, you might expect that at this stage, the Product Manager should take all of these inputs and build a roadmap with clear priorities. This roadmap could then be delegated to the product team to execute. However, this top-down approach to product management won’t yield the best results for your team.
It’s far too easy for strategy and execution to become misaligned.
The first clear drawback with this top-down approach is that the product team will feel little ownership over what they will build. When a team is handed down a list of items to build with little to no rationale, a smart team will soon question whether or not these are actually the right items to work on. Engineers and designers in the team will likely have their own strong opinions about what is important. If they don’t feel a sense of autonomy over the roadmap they will be building, it’s far too easy for strategy and execution to become misaligned.
If you have ever worked in product management, you probably know how expensive these misalignments can be. They are often the main cause of wasteful discussions, friction in product team dynamics and general demotivation in the team.
Making prioritization a team sport
In my experience at Intercom, I have found that letting the team build the roadmap themselves delivers a better outcome all round.
Now, if you’re a Product Manager reading this, you might be hearing alarm bells at this point. You might be thinking things like:
“But the team don’t read hundreds of feature requests like I do.”
“But the team doesn’t have the same relationships with product leadership that I do”.
“But the team don’t have the same 360-degree view of the product I have.”
But to that I say: building a roadmap isn’t rocket science. So long as everyone has access to the right information, everyone can be involved in creating it and in doing so help further the business goals.
The trick is to make sure your team is armed with the right information.
As we discussed earlier, one of the primary responsibilities of a Product Manager is to gather insights that will act as inputs to the roadmap. At Intercom, this looks like some version of the following:
Talking to customers.
Talking to engineers, sales, marketing and customer support.
Reading through strategy docs.
Exploring and analyzing product metrics.
Rather than the Product Manager carrying out these tasks in isolation, try to involve the product team as much as possible. For example, invite the team to customer interviews or share any learnings, feedback and useful information with the team.
Here are a few real scenarios where you can do just that:
Do you need to analyze the performance of a recently shipped feature? Involve the team in the analysis. For example, ask an engineer to help with the analytics or invite them to customer interviews.
Did marketing share with you a competitive analysis? Have a session to go through it with the product team.
Did you find some interesting activation metrics? Share the data and high level findings in an email or report.
Did you happen to attend an interesting meeting with sales? Share the outcomes of the meeting during stand up.
Make it a habit to involve the product team in the input gathering as much as possible. When that is not possible, share any insights with the team whether that is during casual chats, stand up or product workshops.
Crafting a prioritized roadmap
Now that you’ve involved the product team in gathering the inputs, by the time roadmap season comes along, alignment should be strong. The team has sat in customer interviews, you have had multiple product workshops and they are up to date with what is going on in other product teams.
It is time to set up a roadmap meeting with the team. In this meeting, I kick things off by running through an overview of all the inputs we have discussed over the quarter. There shouldn’t be any new information coming to the fore in this session – all of these inputs should have been discussed in depth in previous sessions.
Then I get up to the white board and ask the team a question:
“Given the capacity we have for the next quarter, what should we be building?”
The team will start throwing up ideas on the whiteboard. Usually, the first item is easy, but the further out we get, the harder the conversation becomes. At this point, let the engineers and designers on the team speak and refrain from giving opinions. After some back and forth, the team should settle with a list of items we can work on the next quarter, the roadmap.
It is only at this point that I show the team my own prioritized list, one I wrote down before the meeting. As if by magic, my own prioritized list is usually almost identical to what the members of the team have whiteboarded themselves. In fact, in the last three quarters, the team and I have come up with the same list of priorities for our roadmap. Having such alignment over our priorities has made everyone on the team feel like a cohesive group and has proven very motivating for everyone.
The sense of ownership and purpose has increased the team’s motivation
Of course, you may find that the roadmap your team comes up with and the roadmap you had in mind are not the same. Rather than a negative, this can be a positive, and is a great opportunity to surface misalignments and understand the root cause of them. Perhaps there is something the product team knows you ignore or vice versa. Maybe they don’t have access to the same information you do. Maybe the engineers or the designers on the team are weighing inputs differently to you. These conversations are critical to the performance of the product and the team. They present an opportunity to challenge each other and learn. Most importantly, you now have a space to surface misalignments and work to correct them.
Why the bottom up approach to product management works
This type of ongoing communication throughout the prioritization process has a definite cost, but the number of benefits from this approach is worth it. We have reduced friction between teammates, which has saved us from long-winded conversations that stemmed from misunderstandings. The sense of ownership and purpose has increased the team’s motivation. On a more personal level, having these open product discussions has challenged my own thinking many times over, which has definitely improved our product direction as a result.
Of course, there is an argument to be made for a top-down approach to product management. As a company grows, a hierarchical approach is often the most straightforward way of working. However, if your company is filled with passionate and intelligent staff, a strict hierarchy where they have no say in the direction of the product they are building simply won’t work. The new status quo calls for innovative ways of doing things so we can keep teams aligned and empowered about the work they are driving forward.
Additional reading:
Comments