AMA: Google Product Marketing Lead, Vishal Naik on Influencing the Product Roadmap

I think this one is a bit tricky, because I wouldnt recommend creating a user list without appropriate PII governance. Rather than creating a user list, I'd suggest building an outreach stratgey that can deliver content to customers in a scaled manner. Some suggestions are in-app notifications that can serve easy consumption content at the right moment, or building a webinar series where your customers can sign up via your O&O channels. This way you can still enable users to get the information that will help them do their jobs better, but without introducting excess risk. In my opinion, this is an area where you'd want to leverage the product. In a consumer marketing setting, or in a B2B setting where your route-to-market is PLG, you'd lean on the product to deliver the education; rather than marketing to a user list. On my current team, we have PMMs and PMs who are focused on driving discovery of features. So perhaps an analog would be to map out the user journey, look for areas where product usage isnt where it should be (thus implying that there is user need for educational content to solve the underlying business problem) and then look for leading indicators across that user journey that might signal the moments where a potential breakage would occur. Serve educational content up in product, in those moments. Google Docs/Sheets/Slides are pretty good examples of serving up in-product education without it feeling too obtrusive. As for the PM benefit of direct access to end-users, I'd suggest you work with your Account Managers and create an opt-in program to recruit trusted testers and power users. By making it opt-in, you're protecting yourself from any PII risks, but you're also trimming down your list of customers who would join. However, a PM wouldnt need access to every customer, just a representative sample that can help the team understand patterns in usage--of which an opt-in community could absolutely solve. One of the teams I work with at my current role has an opt-in community of around 700 users, which they run pulse surveys with on a regular basis. It allows us to ask our audience specific questions and run quick feedback cycles. 

I tend to think that teams like to hear their work is appreciated and their processes are modeled. So if another team is required for estimating roadmap costs, I'd ask them questions about how they do this level of modeling? What's their process and what are their inputs? Then I'd take a stab at doing something similar and then set up time with them to review. At my current company, things tend to be measured based on resource allocation (X full time-employees required to work on the project for Y time frame) to measure technical costs. The item that I would add to this though, is that I often come across roadmap conversations where technical costs have been estimated--but rarely come across roadmap conversations where market costs have been estimated. What is the potential impact to your audience if you add a feature (or deprecate one) and is that being measured in the same manner as technical costs? Does launching a feature give you first to market advantages? Does being quick to ideate and release features build better trust amongst your user community? And how do you measure those market advantages against customer awareness and preference? If you think of it as an ROI conversation, you can probably estimate how much it will cost to staff the work required to build a product and can probably forecast usage, but if market perception were also on that list, it could help you have a full picture of the costs associated to your roadmap decisions. 

I'd say this is a volume game where you have to look for patterns while also thinking about your growth model and ideal customer profile. Given these data points you might find that out of the list of feature requests, a handful are commonly requested and and even smaller subset are commonly requested by your most valuable customers. Focusing on these will not only help your current customers but help you win future deals as well. Another valuable thing to consider here is buidling a developer offering for your customer base. At the end of the day, your PM/Eng team only has so much time to create new features; so if you augmented your teams ability to build the most valuable features by enabling your customers to build the long-tail use cases that may be specific to their own orgs via API--then you can end up with the best of both worlds: You take customer feedback, you build high impact features that will support many customers, but for the features that you cant get to on your own, your customers still have a path to solving. Of course another dimension if you should build a feature or not would be cost. You'd obviously want to anchor on high impact low cost features to build, while being selective on high impact, high cost and enabling customers themselves to build low impact, low cost and low impact, high cost features themselves. 

The way I think about this is that PM owns the roadmap. What I mean by that is that, none of my PMs--past or present--have sat down and brainstormed about roadmap with PMM. So in the moments where I've felt that we have an area that is unadressed within our roadmap or that by not adding an item to our roadmap at a certain time puts us at risk of a market moment, the onus has been on PMM to drive the steps necessary to win over PM as a stakeholder around what the future product strategy should be. To do this, I'd suggest you look at timing. When is the right time to field research so that you can collect insights in time for it to actually shape a product teams plans? Is there a market moment -- such as a big company event -- that is at a fixed time in the annual calendar where you can showcase market insights that would inform PM to adjust roadmap in order to make a bigger splash/inform PM that without that change in roadmap their feature wont be showcased? I think you also need to look at your PM/PMM relationship as a whole. My current team has built a reputation with our product stakeholders about being upstream in the product strategy conversation and that we will bring insights about the market and the user to our product teams to help them. Other teams at my current company tend to be more downstream and PM/Eng make the decisions on where the product needs to go, and PMM builds campaigns around those features. If I were on a different team, the expectation to influence roadmap wouldnt be the same, nor would the willingness from PM to think about what PMM is suggesting be as strong. As for my specific team, we tend to do a lot of research. We partner with our PMs and User Researchers to map out what lists of questions we need solved to help build a great product, and split research among PMM and UXR depending on the type of work. PMM also does a lot of desk research to help inform PMs of market trends. When I was on B2B teams, we'd bring in analysts like Gartner or Forrester to bring 3p research to the table. I tend to be somewhat inquisitive around product data so I like to also look at any internal usage trends that may paint a picture. Across that combination of 1P/2P/3P research, I try to think about what decisions I would make if I were a PM on the product and what bits of information I might find valuable. I then compile into a lit review/summary and bring back to product to ask questions and brainstorm. From here, I tend to then let Product build the roadmap and if something feels left out I'll bring it up and have conversations about it in our syncs, but ultimately my goal is to ensure that our team (PM, PMM, Eng, UXR, etc.) are all on the same page around what inputs are needed to make product decisions. This POV of focusing on being an influencer, while bringing insights back to the team, tends to keep us with a seat at the table as products go from zero to 1. 

You'll definitely want to chat with a research agency or your internal researchers to build a game plan, but I think it starts with a list of questions you want answered. Nothing too formal, just conversationally, what insights do you need to know that will help build product strategies? For me, that starts from talking with PMs and Sales people and understanding current context and then looking for where they may be a gap. One of our products is localized only for US-EN, but we have a large volume of global users. So research that would show user affinity for that product within other languages might help our PMs to view localization efforts as a way to increase macro feature usage. But that hypothesis can only be created once you have a good lay of the land for your product and your opportunities and --importantly-- if those opportunities map with your product direction. For example, if you identify a key lever that can increase user adoption, but your product team needs to make the product more stable becuase you dont have the uptime that you desire, then you may not be at the stage where you want user growth just yet, because you'll set up users for a bad experience. As for tangible outputs from your research, I think a good way to think about it is what are features that are exciting to users and how believable is it to users that you could deliver those features. Those that are user delighters that are also things you could deliver, bring those back to your PM team with your own POV on why they matter and have a conversation about their potential impact. (For clarity, when you talk about feature believability, think of it this way. Say we're making TVs. Your data shows that users want the brightest panel because they want to watch tv in rooms with a lot of sunlight. That may cost a lot to build because top of the line panels will increase your cost of goods sold. High cost equals high price. So when you get into a premium TV market, youre competing against Samsung or LG. Does your brand have the reputation to win over those customers? Or do customers buy your TVs for other reasons? So its about mapping the wants from users to users faith in your brand. Unless youre trying to break into a new market, then you'll want to overlay brand building campaigns on top of new feature creation, and cant just rely on informing Product to win in this category) 

I dont actually think my approach changes. I tend to believe that the process will yield results and my process to influencing roadmap focuses on acting (in my head) like I'm the owner of my product: * what users use my product? * what are they thinking/feeling as they go through the journey to understand and ultimately use my product? * is there a known gap in terms of what would make them use more of the product? * is there a common denominator that is driving either upside or downside for the product? And based on that understanding of the user and the product, specific features fall into place. Low technical cost updates with immediate usage impact that fit within the long term narrative make sense as next quarter launches. Big things make sense as next year launches. Fundamental shifts make sense as 3 year updates. Each horizon requires buy-in from the PM org themselves to prove the business case for what you're trying to suggest, which I tend to believe comes from: * usage data * market analysis * desk research * comissioned research * narrative creation * awarness / consideration / preference metrics As you look to shape near term roadmap, you may need less stakeholders in the room and less prep work to prove the business case for your suggested roadmap enhancement. As you look to shape long term roadmap, you probably need more stakeholders in the room (and more senior ones at that) and more prep work to prove the strategy. So the main difference in approach is the amount of work required, but its made easier if you have a sound process that works for you to achieve xfn buy-in and you scale that process as necessary. 

For your sake, I'd hope that if your research shows that MVP doesnt equate to a value add for your customers, that causes your product team to make a full stop and push. That said, at this point I think you need to put your PM hat on and think about what features might make users see value in your product and opportunity size those features for what could be the easiest to deliver in a meaningful way. Have that conversation with your PM team and also reiterate the cost to launching a non valuable product: no adoption, no usage, no revenue, but time spent building marketing and shipping that product. And if that doesnt work and your product team still insists on launching, measure everything. If adoption really isnt there, then use it as a case study that you can take into future conversations to help steer the roadmap in the right direction. It's a long game, you have many years in your career and many products to launch--sometimes the experience and clarity that comes from a failure teaches you more than any other work experience you'll have. 

I'd reframe the question a bit from proving value to adding value. Proving value is a little defensive, vs adding value puts the onus on PMM to show up every day with a task to be done. I think about adding value to PMs in two parts: 1. Trust: If I had to simplify it to a few key things, its a strong understanding of the customer and their problems and then a strong understanding of the competitive space and market. I think its also important to have a point of view. If you bring those insights to your day-to-day meetings, you can establish your line of thinking with your PM stakeholders. If you have a point of view -- meaning have an opinion, dont defer all decisions to the group -- then you can engage in productive conversations and brainstorms with your stakeholders. This will help to earn trust. 2. Results: From there, the second part is to deliver results. That comes in a variety of ways, but some areas where I've built up my internal brand with my PMs have been in creating decks for customer events--taking the onus off product to craft a presentation, and delivering it in a concise, new, and engaging manner. Thus the PM's job is easier and theyre getting a better output. Other areas have been in supplying notes, bullet points, and data points for customer/partner briefings that PMs have led. In one case, I worked on one slide for a customer meeting, and that slide ended up being where our PM team spent a bulk of their time with the customer and that led to the PM proactively asking for my input in other areas. At the end of the day, product teams are in really high demand. If you, as a PMM, can own some of the areas in which a PM might get pulled into different meetings/projects and can deliver high value work back--then the PM doesnt need think like they have to do everything. I read a LinkedIn post a few months ago from a CS leader who wrote about how great CS work comes from a great relationship with PM, so that the product can stay top of mind with CSMs and get its way to customers. And while I think thats true as an end result, I also think it showcases a gap where PMM should have filled. PMMs should know the market and know the product, and that should be able to inform multiple internal teams. While PMs probably dont have an issue meeting with XFN teams, I'm sure they'd appreciate the luxury of focus--and thats where PMMs can help. So while it's obviously great if that established model exists and PMMs can show up with their value to the org known, its much easier (IMO) to take back control and not hope for infrastructure change in an org at the expense of creating your own fortune. 

I personally think the biggest value of an MBA is in getting into product marketing. Most companies dont have APMM roles and so there isnt a ton of opportunities for true entry level roles. PMM roles tend to require mapping customers to narratives to products to marketing strategies, while being able to project manage your time and build relationships internally--thats a pretty nebulous charter, which is where the MBA comes in. For candidates who havent had luck moving internally from another role into product marketing, or are looking to make a complete career pivot, MBAs tend to give hiring teams a bit of security in the candidates ability to handle that workload. However, once youve started your PMM career, I dont think an MBA is then required to get to leadership roles within the company. You can get there with what you learn on the job and what you deliver while in your previous roles. Should you want to branch your skills out into areas where you may not have natural exposure, many of the leading business schools offer certificates that may allow you to sharpen a few skills that might help you in your overall development path; but I dont necessarily see a ton of value in an established PMM getting an MBA in order to get to leadership levels. Candidly, none of the promo conversations I've ever been in referenced a current employees education, and all were focused on impact created in the current org. 

My advice on this one is that there's no real overstepping of your role--as long as you're respectful of others (both people and functions) and act in the interest of the company. If you're doing both of those things, then act like an owner and do what you think is necessary to help the business move forward. PMMs tend to have a vantage point not always offorded to other teams, given the nature of our role is to be so higly cross functional. So if youre seeing silo'd work and its negatively impacting launches and you arent able to deliver meaningful results, raise your concerns. In these types of situations, I also look for a controlled way where I can measure impact. Is there a smaller launch when youre able to execute your way--without a constantly changing roadmap or set of goals? Are you able to then measure impact and see how those results compare to the standard? If impact is greater, you could use these results to try to bring order to roadmap and goal fluidity with a second small launch and if results continue to outpace the norm, you are well on your way to creating cultural change! Of course, you'll want to do all of this around its impact to the business rather than its impact to your role or your work. The health of the business is something pretty defensable that all teams *should* care about. So position your thoughts around how you can drive better business goals and how you can make more impact to the org, ultimately leading to longer term revenue potential and cost reduction, you should be able to gain an ear of an influential leader.

Winning over stakeholders is a key part of being a PMM, and it might be your approach that needs an iterative update. IMO, influencing roadmap comes down to influencing PMs--and some are going to be easy to work with and easily malleable and some arent. So if your product management team isnt open to customer or prospect feedback on your product, what are they interested in? How are they making their decisions about what to include into roadmap? How are you packaging the insights you hear from customers and prospects about your product? Is the "cost" of not listening to your customers and prospects established? I'd start with building a strong relationship with your PM, first at a personal level, then work to deliver business impact back to that PM. If you have feedback from customers, is there something you can do--write a blog, host a webinar, etc. where you can factor in customer/prospect feedback? I'd venture a guess that your performance would be pretty strong on that deliverable, since you've listened directly to the customer. Then take those results back to the PM and talk about how you saw better engagement that drove better business metrics (leads, sales, revenue). While you're at it, ask questions about the PM's process on the roadmap and what is driving how they make choices around what to include. My biggest feeling about PMM influencing roadmap is that its an earned opportunity, not a given one. So if you can learn what makes your PM tick and you can provide metrics around business impact when your customer insights are leveraged, then you can work towards more influence of your product manager which will ultimately afford you more influence over the product roadmap. 

IMO, your roadmap needs to be representative of your company vision. And practically, your company's growth opportunities would come from customer expansion and new deals. So I'd advise that you leverage your advisory board to really understand your current install base well. As you think through segmentation for future opportunities, your current install base may be an analog to your highest potential addressable market, or it may not. Thus, how much your advisory board plays into your roadmap would vary based on where you have opportunity and what your product vision is. Let's assume that your growth opportunity comes from expansion of current customers and from a lookalike audience off of your current customer base; then your advisory board may be a trove of great inputs that can help your product team build roadmap. I'd suggest you consolidate those insights, bring in quotes, ideate with your PMs about what your customers are saying and help your PM team build a product strategy that best suits your customer needs. Some of the best PM/PMM relationships I've had were where I'd bring market insights relevant to our growth targets to our product team, and leverage those insights/quotes/stats/etc as we build new narratives, review materials, and brainstorm. Using a deep understanding of our customer to guide PMM strategy led to an increase in respect from PM. Where I think things get a little messy is when teams try to take product ideas from an advisory board and have a product team build those things--that's a quick way to lose your company vision. So rather than trying to push learnings from the advisory board onto the roadmap, let them define your core PMM work and let that knowledge lead to PM pulling more info out of you as they build their roadmap. 

How I've understood customer journeys in the past have never actually leveraged a software tool to do so. We've started by mapping out the customer journey into normal stages: awareness, interest, consideration, preference, loyalty. Then across those stages, look to see what is the customer thinking, doing, experiencing and feeling across each. Fill all of that out into a matrix and from there you'll have a good grasp for what your customer is going through across the journey and that should help shape the assets you need to create or the campaigns you need to build to move customers through the customer journey towards purchase/loyalty. At my previous company we did this by interviewing internal stakeholders who were customer facing as well as interviewing customers when we could--so it was all internally executed without 3p SaaS. I'd start there and if there was still a gap in terms of what insights were needed, then I'd consider a software tool as a step two in the future. 

As a PMM, I tend to view the RACI as PMM being responsible/accountable and CS being considered and PM being informed/potentially considered. But it depends on your org and how you're structured. The reason I say PMM is because I think the value of an advisory board is to help understand new trends, forecast the future, and help guide the product. So its about the intersection of the product and the market. CS teams could also lead and advisory board as well. I think the best solution on who should lead the creation of the advisory board being whichever team has the bandwith and available time for the critical thinking to maximize the program. Better to have the "wrong" team lead it if they are giving it real thought than having the "right" team lead it and go through the motions without maximizing its impact. 

A great business resource on developing XFN relationships is the book "Five Dysnfunctions of a Team" by Patrick Lencioni. Its an easy read and its scalable to all relationship building in your organization. If you can establish trust, you can have conversations and meetings with productive conflict that will make it easier to achieve buy-in of various ideas which will help keep people accountable and ultimately drive results. But the book is a much better blueprint than that 30 word sentence above. 

I think the most important part of influencing product roadmap is that its an outcome created by a strong understanding of the user, strong understanding of the product and a strong relationship with product management. If you have those items already landed, then you can better understand if theres a gap that truly needs to be filled in the roadmap. If you lack one or more of those areas, then it may be hard to achieve the XFN buy-in required to influence roadmap. To play back a sports analogy; imagine you're a golfer and you want to hit a longer drive. If you work on your stance for the right balance, and work on your core for power generation, and work on your pivot for optimal torque, and your swing plane and ball striking for impact--then you'll hit a longer drive and you'll probably also hit a longer 7 iron and pitching wedge. But if you go to the range and just swing your heart out, you might be trying harder to hit a longer drive but may not see results. The same applies to influencing roadmap--build a great foundation with your stakeholders, have great relationships with them, and in the end influencing roadmap will be much easier.

Empathy (insert business buzzword) around the customer and how they use the product and specifically what CUJs/JTBDs they are participating in during that specific usage. If you can really put yourself in the shoes of your customer and think critically around how it will be used and what impact that will have for the business--and you overlay that with market/competitive info, then you can have a productive brainstorm on feature discovery. 

Impact. If you dont do the training, will the feature be used? Will it create more bugs? I think of this as a cost benefit equation--What is the cost of holding a launch to do a training vs what is the cost of launching without the training? Being able to articulate that potential downside to doing the launch "wrong" will help your XFNs understand why youre making a specific recommendation. For example, if you can quantify that launching a feature without a sales training will equate to a X% conversion rate vs launching the feature with a training will equate to a 2X% conversion rate, then you can make the statement internally that the <week, month, etc.> that it will take to train the sales team will yield double the return, so its a slight cost of waiting a little for a larger benefit. At a previous company I worked at, our PM team was excited about the speed at which they would innovate, so it was a big deal to them that we were launching new features at every sprint. The downside was that nobody was using them. So we had to create a monthly webinar series where PMM and CS had to manage (build, practice, present + create campaigns, emails, segmentation lists, etc.) to recap the highlights from the recent releases. I later worked at another company that did 3 large launches a year but it became so programmatic that it lost its value and the company actually generateed more MQLs off of highly relevant highly targeted singular feature campaigns than it did off the big release moment. So there's no set answer on how to do the launch, but more so what nuanced approach will work for your org to drive the most impact? 

It starts with buy-in. If you can work with your XFN teams before the research is commissioned to chat about what questions the business wants solved and then once you have a vendor share the vendor proposal and then once you have qual/quant outlines share those with your XFNs to get their opinions on the questions being asked and research strategies being leveraged--then your partner teams will feel like they had a part in the research origination, and then they might be more interested in its output. Research is kind of like data, its a great mechanism, but there's so much variability that if you arent bought into the process you may find a bias in how the work was done, which would invalidate it in your opinion. Ex: a qual that may include any prospect vs a qual to just your target persona might yield different levels of trust internally. I also tend to believe that internal partners arent really focused on who is doing the work, or what the final outcome is, as long as they are considered in the process and their opinions are heard. So I'd suggest that in the next time you do a small qual that your team leads, bring your partner teams in on the ride from the beginning: they may help you think about the study in a fresh way and they'll feel like they have some skin in the game for the results. 

Its about doing the work. I view influencing the roadmap as a byproduct of a great process rather than a task itself. So as you build up your understanding of the product and your user needs and you map that to the market and competitive landscape, formulate your own point of view on where your product needs to go and become a thought partner to your PM. Influencing the roadmap is a long game, but if you can brand yourself as a trusted mind with your product manager that has an eye for where the product can go--and you deliver results along the way (your work yields better engagement, more usage, higher MQLs, etc.)--then your product teams will seek your opinion. One example was at a previous company, I came in with a developer marketing background and was excited about low-code opportunities. This company had a robust API, but no low-code strategy. As we would brainstorm, I'd throw out questions about low-code to get the conversation going internally and gauge mutual excitement. I ended up doing research on another topic and included some seed questions on our developer apetite for a low-code solution; and they performed well. As we worked with partners, where we had a low-code integration that we could market, we saw those were performing well as well. So that combination of internal meetings, developer feedback, and marketing results led to more conversations around low code to the point that we started elevating our very nascent low code offering into prime keynote real estate in tentpole internal events. So its really about knowing the customer and the opportunity and having a point of view for where your org should go, and then seeing that through with your PM teams. 

As it relates to influencing roadmap, breadth is important. If youre spread too thin (I don't mean PM:PMM ratio, I mean commonality in what you cover--more on this later) then you wont be able to go upstream and influence roadmap because you'll be playing defense all day. I personally think being tagged to a vertical or a persona will make it harder to influence roadmap because you'll be seen as a person that executes a launch to a segment; rather than being a person that understands both the product and the user to think like a PM. Nuance here: Insights around a persona or vertical will help, but structure matters, because you want your internal teams to think of you as mapped to their product bringing persona insights; rather than mapped to a persona trying to connect to products. So as it relates to being spread too thin--can you find a common denominator in terms of what you cover, and can you bring insights back to your 3+ PMs about that commonality? I focus on Google Assistant and 1p/3p apps. So thats a lot of PMs on Assistant, PMs on 1p app teams and BD folks on 3p app teams; so the commonality is the extensibility of Assistant. The insights are around what makes app usage sticky and what Assistant can bring to an external app. If my ratio was lower, but my focus was on disconnected topics, I wouldnt be able to pull together a common thread to bring back insights that would help PMs, unless I prioritized one product over another. 

I think I mentioned this in another answer, but I think a good framework is the Five Dysfunctions of a Team model. Build trust with your PM and other stakeholders--that's delivering results when called upon and being a key thought partner with your stakeholders. That will allow you to have productive conflict--which is about being comfortable enough to challenge an opinion because you already have mutual trust with your stakeholder. That will allow you to have buy-in on plans because youve both asked the hard questions. That will allow you to have accountability for what happened because you had previous alignment, which will drive results. Thats obviously a lot, but if you can really work on building trust with your PM--know your user, know your product, deliver results (make great decks, build awesome emails, produce better marketing results than the average) then your PM will seek out your opinion. In some cases I've had recurring PM syncs, In some cases I havent. So its not so much about your working model or cadence, but more around how can you own your space and deliver results back to your stakeholders. 

I like to anchor messaging to a foundational message house/messaging framework document that all other deliverables stem from. * List out details about your core persona:what their challenges/pain points are. * List out your market context. * Think about your product differentiation * What are your supporting product proof points. * Distill those down into a 50/100 word messaging statement. * Be presecriptive about alignment and buy-on on that message house, make sure your brand team is on board, your product team and your sales team. Then use that as the basis point for all of the areas in which your story is told--website, blog, campaign creative, sales decks, one pagers, etc--should all be a derivative off of that document.

The best full-stack marketers can go broad and deep. From a hard skills POV, you'd need to know enough to build a plan across any marketing dimension (product, social, email, web, growth, strategy, etc.) but IMO its more about the soft skills to build relationships, know when to do a task vs bring in others, brand yourself as someone who gets the job done and delivers results and the mental model to always think big picture about customer impact and usage--that will bring more opportunities which will help create a full-stack marketer. 

Tracking impact of launches and defining the costs associated with roadmap slipping. Sales deals lost because a feature was promised but didnt ship. Customer trust lost because they dont have confidence in what you say is coming. The opportunity cost of internal teams working on items that didnt ship and what they couldnt do because of it. I tend to view a lot of things as a cost/benefit equation, so really get sharp at defining the costs to the organization that product is creating by not delivering on roadmap timing. 

I dont really have a strong "pro" for why to do this, so I personally wouldnt put too much time and effort into it. But it may make sense for your business challenges. I think something to be aware of is that when you document your roadmap publicly, it puts more pressure to ensure dates dont slip. If you're trying to brand yourself as an innovator by having all these new ideas, it may help, but you run the risk of causing customer to delay their purchase until a later date until a feature they want is live--which doesnt really matter if you have a freemium GTM; so I guess that's how I'd look at it. If you have a bottom-up go-to-market and you want users to get on board as fast as possible and show them whats coming soon, may make sense. But if you have a sales or partner led GTM, you might be creating more cost than benefit. 

IMO PM creates products and PMM maps the product to the user. So I think the ideal role for PMM in shaping roadmap is to thoughtfully validate and critique the roadmap that Product creates based on your knowledge of the 1) user 2) product 3) market; with the ability to (aka having done enough homework to) defend the hypotheses you create for where your product should go. 

To bring the voice of the customer (and all of the external market concerns top of mind to a customer) to help the PM team build the best product possible. Feedback in review cycles or direct questions in 1:1s between leads helps. But its also valuable to read the room when you sit in on meetings with your team. Are the PMs engaged? Is there a buzz in the air or does it feel flat? While a PMM is talking/presenting, are others multi-tasking or are they participating? If your PMM team is bringing value to your PM team, then your PMs will act as though they value the meeting vs acting as though the meeting is a thing they have to do. I use that as a pulse check to see if PMMs are delivering impact effectively to stakeholders. 

Time and resource allocation helps me think about this. If I know I have 40 hours of work already lined up and a new project pops up, it helps me to talk to product about when we'll be able to support a new workstream if I can detail whats currently open. That helps us jointly prioritize so that we can spend time on P0s, hopefully get to P1s, and keep P2s alive until there is time. Having a running document (deck with project plans or spreadsheet/gantt chart) helps to visualize this. Though the conversation here is probably appropriate at an equal level. So PMM team lead can chat about resource availability with PM team lead and IC PMM can chat about current projects with IC PM. This as a matrix convo across levels in different functions feels like an easy way for participants to stop paying attention. 

At my last company we made a launch tiering playbook. It was a series of 6 steps: 1) First, we's look at product's roadmap to see what was on the horizon 2) From there, we'd review PRDs. Mainly, we'd use the PRD to know what was behind the scenes so that we could forecast impact so that we had an idea for meaty vs light features coming. 3) We'd use that to think about bundling and timing. Some features with like components could work well as a bundle, of which the bundle could carry more weight to customers. Some features could stand alone. This is really about your gut feeling, which is where having a PRD to reference and forecast impact is important. 4) We'd then tier the launches. We used 5 tiers, but it could also be 3 or 4, depending on what works for your business. Ours were: * Moments: Flagship launches that open new markets and directly drive revenue * Milestones: Releases that indirectly drive revenue and unblock deals * Modernizations: Releases that create new opportunities for multiple personas with less revenue impact than Milestones * Migrations: Release that drive new ways of working * Maintenance: Releases that keep the current customer experience up to date 5) From there we'd build a S/M/L bill of materials template. We'd map tiers to a BOM and execute a large bill of materials for Moments vs a small one for Maintenance. (Of course the template is a starting point and each launch should include whats necessary rather than stick to a formula) 6) Then we'd create an escalation process, with documented review criteria. This way, if a PM/stakeholder felt that a launch was too low of a tier, there was a documented way where they could appeal for a higher tier of which we would discuss and adjust as necessary This way we could manage internal expectations while setting our PMM teams up to do great work as it came to launch moments. The biggest challenge for us in implementing this was the PRD requirement. Not all teams at my last company made PRDs for their launches, but it also created an opportunity for us to introduce logic behind what information we needed. To compromise, we were building an intake process where absent a PRD a PM could submit a form (we used Jira) that contained need to know information. Not all PMs are equal when it comes to filling out this info, but it allowed us to make reasonable judgements. And for the PMs that didnt submit thorough information, it was a learning routine for them to see that other PMs who did submit more detailed info could get more weight behind their launches. I think if you document a process and explain the reasoning (and have management support backed by business impact to implement the process) then you can create a path to collect the information you need to scope releases and launch appropriately. 

If you dont have data or customer anecdotes, I'm not sure you should be driving roadmap. Influencing roadmap is an earned outcome and not something to just "do" for the sake of checking a box. Think of the roadmap as a business mechanism, and do you have enough to convince stakeholders that the direction of your company should be steered in another direction? For most cases, that is going to be user data, market research, competitive positioning, customer feedback, etc. Without that, I'm not sure I'd be comfortable trying to take on the responsibility of driving roadmap. 

Ultimately I view roadmap as a path to your company's vision to get more customers to use your service. Thus, I definitely dont think that meet-comp features by themselves are justfiable evidence to get something into roadmap--because the market already has that and is it really going to differentiate your product. In certain cases it will help you not lose deals because of a gap, but its not really making you a visionary, so a healthy balance of when to add competitive features is nice. I'd say a must have feature is some combo of high forecasted customer usage, high addressable market opportunity and low cost to create. All of which map to what is the ROI behind building the feature? If you take that approach, and look across a few different features, you'll start to see opportunities that make sense for your business.