Category: Articles

How IBM connected AI features to strategy, leading to $4.5B in annual savings

By Michael Goitein and Jenny Wanger

The existential question far too many product orgs are facing right now:

“What AI features should we ship?”

IBM asked a radically different question:

“Which of our capabilities could AI make dramatically better?”

Looking at itself as “Client Zero,” IBM’s answer generated $4.5 billion in annual savings, contributed $12.7 billion in free cash flow, and launched a new AI consulting product offering that continues to reap compounding benefits.

They stopped asking “what AI features should we ship” and instead asked, “which of our capabilities could AI make better?”

Capabilities, explained

Roger Martin’s Strategy Cascade is one of the most accessible strategy frameworks available. He outlines a set of five decisions that need to be made in order to have a fully-formed strategy. One of the core and most frequently misunderstood decisions is a component called capabilities.

Capabilities are integrated systems of people, processes, and technology explicitly chosen to deliver against a set of strategic choices. Think of them as the organizational muscles that let you execute your strategy.

AI has the potential to make these systems more powerful, more distinctive, and, with the appropriate feedback loops, continuously compound.

At IBM, they identified ways that service delivery could be enhanced with AI. Rather than shipping new features, they took the people and products they had and gave them easier access to IBM’s proprietary data, processes, and expertise.

They used AI to invest in their strategic capabilities. In the terms of Roger Martin’s strategy cascade, they used AI to build capabilities that doubled down on their “Where to Play” and “How to Win” choices.

Your ability to unlock AI’s full strategic value lies not in any single feature, but in creating an underlying system that continuously enhances capabilities. Those capabilities build compounding waves of competitive advantage.

The four types of AI-enhanced capabilities

As we see it, there are four types of capabilities that AI is best suited to enhance. Each addresses a distinct human limitation. As you layer your capabilities, you start to move more effectively than your competition, which creates a durable competitive advantage.

Speed

AI helps you do something you already do, but much more quickly. Examples include:

• Writing PRDs and product briefs
• Code completion

Speed provides the least durable advantage because you’re still doing the same work – something competitors could match by adding headcount or building the prompts themselves. But working on speed helps you invest in other capabilities later, opening up more opportunities.

Consistency

We’re human and frequently drop the ball. AI never does – and never resents doing the same thing repeatedly. Like speed, consistency is where AI helps you do something you already know how to do, but ensures you do it every time. Examples include:

• Drafting meeting notes
• Writing documentation with every code update
• Updating the CRM after every customer call

Consistency similarly provides limited durable value because it operates within your current paradigm. Consistency can drive early savings in your strategy, again freeing up brainpower for deeper enhancements later.

Scale

Scale is where AI starts to unlock real competitive advantages. AI allows us to do things at volumes humans can never match – and find patterns in that volume that humans would miss. Examples include:

• Monitoring all network traffic for anomalies

• Tagging and pattern-matching based on every customer support ticket

Scale increases value because volume reveals patterns that smaller samples would miss. This is where you start seeing inputs into your strategy system that you hadn’t otherwise.

Skill

AI’s most intriguing opportunities lie in creating capabilities that otherwise wouldn’t exist across the organization. This compounds when you translate skills from one group to another. Examples include:

• Creating agents that do code review so product managers can push code that works well with the rest of the architecture.
• Building an editor that mimics the brand voice so anybody can draft marketing copy.
• Publishing a product strategy tool so anybody can suggest a new feature idea and get help refining it into something worth building.

Skill is where the most compounding value comes from. You’re enabling people to do things with fewer dependencies and greater consistency. The more AI-driven skill augmentation, the more time they have to keep investing in capabilities later on.

The most lasting value comes when you cross categories. If you can provide a skill that’s also executed with great consistency and surfaces insights across the organization at scale, you’ve built capabilities that uniquely enable your strategy.

One note across all four: don’t automate a broken process. AI can make a bureaucratic headache faster, but it’s still a headache. Before you scale anything, take a moment to rethink and strengthen what you’re enhancing.

Customers probably won’t see most of these directly. The capabilities layer focuses on internal operations – making what you already do more effective.

The more you build AI capabilities that enhance your Where to Play and How to Win, the stronger your flywheel becomes.

What makes AI capabilities compound

The most powerful way to get capabilities to unlock this flywheel is through combining different types together in a way that supports your strategy.

“Have great AI capabilities” is not a strategy. It becomes strategy when you choose particular capabilities that reinforce your “Where to Play” and “How to Win” choices.

Disconnected AI features create noise. Integrated AI capabilities create flywheel effects that exponentially increase your strategy’s effectiveness as the capabilities strengthen.

By investing in your internal capabilities, it improves operational efficiency in your key strategic areas. This allows more time to be spent on differentiated activities, which leads to more customer value being delivered in the product. You can take those savings or additional customer value that you created and reinvest it back in internal capabilities, which starts the flywheel over again.

No matter what type of capability you’re developing, you want a clear through-line to how it strengthens your strategy.

IBM decided to use AI to tackle basic HR processes. The results exceeded their expectations as they automated 94% of HR inquiries, freed up 3.9 million employee hours, and amassed $4.5 billion in annual savings. And of course, IVM cells.

This connected back to their strategy, which included reducing bureaucratic overhead across 340,000 employees. Reducing turnover has been a core goal of theirs for years, and it’s easy to understand how too much red tape makes people want to leave.

This investment will compound. Lower turnover means current employees increase in value. A more effective workforce can invest in improving themselves.

This flywheel unlocked customer value: internal capabilities compounded first, and when they were strong enough, they became the product itself.

How IBM turned internal capabilities into an advantage

Here’s another example of how IBM leaned into their “Where to Play” and “How to Win” through capabilities:

They created bots to answer internal support questions. This meant that employees were getting immediate answers for 70% of their inquiries. They could then serve clients faster, solve problems more quickly, and it showed with a 25-point increase in CSAT and $165 million in savings. They are now taking that extra time and money and reinvesting it in solving new problems or finding other areas to improve service delivery.

But those results in turn created two additional, even greater benefits. The savings IBM achieved allowed it to fund continued AI investment. Even more importantly, IBM was able to “productize” and resell those same capabilities, creating similar savings for clients. The internal transformation became IBM’s most credible sales proof point, with over 1,000 “Client Zero” client engagements in 2025 alone.

Even if they had never sold these AI-enhanced capabilities to customers, delivering this level of measurable AI benefits internally would still be a differentiating strategy and a strong move for them against consulting rivals.

The fact that they were able to turn around and sell them, on top of the powerful inward transformation made it a stacking set of wins.

On IBM’s Q2 2025 earnings call, CEO Arvind Krishna told investors how AI capabilities had given the company “guidance and confidence… about reimagining and reinventing how we run our company.”

AI-enhanced capabilities exist to execute your strategy

There’s massive value to the AI work no one outside your company sees.

Competitors can screenshot and match your customer-facing AI features within a quarter. Internal AI capabilities, layered across speed, consistency, scale, and skill, show up differently, with faster decisions, cleaner data, fewer dropped balls, and more capacity per person.

The first kind generates press coverage. The second kind generates margin.

IBM didn’t sell its AI capabilities to clients first.

It slowly built its AI internally for two years, watched what happened, adjusted, and only then turned the capability outward as a service offering. By the time its productized version hit the market, IBM could already confidently tell the story, having raked in $4.5 billion in internal savings. That internal use was the credential, allowing them to scale these same skills outward.

Clients couldn’t wait to get some of what IBM had already done for itself.

Capability advantages that compound are the ones customers can’t clearly name, only feel through steadier experiences, quicker resolutions, and account managers who somehow have the time to actually pay attention.

The AI underneath remains invisible. That’s the version competitors can’t copy, because by the time they figure out what you’re doing, you’ve already built the next layer on top

Building AI automations that make you better, not just faster

In a coaching last week, I bit my tongue. I was about to dive into solutions, but instead I said, “How does that change how you see yourself?”

That question opened up some real reflection in the conversation. And it’s a question that I don’t think I would have asked six months ago. I have AI to thank for it. And no, I wasn’t parroting an AI copilot.

As a coach, it’s tough to get real feedback on how I’m doing. My clients are not there to grow me; I’m there to grow them.

The reason I was able to stay in that moment of identity instead of moving out into tactics and solutions was because of the constant feedback I’ve been getting.

After each coaching call, I get a personal message from my workflow tool, walking me through things I did well and things I could improve upon in the future. It also conveniently drafts the follow-up email to the client and walks through potential LinkedIn post ideas that I could use for my social media (not disclosing client discussions, but highlighting things I mention).

Building this feedback loop has changed my behavior in the room.

As product people, we’re constantly having high-stakes conversations— user interviews, 1:1s with direct reports, stakeholder negotiations— yet feedback on how we showed up rarely comes, or arrives weeks later in a performance review. That gap in self-awareness used to be unavoidable. Now we can have the luxury of continuous, near-instant feedback.

If you’ve been using AI for one-off tasks but haven’t built automated workflows yet, you’re leaving a lot on the table. Here’s what I’ve learned so you don’t have to figure it out from scratch.

Deliberate practice in the age of AI

Deliberate practice, a framework coined by Anders Ericsson, is one of the most effective ways to build skill. It has four core components:

• Targeted tasks: choosing something specific to work on
• Immediate feedback: the ability to correct as soon as possible
• Effortful focus: being in your stretch zone, neither too easy nor too hard
• Repetition with refinement: each time you practice, you’re making targeted adjustments

The hardest part has always been immediate feedback — it usually requires someone with more expertise to provide an outside perspective on how to improve. Historically, this meant hiring a skills-oriented coach.

AI lets us automate that coach. Immediate feedback is now accessible to anyone willing to build the workflow. It may not be as amazing as the feedback you’d get from a real human coach, but it’s far better than nothing at all.

To make deliberate practice real, you need workflows that trigger themselves and deliver the same feedback every time—reliably, cheaply, and without you having to push a button.

When a workflow tool is the right choice

So what exactly is a workflow management tool? (and if you’re familiar with them, skip to the next section)

It’s a tool that allows you to say, “When this thing happens, then do these other things.” The other actions it can take might be AI-driven or they might be programmatic and deterministic.

They’re lighter weight than building out an app to do something and more persistent than asking an AI chat as a one-off. They run when you’re sleeping, they run when you’re not at your computer, and without needing an extra machine like OpenClaw. They have clear limits on what they can do, so won’t go rogue on you.

The persistence and boundaries matter more than you’d think. For a workflow to actually change your behavior, it needs to run consistently — every time, without you remembering to trigger it.

I use Relay.app* for my workflow management tool because it integrates easily with my existing stack. It handles AI steps cleanly, I don’t have to do too much setup of memory, and it’s really easy to iterate.

Other tools in this space include Zapier, Make, n8n, or Workato. Each has different integrations, setup complexity, and pricing.

There are plenty of great articles that help you choose a workflow management tool, so I’m not going to dig into it here. And while I will be sharing examples of how I’ve set up Relay, these could translate equally well to any of these other tools.

Disclosure: I’m a Relay affiliate, but I have been using this tool for years, well before I became an affiliate, and you should choose whichever platform best meets your needs.

Enabling the four components of deliberate practice

Use AI sparingly. Use deterministic workflows aggressively.

Deliberate practice demands consistency—you need feedback every time you perform the task and confidence that the feedback is oriented towards your goals. A workflow that behaves differently every time or costs too much won’t solve this problem.

As product managers, we know that a simple solution always beats a complicated one. Deterministic steps are simpler and more reliable than AI steps. Design your AI workflows to use as many deterministic steps as possible first, and only lean on the AI once those hit their limits.

If you lean on AI too much, you end up with prompts that say “Do tasks one, two, and three”. It ends up spending a lot of tokens and the outputs will be variable.

Instead, think about how you can feed AI stronger context and ask less of it. This saves you tokens and makes sure that your AI is actually completing the task at hand.

• Use deterministic steps for:
  • moving data
  • calling APIs
  • known logic
• Use AI for:
  • classification
  • synthesis
  • generation

For example: I wanted every CRM profile to have a LinkedIn URL attached. My assistant’s first draft asked Claude to web-search for each person’s profile—hundreds of tokens per run. We swapped it for a built-in LinkedIn API lookup that matches on search results. Under 20 tokens.

From there, deterministic steps handle the CRM lookup and upload. No AI required. Where do we have AI jump in? Populating the CRM with the types of topics they like to talk about, gleaned from their public posts.

The best workflow is the one that actually runs. Deterministic steps make that far more likely.

The feedback should be continuously improving

The fourth component of deliberate practice is “repetition with refinement”—each iteration should be slightly better than the last. This applies not just to what you’re practicing, but to the feedback itself. Your coaching prompt should evolve as you identify which habits matter most.

To improve the feedback I’m getting, I make sure to keep a version log of the AI prompts I use.

In practice, this means I never put the prompts directly in the tool. Instead, I store them in a third-party platform and have the tool look up the prompt. This allows me to quickly iterate, keep track of versions, and make sure that my AI is actually improving over time.

When I kept the prompt in the tool instead, I ended up duplicating the prompt across workflows, which meant keeping track of more versions. I then made an edit. The output got worse, and I couldn’t figure out how to undo.

For instance, I have a style guide that I use to make sure the AI can write like me. All of my writing workflows refer to this single guide. If I kept the prompt in the workflow itself, I’d have to manage it in multiple places.

By having it in Coda and clearly versioned, I can track and edit my writing guide in one place and know it will be updated everywhere. I can then track when prompts work, when they fail, and what changes actually improved them.

My coaching feedback prompt has evolved significantly since I first wrote it. As I refined it, I got clearer on which habits matter most—staying in the moment, asking identity questions, resisting the urge to jump to tactics. I’ve customized the prompt to make sure that I’m getting high-quality feedback unique to my goals.

This also touches on the deliberate practice pillar of targeted tasks. I’m not trying to become a better generic coach. I’m trying to become the best coach I am uniquely suited to become.

Know your Job To Be Done, singular

Deliberate practice requires choosing something specific to work on. A mega-workflow that handles everything is like a product doing too many things at the same time. It can do it, but it’s hard to stay focused and make sure you’re really hitting the most important goal.

Each workflow needs a clear job to be done. My coaching feedback workflow has one job: provide me personalized feedback after every call to help me improve my craft.

If you don’t have a clear job to be done, you end up with a mega-workflow that’s unwieldy. I started with a single post-meeting follow-up workflow. It managed meeting notes, LinkedIn posts, coaching feedback, client follow-ups, and a few other administrative tasks. It became a mess — lots of conditional logic about when to run one thing versus another and how to handle edge cases.

I had lost track of the job to be done.

I recently refactored it into several separate workflows:

• a marketing workflow
• a coaching workflow
• an administrative workflow

Though the trigger was the same (a meeting ending), each workflow needed different context and had a different purpose. Separating them made each one easier to manage and improved the outputs.

The coaching workflow was about growth; the administrative one was about efficiency. Bundling them meant I kept optimizing for speed when I should have been optimizing for insight.

Efficiency jobs and growth jobs are best kept separate. Drafting follow-up emails is an efficiency job — it saves me time. Getting feedback on my coaching is a growth job — it makes me better. When they’re tangled together, I have more trouble staying focused on the real value the workflow is giving me.

Let the tool build the workflow so you can focus on what matters

Effortful focus means operating in your stretch zone—working on the hard thing, not the tedious thing. Building workflow logic step-by-step is tedious. Designing what feedback you need and how to structure your practice is the actual work.

As these tools have advanced, they’ve added AI builders directly into the workflow tool itself. You can now vibe code your workflows.

Treat the builder prompt like a product brief: state the goal, key context, and constraints, then let the tool draft the steps. Its success or failure becomes your immediate feedback loop on the brief—and keeps your effort on the hard thinking, not the wiring.

I’ve started doing this with Relay, and it’s far better and faster at designing workflows than I am. I use it to iterate quickly on edge cases and architecture instead of hand-building logic blocks.

Because building is faster, I’ve been able to add far more workflows focused on growth — not just efficiency. Workflows I never would have built if I had to construct them step by step.

Start with the feedback you wish you had

If you’re looking to use workflows not just to move faster, but to actually get better at your craft, think about the areas where you need immediate feedback. As a PM, perhaps you’re working on your executive presence or user interviews.

For me, hiring a coach to review my coaching calls would mean a few calls reviewed every so often — hardly immediate or consistent. That’s why I targeted this as one of my core workflows.

I have similar workflows for sales calls and one that reviews my LinkedIn post performance. These are all feedback loops that wouldn’t have been cost-effective without AI.

The feedback compounds. As I’ve gotten better at staying in the moment during coaching calls, I’ve started getting feedback about new areas to grow — areas that weren’t visible until I’d improved the basics. I can now update my prompts to talk about where I’m at and where I’m trying to go next. That’s how deliberate practice works: each level unlocks another.

The more we invest in our craft, the closer we get to becoming the product manager they always dreamed of — the elusive PM who can actually do it all.

More automation frees up our time. More immediate feedback makes us better at using the time we invest. We don’t need more workflows creating slop, we need workflows that help us get better at our craft.

How to fix a low-trust relationship across an ocean

I frequently end up working with clients who have a team based offshore, often in India. And somehow, there’s frequently a feeling of frustration and disappointment when working with them due to a general sense of a lack of communication.

What this lack of communication exactly was changed across each client. But I kept running into a variant the same frustrating dynamic:

• Agreement in meetings, but missed delivery
• Low visibility into what’s actually happening
• Difficulty getting proactive input
• Frustration from the US team

While I haven’t been responsible for fixing this dynamic with any of my clients, I’ve wanted to be better able to advise them on how to turn this dynamic around. So instead of making up some advice, I went ahead and interviewed six different people who have managed to turn this type of situation around.

It’s easy to blame culture. But the fixes are about trust.

There absolutely is a difference in cultures between India and the US, just like any two locations. The cultural differences showed up in many of my interviews.

But one thing I realized as I was having these conversations is that the advice I was hearing wasn’t primarily about navigating cultural differences. It was the same advice that I would give when talking about creating successful async work environments.

Every strong relationship and every productive relationship has a strong layer of trust underneath it.

One of the patterns I was seeing with the contractor teams is that the US-based teams I’ve been working with assumed trust was there, as opposed to thinking about how to constantly re-establish trust.

Cultural awareness helps you understand why trust might be missing—but the interventions that actually worked were about building trust and creating structure. These are the same levers you’d pull for any distributed team starting from a low-trust place.

And the way to fix these relationships was not to just say, “Hey, this is what I need from you” and ask for it more loudly, but instead to change the environment, the communication infrastructure, and the incentives to lead to a behavior change.

The disconnect goes both ways

In the most recent case, we got lucky. A member of our product team was headed to India to visit family, so we extended his trip to meet with the offshore team in person.

The biggest insight from that trip: the India team was feeling the exact same frustration we were.

They described the US side as a black box. Tickets got thrown over the wall with little context. Communication happened sporadically. They wanted to do good work but didn’t have what they needed to succeed.

This reframed everything. We had been thinking “how do we fix them?” when the real question was “how do we fix this relationship?” The trust deficit ran in both directions.

The US team assumed the India team didn’t care about our goals. The India team assumed the US team didn’t care about them. Both assumptions were wrong—and both were creating the exact behavior that confirmed the other side’s suspicions.

Once we understood this, our interventions changed. We stopped trying to enforce behavior through process and started investing in connection. The results came faster than any of us expected.

If you’re struggling with an offshore team, it’s worth asking: what does this relationship look like from their side? The answer might surprise you—and it might reveal that you’re contributing to the problem more than you realized.

The decision guide: Match the symptom to the intervention

While there are many different variants of not having the right level of trust with offshore contractors, I would say that there were three key symptoms that I saw emerging from both my own experience and the interviews I was conducting.

Choose your interventions based on the behavior patterns you’re seeing. One thing that there was consensus around was layering in interventions to become more effective.

Radio silence: You get finished work only

One pattern that I run into is where work is happening and tickets are being completed, but there’s a black hole effect. Between when the work starts and the work ends, there isn’t a strong sense of what is happening or what choices are being made.

When trust is lacking, sharing insecurities, questions, and uncertainty can feel like admitting incompetence. So much of the fix here is creating psychological safety—making it clear that sharing work in progress is expected and that there won’t be negative consequences for asking too many questions.

Start with standups and chit-chat. As challenging as it is given the time zones, 15 minutes of verbal communication every day goes a long way. As Jason Meresman said, “Not having the daily standup is the same as saying I’m not going to take any corrective action.”

One piece of feedback we got from the team in India was that they felt like they didn’t know much about us. When there were meetings, we would jump immediately into the work.

Standups give you 15 minutes each day not only to talk about work but to get a little bit of a sense of each other’s lives. What you ate for dinner or what your weekend plans are.

Those little moments of interaction help build trust between people who have never met face to face. We assumed the trust was already there instead of building it.

Move decisions into shared channels. One thing we saw: a lot of conversations were happening via DM or on the contractor’s internal Slack channel. No wonder it felt like radio silence.

Conversations, even if they don’t involve everybody on the team, need to happen somewhere where the whole team can see them. It’s important to model how decisions should get made and what good communication looks like.

We asked the teams to move conversations into public channels so that there was a sense of chatter within our workspace, and did the same on our end.

Both of these interventions work because they create repeated, low-stakes opportunities to build familiarity. Trust accumulates through dozens of small interactions where nothing goes wrong.

The waiting game: No action without explicit direction

Another pattern I’ve seen is when the team waits for direction. If you don’t tell them exactly what to do, nothing happens. If it’s not documented precisely in Jira, it doesn’t get done. When they run into roadblocks, nobody flags them.

This pattern almost always emerges from an environment where they’ve been criticized for taking initiative. There’s an expectation that they were hired to output code, not for their technical thinking—so they wait for direction instead of acting independently.

Double down on business context. Through our product manager’s research in India, we found out that nobody had walked the current team through the product strategy, user base, or how the various components fit together. That onboarding had been done years ago with different people—there had been turnover since then.

We took the time to walk everybody through who our users were, how they used the product, and how it fit into the overall business. The team was thrilled to get this context.

Without context, the team can’t take initiative—they’d just be guessing. Sharing business context signals: “We trust you with this information, and we expect you to use it.”

Treat the team operationally like internal staff. The more you can treat your contractors like employees, the better. Darin Swanson used this approach explicitly: “The company decided they weren’t employees—but in every other facet, we asked how we could treat them like employees. That drove pretty much every decision.”

If you want them to take ownership, treat them like owners. Darin even ran performance reviews with contractors on the same cadence as full-time developers.

Model the behavior you want to see. If the goal is to shift from a world where every ticket needs to be fully explained to one where they ask questions proactively, modeling goes a long way.

Lee Almegard made a practice of publicly asking for help and flagging when she was stuck. As she put it: “I was trying to ask for help in public as an example to them—to show it’s safe to ask questions and to flag that you’re stuck.” She would tag others on the team, and they would jump in, demonstrating that asking for help doesn’t lead to punishment or embarrassment.

It took time, but the more she did it, the more comfortable others felt doing the same.

For people to take ownership, you have to treat them like owners. You can’t just tell them that’s the behavior you want—you need to include them in the work the same as anyone else. Every time you exclude them from context or decisions, you’re reinforcing that they’re outsiders who need permission to act.

The cold shoulder: Everything just feels extra hard

In other contexts, the relationship with a contract team has just felt tense and awkward. There’s no single word for it, but it feels like there’s no openness. Things are moving along, but everything is a little bit painful.

This might be the line between a lack of trust and active mistrust. There are almost certainly skeletons in the closet—whether from working with your company or other overseas clients where they got burned badly. They’ve learned it’s best to keep their heads down and just do the job.

Reset working agreements. Sometimes it’s healthy to sit down and talk about how you actually want to work together. Bring both teams into the room and decide what good looks like—rather than deciding unilaterally how things should work.

Roger Marley has used this approach to great success: “We do a show and tell of honest frustrations of what we felt from the other side, on the basis that we’re going to do a trade. You’ve had this difficulty with us—we’re going to give you this. And then you’re going to do the same thing for us. That starts to reduce the distance between the two.”

The emphasis is on making it an equal partnership when everybody comes into the room. By saying the mistrust out loud, you create a structured way to rebuild rather than pretending the problems don’t exist.

Use a neutral intermediary if needed. Sometimes there’s so little trust that contractors feel uncomfortable raising any issues while a leader is in the room. In that case, it can help to designate someone they see as a peer—someone who can have one-on-one or small group conversations to collect feedback and relay it to leadership.

Ryan Alexander described his approach: “The main thing I did was act as a surrogate communicator who could say no. That was what they needed—someone who could push back.” He positioned himself as an advocate who could translate their “soft yeses” into actual pushback, since doing so directly felt culturally unsafe to them.

Over time, the neutral intermediary can build relationships that encourage people to speak up in more public forums. The more that happens, the less tense the relationship feels overall.

By sending our product manager to India, we accidentally did this. The team saw him as a peer instead of a leader and so could have more honest conversations.

If things feel really tense and awkward, the trust deficit is likely severe. That needs to be addressed before anything else can be fixed.

What has never worked for me

A narrative had been circulating at my client: if only we could provide more detailed tickets, better-explained PRDs, a RACI, and ask for more Slack communication, this would all be solved.

Talking with the developers one-on-one showed just how wrong this was.

More detailed documentation, more pressure, more asking for things—none of it changes behavior on its own. It’s easy to believe that since there’s a client-vendor relationship we can just ask for what we want and get it immediately. But that type of relationship doesn’t buy you teammates.

If you’re hearing demands for contract partners to behave differently in your own organization, it’s a sign to pause and focus instead on interpersonal connections and shared context. Those are the things that actually move the needle.

What I do differently now

I had a kick-off call with a few developers for a new initiative this week. I prepared the epic and created a workflow chart to show them what the user journey needed to be.

I started with small talk—asked about one developer’s recent PTO. Then I explained not just the initiative, but why it mattered for our users. When they offered to build a POC, I pushed back: could we collaborate on an architecture diagram first?

“We’re used to being given the architecture, not being asked to design it,” one of them said. I could tell he was excited about the shift.

In one call, I’d hit several of the patterns from this article: small talk to build connection, business context so they understood why the work mattered, and treating them like owners by asking them to design rather than just execute.

Notice what I didn’t do: I didn’t ask them to communicate differently. I didn’t send a document explaining “how we work here.” I didn’t lecture them about proactive communication.

I just treated them like I’d treat any team I wanted to build trust with.

Culture and time zones will always make offshore relationships harder. But the playbook for fixing them isn’t some special cross-cultural toolkit. It’s the same work you’d do with any distributed team starting from a low-trust place: show up consistently, share context generously, and treat people like partners instead of vendors.

The gap isn’t cultural. It’s relational. And relational gaps close the same way everywhere—one interaction at a time.

How to escape work that shouldn’t be yours in the first place

I’m a solo product ops manager supporting 14 PMs across several product lines. Half my time goes to triaging support tickets that escalate to product—I’ve automated what I can and cut volume from 300/month to 80, but the remaining tickets require deep product knowledge and nuance.

The other half of my time gets split across too many initiatives: rolling out opportunity solution trees, enabling our new product management tool, tracking OKRs, coordinating metrics, fielding questions from every team in the company. I can build processes and training, but with my attention scattered, nothing gets the focus it needs to actually stick.

I know there’s higher-leverage work I should be doing. Strategic improvements that would reduce those tickets in the first place. Process changes that would actually get adopted if I had time to build proper buy-in. But I can’t get to any of it because I’m constantly reacting to whatever’s on fire today.

How do I break out of the reactive cycle when the reactive work genuinely needs to get done?

—Buried in Tickets

Dear Buried in Tickets,

You already know what your highest-leverage work is. You can see it clearly. You also know that you can’t get to that high-leverage work while ticket triage is in the way.

The problem isn’t insight about what you should do—it’s permission. Even though it’s uncomfortable to say no, it’s time.

The reactive cycle you’re stuck in is a symptom of lacking organizational permission to focus. Without that permission, you’ll stay trapped between initiatives, never able to get any of them to a truly healthy place where they don’t need constant maintenance. You’ll keep building processes nobody follows, because you don’t have time to build the buy-in that makes processes stick.

Meanwhile, your leadership will get frustrated (if they haven’t already) that the things they hired you for aren’t progressing. You need to make sure that your leadership is aware that there is a focus issue, and then get permission to actually solve it.

The way out isn’t to work harder or hope leadership notices you’re overwhelmed. The way out is to bring it to their attention so you can drop some things on your plate and return to them later.

Here’s how.

Track your time and do the math

Before you can ask for permission to focus, you need evidence.

This week, spend five minutes at the end of each day logging where your time went. Don’t overthink the categories: Tickets; Meetings; Fielding questions; Roadmapping program; Opportunity-Solution Tree Buildout; etc.

At the end of the week, do the math. Let’s walk through what yours will look like:

Start with 40 hours. Subtract the meetings that have to happen regardless—let’s call that 10 hours. You’re down to 30. Half of that goes to tickets. Remove 5 hours for general answering questions, eating, and task switching. Now you’ve got 10 hours for everything else: opportunity solution trees, tool enablement, OKRs, metrics, answering questions from every team in the company.

Split 10 hours across four or five initiatives and you’ve got maybe 2-3 hours per week on each one. That’s not enough time to make real progress on anything. It’s certainly not enough to build the buy-in that makes change stick.

This math is your evidence. When you bring it to leadership, you’re not saying “I feel overwhelmed.” You’re saying “here’s why none of these initiatives are getting traction — I have 2 hours a week to spend on each of them.” 

Write down your strategy

Your evidence gets you a discussion about time management. A strategy gets you permission.

You can’t ask leadership to deprioritize things without offering an alternative. “I’m overwhelmed” isn’t a strategy. “Here’s what I’d focus on, why it matters, and how I’d make time for it” is.

You can’t get product ops work done in short bursts. Product ops work is almost always about building systems that require adoption: Rolling out opportunity solution trees; Getting PMs to actually use the new tool; Making OKR tracking consistent. 

Those initiatives won’t succeed if you aren’t actually changing behavior. Behavior change won’t happen in 2-hour weekly increments. You need sustained attention to build the buy-in and iteration cycles that make processes actually stick.

Ticket triage isn’t helping change behavior—it’s support work that happens to require product knowledge. The fact that it landed on your plate doesn’t mean it belongs there.

Start by identifying what you believe is your highest-leverage problem. Write down why you think it’s the most important thing you could work on—and what outcomes you’d expect if you had real time to focus on it.

Escaping the tickets

Then comes the hard part: your strategy has to include how you’ll escape the ticket trap. This work ended up on your plate because someone needed to do it—but “someone needed to do it” isn’t the same as “this is product ops work.” Without solving that, any plan for “higher-leverage work” is wishful thinking.

There are a few ways to approach getting tickets off of your plate:

Automate yourself out. You’ve already cut ticket volume from 300 to 80. What would it take to cut another 50%? Maybe you spend four to six weeks focused exclusively on building a solution to reduce inbound ticket volume to under 10 a week. The goal would be to get ticket time from 50% of your week to 10%—then you’ve got real capacity for transformation work.

Find another home for triage. You mentioned the remaining tickets require deep product knowledge. But just because you have that knowledge, should it be your job? At one company I worked with, QA handled triage on escalated tickets. They had capacity, they knew expected behavior, and they could determine whether something was a bug, a configuration issue, or expected functionality.

Tickets don’t have to flow through you—and frankly, they shouldn’t. Your 14 PMs and the teams they’re on have product knowledge too.

Reduce the volume coming in. This is the boldest option. What if you only took tickets from customers above a certain revenue threshold? Or paused ticket intake entirely for four weeks while you focused on strategic work? The reactive work feels essential, but it’s worth asking: what would actually break if you weren’t doing it? This experiment might also help the organization get a sense of how important these tickets actually are.

Once you’re clear on how to escape the tickets, put all of this in a document. Your highest-leverage problem. Your plan for escaping the ticket trap. What you need from leadership to make it happen.

A strategy that lives in your head won’t be able to convince everybody that a new direction is needed. A strategy that is written down can be circulated, debated, and approved.

Get organizational buy-in

Once you’ve got your strategy written down, treat it as a conversation starter.

Before you bring it to your EVP, think through who else needs to be on board. If your plan involves QA taking over ticket triage, you need the QA lead bought in. If it means changing how support escalates issues, you need support in the loop.

For each person you need to influence, ask yourself: What are their incentives? What’s in it for them? What do they need from you to say yes?

Your QA lead might be worried about capacity. Your support manager might be relieved to have clearer escalation paths. Your EVP might just want to know that the transformation work they hired you for will actually get done. Understand what each person cares about, and frame your chat with them accordingly.

Then circulate the document. Don’t just present it in a meeting and ask for approval. Send it ahead. Let people read it, poke holes in it, ask questions. Their pushback makes the strategy stronger and helps them invest in your mission. Their questions reveal gaps you hadn’t considered.

By the time you’re asking for formal approval, the people who matter should already understand what you’re proposing and why. The meeting becomes a confirmation, not a pitch.

When the answer is no

Sometimes you do everything right—data, strategy, buy-in conversations—and leadership still says no. 

This is information. Understanding that they’re happy with the status quo means you’ve got buy-in for your split attention approach today, which is confirmation you didn’t have previously. 

Even so, there might be space to improve your current workload. A few paths forward:

Make the tradeoffs explicit. If leadership won’t let you deprioritize the tickets, ask them to choose what gets your time. “I have 10 hours a week for these five initiatives. Which one or two should I focus on?” This forces them to own their contribution to the challenges you’re facing.

Shrink your ask. Maybe a six-week focus sprint is too big. Can you get two weeks? A clear timeboxing on tickets to 5 hours per week? Sometimes a small win creates the opening for bigger ones later.

Accept the signal. Some organizations don’t actually want transformation work right now. They want someone to keep the plates spinning. That’s a legitimate choice, even if it’s disappointing. If the role you were hired to do isn’t the role they need filled, that’s worth knowing sooner rather than later.

The goal is to get clarity on what’s actually possible so you can make informed decisions about where to invest your energy. Any progress on this is better than no progress.

One win at a time

You probably won’t get everything in your strategy approved. Leadership has competing priorities, and your ask is one of many.

But you’ll likely get at least one win. Maybe it’s permission to focus exclusively on reducing ticket volume for six weeks. Maybe it’s agreement that QA should handle first-line triage. Maybe it’s just taking OKR tracking off your plate for now.

That one win matters more than it seems. It buys you space to actually make progress on something. This is the start of the strategy flywheel. 

More importantly, it builds trust. You made a specific ask. You delivered results. You demonstrated that you can prioritize and execute. Leadership now knows you’re not just complaining about being overwhelmed, but actually trying to do something about it.

That trust becomes leverage for your next ask. And the ask after that. Perhaps at some point they’ll even realize that one product ops person supporting a 14-person team isn’t the right ratio for the amount of change they’re trying to lead.

Over time, you’re not just earning permission to focus on one thing. You’re establishing yourself as someone who thinks strategically about where to invest their time—which is exactly the kind of thinking product ops should be modeling for the rest of the organization.

The reactive cycle won’t break itself. But with data, a strategy, and one win at a time, you can break out of it.

One document that helps you find the right coach and get budget for it

A product leader wanted to get coaching approved as her role grew in scope from managing a single product to owning more of the post-sales workflow. Her CEO was supportive of professional development but hesitant to invest without understanding what they’d get from it.

She approached it like a product manager. She sent the CEO a two-page document that outlined exactly what she was struggling with, what success would look like in concrete terms, and how she’d measure progress. Almost a PRD.

The document showed she understood her gaps, had done her homework on what kind of coaching relationship would work, and could articulate why investing in coaching would help her be more effective as she scaled her product responsibilities.

A short while later, she had CEO approval and found a coach who specialized in post-sales product work.

Six months into working with that coach, she reached out to me. The coaching had helped her navigate the GTM workflow challenge, and now she was facing a different set of problems as she shifted from managing a single product line to managing a portfolio. She needed to update her coaching focus and realized that she could use a different coach now.

She sent me her updated CRD—the same document she’d used to get initial CEO approval, now revised to reflect her new challenges. I could immediately understand exactly what kind of support she needed and how to work together.

What struck me wasn’t just that she got approval twice. It was that her document transformed coaching from a “nice to have” perk into a scoped development initiative with clear outcomes. She knew what she needed, could articulate why it mattered to the business, and as a result, got the investment she needed.

From the coach’s perspective, it helped me make sure I was always helping her towards those outcomes.

Why most coaching searches fail before they start

This product leader’s success wasn’t luck. She avoided the trap that catches most people who want coaching.

Most leaders never get to the point of evaluating coaches at all. The conversation usually goes like this: a product leader tells their manager “I want a coach.” The manager asks what they want to work on. The answer is vague – “leadership skills” or “becoming more strategic.” Without clear outcomes or success criteria, there’s no way to justify the investment.

Coaching gets framed as personal development, something nice to have but not essential to the business. When budgets tighten, it’s the first thing cut.

The difference in the story above? She had a document that did two things at once: got budget approval and helped her find the right coach match quickly.

When people ask me for advice on how to hire a great coach, I ask if they’ve written their CRD – their Coaching Requirements Document – yet.

Most haven’t. And that’s often why their coaching search stalls out before it even begins.

What a Coaching Requirements Document is (and isn’t)

The CRD flips this dynamic. Instead of “I want a coach,” you’re presenting “Here’s the development problem I’m facing, the outcomes we’re targeting, and how we’ll measure success.” You’ve translated coaching from a personal perk into a scoped development initiative with business outcomes.

A CRD is a one or two page client-authored document, similar to how product managers write PRDs before building features. Just like we don’t go picking solutions before we figure out what the user problem is, we shouldn’t go interviewing coaches until we have clarity about what we need from one.

What it is:

• A written articulation of what you want to work on, how you want to work, and what success looks like right now.
• A snapshot in time, meant to evolve.
• A document that serves double duty: helping you find the right coach AND making the case for budget approval.

What it’s not:

• A guarantee of fit.
• A permanent requirements doc.
• A way to optimize for speed or price-shopping.

If you’re thinking “I’ve never had a coach before – how do I know what to ask for?” – that’s exactly why writing the CRD is valuable. The process of articulating your needs forces you to think through what you’re actually trying to achieve. You don’t need to get it perfect. You need to get it clear enough to start the conversation.

The core sections of a CRD

If you’re looking for some good questions to answer, this list from Natalie Rothfels that was posted on Adam Fishman’s newsletter is a great starting point.

Here are the sections I recommend, along with guidance on how to think through each one:

1. Context & Current Reality What’s your role, team size, and company stage? What constraints and pressures are you facing? Most importantly: what’s triggering the desire for a coach now? Something changed – a new role, a team expansion, feedback you received, a challenge you’re stuck on. Name it.
2. What “Good” Would Look Like in 6–12 Months This is where many people get stuck because it feels abstract. Make it concrete: What would your manager notice is different? What would your team notice? What decisions would you be making more confidently? Think about observable changes in behavior, decision-making, or outcomes – not just feelings.
3. What You Think You Need Help With A brief bullet point list of challenges you’ve been running into recently. Don’t overthink this – you might be wrong about what you actually need, and a good coach will help you refine it. But your initial hypothesis matters because it signals to potential coaches whether they have relevant experience.
4. Business Impact How does solving this development gap connect to company priorities? If you become more effective in the areas you’ve identified, what becomes possible for the business? This is where you translate personal development into business value. Examples: “Better stakeholder management means we can ship features 2 weeks faster because we’re not stuck in approval cycles” or “Clearer product strategy helps the team prioritize better, reducing wasted engineering time.”
5. Preferred Coaching Relationship (Initial Hypothesis) Do you want someone who gives you direct advice, or someone who asks questions to help you find your own answers? How frequently do you want to meet? Do you want someone who pushes back hard, or someone who’s more supportive? If you’ve never had a coach, make your best guess – you can always adjust.
6. Constraints & Non-Goals What you don’t want, timing limits, org realities. Be honest here. If you can only meet during certain hours, say so. If there are topics that are off-limits, name them. If you’re trying to solve a specific problem and don’t want general leadership coaching, make that clear.
7. Open Questions & Uncertainty Explicit acknowledgment of what might change. This section gives you permission to evolve. Maybe you think you need help with stakeholder management, but you suspect the real issue is something deeper. Say that. Coaches appreciate honesty about uncertainty – it helps them understand how to approach the relationship.

To help you out, I made a customGPT to help you draft your document. share it with your leadership to make your case, and then share it with potential coaches to make sure that they’re going to be a good fit. You can download an example here.

Why this document works (for finding fit AND getting budget)

For coach selection: Not every coach is the same. We all bring different approaches, philosophies, experience, and styles. I lean more towards product operations and thinking through how to structure and enable your team. Other coaches might focus on communication styles, developing strategy, or managing across a broad portfolio of products.

The CRD makes non-fit show up early in the process instead of several months in, after you’ve already committed. It allows coaches to select in and out honestly. When the product leader first reached out to me, I could immediately see from her document that I wasn’t the right fit for what she needed at that moment. Six months later, when her needs had shifted, the fit was clear.

For budget approval: The CRD transforms the conversation from “can we afford this?” to “can we afford not to invest in solving this problem?” You’ve demonstrated intentionality and readiness. You’ve created a shared artifact that your manager and HR can review together. You’ve made it easy for them to say yes.

One document, two critical problems solved.

The CRD helps you figure out if coaching is the right solution

You can write your CRD even before you start looking at specific coaches. In fact, that’s often the best time to do it. The clarity you gain from articulating your needs will make every conversation with potential coaches more productive.

When clients approach me without a CRD, we spend our first session writing it together. It’s the foundation that makes every session after more valuable. We get aligned on what we’re actually trying to solve, what success looks like, and whether I’m even the right coach for this phase of their development.

And as your context shifts—a new role, a major confidence jump, a change in organizational priorities—your CRD should evolve too. It’s a living document that reflects where you are right now, not where you were six months ago.

The goal of writing a CRD isn’t to find a coach faster. It’s to invest wisely – sometimes later, sometimes differently, sometimes not at all until the real need becomes clear.

Write your CRD now, even if you’re not ready for coaching

The real value of a CRD isn’t just getting coaching approved. It’s creating a framework for thinking about your professional development needs on an ongoing basis.

By writing down what you’re struggling with, what good looks like, and what kind of support you need, you gain clarity. You start to see patterns in where you need help. And more importantly, you can evaluate whether coaching is actually the right solution.

Once you’ve articulated your development gaps, ask yourself:

• Can my manager help with this? If you need context on company strategy or decision-making frameworks specific to your organization, your manager might be the best resource. No coach can replace that institutional knowledge.
• Can peers help with this? If you’re figuring out how to navigate a common challenge (like running effective roadmap reviews or managing up), other product leaders in your company or network might have already solved it. A peer mentorship or roundtable might be more valuable than formal coaching.
• Am I trying to understand myself and my leadership patterns better? If you’re working through challenges your manager hasn’t faced, or need confidential support your peers can’t provide, or want to accelerate development in ways your organization can’t support—that’s when coaching makes sense.

The CRD helps you be honest about which of these you actually need. Sometimes the answer is “all three, for different things.” That’s fine. The exercise forces you to stop treating professional development as a vague aspiration and start treating it as a concrete problem you can solve.

Take an hour this week. Answer the six questions in the framework above. You might end up with a document to get coaching approved. Or you might realize you need to have a different conversation with your manager about development opportunities. Or you might identify three peers you should be learning from.

Any of those outcomes moves you forward. The worst outcome is staying stuck because you haven’t articulated what you actually need.

How AI breaks flow, fragments attention, and quietly changes how product teams think

Monday morning I sat down to write about AI-induced distraction. Then, while waiting for ChatGPT to finish a response to a proposed outline, I checked Slack. Next response? My phone. By the time the output appeared, I’d forgotten the critique I wanted to make.

It can happen to me two to three times an hour. Some detours last five minutes. Across a workday, I estimate I lose an hour or more to context-switching—not because I lack discipline, but because AI’s variable latency creates 10-second gaps my brain can’t ignore.

I’m not alone. When AI takes 10 seconds, 30 seconds, or two minutes to respond, the herky-jerky rhythm invites distraction. The problem isn’t individual willpower—it’s a mismatch between how the tools behave and what humans can actually sustain.

And if I’m not the only one having this problem, then it isn’t a matter of me becoming more focused or mindful or present, but actually that there’s a structural issue here around how we work with AI. The way AI is currently designed encourages us to lose focus and flow. This has influence not only on our own individual productivity but on how we function on product teams more broadly.

Why “just focus harder” doesn’t work

The common prescription is mindfulness: stay present, resist distraction, build better habits. But that misses the structural problem.

At this point, we all know the struggles of waiting for AI to respond. It’s variable. Sometimes we get an immediate response, and sometimes we’re waiting for a minute or two for it to run. And we never know how long it’s going to be.

There’s a long-standing body of UX research on how long humans are willing to wait for the computer to get back to them. “It’s incredibly taxing to stay focused and alert in the absence of activity, but users can keep their attention on the goal for about 10 seconds.”

As one commenter shared on Reddit: 

Whatever you choose to do in that couple of minutes of waiting, is something that breaks the flow. It takes time to go back to what you were dealing with and it’s so frustrating. Can’t have a single hour of focus since vibecoding started. –aleciak9669

After 10 seconds, attention drifts. It’s not a character flaw, it’s just how we’re wired. AI’s variable latency creates dozens of these micro-gaps daily. Willpower isn’t the solution; better structure is.

So we’ve got a conflict between how our tools are behaving with us and what we can actually do with them with regards to mental stamina.

How people cope while waiting (the modalities)

I asked around to see how people handle AI waits. The strategies fell into clear patterns—some effective, most not.

Broadly, everything falls into two categories:

1. More mindfulness
2. Multitasking, multi-threading

On a typical day, I get distracted from my AI two to three times an hour; some of those detours stretch five minutes or more. Across a full workday, I worry that adds up to roughly an hour lost to context switching instead of staying with the thread while I wait.

Here’s what people reported trying on Reddit, Hacker News, and Lenny’s Community:

Parallelization: “I vibe code multiple projects at once and rotate between them.” — thehen. Others on Slack mentioned starting another prompt or opening a different AI tool while waiting.

Micro-task switching: “I often end up spending 5–10 minutes on YouTube while waiting.” Others mentioned catching themselves checking Slack or email during short pauses. This is the bucket I fall into most often.

Scenario priming: “I use AI to plan my next prompt as it’s executing the last prompt.” — Happy_Acanthisitta92.

Embodied reset: Lenny’s community members mentioned standing up, stretching, or grabbing water to avoid sitting there getting irritated.

Mindful waiting: TackyFish shared “a slightly philosophical take on this – what’s actually wrong with sitting idle for those moments? This mindset may save time in real. [sic] Since you don’t fragment attention, you don’t lose the thread, and you engage with the response immediately and more thoughtfully.”

Tool orchestration: “Email is a better interface for long-running AI tasks than chat.” — Rahul Gupta-Waksal. Sometimes it’s better to not be explicitly waiting for the AI to finish typing, but instead change the interaction overall.

Each of us needs to figure out which modalities of waiting work better for our own brains. There is nothing wrong with any of these options. Underlying all of this is a broader conversation about how we view the necessity to be productive with every minute of every day and whether that’s actually healthy or productive.

But until the tools provide us with a more comfortable interaction that allows us to feel like we really are in an active conversation with another thinking partner, we are all going to have to figure out how we deal with these moments of waiting.

I now decide upfront: will I plan the next prompt, set a notification for longer tasks, or take a physical break? Having a default prevents drifting to Slack on autopilot. It’s not about perfect focus—it’s about giving your attention somewhere productive to sit while AI thinks.

Why this is a leadership problem

Individual distraction compounds into team-level costs. When everyone’s reasoning happens in private AI chats, then gets disrupted by micro-switches, product teams end up with:

• Thinner meetings: People half-listen while prompting in parallel. Decisions get vague agreement, not real alignment.
• Degraded reasoning: When I’m coming back to a topic after context switching, I find it harder to really read the AI output in enough detail to thoroughly think it through.
• Invisible work: Leaders can’t tell if silence means thinking or distraction. Engagement becomes hard to read.

The leader’s job is not to police focus. Our job is to coach people through a new form of cognitive load that fragments both individual thought and shared understanding.

How leaders can manage the distraction

As an operations person, my instinct is to build systems and tooling to handle fragmented attention. But the tools aren’t there yet, and as long as AI usage remains largely individual, this isn’t really an ops problem to solve.

Here’s what I’ve come to realize: for now, this is a coaching challenge, not a tooling one. Especially when working remotely, we need to shift how we interpret team behavior and watch for specific red flags.

Silence doesn’t mean thinking anymore

Silence used to signal reflection, processing, or careful consideration. When we’re working with AI, silence increasingly means attention has gone elsewhere.

In meetings, silence might mean someone is prompting AI in parallel, waiting on output, or already context-switched away. The danger isn’t the multitasking itself—it’s misreading engagement. You think everyone’s aligned when they’re only half-listening. Decisions get made without everyone actually processing them together.

Meetings start to feel thinner: fewer strong reactions, more vague agreement, less productive disagreement. People are physically present but cognitively split. The meeting still happens, but the shared cognitive moment is weaker.

Speed isn’t the same as good reasoning

When AI outputs arrive quickly and continuously, it’s easy to mistake speed for efficiency. But when attention is fragmented—jumping between AI and other work—the quality of thought quietly drops.

AI outputs get skimmed rather than interrogated. Subtle caveats get missed. Earlier assumptions fade as conversations stretch across hours. You end up responding to whatever AI just said rather than thinking through a coherent strategy. You’re moving fast, but you’ve stopped thinking deeply.

This is particularly risky because AI responses sound confident and complete. Errors are plausible rather than obvious. The burden of critical thinking shifts more heavily onto humans.

The cost shows up later: decisions that feel “off” but are hard to diagnose, missed implications no one can trace back, a nagging sense that something important slipped through. Without real attention, speed can make shallow thinking worse just as easily as it boosts productivity.

Name it, don’t normalize it silently

As team leads, we need to make sure people are thinking through this problem and handling it well. We can support them—and get better at it ourselves.

In your next 1:1, ask whether waiting for AI breaks their focus. Acknowledge that this is genuinely hard. Share your own struggle briefly and compare strategies without judgment.

This is time management coaching for the AI age. It can’t be a “you should stay focused” lecture. Approach it with empathy. This is hard for all of us—not something to feel shame about, but something worth working on together.

Start with intention, not willpower

Writing this article took twenty minutes longer than it should have. I got distracted while waiting for AI responses, but also just because my brain does that. When Slack messages come in from client work, I chase the shiny distraction rather than stay focused.

But thinking deliberately about this challenge has helped. I realized I’d been defaulting to distraction—messages, tasks, my phone, whatever was closest.

Now I set an intention before I start any AI conversation. Which modality do I want to spend the next hour in? Will I plan the next prompt while this one runs? Set a notification for longer tasks? Take a physical break?

Having a default prevents drifting to Slack on autopilot. It’s not about perfect focus—it’s about giving your attention somewhere productive to sit while AI thinks.

This is also where to start when coaching your team. Don’t expect willpower to overcome structural problems. Help people recognize the pattern, name their default distraction, and choose a better one.

Some values can only shift through lived experience

I spent a month in Barcelona, and I couldn’t stop fighting the schedule.

Breakfast is small. Lunch happens around 2pm and might stretch two hours. Dinner at 9pm is perfectly normal—restaurants stay packed until 11. The whole city operates on this rhythm, sleeping past sunrise and staying up late into the night.

I can physically do all of this. My body is capable of eating dinner at 9pm. But emotionally, I’m in rebellion. Every morning I wake up around 8, then don’t get out of the house until 10 or 11 after getting the kids ready. The shutters stay closed, the rooms stay dark, and I feel like I’m wasting the day before it even starts.

Here’s what I realized: my resistance isn’t about logistics. It’s about a core belief. I believe daylight is precious. Maybe it’s from past bouts of winter blues, maybe it’s American productivity culture, maybe I just love sunshine. But when I’m not up with the sun, something feels fundamentally wrong.

The Spanish schedule expresses different values—quality time with others, communal meals, building relationships. Neither set of values is “wrong.” But knowing that doesn’t help. I still can’t relax into it.

But my resistance wasn’t just about conflicting values. Even if I’d wanted to adopt the Spanish approach, I couldn’t have. Here’s why: I was essentially a tourist in Barcelona. I didn’t have a community there. To truly understand the value of a two-hour meal with friends, you need friends to share it with. To appreciate staying up until midnight talking, you need people worth staying up for. The Spanish cultural values around connection and community? I never had the context to experience what made them valuable in the first place.

I couldn’t think my way into understanding—I would have needed to live my way into it. And without the social infrastructure that makes those values meaningful, no amount of intellectual understanding would help me adapt.

This is exactly what happens when we try to change product culture.

We introduce a new process. People can technically follow it. But they fight it anyway—not because they can’t adapt, but because we’re asking them to change what they believe, not just what they do. And until we address those beliefs, the change won’t stick.

The same pattern shows up in product management

The same pattern shows up in our work lives. Early in my PM career, a lead engineer taught me that every ticket I write is a contract. Any ambiguity or confusion wasn’t the engineer’s problem – it meant I hadn’t been clear enough. I came to believe that my core responsibility as a PM was to provide perfect clarity and control every detail.

Years later, at a different company, I was spending hours writing exhaustive tickets when an engineer suggested a different approach. He wanted the engineering team to take the lead on tickets while I spent more time talking to customers. A more collaborative model where we’d figure out details together.

I said I’d try it. I could physically do it – nothing stopped me from writing shorter tickets. But emotionally? I was in rebellion. After a few days, I had what felt like an allergic reaction. Just like those Barcelona mornings, I felt like I was doing something fundamentally wrong. I was still going back to expand and edit the engineers’ tickets, creating more work for everyone.

The engineer was asking me to trust that collaboration would create clarity. But I’d never experienced that version of product management. I had no evidence that his approach could protect what I valued. Just like with Barcelona – I couldn’t adopt values I’d never experienced in action.

I brought an underlying belief – that ambiguous tickets meant I was failing as a PM. He was asking me to value collaboration and shared understanding over my need for control and clarity. Neither value is wrong, but until that belief shifted, I couldn’t change how I worked.

Culture is downstream of beliefs—and some beliefs require experience

Culture isn’t just “we do things this way.” It’s “we do things this way because we believe this matters.” And some beliefs can only shift when you’re embedded in the conditions that make them meaningful. You can’t think your way into them – you have to live your way into them.

In Barcelona, I valued daylight. Spaniards valued connection. Neither is wrong—but they lead to completely different daily rhythms. In my PM role, I valued clarity and control. The engineer valued collaboration and shared ownership. Again, neither is wrong—but they produce incompatible ways of working.

The behaviors we see are downstream of beliefs we often don’t articulate. And you can’t durably change the behavior without shifting the belief.

What this means for product transformation

This is why product transformation is so hard. You’re not just asking people to follow a new process—you’re asking them to believe different things about what good work looks like.

When someone resists a change you’re introducing, the instinct is to push harder or explain better. But if the resistance is rooted in values, more explanation won’t help. They’re not confused about what you’re asking. They’re protecting something they believe matters.

The next time you hit a wall of resistance, pause before assuming it’s a process problem. Ask yourself: what value is this person protecting? Until you address that, the behavior won’t change—or it will change temporarily and snap back the moment pressure lets up.

How to shift values: a three-step approach

When you’re hitting resistance, you need to work at the level of beliefs, not just behaviors. This requires a progression—each step building on the last.

First: Surface the protected value

In my ticket story, the engineer asked me to change my behavior without understanding what I was protecting. He saw inefficiency; I saw the only way I knew to be a good PM.

What if he’d asked: “What are you worried will happen if we write shorter tickets?” That question would have surfaced my real concern—that ambiguity meant failure. From there, we could have explored how collaboration might actually reduce ambiguity, not increase it.

Before pushing a process change, ask people what they’re afraid of losing. Not “what’s your concern with this new process” (which invites logistical objections), but “what feels at risk if we do this?” Once you understand the protected value, you can show how the new approach serves that same concern differently.

This step is necessary, but it’s not always sufficient. Sometimes awareness alone can shift behavior—people realize their fear is unfounded, or they see how the new approach protects what they value. But often, surfacing the belief reveals a deeper problem: the person has never experienced what would make the new way of working feel safe or valuable.

Then: Recognize when experiential conditions are missing

Some values can’t be argued into existence. Before moving to implementation, ask yourself: Has this person ever experienced what makes this new approach valuable?

In my ticket example, I’d never experienced collaborative product management done well. I had no evidence that lighter documentation could work. The engineer was asking me to trust something I’d never seen succeed.

This is the critical diagnostic moment. If someone hasn’t experienced the value you’re asking them to adopt, they’re missing the prerequisite for change. You can’t skip this step—you have to build it.

Finally: Build the experiential conditions

I couldn’t embrace Spanish dining culture from the outside. Reading about the value of two-hour meals didn’t help. To understand why late dinners matter, I needed friends worth staying up for. The value only makes sense inside the experience.

The same is true for product transformation. Running a three-day experiment with skeptical participants won’t reveal the value of a new way of working. Trying shared ticket ownership with an engineer you barely know isn’t the same as doing it for three months with a tight-knit team.

The distinction matters: attending one Spanish dinner ≠ having friends worth staying up for. A pilot project ≠ being embedded in a thriving practice. When values require lived experience, you need sustained exposure to the conditions that make them meaningful, not brief exposure to the mechanics.

When introducing a significant change, ask yourself: Have we built the conditions for people to actually experience what makes this valuable? If the answer is no, the pilot will fail—not because the change is wrong, but because the context isn’t there to make it work.

Context isn’t optional for culture change

I never adapted to the Barcelona schedule. Even on my last day, I woke up feeling like I was wasting daylight (and my son fell asleep at the dinner table that night). But this wasn’t a failure of understanding or effort—it was proof of the thesis. I was missing the prerequisite for that culture change. Without a community there, no amount of intellectual appreciation for Spanish values would help me adopt them. Context isn’t optional when you’re trying to shift deeply held beliefs.

This is what makes organizational culture change so difficult. We often ask people to adopt new values without building the conditions that would make those values meaningful. We run workshops, write memos, and explain the “why” behind changes. But if people haven’t experienced what makes the new way valuable, they’re working without the foundation they need.

The next time someone on your team resists a change, don’t just push harder or explain better. Ask what they’re protecting. Then ask whether they’ve experienced what they might gain. And most critically, ask yourself: have we built the conditions—the relationships, the safety, the sustained practice—that would let them experience it?

Culture change requires more than understanding. It requires living it. And that means creating the context where new values can take root.

Six minutes into my INDUSTRY keynote, my dangle earring started banging into my microphone. Nobody in the audience could hear it, but every time I turned my head – clank.

Without stopping, I reached up, slid both earrings out, dropped them into my pocket, and kept talking.

After the talk, I found out one person out of the hundreds in the audience noticed that I touched my head.

I’m a theater kid – I know how to keep the show going when things break. But in the past, I would have spent the rest of the talk slightly rattled, and afterwards I would have fixated on the hiccup. Did anyone notice? Did it throw off my timing? Was that the moment where I lost them?

This time, I handled it and moved on. Not just externally – internally. I knew it was nothing. A speck. My delivery stayed smooth because I wasn’t carrying the weight of it.

That moment captures my 2025 vibe better than any metric I could share.

A year ago, I wasn’t sure this business was sustainable. I was hustling, hoping things would click, performing confidence while quietly anxious about whether any of it would last. This year was different. I felt like I belonged on that stage.

Finding Fit

For this reflection last year, I predicted that 2025 would be the “year of scale,” driven by course growth. It wasn’t. Reforge focused on different live courses, so my product ops program didn’t run. Maven became fill-in work between consulting gigs, not the third leg of my business I’d hoped for. I shut down the Product Ops Jobs Board.

Scale didn’t happen. But something better did: I finally started getting traction on my own product-market fit.

The big shift was positioning. I stopped selling “product operations consulting.”

People don’t wake up thinking “I have a product ops problem.” They think: “Product and engineering are at each other’s throats.” Or: “My PMs don’t have time for discovery.” Or: “GTM communications are a mess and launches keep getting botched.”

So I started leading with their problems instead of my methodology. Scaling product teams. Improving product/engineering relationships. Creating space for discovery. Fixing cross-team and GTM communication.

The work itself is landing in my sweet spot: operational challenges that tie directly to product strategy. Not just “fix our process” but “help us execute on this strategic shift.”

Revenue up 50%. Coaching went from one or two clients at a time to an average of four or five, consistently.

Why did this year work when previous years didn’t? Focus. Even when I wrote last year’s strategy, I knew courses didn’t quite align with my core work. I pursued them anyway because teaching made me happy. Classic product management mistake – too much work in progress. The less I spread my attention, the better my business got.

Fit isn’t permanent. I know it can slip away if I stop paying attention. But this year, I got to experience what it feels like when the work coming in matches the work where I deliver real value.

Un-branding the newsletter

For two years I called this newsletter “The Next Iteration” and tried to build it into its own thing – a brand separate from me. This year I dropped the name. It’s just my newsletter now. (You’ll see new visual branding soon) 

That small change reflects the same lesson as everything else: stop trying to make things into something they’re not. This newsletter is me sharing what I’m learning. It doesn’t need a separate identity any more than my consulting does.

The funny thing? Once I stopped actively trying to grow it, growth came anyway – subscriber count up 66% this year. A Reddit thread where someone recommended me brought in 250+ subscribers in a week. Events I ran to promote courses (even when enrollment flopped) turned into audience growth on their own.

To everyone who joined this year: thank you for trusting me with a line in your inbox.

My top articles

I run a survey for all new newsletter subscribers asking what challenges you’re facing. The 2025 answers clustered around a few themes: strategic focus, AI integration, prioritization, and team communication.

Luckily, I was able to keep a strong writing cadence going this year. Here are the articles I wrote this year (plus a few top ones from years past) that speak directly to those struggles.

1. Gaining strategic clarity and focus

Many of you described drowning in requests that don’t move the needle, or chasing “AI all the things” without a real strategy underneath.

• Execution won’t stop. Strategy will — My INDUSTRY keynote on escaping the execution hamster wheel.
• The Product Ops Strategy Stack — How to connect high-level vision to daily work.
• What to do when your manager doesn’t have a strategy — They probably do. Here’s how to pull it out of their head.
• The uncomfortable truth about saying no — If you don’t say no, you don’t have a strategy. You have a wish list.

2. Mastering AI integration

AI came up constantly—how to actually use it, where to draw lines, and how to implement it when you’ve got data restrictions.

• Becoming the product manager they dreamed of — AI might finally let us meet those impossible PM expectations.
• Why your brain is the biggest bottleneck in AI — The cognitive biases making “free” AI expensive.
• What AI can’t—and shouldn’t—do — Where I draw the line (spoiler: it shouldn’t do your user research).

3. Improving prioritization and making trade-offs

Prioritization pain showed up in different flavors: scope creep, drowning in customer requests, struggling to say no.

• Stop scoring everything — Filter ideas with strategy before you waste time on RICE scores.
• Everything you need to know to run a premortem — Prioritize risks before they become surprises.

4. Enhancing communication and team alignment

Friction between teams. Dependencies that slow everything down. Portfolios with 150+ products and no clear ownership.

• RACI charts are stifling collaboration — Why I refuse to make them and what to do instead.
• Stop talking about your impact. Spotlight theirs. — Build alignment by celebrating others, not yourself.
• Leading Through Layoff Fear — How to redirect anxious energy back toward impact.

5. Building business cases and driving outcomes

Using data to make decisions, pitching to leadership, building stories that land.

• The business case spectrum — Right-size your analysis to get the next “yes.”
• Building business cases leadership can’t ignore — Financial analysis meets strategic storytelling.
• Beyond release management: Feature flags for product discovery — Use flags to validate demand early, not just manage releases.
• Your competitors are telling you their strategy — What pricing pages reveal about strategic bets.

Writing was one of the things that worked this year. Courses were not.

I didn’t find scale in courses

I love teaching courses. I believe firmly in interactive pedagogy – if you can get all the value from a recording, then I shouldn’t be teaching it live. The magic happens when participants are doing things, getting feedback, learning from each other. That’s when real learning sticks.

But this belief creates a business model problem.

Interactive courses don’t scale easily. The value comes from my feedback, which means I can only have so many people in each cohort. Scheduling is hard when everyone needs to attend together. Budgets for professional development are tight. And the number one predictor of course enrollment? The size of your existing audience – which, for a niche-within-a-niche like product ops, limits the addressable market.

So when Reforge shifted toward larger courses and my product ops program didn’t run, I wasn’t surprised. I hit the same wall trying to fill my Maven courses.

The hard truth: courses aren’t becoming the third leg of my business anytime soon. Scaling them back – I’m still not ready to say “drop” – opened space for finding fit this year. But I’d be lying if I said it doesn’t sting. Teaching is one of my favorite things to do.

The jobs board solved the wrong problem

Not everything found fit this year. I shut down the Product Ops Jobs Board.

I launched it in late 2023 to connect product ops job seekers with hiring managers. The idea seemed obvious – job seekers needed visibility, hiring managers needed qualified candidates. I offered it as a free service.

263 job seekers signed up over two years. But hiring managers? Almost no traction. When I reached out, I heard the same thing repeatedly: they were already inundated with resumes. Their problem wasn’t finding more candidates – it was sorting through the ones they already had.

I was solving the wrong side of the problem. Classic product lesson, applied to my own business.

Shutting it down felt like I was abandoning the jobseekers, but keeping it running wasn’t helping anyone. Sometimes fit means recognizing what isn’t working and letting it go.

Getting fit (pun intended)

I always take a moment in these end-of-year reflections to share a little bit of life outside of work.

I started powerlifting this year. It began as physical therapy for chronic back problems, but turns out it’s also just something that feels good and is fun. My neighbor across the street has a little gym setup in their garage, and I make use of it about once a week.

That neighbor gym is part of something bigger. We’ve built real community on our street – happy hours and brunches almost every month, rotating who hosts. My kids will run across the street and ring doorbells for playdates. It sounds small, but having a group of friends who just come by to say hi because they see you outside has changed how I experience daily life.

When you work for yourself, from home, the risk of isolation is real. Local community has become my antidote.

What’s next

I want to deepen my impact in 2026 – help more people than I can reach through my current business models (but maybe not courses). I don’t know what that looks like yet. A year ago, that uncertainty would have made me anxious.

But here’s what I’ve learned: I can’t figure out “what’s next” while running at full capacity. Discovery requires space, and the only way I can find even stronger fit is through focus. I found fit this year by letting go of things I loved. I’m not going to find the next level by cramming my calendar full again.

So I’m leaving room…for something. Protecting space to think. Trusting that the clarity will come – the same way I trusted, six minutes into that keynote, that a loose earring wasn’t going to derail anything that mattered.

A practical path for turning strategy into something that works

You’re trapped in the execution loop. No time to work on strategy. No clarity coming from leadership either. Just shipping, reacting, shipping again.

“If only I had more time for strategy.”

But here’s what I’ve learned working with product teams: most don’t have a strategy problem—they have a communication problem. When others don’t have clarity on your strategy, you end up spending time validating their ideas and following their strategies instead of your own. You can’t say no because you haven’t given them a clear yes to something else. The way out isn’t finding time for strategy. It’s using whatever strategy you have—even if it’s incomplete—to stop the time leaks.

In this talk from INDUSTRY 2025, I walk through the Strategy Flywheel and the six techniques that help product teams reclaim time, make sharper decisions, and create momentum instead of chaos. If you’ve ever felt like your team is “getting a lot done… but not moving forward,” this will land.

Want this for your team? I’m bringing this talk to companies as both a keynote or a hands-on workshop where we apply the Strategy Flywheel to your actual work. Get in touch if you’re interested.

Here’s the full recording.

Since you’re on my mailing list already, you can also access the supplemental materials directly. 

---

It takes a village

This talk came together because a lot of people shaped it—through critique, encouragement, expertise, and the kind of generosity that makes work like this possible.

Tami R. — helped me shift from platitudes to real stories, which changed the entire arc of the talk.
Kelle S. — asked the exact questions that forced clarity and stronger reasoning.
Curran S. — ensured the delivery resonated, not just the ideas on the slides.
Anne L. — provided steady support and made me feel like I had a real team behind this.
My alumni product chat thread — a constant source of wisdom, pattern-spotting, and honest perspective.
Jon H. — brought the design to life and made the visual story match the strength of the ideas.
RLS feedback team — gave candid reactions at the moments I needed them most.
Rachel W. — helped me find my voice and land the storytelling choices that mattered.
Holly V. — the quiet, steady encouragement in the background that made it possible to keep going.
Matt K. — sat through all of my stress, all the drafts, all the run-throughs—essentially the entire emotional lifecycle of this talk.
Olivia V. — the key on-the-ground partner who handled logistics so everything could run smoothly.
Carlo C. — my behind-the-scenes engine, making sure every freebie, handout, and detail was ready for showtime.
Diana S. — pushed me to sharpen my spiky point of view and articulate what made this talk distinctly mine.

If something clicks, or if you think I’m completely wrong about something, tell me. I don’t want this to be a framework that lives without getting tested by reality.

How to build a culture of recognition that quietly amplifies your own reputation.

My client turned to me and said, “I feel the only way to show my value is to take on more work.”

She was feeling stressed out about whether or not she was getting appropriately recognized for her contributions and the amount of things she had been doing. But, as with many product ops roles (and many product leadership roles), the work she was doing was really behind the scenes.

“I don’t want to just talk about the things that I’ve done successfully in my one-on-ones. That doesn’t seem like a good use of time, and talking about myself feels a bit gross.”

This is a core tension that I have had to grapple with as well: How do I promote and make sure that I’m bringing attention to the good work I’m doing while not feeling like I’m bragging or being too salesman-y? How do I navigate the political landscape of my workplace without becoming overly political?

The technique that I’ve developed over the years is not to look at it as self-promotion, but instead to reframe it into playing my part in creating a culture of recognition.

Here’s the important bit: building recognition isn’t charity — it’s the most credible form of self-advocacy, because the story centers on outcomes and shared wins, not on you.

Others need to know you’re doing good work

By focusing on outcomes and shared wins, you’re doing self-advocacy right. If you don’t advocate for yourself, nobody else is going to. Your manager might do a bit, but at the end of the day, if they don’t have a clear enough idea of what you’re doing and why it’s making them look good, they can’t be a big advocate for you.

If product operation work goes well, we help the product team avoid a last-minute scramble. But it’s hard to point at the fires that didn’t happen and say, “Look at the ROI of this thing that didn’t happen.”

Therefore, we need to become really good self-advocates. And to do it in a way that still feels authentic.

One of the advantages we have in Product Ops is we’re seeing so much of the work that others are doing and their work touches ours as well. By creating a culture of recognition and spending time highlighting the work that others are doing, we can tie it back to the work that we’re doing and the value we’re adding.

Become really good at highlighting the work of others as a strategy to quietly bring attention to the work that you’re doing yourself.

How to make others look great

Making others look great is a skill. It’s not “this person is awesome” spam — it’s specific, verifiable, and tied to outcomes.

Try this micro‑pattern:

• Name the person and the behavior: “Anna split the rollout into two phases.”
• State the effect with a metric or observation: “Bug reports dropped 18% in week one.”
• Connect to the system or goal: “That phased rollout is exactly what our launch checklist was designed to enable.”

A quick example: “Shoutout to Anna for phasing onboarding — splitting activation steps cut first‑week bug reports by 18%. Leo’s QA checklist made the switch painless, and the phased plan came straight out of our launch playbook. Nice teamwork.”

Do:

• Be concrete (behavior + outcome + system link).
• Attribute broadly (peers, manager, cross‑func partners).
• Move the win where it matters (thread, standup, or an upward note when it ladders to leadership goals).
• Connect it quietly to the work you’ve been doing.

Don’t:

• Praise without an outcome (“great job!”).
• Center yourself (“my framework…”).
• Let wins stall in Slack; close the loop upward when they support strategic goals.

This sets up the next move: turning specific, outcome‑linked praise into a message that travels to the right altitude.

Books on Gratitude

There’s lots of good information out there about how important gratitude can be in career development. A few of my favorites:

• Wild Courage, Jenny Wood
• Give to Grow, Mo Bunell
• Give and Take, Adam Grant

Share Wins That Travel Upward

You aren’t trying to shout about your own work; you want to make sure the right wins reach the right altitude — especially the ones that ladder directly into leadership goals.

When a project you’ve supported succeeds, don’t just celebrate it with the team. Close the loop upward. I learned this technique first from Jenny Wood, who included it in her book Wild Courage.

As she says: “Cheering every win means assigning credit liberally wherever it belongs, highlighting your team’s accomplishments.”

Let’s say you recently built a new reporting framework to make it easier for product managers to pull their own data and access insights without writing SQL queries.

A few weeks later, one of the PMs you support, Marco, sends you a message:

“That new dashboard saved us hours this week — we finally have the data we need without having to ping analytics.”

Priya is your skip-level leader — the VP of Product, who’s responsible for the broader strategic goal of improving product insight velocity across the organization.

This is your moment to craft a short message to Priya and cc your manager:

Hey Priya — wanted to share a quick win. Marco’s team just finished their first sprint using the new reporting framework, and it’s already saving about two hours a week per PM. My manager gave me great coaching to encourage smooth rollouts across the PM team.

If Marco’s example is representative across the board, with the eight PMs on our team each saving two hours, that’s 16 team hours a week reclaimed from manual SQL queries — time now spent making better product decisions. This directly supports your goal of improving product insight velocity.

You’ve now sent a message that your skip-level could drop straight into the next board deck: clear, strategic, gratitude-filled, and measurable.

Why It Works

This one note accomplishes multiple things at once:

• Celebrates someone else’s success: Marco, the PM, and his team look great.
• Connects that success to a system you created: The reporting framework.
• Attributes coaching and collaboration upward: Your manager, gets visible leadership credit.
• Translates the whole story into the skip-level’s strategic language: Insight velocity improved.
• Makes your manager look good: Every success you communicate upward reflects their ability to develop and support effective people.

You’re not saying, “Look what I built.”You’re saying, “Look how the system we built together advanced your strategy — and how my manager’s leadership made this possible.”

That subtle layering is what makes this technique powerful. There are three levels of benefit baked in:

1. You elevate the person doing the work. Marco’s contribution is visible and celebrated.
2. You elevate your manager. Their boss now sees tangible results from her team — a reflection of strong leadership.
3. You elevate yourself. You’re the one connecting dots, amplifying wins, and reinforcing how your work aligns to organizational goals.

Instead of, “Look what I did,” the message reads as:

“Look how the system we built together advanced your strategy.”

That’s the difference between brown-nosing and leadership. It builds a recognition-driven culture.

Over time, recognition becomes predictable: a win, a clear outcome, a link to strategy. At that point, you don’t need ad‑hoc shoutouts. You need a simple playbook for visibility. The next step is to run an internal GTM.

Treat Internal Work Like a Launch

An internal go-to-market (GTM) operationalizes the recognition loop you just ran upward. It’s not “we shipped X,” it’s “here’s who enabled X and how it advanced goal Y” — delivered to the right audiences at the right altitude.

The same way product teams plan an external GTM, design an internal GTM to spread adoption of your systems by spotlighting the people succeeding within them — so wins compound and recognition becomes procedural, not political.

How this differs from “we announced the launch”:

• Outcome‑first, not feature‑first: lead with impact, then the change.
• Credit architecture: name contributors across functions and link their work to the system.
• Altitude‑aware: tailor the message so peers learn “how,” leaders see “why it advances strategy.”
• Close‑the‑loop cadence: announce, narrate, and celebrate — not a one‑off blast.

Announce, Deliver, Celebrate

Every internal GTM has three simple steps:

1. Announce what’s coming – Give people a reason to care. Explain why this work matters and how it connects to a company goal. Example: “Next week, product ops will be rolling out our new experiment-tracking dashboard. Our goal is to make experimentation faster and easier across teams.”
2. Deliver and narrate the journey – As the rollout happens, share updates where people already work — Slack, team meetings, internal newsletters. Tag the people who are making it successful. Example: “The growth team just ran the first experiment in the new dashboard — huge thanks to Mason and Esther for helping us spot early bugs and make the onboarding smoother.”
3. Celebrate the results – Once it’s live, close the loop. Share what changed, what improved, and who made it possible. Example: “Three weeks after launch, 40% of product teams are using the new dashboard. We’re seeing faster test setup and cleaner data. Huge shoutout to the growth and analytics teams — your feedback shaped this into something better than we imagined.”

Each step of the way you’re sharing something that was not done just by you but that had an impact on the team or where somebody else supported you in it. You’re appreciating the help that you get in recognizing that there’s no way to change a product culture single-handedly.

Why It Works

Running internal GTMs changes how people talk about work. Instead of project updates that sound like checklists, you’re telling stories that show progress, gratitude, and impact. Everyone sees not just what happened, but why it matters and who made it possible.

This practice also strengthens the recognition loop:

• Team members feel proud because their names and contributions are visible.
• Social proof encourages others to adopt your solutions.
• Leaders see alignment between tactical work and strategic goals.
• You become the connective tissue — the person who builds clarity, morale, and momentum.

And when you consistently share stories of others’ wins through your systems, the reflection is inevitable: your work becomes visible because others are succeeding within it.

Help others practice praise

If you were the only one doing this at your company, you haven’t quite changed the culture in any meaningful way. But if you’re the first to start doing it and you help others get better at this skill themselves, now you’re beginning to make real progress.

This is a good habit not only to build yourself but to encourage others to develop as well. If they’re on your team, you can suggest that somebody send a note to your manager celebrating their win.

If you’re supporting another product manager in a feature launch, you can coach them through how to do the internal launch as well.

So long as everybody keeps the praise genuine and authentic, it’s hard to imagine this going wrong.

The best reputation to have

The amazing thing about this is that the more you practice recognizing others and their accomplishments in order to channel your own, the more that you get the reputation for being a strong organizational leader, whether or not you’re in a position of actual leadership.

Jenny Wood mentions in her book: “The best part about being a manager is that you never have to steal an ounce of credit. You receive full points when your team wins. A leader’s most valuable trait is bringing out greatness in others.”

Even as I wrote this article, I went and revisited my weekly update to one of my consulting clients and found three different places where I could do a better job highlighting somebody else’s work.

This reputation is far more valuable than being known as “the person who ships features” or “the PM who hit their metrics.” It turns out that demonstrating your value isn’t about showing how much you can get done. While it’s important to get the right work done in your job, more is not more.

Take a look at what your wins have been this week. Find one thing that you can turn into a thank you or highlighting somebody else’s win and share that around.