Something that comes up periodically in my product leadership coaching sessions: “As a Director or VP of Product, how do I get folks outside my immediate span of control to make improvements or do their jobs better or take my advice?”  This is usually in the context of some (seemingly) obvious problem that we (believe we) know how to fix.

I try to frame this as either in scope or out of scope for their particular role.  In scope means that they own the decision/action, but might consult others.  Out of scope means they can advise, counsel, suggest, offer to help… but don’t own the decision/action.  With lots of gray space between the two.

Let’s imagine a Director of Product responsible for a portfolio, with 5 product manager direct reports matched to 5 stable maker teams.  (Idealized, I know.)  Decisions that should be in scope for our Director:

• Final calls about which product managers (PdMs) are matched to which maker teams
• Overrides on team-level priorities or roadmaps, especially around cross-team dependencies; shared metrics; or information that individual PdMs/teams lack
• Promotions, hiring, firing, comp, transfers for product managers (but not engineers or designers or growth marketers)
• Mentoring/coaching, skills assessments, and career planning for direct reports
• Assigning or loaning staff to task forces and cross-functional groups

Most other issues and challenges and opportunities and departmental dumpster fires are nominally out of scope for product leaders.  But that doesn’t mean we ignore them or sit idly by while colleagues get into trouble.  So let’s imagine (or anonymize) responses to some real-world scenarios. 

(BTW, every company has a unique culture.  Some are top-down command-and-control, others are freewheeling or consensus-driven or chaotically leaderless or run by a CEO who had a bad childhood.  Please don’t apply any of this without matching it to your situation.) 

UNFILLED PRODUCT POSITIONS

There are thousands of talented product folks between gigs, looking for their next adventure.  But hiring is notoriously difficult: world salad job descriptions that mix up proDUCT with proJECT and proGRAM; in-house recruiters focused on higher-volume sales and engineering roles; bots that submit mountains of inappropriate résumés to every open position your jobs site.

IN SCOPE:  If you’re a Director who is short a product manager or two, you’re doing two or three full-time jobs (badly) and probably very sleep deprived.  So hiring that great someone is your most important task.  (Discovery and portfolio planning and your team’s internal reputation will keep suffering until you do.)  Things you might try:

• Block out 30 minutes every other day for recruiting, interview planning, and social networking.  Put it on your calendar.  Strategy and escalations and Board slides can wait a half hour.
• Push internal recruiters hard, perhaps reviewing stacks of résumés together to clearly communicate what you’re looking for.  If you’re not getting the candidates you need, go outside for a contingent search professional who focuses on product roles (not engineering or design or sales or marketing).
• Share job links widely.  (Wildly!)  Social networks, email to former colleagues, last year’s candidates who turned you down.  The talent is out there!
• Review hard qualifiers vs. nice-to-haves with your interview roster, and assign areas of  focus for interviewers

OUT OF SCOPE: One of your peer Directors isn’t filling their open PdM slots, or is hiring the wrong people.  That spills over into your group, since your team leans in a lot to help.  And you may be asked to ‘lend’ some of your strongest performers to cover gaps in adjacent product groups.  Not strictly your problem, but it can have severe knock-on effects for your products and team and broader outcomes.  You might offer advice and assistance to your peer:

• Encourage them to put recruiting at the top of their to-do lists.  Describe how those open slots have wider impact.
• “X and Y on my team are really strong, and I worked around our normal internal recruiting channel.  Can I walk you through what I did?  Connect you with the outside recruiter who found them?”
• Offer to review job descriptions, scan résumés, join interview rosters
• “Seems like you’ve been hiring for enthusiasm rather than product experience.  What about shifting criteria for this next hire?”
• “This is important to me.  How else can I help?”

MAKER TEAM MISSIONS AND WORK ASSIGNMENTS

IN SCOPE:  Product Directors often have the last word on how we assign broad parts of the product portfolio to maker teams.  In deep collaboration with our Engineering and Design peers.   Creating teams by audience (end user feature team, admin function team, security auditor capabilities) or user journey (trial sign-up, engagement, upsell to paid subscription) or architecture (APIs, shared infrastructure) or verticals (automotive vs. finance vs. education) or front end vs. back end will have a huge effect on product success. 

• “At a previous company, organizing development by industry resulted in a manufacturing version of our API and a banking version of our API and a healthcare version of our API and 6 others.  More to maintain, lost leverage, unhappy teams, plummeting productivity.  Unless there’s a really strong technical or design reason to go that way, I’ll go with another division of labor.”

Getting this wrong – or reshuffling teams every quarter – could sink the company. 

OUT OF SCOPE:  We product folks have lots of opinions about how makers should divide work within teams; about technical answers to technical problems; about kanban vs scrum vs. XP vs. SAFe versus roll-your-own-process; about engineering hiring criteria; about effective UX.  And we feel the pain when Engineering or Design is unhappy or apparently wasting effort.  But we don’t own those problems or manage those people.  We need be humble in offering advice:

• “Walk me through your thinking or analytics on this part of the sign-up workflow.  I’m not sure I understand how that will improve subscription rates.”
• “Aria is the SQL ace on the Reporting team, but could get promoted elsewhere.  Single point of failure.  Have you thought about pairing her with someone more junior or cross-training more of the team?”
• “One of the requirements we chose to ignore/set aside/postpone was X.  But it might rear its ugly head again. What would happen if we added that back?  Easy to address, or massive potential technical debt?”
• “I’m hearing that our old test harness is costing the team lots of time.  Thoughts on the time to replace it versus improved longer-term velocity?”

But Product opinions are just that.  We need to respect our partners’ expertise and let them make their calls.

SALES COMP PLANS

In the last four decades, I don’t think I’ve seen a product leader (other than a CEO) who owns the sales compensation plan.  Or a CRO/Sales VP looking to share that responsibility with Product.  So any PdM input on comp plans should be offered as advice from peers, for the broader good of the company.   Very much out of scope.  Two areas of likely cross-department friction, though, are selling very new products and allowing deep-dive customer discovery around not-yet-committed concepts.  Unpacking those:

Sales’ motivation to sell new products.  If an enterprise software company has strong revenue from existing products and very satisfied customers, there’s often little motivation for account teams to pitch some risky new offering that’s not perfect.  A still-evolving set of benefits, likely v1 shortcomings, no enthusiastic references yet, new tech and qualifiers to learn… sales teams that can reliably hit quota with battle-hardened products will often stop there.  But Product (and Engineering and Design and Marketing and Support…) may have spent years building the next great new thing.   And lectures from product managers about the importance of getting customers for the new widget don't hold much sway. 

So how might a product leader offer advice and counsel?  I try to leave the tech- and product-speak behind, and use the language of money. With Sales leadership, it’s all about upcoming quarters. 

• “We started building XYZ in 2023, with your agreement and Board approval, because we see current product revenue flattening in early 2025.  Sales and Finance projected $10M next year for XYZ and $25M the following year… which will fill a big hole.  But we need a dozen customers to buy and deploy it this year in order to build momentum and get the references your teams will need to hit that.  I understand your folks’ reluctance, and know that v1.0 is far from perfect.  But we’re all going to have to answer for the $3M/year R&D costs and meager top-line results.
  “A modest proposal: you change next quarter’s comp plan so that every team has to sell one unit of XYZ to hit 100%.  And I’ll organize the best deal support group we can for the first dozen accounts: product, technical support/implementation, engineering, product marketing.  T-shirts and internal PR for the reps who close the first four.  That should help meet quota in Q4 and next year.  Thoughts?”
• There are other members of the exec team to pull into a coalition on this.  Finance wants a 6x return (=$18M+) on our investment rather than a write-off.  Marketing has invested 2-3 quarters into new product campaigns, beta user stories, and Gartner briefings.  Support has trained ten people on the new tech.  The VP Engineering fears a talent exodus when teams realize their brilliance has been wasted.  The CEO wants good news for investors.  So I might (humbly, gently) rally more of the C-level around this.

Who talks with customers?  Account teams (quite rightly) remind us that they talk with their customers (buyers rather than users) more than anyone else in the company.  Sometimes they need a product manager on a call to share upcoming tech / walk through the roadmap / deposition the competition / help sort out use cases. 
At the same time, they are generally unexcited about the open-ended product-led discovery calls and technical deep dives that are essential to good product management.  We might expose shortcomings, uncover new issues, soften some marketing claims.  (How would your sales team react to asking a paying customer this:  “Our XYZ product doesn't currently include an API for generative AI.  We want to understand if this is important, what AI tools you’re playing with, whether/how you’ve thought about integrating those…”)  It only takes one bone-headed PdM to mess up one discovery call to have Sales demanding a stop to all discovery meetings.

So we can find ourselves at a bit of an impasse: Product believes that deep-dive discovery is essential — in scope.  And we (grudgingly) join sales calls even though they aren’t explicitly in our job descriptions — out of scope.   Important to support revenue and the greater good, but not the core of what we do.
Sales teams need help closing selected deals, so they expect product managers to make technical briefings a top priority — in scope for Product from Sales’ POV — even with no notice and full calendars.  But Sales typically assigns low value and high risk to validation and discovery (product/maker teams grilling users about potential problems and unmet technical needs) – out of scope for Product from Sales’ POV.  Opposing priorities.  Where you stand depends on where you sit. 

I‘ve worked this more as executive horse-trading than an argument about scope and roles and charters:

• “With 37 sales teams worldwide and only 6 product managers, we’re doing 12 customer briefings a week – with prep time, that’s almost a full product manager just supporting calls.  And getting poor-to-middling cooperation on our core work: digging deep to find out what customers (end users!) really need, instead of what C-level buyers think they need.
  “Let’s put these together.  We’ll do up to 4 customer briefings/roadmap reviews/pre-sales talks per week across the product group.  You (CRO/VP) can prioritize those, or we can do first-come-first-served.   In exchange, your teams will facilitate up to 4 discovery calls per week, with product-led agendas and the sales team on mute after making introductions.  I suspect your folks will quickly see that these are safe, and will prefer post-meeting summaries rather than listening to hours of technical discussion.  Waddaya say?”

Lots of gray area, which HR job descriptions and CEO escalations won’t solve. 

It’s worth examining our own motivations.  If I’m leaning in only because my product team needs something fixed/changed, I want to be straightforward about it.  (“When your group does X, it creates tons of extra work for my folks.  And demoralizes us.  And doesn’t encourage us to be helpful.”)  If something is out of scope but for benefit of another group or the whole company, I frame it for the greater good.  (“Approach A is high risk, and I’ve seen it fail elsewhere.  Absolutely your call, but have you thought about B or C?  Happy to share what I’ve seen.”)

Sound Byte

It’s important to recognize what each of us owns — the decisions we have final say about — and what’s nominally out of scope.  Then offer real advice and assistance when we think that will be valuable.  Not to score points or show that we’re smart, but to help our peers be more successful.