Swaroop Sham

With so much at stake, a lot can go wrong when trying to influence the product roadmap. When tensions run high, PMMs might risk their most important relationship by: Not providing Sufficient Quantitative and Qualitative data. Most PMs are data-informed and driven. Insufficient quantitative and qualitative data on the impact of a feature is a sure shot way to fray the relationship. Focusing on the how: Many PMMs are technically savvy and understand the product’s capabilities and anyone. PMMs should leave the final ownership of how a feature is prioritized and developed to a PM. Telling a PM on developing a feature should only be a suggestion for the PM to consider. Unaligned timelines and capability: Timeline mis-alignment is a common source of disagreement. Product capability being delivered is another key area. Having clear communication, visibility, and reasoning in either direction can help drive alignment

For the definition of reviews, I will consider analyst product evaluations also as reviews. It is also important to know that not all public reviews have the same weight. From my own experience, well articulated, attributed - negative feedback can have the right impact on product roadmap decisions. It allows the PM-PMM team to even reach out for further investigations and understand the key gaps for the customer. It also gives the team a chance to respond to the feedback by providing acceptable work arounds or provide product roadmap guidence. 

First of all, most well-heeled product managers tend to be strongly opinionated but open to reasoning and change. The PM-PMM relationship is one of the most critical relationships for product people, and the success of the relationship has a direct impact on your success. Here are some methods i commonly use. Effective questioning: My fav go-to strategy when dealing with a strong-willed or challenging to work with PM (or anyone for that matter) is the "Idea of Influence with good questions." I adopted this strategy as it moves the conversation to "educate me" on your approach. A vital element of this approach is to make the questions nonthreatening. A common and related approach is the 5-why approach. I find this approach to be my most effective method. Research: Another approach that I commonly leverage is proof-driven reframing. Most PMs are data-driven individuals. In this regard having strong information such as (below) is very effective. - Quantitative sales and field data - Qualitative customer feedback - Compete information - AR feedback Ownership: Having clear areas of ownership in terms of product development and GTM strategy clearly set the stone on who has the final word(and ownership) on any specific area of contention.

Yes, launches are a big element of the PM-PMM equation, but this relationship is much more than helping us launch things. Done right, Product Managers and Product Marketers form a strategic team for the product area in an organization. This relationship typically guides the product development, adoption, marketing, and overall success of the Northstar metrics for the product. The PMM team is key to developing the product's strategic messaging built off customer understanding. This strategic messaging is built on a combination of both in-bound PMM skills and outbound PMM skills that the PMs can tap into. At Okta, on the Inbound side, PMMs help with: Strategic Customer initiatives and problem statements Market, gaps, and use-case development Key Persona development Messaging development Market sizing and segment Adoption feedback and roadblocks Analyst feedback Strategic product partnerships On the outbound side Demand generation patterns (Channels and methods) Feature adoption programs Win/Loss Deal analysis Pricing and Packaging strategy Compete analysis Sales enablement The PM-PMM team also partner up when doing QBRs for their respective spheres. 

“Develop a number of direct and in-direct forums to pass feedback to the product team”. In the course of my experience, I have seen a combination of the following specifically for roadmap feedback and chatter from the field: Setup Weekly PM-PMM roundtables and 1:1 - Focus on sharing feature feedback, product gaps based on customer conversations, compete for notes. Offer Office hours: Develop the idea of office hours in conjunction with the sales enablement team to provide PMs with direct feedback. Build dedicated slack channels: Slack channels, especially that have field team visibility, tend to be a rich forum to pass roadmap feedback. Actively monitor channels and have PMMs and PMs triaging and tagging on a near real-time basis. These slack channels can benefit from both CSM feedback and SE feedback. Promote the internal ideas page: The field teams are rich in product ideas and areas for improvements. An internal “Stack overflow” style page allows ideas to germinate, get voted upon, and benefit from Work with Jira/Confluence: PMMs can add a lot of new perspectives to the roadmap by taking time to review the feature storyboard or even the product spec. PMs should actively include and solicit PMM feedback for the product spec. Share Win/Loss Analysis: Actively triage and share win/loss notes. Highlight opportunities that could have benefited from roadmap prioritization or changes to the roadmap.

“Repeatedly sell your roadmap internal and externally” Key Elements: Any good roadmap does three things. Set product vision, showcase product features, and set expectations on timeline and capabilities. The product vision sets the directional tone for the product while the product feature goes into the nuts and bolts, showing the key capability, use-cases as well as product limitations. Cadence: At Okta, our key roadmaps are overhauled and developed end-to-end approx once a year. Every quarter, the respective product sphere team does a quick iteration to indicate key movements in the product roadmap and establish continuity throughout the year. Roadmap Visibility: In our roadmaps, we provide a lot of product depth for features that are in a three-month window of delivery. For everything else, we provide vision and guidance. Delivery: So then, how do you deliver the vision and feature level roadmap? At Okta, we have settled on a multi-forum strategy to communicate the roadmap. Internally: We deliver the roadmap once every quarter to the product team to the entire field team. This session is a well-developed session with support provided by the PM and PMM teams. Externally, We deliver the quarterly roadmap to customers in recorded sessions that can be used in a self-service manner. Additionally, the field teams, PMMs, and PMs deliver the roadmap to customers in dedicated executive business reviews with major customers. Very critically, all roadmap delivery teams are anchored around the key roadmap deck that is first delivered by the PM-PMM team combination. Expectations: Setting expectations is another key item that is conveyed in our roadmap. It is important to understand that timings change or features move on the roadmap due to various business and technical reasons.

"Be pragmatic" Yes - sometimes, deals tend to have revenue opportunities linked to them, and the PMM-PM team needs to decide on the trade-offs about making changes to the roadmap that have revenue linked to them. In such situations, it is important to be pragmatic. Some of the questions to think about while considering revenue linked feature development are: Customer and deal pipeline impact - How many opps and current customers will be positively impacted by building the feature now? Timeline - How long will it take to meet the customer's demand. Can we meet to offer the customer an acceptable solution within the timeline promised? Customer considerations: what will be the impact to the customer if we do not accept or agree with their contractual terms and timeline. Will, the customer consider other competitive solutions. Internal Cost and roadmap impact: How much will this feature cost to develop, and can we offer a pragmatic(often nonideal) solution that meets most of the customer's goals. Think long-term: How can we ensure we are not building a unicorn feature that only works for this customer. I.e. Should this be on the roadmap, or this better serviced via a professional service or consulting engagement. Build extra timeline padding: Avoid pushing your organization into a box by over-committing on the timeline. There is probably a good reason why the feature does not currently exist in your product today, and contractually accepting this feature will likely force you to revisit previous decisions and deal with technical debt. Allow enough timeline padding for such ghosts. Broader customer impact: Consider the broader impact of the feature on other customers. Over rotating a feature to meet the needs of a paying customer can end up in a sub-optimal experience for everyone else. PMM impact: Think about how building the new feature will up-end the current pmm obligations. Can you develop new messaging in the timeline? Would you do a formal full-fledged launch for the feature? How will your pricing and packaging change? How will field enablement look like for the feature? How will broader customers have access to the feature?