AMA: Splunk Sr. Director of Product Management , Kara Gillis on Stakeholder Management

TLDR: Stay aligned by clearly defining your roles and responsibilities. There are published RACI models on the role of PMM. Align on a RACI and stick to it. Then establish a continuous cadence for staying in contact throughout product development to ensure PMMs are always in the loop. I love product marketing as a function, and there is nothing more valuable to me than a strong product marketer. The triad model of product development often refers to Design, Product, and Tech/Engineering leads but truly it should be a "quad" model to include product marketing. The relationship shouldn't be too complicated. It should be pretty clear where one function begins and the other ends based on the owners of certain deliverables: Product manager - product strategy docs that talk about positioning - what differentiates the product relating to competition/alternative solutions, PRFAQ, PRD, use case requirements, user stories, prioritization of requirements and features, roadmap - both in presentation and system format * Design - Figma mockups, user journeys, user persona research, UX research (plan, notes, analysis) * Arch/Engineering - technical requirements on user stories/eng requirements doc (ERD), solution architecture, sprint plan, quality / testing plan * Product marketing - product messaging brief, sales plays, field enablement (on products, buyer/user personas, use cases), customer facing decks, industry analyst presentations Where this can get confusing in some organizations is deciding who owns pricing/packaging and competitive analysis. Sometimes organizations actually have departments that own each of these areas separate from product and PMM. I often see pricing/packaging owned by product and competitive in PMM. I meet with PMM every other week. PMM joins customer calls, gets access to early product strategy docs to provide feedback, pulls data to analyze different dimensions of performance and sales for me, and proactively creates messaging docs that she asks me to review. We have a lot of trust and open lines of communication because we have very clear ownership areas defined.

If I am in my current role managing PMs, I care about the following success metrics: * How are each of the team members progressing on their areas of ownership, achievement of their own OKRs? * How are my team members progressing in their career development plans? Have I successfully rewarded and promoted high potential team mates? Do I have development plans for each of my direct reports and are they on track for their next promotion cycle / role / increase in responsibility? * Have I been able to successfully develop a product strategy and prioritize my area of ownership? Have I worked cross-functionally to establish trust and build relationships that help manage dependencies we have on other teams? * Have I unblocked my team by helping secure decisions so they can move forward? * Have I communicated areas of ownership transparently to my team so everyone understands their role, context of the product strategy, customer needs, OKRs, and success metrics? * Have I been able to hire and coach team members, or remove team members when required? If I am an IC PM... * I establish a very clear objective for myself in my role depending on what my ownership area is as a PM - examples could be: * Driving better onboarding experience * Launching a brand new product or feature * Drive product led growth * Improve retention of a product * I select a key result that is quantifiable that reflects whether or not the objective has been met - examples could be: * Time to value metrics (how quickly a customer can onboard or start getting value from the product) * Adoption of a new feature (DAU, MAU, etc.) * Conversion rate from free to paid user * Churn rate * And I track my progress towards these metrics (hopefully there is one primary metric on a monthly or quarterly basis. Other IC PM considerations include how well I communicate, present roadmaps, regularly create and iterate on product requirements, PRFAQs, collaborate cross-functionally, communicate with engineering and design stakeholders, etc.

If this is an HR issue - please involve HR right away. I'm intentionally going to assume it's not for this question. As a people leader, your role is to provide a psychologically safe environment for your team to strategize, collaborate, discuss, disagree, and align. A lot of people call this "storming and norming in order to perform." Your team will be made up of different types of people who must get used to each other, and it might not be smooth sailing initially. In general, it's good to create team bonding opportunities to reduce unnecessary/unproductive conflict. When conflict arises, it's important for you as the team lead to remain objective, calm, and open to both team members. To resolve conflict, I would hear each team member out about the conflict: how they are feeling, what their issue is, and evaluate their interpersonal communication style, and make an assessment on how to move forward. Depending on the disagreement (assuming nothing violated HR policies), one party or both will require coaching on how to approach the conflict. That could mean seeing someone's point of view, understanding how their communication may have been misinterpreted, getting more context/clarity about an element of strategy. To put an end to the conflict - if the situation isn't too toxic, asking them to work on a joint solution or compromise can be very productive, especially if you give them a specific deliverable or template that they have to work on together. It's not always possible to do that - sometimes you must make the decision to move forward and ask them to "disagree and commit" to the plan, providing them with a reason for the decision.

I have led different sizes of product teams and single product teams or multiple product teams within an org. My philosophy is to structure a team to make ownership and decision making very clear; I use the MECE (mutually exclusive, collectively exhaustive) framework to reduce as many inter-team dependencies as possible. How do I do this? It depends on the type of team I'm leading. For example - for customer facing products that my company sells, I first separate teams by the product on which they work. Then, I assign team members to discrete customer use cases for that product. For this to work, there have to be clusters of features that are clearly delineated to that use case. Try to organize by use cases that have as little overlap as possible so that one person can own a use case for a particular product and drive a roadmap for features that don't impact / have dependencies on other use cases. For more shared services/platform oriented teams that probably enable multiple use cases (think backend services or data pipelines) and maybe aren't directly end user focused, it can get tricky. Some teams appoint owners of each backend service, but others can still structure ownership around a broader use case that could require APIs to be leveraged by multiple teams to enable a particular use case. A good example would be "Identity and Authentication" or "Dashboards and Reports" or "Product Telemetry." There are probably multiple services that drive each of these platform use cases that require a structured way/API with which multiple teams could interact. To the extent possible, even with platform service PM teams, try to organize ownership around clusters of features that are solely owned and managed by a single PM. It reduces complexity around decision rights and interaction points.

TLDR: get as much feedback as early as you can from your customers to validate the use case you're solving and your approach to solving it, validate the solution with product leadership, as well as with sales and marketing in terms of messaging, make sure the product can be built to the requirements customers need, and ensure all go-to-market functions sign off on the launch plan. There are two big influences on the cadence of gathering feedback: 1. Which stakeholders - who are you referring to as a "stakeholder"? I assume we mean customers, sales (technical and non-technical), engineering, marketing, customer support/success, and pricing. 2. Stage of launch prep - how far out are you from launch? This question could get really long - so I'm going to try to make it rather concise: 1. Business case development - conduct UX research, or your own customer interviews to discover pain points about a use case. Synthesize the findings and use them to put together a PRFAQ or PRD and socialize that with product peers and leaders and engineering counterparts. Also with product marketing to ensure the "PR" part of the PRFAQ makes sense. Once these internal stakeholders align on the 2. Establish a product preview program with customers that have the use case requirements that drive your approach on a biweekly or monthly basis as you make progress on solution development. Early on, show Figma mock ups if you don't yet have code. Run the preview as long as you need until the solution is ready. You may need to add additional customers over time as requirements may evolve or be added once customer see the solution for themselves. I would focus on nailing the activation and onboarding elements of the product first, and ensuring one critical use case can be completed by the end of the preview program. 3. In parallel to #2, run a series of sales feedback sessions on a monthly or quarterly basis (depending on how long the solution preview is) to get an understanding on how to go to market, learn what pitfalls to avoid, how to structure pricing, metering, etc. This feedback will probably inform some smaller elements of the product itself but it will greatly influence field enablement and messaging. 4. Have checkpoints throughout the preview process with product marketing to nail the messaging. How often depends on how embedded product marketing is in the product development process. PMM should really be in those customer and sales feedback sessions. PMM should create a messaging brief based on customer feedback. The messaging brief should be complete before the end of the preview. All marketing content and sales enablement should be based off of this messaging brief. 5. Having a bill of materials for launches that goes through the required checklist of everything that's required before launch is really important - it should define when certain functions need to provide input or sign off. 6. Launch the product! 7. Continue getting feedback in a monthly or quarterly customer advisory board - never stop getting feedback to iterate and improve on existing functionality or expand into new use cases.