Who Owns the Product Roadmap? How to use Insight and Influence to Guide Product Direction

In my early days as a Product Manager, I wondered why the experiences of my peers varied so much from one company to another. I’ve come to realise that different organizations operate with very different levels of flexibility and ownership around multiple aspects of a product manager’s traditional role. In this article, we’ll take a dive into the different scenarios product managers may find themselves in, with a special focus on product roadmaps as a perfect exemplar of the wider organisational ecosystem.

In this post, you will learn:

• How to identify a scenario early enough
• How to make the best out of each scenario
• How to influence the transition from one scenario to another

Let’s begin with the basics – a statement of intent. Product roadmaps are a high-level visual strategic summary of the vision and direction of a product offering over time. I like to think of a roadmap as the highway to the desired vision or end-goal of your product. It’s a plan that helps answer the question: What am I building today? What comes next? What am I building next, be it in 6, 12, 24 months, and why?

The Advent of the Product Manager

Before the Product Management role came to be, the function of managing “mostly” hardware products was performed in a way that was unique to each organization. In the case of startups this is still largely the case! In many cases, the CEO (or a founder) takes a fairly direct role in setting the future of the business. This creates a natural friction over the longer term, as CEOs often find it difficult to step back from having direct control, and ceding power to those hired to drive innovation and manage the organization’s portfolio. This scenario, where a C-level leader continues to be involved in product development at a micro-level, is tragically more common than you might think, and incredibly ineffective. Not only is this constraining the product manager from being able to support the organisation effectively, the CEO also limits themselves from focusing on other strategic imperatives to drive the organization’s growth.

For a young product manager, it can appear to be both a straightforward and complicated role. One that has you fired-up one moment, and wishing you had not taken it up the next. Martin Eriksson’s illustration of the product manager (below) places the individual as the bridge between traditionally established roles such as UX Design, Sales & Marketing and Engineering; that’s bound to create some friction.

As a Product Manager, you are likely to encounter one of the below scenarios:

#1 – The Top-down Product Roadmap

The CEO or founder knows what’s best for the user (or certainly believes that they do) and sets the agenda for the next couple of months. It is set in stone, with everyone expected to align and execute. In this scenario, the product roadmap is owned by the senior executive, and the product manager is saddled with execution.

I’ve particularly seen this happen in start-ups with founders coming from a software engineering or technical background. They set a compelling vision and spell out the “how” of execution in as much detail as their knowledge or experience permits.

A reason for this scenario is that, in a typical startup, the founders are usually the first product managers. They take up the role of conceiving the product concept, working closely with engineering to push it out to markets, and only when some traction is gained does it become clear that a product manager is needed.

#2 — The WOLF or Visionary Product Manager’s Product Roadmap

In startups actively pursuing growth, the founders generally choose to focus on activities like fundraising and investor relations – sometimes to the detriment of other aspects of the business. In this scenario, the function of setting the product vision and roadmap is left to the product manager, who is often expected to “step into the shoes” of the founders, and “figure it out”.

This tends to breed two types of results:

• A WOLF Roadmap: A Product Manager who ends up being operational in nature and creates a roadmap mostly consisting of WOLF (“Works on Latest Fire”) items. This product manager makes few contributions to the strategic direction of the product, and maintains focus on hot fixes and operational activities. Product improvements are executed based on customer requests and “what doesn’t work” with the current product build.
• A Visionary Product Manager’s Roadmap: This is the result of a “visionary” product manager who chooses to take charge of the scenario, and ends up being the sole driver of the product roadmap in the gap left by the founders. This might result in features being implemented based on gut feel (“vision”), without consulting customers or external stakeholders, as there are no established rules or processes for such engagements.

#3 – The Team-driven or 360-degree Product Roadmap

I like to call team-driven roadmaps the “360-degree product roadmap”, as a good product roadmap should involve coordination across multiple business functions. Here the product manager collaborates with both internal and external stakeholders to identify the problems, reviews user feedback and usage data to corroborate issues, and ideates possible solutions with the team. They not only consider customer needs, but also the overall strategy of the business in painting a picture for the next 6 – 12 months, maybe more. The product manager drafts a roadmap and takes feedback from different stakeholders before “locking it in”. They consistently review the roadmap every couple of weeks to ensure the team remains aligned, and stay true to the vision.

How to make the best out of each scenario?

How do you deal with a scenario where your entire workload is handed down by a founder or a senior executive, or you find yourself working mostly on hot fixes, or doing most of the ideation around what comes next for your product portfolio? How do you institutionalize the 360-degree roadmap to deliver consistent results?

Here are a few suggestions to make the best of things if you find yourself in either scenario:

#1.  The Top-Down Scenario

1. Context is King: Gain as much context as you can. Identify what’s driving the existing scenario, and if it’s worked so far.
2. Gain the Leader’s Trust: Standing up to a founder or a CEO should be a careful, tactful and data-driven process. You’ll have an easier ride once you’ve established a reputation as someone with the right understanding of things, with key data to back it up.
3. Work behind the scenes: Influencing your leaders to a different outcome behind the scenes always works better than standing up to them at a meeting, where their seniority and egos will often actively work against you.

#2.  The WOLF and Visionary Product Manager Scenario

1. Explore a structured consultative approach: Set up quarterly (or, at the very least) bi-annual roadmap review sessions to carry the different stakeholders along. If you’re in a really fast-paced environment, you may want to make it more frequent (maybe even monthly). Present the problems faced by your customers / end-users, and aim to ensure everyone at least understands and agrees with the problems to be solved.
2. Refrain from solving every problem yourself: The best solutions to product problems often come from unexpected places. You should be intentional about not solving the problem until you’ve heard the opinions of others. Don’t take this to mean you should never have a solution in mind, because you definitely should. But make sure you evaluate and sense-check whatever options you’re coming up with.
3. Leverage Design Thinking, Not Your thinking: Discussing problems as a team gives everyone the opportunity to share and construct ideas collaboratively. This cross-exchange can be incredibly powerful, and it helps a lot to bring everyone to the same page with the challenges being faced and the overall direction for next steps.

#3. The Team-driven Scenario

1. Collaboration is king: A key to maintaining the team’s buy-in to a roadmap is to continuously work through a collaborative process. Working with other stakeholders to get to the result almost always leaves you with an outcome that has buy-in across the room. Essentially, you’re less likely to get push-back from me if you’ve captured my opinion!

1. Create a steady road-mapping process that works: A rule of thumb in product management is that ad-hoc initiatives tend to not be repeatable, or done in a coherent fashion to create optimal results. You want a clear road mapping process, with activities lined up and aligned with the various stakeholders involved. Set periodic roadmap review sessions, and send out calendar invites to hold yourself accountable.

1. Take the “Kaizen” approach: It’s quite commonplace to get “stuck” in the details of your work, such that evaluating how the work gets done gets forgotten or sidelined. You must be intentional about reviewing your road mapping process – ideally on at least a quarterly basis – to determine what’s worked well with the process, and what can be improved upon. Did you miss out on any stakeholders? Has your roadmap led to features that delighted customers? The results of this should go into an improvement plan to make things better the next go-round.

Is There an Ideal Scenario?

In today’s startup world, it is quite common to find the role of a product visionary in existence long before the product manager role. If you get a job at a young startup, you’re more likely to encounter scenario #1, and the job is likely going to involve being a “Vision Courier” – someone who is expected to understand, translate and amplify understanding of the vision to the execution team.

In a more established organization, you’re probably going to be amongst a team of product managers. Depending on team structure, you’ll either be supporting product management activities with someone higher up, or be responsible for a small internal product to cut your teeth with.

Scenario 3 happens to be the most ideal scenario for product road-mapping, as it naturally leads to alignment of your team and stakeholders, and synthesises the widest set of customer and product insights. That said, it isn’t necessarily a scenario that comes naturally to an organisation. Product managers must typically negotiate this outcome by taking ownership of the process, and collaborating across multiple channels and levels within the organization.

How to Move Your Organization to a Team-Driven Scenario?

With either scenario, there’s a sensible series of suggestions you could apply to move your organization in the right direction (scenario #3). Dealing with a difficult leader is sometimes just as tough as getting yourself to stop solving problems on your own. Try these suggestions to get the ball rolling into collaborative, team-driven product roadmapping:

1. Take a data-driven approach to decision-making: One of the strongest ways I’ve seen to sense-check senior leaders is to present data as a means to validate or challenge whatever the team is being asked to work on. You could collect this data from multiple KPIs and metrics your team is already tracking (e.g. activations, churn, upsells, revenue etc.), or from back-end analytics, customer feedback, and surveys. The more grounded the data you have to present, the better your chances of convincing your senior leaders to see your view point.
2. Build trust in your ability to drive the conversation: A product manager who understands the market, represents the voice of the customer and uses data to their advantage stands a better chance at winning the trust of any leaders in the room to do the right thing. CEOs and founders are just individuals trying to look after the interest of the organization from their own perspective. The great thing about building trust is you can then achieve their goal without necessarily having them bark orders and setting ironclad direction.
3. Get a portfolio of small wins under your belt: Do you have decisions you’ve taken that led to some success or a solution to a problem? That’s a small win that helps validate your product leadership. Again, you must strike the right balance here so you don’t move from a scenario #1 to a scenario #2, but balance it out by ensuring team collaboration reigns supreme, with you being in a facilitator role.