This article has been adapted from Jana’s stellar talk at the exclusive Product Marketing Misunderstood event. PMA members can enjoy the complete recording here. 

Hello, and thank you for joining me as I share how you can influence the product roadmap. My name is Jana Frejova, and I'm a Product Marketing and Growth Lead at Spendesk. 

Here’s what we’ll cover in this article:

  • Why PMMs should care about the product roadmap 
  • The levels of input you can provide
  • A case study from my time at Opower
  • A case study from my current role at Spendesk 
  • Lessons learned from my experiences of shaping the product roadmap

Let’s go!

Why should PMMs care about the product roadmap?

Before we dive in, let’s take a step back and reexamine how we talk about product marketing’s role with regard to the product roadmap. Many people, myself included, talk about “influencing” the roadmap. However, I don't think that’s quite right. 

The word “influence” has negative connotations. It sounds like something you do behind closed doors, implying that product marketing shouldn't have a real seat at the table when roadmap decisions are being made. 

I’d argue that product marketing should have an equal seat at the table and, along with other stakeholders, help decide what the roadmap should look like. So, instead of talking about “influence,” let’s talk about “input.” 

But why should we even want to provide input on the roadmap? There are three key reasons:

First, on a basic level, we don't want any surprises. We don't want the product manager to come to us the day before launch asking us to promote something we’ve never heard of before. 

Second, and more importantly, we want to ensure the roadmap focuses on real market needs – the things buyers care about and are willing to pay for. Now, some product managers focus on what the market wants, but some are more driven by technical interests or their own excitement about a product, without considering the end user – in these cases, product marketing’s input is absolutely vital.

Third, and more selfishly, sometimes we have to get involved so we can secure resources for our own projects. Maybe we’re trying to implement single sign-on or launch a new customer communications platform and we need engineering resources to help set this up. We’re much more likely to get those resources if we’re collaborating from the very beginning of the project.

The levels of input you can provide

Whatever our reasons for getting involved in the product roadmap, we also need to realize there are different levels of input we can provide:

  • At the most basic level, we're just informed about the roadmap.
  • At a medium level, we work with the product team to prioritize what's already on the roadmap and provide feedback on the bets they’re making.
  • At the highest level, we work hand-in-hand with product management to decide what will be on the roadmap.

Pyramid showing the three levels of input. Top level: We decide together what to build. Mid level: We help prioritize and provide feedback. Bottom level: We are informed.

Notice the top section of this input pyramid is smaller – that’s because the highest level of collaboration happens less often than it should. It's the most important form of input you can provide, but it’s also the most resource-draining. If your product marketing team is very lean, you may need to prioritize other areas and just provide feedback on agreed plans.

Case study: Opower

Now I want to share a couple of case studies. Each is an example of a time when, thanks to certain tactics, product marketing and product teams worked together to properly prioritize the product roadmap.

Across the different companies I’ve worked for, product marketing has played very different roles in the roadmap. In some places our input was negligible, but in other places – notably Opower – we had a loud voice and truly collaborated with product managers on the product roadmap every time. 

For context, Opower offers energy efficiency solutions and customer engagement solutions for utilities. We realized there were growing numbers of households with solar panels, but we didn't provide utilities with anything to serve those customers, and not much existed in the market. So, we built a suite of engagement solutions for solar households. The utility was the buyer, and the household was the user. 

We provided communications when the household started using solar, explaining the energy calculations and things to be mindful of. Then, once they began using solar energy, we gave tips to avoid expensive summer and winter usage and maximize their solar panels. We also provided insights comparing their solar production to energy use and telling them how much money they were saving.

Title: Favourite memories: Opower. Images of solar onboarding and engagement communications.

But how did we get there? For all this to happen product marketing and product had to work hand-in-hand.

First, product management noticed the potential need for a solar solution and asked product marketing to analyze it. So, I worked on a market requirements document (MRD) assessing the overall market size, buyer needs, and existing solutions. The aim was to decide if we should investigate further. 

Next, I presented my findings to the team. It turned out there was a market opportunity with few competitors, so we agreed this was worth pursuing.

After that, the product team made a product requirements document (PRD), translating the market needs into potential technical solutions and resource requirements.

We then held workshops with existing customers who we thought might be interested in the solution we were developing. The goal of the workshops was to get feedback on our minimum viable product and confirm that this was something they’d pay for. We even got insights into their budgets and willingness to pay.

With that final confirmation, the product team built out the solution while I developed the go-to-market plan. Then we launched together.

Title: Favourite memories: Opower. Diagram showing the collaboration process, as follows: Need noticed, MRD, PRD, then workshop, before the PM team works on building the solution while the PMM team tackles go-to-market.

How to write a market requirements document

The MRD was a key part of the way we collaborated with product management and influenced the product roadmap at Opower. At least twice a year, we'd sit down with the product team to identify areas that might need more research – either for an existing product or a gap in the market we might fill. Each team member would then research and write their own MRD.