An essential role of CPOs and other product leaders that’s never listed in the job description is giving organizational 'air cover' to product managers to postpone almost all new requests — so that their teams can finish work already underway.  Lately, I’m calling this permission to stay focused.

Some context:

• The typical product manager (PdM) gets dozens of new requests and demands and ideas and suggestions and escalations and bug reports and customer complaints and ChatGPT-generated word salads each day.  A typical maker team* can finish a handful of small things each week, or chunks of one or two larger things.  So the ratio of wants/needs/demands/couldas/shouldas to actual development capacity is often 20x-50x.
  Said another way, this week’s new “must do” items look like a year’s worth of additions to the roadmap.  To do most of them, we’d need to violate the time-space continuum.
• But each requestor (naturally) sees their item as urgent, strategic, top priority.  They are coming off customer calls, strategy sessions, renewal discussions, marketing automation planning sessions, compliance reviews, and industry analyst briefings that highlight improvements that must be made.  Now.
• And PdMs tend to respond with process discussions: talking generically about sprints or backlogs or spreadsheets or the general need for discovery/validation.  This is deeply frustrating to stakeholders, who hear generic excuses not to fulfill their very reasonable requests.  The PdM equivalent of mansplaining.

Of course, your organization may look/behave very differently.  My focus is on B2B/enterprise companies where sales cycles are long; attributing revenue to individual product improvements is challenging; and a few large deals have visibility up to the Board.  It’s hard for product managers to throw themselves in the way of potential 6-figure revenue.

Crack the WIP

Agilists and systems thinkers call this the WIP/Work in Progress.  There’s a ton of real-world evidence that overloading a system or team delivers less total output, so starting more things means finishing fewer of them.  (Agilists state this in the positive: “start less, finish more.”)  Building software is a complex intellectual team exercise, not simply reading specs or typing.  Overloaded teams frantically thrash, hopping from one unfinished thing to the next, losing the detailed context that’s required to create good software.  But each requestor is sure that we have a little uncommitted capacity for their thing.  “How hard could it be?  Probably only 10 lines of code.”

That puts product managers in the awkward position of telling senior stakeholders and execs that they can’t (immediately) have the next new thing, that they can’t (immediately) get a yes/no answer about a ticket, and therefore can’t (immediately) get they truly want – an immediate commitment, including delivery date and sized effort, for one more apparently small item.

Product managers can sound silly, weak, or uncaring when they respond with “I don’t have time right now to look at your thing” or “you need to fill out this 5-page request form” or “we’re on a sprint model and don't interrupt the current week’s priorities for anything except P0/system-down failures.”   Senior stakeholders think “That’s a dumb excuse, this is urgent, I didn’t ask how to make a watch, and I outrank you!”  I’ve seen PdMs fall off the promotional ladder for less. 

That Doesn’t Sound Good

C-level product leaders need to constantly frame the larger strategic picture for other execs, providing organizational support for PdMs to say NO or LATER.  In my product leader courses, we talk through variations on C-suite messaging about urgent interrupts that use the language of money and high-level trade-offs:

• “We have a product strategy that the exec team has approved, and has shared with the Board.  We think our top 2-3 major R&D efforts will bring in £15-20M this year.  So let’s focus on new opportunities worth at least £5M.  Please pull me in on those.”
• “The CRO and I agreed that Sales gets one unplanned 'magic bullet' each quarter  – that will take no more than one engineer-week.  If you can convince her that this new feature will bring in more revenue than Sales’ other hot requests, I’ll personally get it evaluated and sized.”
• “Roadmap items X and Y specifically benefit your functional group, and were the ones that your directors prioritized as their top two.  Do you want to postpone/cancel those in favor of this?  Let’s check back with your folks.”
• “Interrupting the scalability team right now would mean that we can’t add new users in Q3.   That would put our entire revenue plan at risk.  (Customer queries are already maxing out our back end.)”
• “I agree: EU date formats and currency conversions would be a big help opening up opportunities in Central Europe.  Corporate strategy is focused on AsiaPac in 1H24, though, and that’s where our new Sales/ Marketing/ Implementation team is being hired.  Do we have the field staff to turn this feature into EU revenue?  (and how much?)”
• And sometimes…  “That’s a terrific idea!  Not sure how practical it is, but I love it!  Let’s get a couple of your best thinkers together with a couple of product/engineering leads for some brainstorming.  And a 5-minute revenue guesstimate.”

Notice that in each case, we’re talking about business priorities and the (eventual) money that our company might earn.  The corporate strategy, which the product strategy supports.  The hard trade-offs between segments or audiences.  The pain of walking back public/Board commitments. The existential threats that could cost all of us our jobs. 

As product leaders, we should be using the language of money with our peers – and coaching our PdMs on it. BTW it's likely that your company has its own local dialect and nuances for conversations about future revenue: so listen carefully and adapt your approach.

Why Is This Necessary?

Product managers often don’t feel comfortable (empowered) to say NO every few hours, especially with senior stakeholders.  So we fall back on process excuses descriptions and generic ‘out of capacity’ jargon. 
Also: many product teams are too far from the company’s economics: how do we make money?  How does my product fit into the larger revenue generation cycle?  What has/hasn’t worked before to drive sales or renewals or subscriptions or paid usage?  Can we tell a convincing story about money that highlights real trade-offs?

On the go-to-market (GTM) side, I see a lot of “roadmap amnesia.” Shiny new business opportunities and customer suggestions tend to wipe away the weekly (daily?) roadmap updates from Product.  Salespeople are paid to land the next new deal, not focus on the development queue – or remember technical commitments we made to close last quarter’s deal.
We need to reset our expectation that GTM will be fascinated by the minutiae of discovery, specs, tech debt, agile processes, internal code names (“Project Thor”), geographic failover, or performance metrics. Do you recall the last time you were stuck in a chat with a rabid golf fan, blockchain enthusiast, serious foodie, or political conspiracy pundit?

Sound Byte

As product leaders, then, we have to model the behavior and language that usefully frames product work and trade-offs for GTM folks.  We have to support our PdMs when they take strong positions.  We have to anticipate the friction between “I need it now” and “the roadmap is already overloaded through 2026.”  We have to give our teams permission to stay focused and the safety to make unpopular calls. And to help them recognize when there’s a very important reason to get distracted.

 ____________________________________________ 

* I use 'maker team' rather than 'development team' or 'engineering team' so that we include designers, DevOps, tech writers, test automation engineers, and other essential makers in our thinking.