Category: Articles

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. 

I wish I could work one-on-one with every product ops person who reaches out to me.

The conversations usually start the same way: “We’re struggling with X, and I don’t know where to start.” Maybe it’s engineering velocity, or misaligned priorities, or a team that can’t seem to ship anything meaningful. They’re stuck, and they need help now.

When I consult with teams, a huge part of my job is pattern matching. I recognize what they’re going through because I’ve seen it before—or lived it myself. Then I surface the right framework, the right question, or the right mental model at exactly the moment they need it.

This reading list is my attempt to scale that.

Most book lists organize by topic or author, which works fine when you’re browsing. But when you’re in crisis mode—when your team is struggling and you need answers—you don’t have time to read twelve leadership books to find the one chapter that applies to your situation.

So I’ve organized these books differently. Instead of categories like “strategy” or “leadership,” I’ve grouped them by the specific challenge you’re facing right now. Each book has shaped how I approach product ops work, and I want to help you find the one that will get you unstuck today.

Find your current pain point, grab that book, and get moving.

I’m just getting started in product ops

New to product ops? Start here. These books will help you understand what the role actually is, how to structure your work, and what “good” looks like when you’re building systems for your product team.

Product Operations by Melissa Perri, Denise Tilles

Read this when: You just got hired into a product ops role and need to figure out what you’re actually supposed to do.

This is the book on product operations. If you’re trying to understand what your job is, how to organize your team, or what projects fit underneath the product ops umbrella, start here. Melissa and Denise lay out the fundamentals clearly—what product ops owns, how it connects to product strategy, and how to measure success.

I did a full book review if you want more detail on whether it’s right for you.

Product Roadmaps Relaunched by C. Todd Lombardo, Bruce McCarthy, Evan Ryan, Michael Connors

Read this when: You have operations experience but not product experience, or you’re coming from a feature factory and want to see what good looks like.

Roadmapping is a perennial product ops challenge—everyone wants visibility, but most roadmaps become either useless Gantt charts or wish lists that don’t get updated.

This book shows you what modern, outcome-focused roadmaps actually look like. It’s especially valuable if you’re trying to move your organization away from feature factory habits toward more autonomous teams. I’ve used this book more than once to help convince leadership that there’s a better way to do roadmaps—and it works because the examples are concrete and practical.

True story: I had loaned this book out to a colleague when COVID hit and so never got it back. Bought another copy for my shelf because it’s a permanent part of my reference library.

I want to improve team delivery

Teams move slowly for dozens of reasons—unclear requirements, too much work in progress, misaligned incentives between product and engineering. But often the bottleneck isn’t the people, it’s the system they’re working in. These books help you see the system clearly so you can fix it.

Accelerate by Nicole Forsgren, Jez Humble, Gene Kim

Read this when: Your leadership keeps asking “why does it take so long to build good software?”

This is the book that made me question many truisms I thought I knew about software delivery. It’s filled with actual data about how high-performing engineering teams work, and it will make you uncomfortable—in a good way.

One of the most controversial findings: code reviews don’t meaningfully improve code quality when measured by bugs in production. This raises an awkward question: what’s the actual purpose of code reviews? Fair warning: quote this finding too enthusiastically to your engineering partners and you’ll make some people angry. (Speaking for a friend.)

The Goal by Eliyahu M Goldratt, Jeff Cox

Read this when: Work seems to pile up in certain places while other teams sit idle. You feel like you’re in the land of “hurry up and wait”.

Every business school grad has read “The Goal.” It’s not about software at all—it’s about manufacturing plants and systems and how work flows through them. And yes, it’s extraordinarily tacky. The framing story is painfully dated.

But here’s why it matters: it teaches you to see bottlenecks. Once you understand the Theory of Constraints, you’ll spot them in your backlog, your review process, your deployment pipeline. You’ll learn to prioritize not by what seems to be on fire, but by what’s blocking everything else. This book is the most painless way to develop this critical skill.

I am trying to create strategic alignment

You know that feeling when everyone agrees in the meeting, but then each team ends up pointing a different way? That’s the alignment problem. It’s not that people don’t care—it’s that alignment requires more than good intentions. You need shared language, clear priorities, and systems that keep everyone pointed in the same direction.

Radical Focus by Christina R Wodtke

Read this when: Your team sets OKRs every quarter and then immediately forgets about them.

Every product ops person eventually gets asked to “fix the OKR process,” and there’s no better book for this than Christina’s. It’s a short, fantastically written read that shows you what makes OKRs actually work—not just how to set them, but how to use them weekly to drive strategy and team productivity.

The book will make you think differently about how you spend time with your team. Fair warning: I’ve never quite been able to live up to the vision Christina paints here. But knowing that kind of alignment is possible? That keeps me trying.

I’m struggling with building product culture

Culture problems are the hardest to diagnose because everyone experiences them differently. One person says “we don’t trust each other,” another says “leadership keeps changing direction,” and someone else complains about misaligned incentives. These books help you see the patterns underneath the symptoms so you can actually fix what’s broken. and of course, long-time readers will know that I think that product operations and product culture are nearly synonymous

The Culture Code by Daniel Coyle

Read this when: Team dynamics just aren’t clicking and people don’t seem to trust each other.

This book taught me what psychological safety actually means—and showed me all the ways I was accidentally undermining it as a product leader. It’s easy to look at our own behavior and think we’re doing the right thing. This book is a wake-up call about how hard it actually is to create environments where people trust each other.

If you’re dealing with teams that can’t seem to cooperate or relationships that need repair, start here.

Turn the Ship Around by David Marquet

Read this when: You’re trying to turn around a struggling team or misaligned organization.

Turn the Ship Around has become one of my most recommended books. It’s about a nuclear submarine commander who transformed one of the worst-performing crews in the Navy into one of the best—by completely rethinking how leadership works.

The insight I carry everywhere: it’s not just about the words you say or the systems you build. It’s about incentive structures. The book teaches you how to spot when incentives aren’t aligned with goals—which happens constantly in product ops. Product wants one thing, engineering is measured on another, and everyone wonders why nothing works.

This book helped me identify those misalignments and fix them. It’s been a hugely influential book for my ability to catalyze change across a company.

I need to expand my thinking

Some problems resist every obvious solution. You’ve tried the standard approaches, talked to everyone involved, and still can’t figure out what’s actually wrong. These books teach you how to reframe problems so you can see what you’ve been missing.

Images of Organization by Gareth Morgan

Read this when: You’re trying to make sense of an organization or behavior that makes no logical sense on the surface.

John Cutler recommended this book to me, and as I read it, I started to understand how John can come up with such unique perspectives on classic product challenges. It teaches you to look at one situation through multiple lenses—political, ecological, mechanical, cultural—and shows how each lens reveals different truths about what’s actually happening.

My copy is covered in highlights where I’m connecting dots between concepts. For instance, looking at a product organization through a political lens versus an ecosystem lens reveals completely different intervention points.

Fair warning: this is the most academic book on this list. It’s long, dense, and not a weekend read. But if you’re a nerd like me who loves systems thinking, you’ll be blown away by the depth and quality of the writing.

Team Topologies by Matthew Skelton, Manuel Pais

Read this when: You’re reorganizing product teams and can’t figure out the right structure.

I’ve been pulled into more product team reorganizations than I can count, and this book provides the frameworks that make those reorgs actually work. It breaks down four fundamental team types and shows you how they should interact—which sounds simple until you realize how many reorgs fail because teams are structured wrong or have the wrong interaction patterns.

The book’s real gift is showing you the trade-offs. Want faster delivery? You’ll sacrifice some knowledge sharing. Want deeper expertise? You’ll slow down cross-team projects. There’s never one correct way to structure a product team, and this book helps you make those trade-offs consciously instead of accidentally.

I just need to stop thinking about work

Sometimes the best thing you can do for your product ops practice is to completely step away from it.

We spend all day optimizing systems and solving other people’s problems. My brain sometimes needs a break. These books have nothing to do with product operations, won’t make you a better strategist, and definitely won’t help you fix your roadmapping process. Grab one of them as your fireside read over the winter holidays and just enjoy.

Horse by Geraldine Brooks

Read this when: You need something that reminds you why storytelling matters.

This novel weaves together three timelines around a single racehorse, touching on art, ambition, and America’s complicated racial history. It’s the kind of book that makes you think about how we tell stories about the past. It’s beautifully written and will pull you completely out of your work brain.

Anxious People by Fredrik Backman

Read this when: You need something that feels like a hug.

I read this when dealing with overwhelming and overpowering grief, and it gave me something I didn’t know I needed—a story about messy, complicated people trying their best and mostly failing in charming ways. It’s about a bank robbery and strangers who end up stuck together. Saying more would spoil it. Just know that it’s funny, surprising, and will probably make you both laugh and cry in a good way.

One more thing before you go

Here’s what I’ve learned after recommending these books to dozens of teams: reading them isn’t enough.

The product ops managers who get the most value are the ones who treat these books as starting points for conversation. They read a chapter, then gather their team to debate whether it applies to their context. They highlight the parts that resonate and openly question the parts that don’t.

So yes, find the book that matches your current challenge and read it. But then do the harder work: figure out what needs to change in your specific situation, and make it happen.

And if you want to talk through what you’re trying? I’m always up for that conversation. Reach out—I’d love to hear what’s working (and what isn’t) in your context.

Layoffs blur the path ahead — but individuals and leaders both have tools to find their way through

This article was originally posted on Mind the Product on October 28, 2025.

The meeting that changed everything happened three months into what should have been a growth project. My client had brought me in to help their product management team scale after a successful acquisition — more people, bigger ambitions, booming business.

Then came the strategic pivot. Suddenly I wasn’t helping them grow the team. I was helping them shrink it dramatically.

I found myself caught between two impossible roles: advising a CPO on layoff decisions while coaching the very people whose jobs were at risk. The team could sense something was up. They peppered me with questions about what I knew, while I struggled to maintain both leadership’s confidence and the team’s trust.

Being stuck between knowing layoffs are coming and when that shoe actually drops? It’s one of the hardest positions any product leader can face.

Last month at Mind the Product’s leadership forums in Cleveland, this exact challenge came up in every conversation I hosted. The wisdom that emerged was remarkable.

Here’s what struck me most: even when there’s no impending layoff, the industry’s track record has everyone convinced the next one is coming for them. Product managers are freezing up, paralyzed by fear. It’s making strong product leadership even harder to achieve.

From those conversations and my own experience caught in the middle, here’s what I’ve learned about leading through both actual layoffs and the fear of them.

When you know more than you can say

The pressure on product leaders doubles during layoff season. You’re worried about your own future while trying to protect your team. And if layoffs are actually coming, you’re trapped in an impossible position.

You know it’s happening. You probably know the names. But you can’t tell anyone.

The leadership forum participants shared hard-won wisdom for navigating this ethical minefield:

Stay anchored in what’s still true. As long as you’re employed, the company’s purpose and priorities remain valid. Your team’s work still matters, and their contributions are still valued.

Avoid false reassurance. “Everything’s fine” destroys trust when reality hits. Be honest about what you can’t discuss: “I can’t share details, but I know this uncertainty is hard.”

Advocate behind closed doors. Push for clear, fair processes. Build your network now so you can help affected employees find their next roles quickly when the time comes.

Protect yourself too. Carrying secrets is emotionally expensive. Find safe peers or mentors for support — don’t offload that burden onto your team.

Every conversation can feel two-faced when you’re projecting confidence while bracing for bad news. The key is staying authentic within the constraints you’re given. You can acknowledge uncertainty without breaking confidentiality.

But even when you’re not privy to layoff plans — when there’s no inside information to withhold — the industry’s track record has created a different kind of leadership challenge.

The new normal: leading teams paralyzed by layoff fear

Whether your company is actually planning layoffs or not, fear of them has fundamentally changed how individuals on your team operate.

You’ve probably noticed it in meetings: “When will the next round hit?” has become the unspoken question behind every strategic discussion. Your product managers are struggling to think long-term when they’re not sure they’ll be around to see their roadmaps through.

As a leader, you’re watching talented people operate in permanent fight-or-flight mode. Their decision-making suffers. Strategic thinking becomes nearly impossible. Even your strongest performers are starting to show signs of burnout.

The leadership challenge has evolved: it’s no longer just “how do we handle an actual layoff?” but “how do we keep our teams effective when layoffs always feel imminent?”

When your team members are living in suspense

Over the past 18 months, I’ve coached quite a few product managers, and a troubling pattern has emerged that every leader needs to recognize. Nearly every conversation includes unprompted mentions of “the next layoff” – even when there’s no rumor, no indication, nothing concrete to point to.

Your team members are making decisions based on one question: will this action make me more or less likely to survive the next round?

As their manager, you need to coach them into a more stable mental state. Because otherwise they’re going to make choices that hurt themselves, the company, and you.

I’ve watched product managers stop pushing back on executive requests, afraid that disagreement signals disloyalty. They’ve stopped advocating for customer needs because saying “yes” to leadership feels safer. They’re choosing visibility over impact, politics over product sense.

The irony? These choices reduce the likelihood of great products getting built. It instead increases the chances that the company will need to cut costs because of underperformance.

Here’s the coaching framework that cuts through the fear: Whether your team members stay or go, their best move is the same — do great work that matters.

If they stay, driving real outcomes makes them valuable. If they go, that’s exactly the work that makes them marketable.

Your job as a leader is to redirect their energy from survival politics to meaningful impact. Here’s how: Help them focus on projects that build real value, coach them to document their wins as they go, and shift team metrics to measure success by contribution rather than visibility.

This coaching approach serves a dual purpose. Product managers doing their best work give you the strongest case for keeping them if budget cuts come.

A practical exercise for managing fear

Fear thrives in ambiguity. Both you and your team can regain control by getting crystal clear about what’s actually within your influence.

Here’s a framework we covered specifically for navigating layoff anxiety with leadership teams:

Draw a simple 2×2 grid with these axes:

	The Control/Influence Matrix
	In Your Control	Not in Your Control
Internal Factors	Team performance metrics, quality of documentation for handoffs, project completion rates, how you advocate for team members during reviews, building skills that make the team indispensable	Layoff decisions already made, budget cuts from above, other teams’ layoff fears affecting collaboration, executive communication timing and style
External Factors	Individual skill development, professional networks within your industry, updating LinkedIn profiles and portfolios, building relationships with recruiters, having up-to-date references	Industry-wide layoffs, economic recession, VC funding dry-ups, market demand for your specific product category

How to use this:

Fill it out honestly for your layoff fears. What specific actions can you take to protect your team or improve their prospects? What layoff-related anxieties are you spending energy on that you can’t actually influence?

Focus your energy on the “controllable” quadrants. Instead of obsessing over potential layoff lists, direct your efforts toward demonstrable outcomes, building stronger stakeholder relationships, and ensuring your team’s work is visible and valuable.

Use it to guide your crisis leadership. The “internal factors you control” become your layoff-season priorities – how you communicate uncertainty honestly, how you advocate for your people in leadership meetings, how you help them prepare professionally without creating panic.

Revisit during layoff rumors. When the next round of industry layoffs hits the news, return to this matrix. It’s a reminder that even when you can’t control hiring freezes, you can control how prepared and resilient your team is.

This isn’t about false optimism – it’s about strategic focus. Leaders who concentrate their efforts where they can actually make a difference consistently outperform those paralyzed by factors beyond their control.

Leading through the fear, not around it

Remember my impossible position from the opening — caught between a CPO planning layoffs and a team sensing something was wrong? I learned something crucial: you can’t eliminate the fear, but you can lead through it.

The most effective leaders I’ve worked with during layoff seasons don’t pretend everything is fine. They acknowledge the uncertainty while redirecting energy toward what actually matters. They coach their teams to do great work instead of survival theater. They focus their own efforts on the decisions they can influence rather than spinning on executive choices they can’t control.

Here’s what I wish I’d known during that gut-wrenching engagement: your team doesn’t need you to have all the answers. They need you to be the steady presence that helps them focus on what they can control.

When everything feels uncertain, you become their anchor point. Not because you can guarantee their jobs — no leader can do that — but because you can guarantee that under your leadership, they’ll do work that matters, build skills that transfer, and maintain their professional integrity regardless of what happens next.

The leaders who master this don’t just survive layoff seasons. They emerge with stronger, more resilient teams that trust them to navigate whatever comes next. In an industry where layoffs have become the new normal, that trust is your most valuable currency.

Three techniques to validate and learn faster

I’m excited to share this guest article by ​Chetan Kapoor​, a fellow product person I’ve known since my early days as a product manager in Chicago.

This article started when I posted on​ LinkedIn​ last year arguing that feature flags are a powerful product operations tool most teams underuse. Chetan jumped into the comments to share the innovative work he’s doing with feature flags at eBay – specifically how his team uses them to accelerate product learning, not just manage deployments.

---

Most product decisions are made with incomplete data. That’s not a failure – it’s just reality. As product managers, we want to optimize for quickly generating new insights and adjusting course.

Feature flags are one of the most under-utilized product management tools for speeding up our learning.

I’m Chetan Kapoor, Product Leader for Experimentation and Chief Evangelist for Feature Flags at eBay. As a growth hacker, product storyteller and change agent, my mission is simple: unlock eBay’s magical future experience. Previously, I grew a Chicago FinTech’s portfolio from $160M to $650M during my time there—the business has since passed $1B—and honed my technical craft at Expedia as a DevOps engineer. Today, I help teams turn ideas into customer value with speed, safety, and scale.

At eBay, where millions of buyers and sellers interact across hundreds of product categories and dozens of markets globally, the stakes for getting product decisions right are particularly high. We run over 3000 experiments behind feature flags each year.

We believe product velocity matters, and we’ve learned that feature flags are one of the most underrated tools for accelerating the continuous learning loop. They’re not just toggles to launch a feature quietly – they’re infrastructure for discovery, experimentation, and confidence.

We consider them not only a useful tool for engineering, but a critical tool for great product management.

In this article, I’ll walk through:

1. The difference between feature flags and A/B tests.
2. How teams use feature flags today (and why it’s limited).
3. Strategically integrating feature flags into modern product lifecycle.

Feature flags vs. A/B tests

I’ve talked to many product managers who see feature flags and A/B experiments as interchangeable. It’s important to know the differences. 

Feature flags and A/B tests both control who sees what, but they serve different purposes. Let’s quickly break down how they relate and where they differ:

Feature Flags are on/off switches in your code that let you control who sees a feature and when, without redeploying. They help product teams test, release, and iterate faster, safer, and more strategically. A/B tests are experiments run on top of feature flag capabilities to compare performance across two variants.

Feature flags should be used when teams need control over who sees a feature and when: for safer rollouts, gradual ramps, or quick rollback. Here is a simple example:

For example, say you’re rolling out a new “Express Delivery” badge on product pages. A feature flag lets you show it only to a small region first, so you can validate performance, fix bugs, or pause rollout instantly if needed. Even without an A/B test, the flag gives you precise control over exposure, making launches safer and more flexible.

Experiments are used when teams want to measure what works best: validating product decisions with data before going broad.  After you’re confident your feature is ready, you can layer on an experiment to measure if the badge increases conversion, without changing the rollout setup.

While experiments are often seen as a tool for learning, most teams treat feature flags purely as a release safeguard. But that approach limits their full potential.

How many teams use feature flags (And Why That’s Not Enough)

Across industries, here’s how I’ve seen most teams use feature flags:

1. Toggle ON/OFF to show or hide features
2. Control environments (staging vs. pre-prod vs. production)
3. Opt-in internal users for dogfooding on production environment
4. Target customer segments (based on location, device, user ID, etc.)
5. Gradual rollout of features (traffic ramping, data center based release)

To help illustrate this, let’s do a little case study. Meet John*, a PM at eBay working on a new AI-powered payment feature for multiple global markets. The team wants to ship fast, validate quality, and de-risk rollout. Here’s how they use feature flags during product development and delivery: 

A sample engineering-oriented feature flag workflow

Phase of Development	What it is	Feature Flag Toggle	Targeting Configuration
Feature Development	Create a new flag and build code safely behind it.Keep the feature invisible.	OFF	N/A (flag is off, not user-visible)
Quality Validation (QA)	Engineering validates usability, test coverage, and backend logic in staging.	ON	Staging only, Developers only
User Acceptance Testing (UAT)	PM & Designer verify flows, copy, and experience directly in production without exposing to real users.	ON	Limited to PMs & UX team
Canary Testing  (soft launch)	Gradual rollout to measure funnel impact, early feedback, and performance. Fix friction.	ON	US market only, 5-10% traffic
Full Rollout	Monitor potential impact for a few hours or days, as needed	ON	All users in US and UK

1. Feature Development
John’s engineering team begins by building the new feature safely behind a flag. With the toggle off, the feature is deployed but invisible to users, reducing risk from the start.

2. Quality Validation (QA)
Once the feature is in place, developers validate usability, test coverage, and backend logic. The flag is flipped ON in the staging environment only for developers, catching issues earlier without user impact.

3. User Acceptance Testing (UAT)
Next, John and his designer test flows, language, and responsiveness in production using targeted flags. Only their accounts can see the feature, ensuring feedback without exposure to customers.

4. Canary Testing (Soft Launch)
Confident in the basics, John enables the feature for a small slice (e.g., 5% of U.S. shoppers). This allows monitoring of funnel metrics, engagement, and performance under real conditions before broader rollout.

5. Full Rollout
Finally, with validated demand and stable performance, the team enables the feature for 100% of users in the US and UK. A final round of monitoring for guardrails (critical business and engineering watch-metrics) is in place to catch any last-minute surprises, but by this point, risks are minimal.

These are great for reducing risk, but it’s not helping John and the team learn more about their feature. What he’s missing is using feature flags as a product discovery tool, not just a release safeguard. 

The real unlock is when feature flags are used earlier in the process, during product discovery itself.

3 Ways to use feature flags in product discovery 

Let’s go back to John at eBay. He’s been tasked with a massive, cross-market AI-powered payment feature, something that could easily take 8 sprints to build. He came to me asking for some ideas on how to speed up time-to-learning. 

I advised that instead of building it all at once, he use feature flags to de-risk decisions early and often, across three powerful learning techniques. 

He ended up using three techniques:

Technique 1: Validate demand early

In the very first sprint, John doesn’t start with code. He starts with curiosity.

Using a feature flag, he exposes a painted door to a select group of users: a new “Pay Later with AI” button on the checkout page shown only to U.S. Chrome users with low cart values. Behind that button is a quick survey: “Would you try this feature to speed up your checkout?” 

This helps John validate early demand without building any functionality. He even adds email capture to build a beta waitlist. By tying this entry point to specific user behaviors and contexts, John ensures only qualified users see it, creating a more meaningful signal. 

Painted door tests are a secret weapon in technology industries (eg: gaming), and can help you save million dollar investment mistakes. 

Technique 2: Dogfood for proof of value

Next, John can ask his engineers to frugally build (or he can vibe code) a working prototype, just enough to simulate the experience. 

They use a flag to roll it out internally to eBay employees only. This dogfooding round provides high-quality feedback from people who know both the product and the user base. 

Employees point out confusing flows, performance quirks, and missed opportunities, well before any customers are exposed. Dogfooding also helps shape a higher quality experience and demonstrates confidence in the product before full launch. 

Even though the code may not be scale ready, it’s one of the fastest, most cost-effective ways to test proof of value before investing in full development. As the team learns more from feedback, they refine the prototype that’s in the wild, hardening the code over time and getting it ready to launch to an outside audience.

At eBay, some of the most ambitious AI-led reimaginings like Magical Listing (bulk listing) and Shop The Look (curated personalized outfits), began exactly this way: as lightweight internal prototypes. Tested by employees behind a feature flag, refined rapidly, and championed with proof of value, these ideas secured executive sponsorship, ran a series of experiments and scaled into high-impact features.

Technique 3: Beta testing with the right slice of users   

After internal dogfooding shows promise, John’s next move is critical: real-world beta testing. Not with just any users, but with the right users.

John uses feature flags with eBay’s segmentation tools to design a targeted beta that reflects his product’s real-world challenges. Instead of releasing to a random 10%, he curates a high-signal slice to test intentionally with users who are most likely to surface edge cases (e.g. low-bandwidth environments) or usability friction (e.g. less tech-savvy users who may struggle with new flows), before scaling.

His core question: Will this new AI-powered payment method drive adoption among high-friction user groups without causing drop-offs or regulatory issues?

To find out, he uses eBay’s feature flag and segmentation tools to create a precision-targeted beta cohort that mirrors real-world complexity:

• User Type → Sellers managing high-volume transactions
• Cost Sensitivity → First-time users who may hesitate at added costs 
• Behavior Archetype → Support-heavy “Complainers” likely to flag the UX flaws
• Geographic and Legal → UK users opted into experimental features under GDPR

This isn’t just a beta – it’s a smart slice, built to reveal weak spots before the feature reaches the masses. If this group of users can effectively use the feature, John will have confidence that one of the most complex scenarios is addressed, meaning simpler cases should encounter fewer challenges.

By the time John has cycled through these three techniques, he’s got a working version of his product and a much higher level of confidence that it will hit its outcomes. He’s introduced limited delays to the delivery timeline because he’s been simultaneously learning and building.

From guessing to knowing: Three forms of insight

Looking back, John didn’t need 8 sprints to prove the value of an AI-powered payments feature. By using feature flags, he validated demand using painted doors in Week 1, shipped a dogfood-ready prototype in Week 2, and got high-signal feedback from targeted beta users before writing scale-ready code. 

This is exactly what we promised at the start – optimizing for quickly generating new insights and adjusting course. Instead of spending months building in the dark, John generated three types of critical insights simultaneously:

• Market demand insights from painted door testing revealed real user interest before any development
• Product-market fit insights from internal dogfooding validated the core value proposition
• User experience insights from targeted beta testing surfaced edge cases and usability issues

When it came time to roll out, he wasn’t guessing. He had data, confidence, and control.

Key takeaways from John’s journey: 

1. Target Intentionally: Use feature flags to ship earlier to the groups that will help you learn about core value props and potential edge cases as quickly as possible. 
2. Iterate Quickly: PMs and engineers should co-create, validate early and monitor continuously.
3. Experimentation: The best teams don’t just release with flags, they run A/B experiments on them too, before launch and after, for continuous and cyclical learning. 

This approach transforms the traditional product development cycle from sequential learning to parallel insight generation. Instead of building for months only to discover problems at launch, you’re course-correcting from day one based on real user feedback.

Feature Flags aren’t just engineering tools; they’re a product power move. 

* John is a combination of several product managers I’ve worked with at eBay. The story is for illustrative purposes only.

The playbook to coax it out of them

Years ago, I pulled five PMs into a conference room and, in an afternoon, we drafted what we thought was a solid product strategy for our team. We were all sick of trying to figure out our own strategy when it felt like leadership’s guidance was a shrug. Any strategy felt better than the current state of ambiguity and aimlessness.

I went to my manager with our output. “Look—we made you a strategy.” (Pro tip: telling your boss they don’t have a strategy is not a good career move.)

That moment taught me two things I use to this day: most leaders do have a strategy (it’s just not explicit), and the most effective way to help is to translate what you’re hearing into a draft they can quickly react to. The steps below are the system I wish I’d had then.

The impossibility of moving in a strategic vacuum

When I don’t know the goal, strategy, or context of organizational decisions, I get extremely frustrated. In that vacuum, teams step on each other’s toes, roadmaps collide, and people slow down their work, waiting for clarity that may never arrive.

Why the vacuum hurts:

• You can’t make trade‑offs. If everything is “important,” nothing gets put to the side.
• You can’t say no. Without a clear yes, your backlog turns into a junk drawer.
• Collaboration disappears. With no shared goals, everyone just does the best they can, in different directions.
• Ennui sets in. When you don’t know what’s happening, motivation slips—for you and the team. What’s the point if the direction is just going to change tomorrow?

There’s certainly some strategic context sitting in your leadership’s head, even if you don’t know what it is. Your job is to get it out of there and written down so they can react to it, refine it, and make it clearer.

I have a playbook for extracting this knowledge from a leader’s head, without ever making it feel like they’re being accused of failing on strategic leadership. Let’s walk through each step in detail.

1. Never Say “You Don’t Have a Strategy”

Even if it feels true, saying it out loud lands like an accusation. People hear “you’re doing a bad job,” and the whole conversation slides into defensiveness.

Assume there is a strategy — it’s just living half‑formed in your manager’s head, leaking out in ad‑hoc requests. Your job is to turn “you don’t have one” into “let me reflect back what I’m hearing so we can move faster.”

One thing I discovered when moving into leadership myself is that there’s always additional constraints, context, and reasons why the manager is not sharing as much with you as you’d like. You generally don’t get an inside look into those constraints, and so from your perspective, it might look like there is an absence of leadership. Have empathy instead for the challenges they’re facing, and realize that there are probably reasons why you feel like they are disappointing you.

2. Position Yourself as a Learner and Supporter

I’ll usually open with something disarming: “I want to make sure I’m aligning my work to the broader goals, and I want to learn how you approach strategy. Can I try to write down how I think our strategy works and have you mark it up?” It’s amazing how quickly the temperature drops when you position yourself as a student of their thinking.

Notice what’s happening: you’re reinforcing their authority (“your guidance”), lowering the lift (“one‑pager,” “draft we evolve”), and making the payoff explicit (fewer repeated questions, faster execution). You’re not asking for permission to create bureaucracy; you’re offering leverage. And you’ve framed the exercise as apprenticeship: you’re learning how they think about strategy so you can operationalize it.

3. Interview Your Manager About Their Strategy

I think of interviewing the manager as user research, where my goal is to understand the strategic context they have in their heads.

The easiest question to start with is for them to explain the strategy. But it’s rarely a comprehensive explanation. I am always prepared with some critical follow-up questions:

• Tell me about our target audiences. Why are we going after those users?
• What are some things we really don’t want to do?
• What do you think the world will look like a few years from now and how should we be preparing for that?
• Why are we doing X now? Why not wait on it?
• What financial goals are we targeting?
• Are there external deadlines we need to anchor to (e.g., exit, fundraising, board milestones)?

I listen carefully and add in more questions as we go. By the end of an hour-long conversation, I’ve usually gotten a decent amount of context.

4. Write It Down, Fill the Gaps, and Flag Assumptions

Now you do the most important thing: write it down. Take the information you’ve collected and turn them into a document your manager can react to. Try to make it as true to what they told you as possible.

There are going to be holes in what they’ve told you. In those cases, try your best to fill in the blanks based on what would make the most sense. You can also reverse-engineer the unknowns by analyzing past decisions. Mark with a comment that this is an assumption, so they know to give that extra scrutiny to see if it aligns.

As you’re writing it down, you might also think of new ideas, opportunities, or other ways in which the strategy could be strengthened and expanded. Write those in, because this is your opportunity now to have extraordinary influence on your company’s strategy. Not only are you translating this information from somebody else, but you are now shaping the document where it will be communicated to the rest of the organization. Use this power wisely.

5. Take It Back for Feedback and Refinement

I’ll set the tone up front: “I wrote out my impression of what we discussed and filled in some of the blanks. Let’s walk through it and fixed where I missed things.” Then I walk through the document with them, adding comments and corrections as they point them out.

Close the loop with a crisp next step: “I’ll incorporate today’s edits, highlight any open questions, and circulate this by end of day. If you reply ‘looks good,’ I’ll create a communication plan for you to share it out.” Then follow through.

Once you’ve gotten it to a good place, let them share it out and take the credit. After all, it’s their strategy. But make sure that in that initial draft of the communication that you get a contributing credit – “Thank you to Jenny for writing it all out!” It’s their strategy, you were just the ghostwriter.

Make them look good

It might be frustrating to be doing this exercise with your manager. After all, isn’t it their job to communicate their strategy? Why does this fall on you?

Managing up is just part of the job. As much as we wish we didn’t have to do this, in reality, your manager is dealing with their own set of constraints, time pressure, and execution needs that might be getting in their way of operationalizing and communicating out their strategy.

We need to be strong team players in this case and take the high road of helping them to be more successful in their jobs in order to power our own success instead of waiting on them and getting stuck ourselves in the meantime.

The good news is by doing this you are getting the strategic guidance you need in order to move forward with your own work. So even though it might be frustrating, it helps you reach your goals faster and your manager will remember that you are the one who stepped up to help them be more successful. The better you make them look, the better you look yourself.

I have to confess something embarrassing: back in 2018, I wrote an entire article about prioritization that missed half the point.

The piece was called Silence the Squeaky Wheel Through Feature Prioritization, and it became pretty popular on Mind the Product.

That article was me at peak framework enthusiasm. I spent pages explaining how to score features, create fairness in decision-making, and get stakeholder buy-in through structured processes.

The advice wasn’t wrong, exactly. At SpotHero, where I was working at the time, having a clear scoring system did help me push back on urgent requests from executives and engineers. It gave me the confidence to say “this is how we decide” instead of mumbling something about gut feelings.

But here’s the thing that makes me cringe: that entire article never once mentioned strategy. Luckily, I got the chance to correct myself during my keynote at INDUSTRY this year.

I was so focused on the mechanics of ranking ideas that I completely missed the bigger question: should we even be considering these ideas in the first place?

The promise and reality of prioritization frameworks

I get the appeal of prioritization frameworks. You take all your messy, political feature debates and turn them into clean math. Pick some factors — reach, impact, effort — assign numbers, and boom. The spreadsheet tells you what to build.

No more sales screaming about their “urgent” integration request. No more engineering pushing for technical debt work that nobody understands. Just objective, data-driven decisions.

Except here’s what actually happens:

You spend three hours in a room debating whether something is a 3 or a 4 on “impact.” People start gaming the system, inflating scores for their pet projects. You get false precision — a score of 8.2 somehow feels more scientific than “this seems pretty important.”

Frameworks do help. They quiet the loudest voices and create some transparency. But they only solve half the problem.

Frameworks help you rank ideas. They don’t help you figure out which ideas deserve to be in the conversation at all.

That’s where I went wrong in 2018, and it’s where many teams still get stuck today.

When the framework becomes the roadblock

My client, Eric, lived this firsthand. His CPO had asked him to implement RICE scoring across his backlog to create more consistency in prioritization decisions.

Eric called me in desperation.

He was drowning in scoring work. Just getting lightweight data for each item was taking him too much time. It was going to take weeks for him to make time to go through everything. Meanwhile, new ideas kept flowing in.

“I’m spending more time talking about prioritization than actually building anything,” Eric told me. “And I still can’t tell you what we should work on next quarter.”

The breakthrough came when Eric introduced a simple filter:

• Step 1: Ask, “Does this idea clearly map to one of our strategic goals?”
• Step 2: If no, archive it without scoring.
• Step 3: If yes, run it through the prioritization framework.

That one change transformed his workflow. The backlog shrank dramatically. He stopped wasting time on noise. And because he was only scoring the ideas most likely to move forward, he had the time to make those scores more accurate.

The result? Better conversations, more confidence in the roadmap, and far less time sunk into scoring for scoring’s sake.

Why strategy filtering matters

Filtering ideas by strategy before scoring unlocks three big benefits that compound over time:

• Efficiency → You stop wasting time scoring things you’ll never do.
• Accuracy → With fewer items to assess, you can dig deeper into the ones that matter. Your inputs get sharper, your estimates more realistic.
• Alignment → Everyone knows the backlog only contains ideas that ladder up to strategy. Saying “no” feels less personal and more principled.

The real power of strategy filtering goes deeper than just time savings.

When I filter by strategy first, I start changing organizational culture.

Sales starts connecting customer needs to broader goals. Product managers become more strategic. Engineering suggests improvements that tie to business outcomes.

The result? Instead of “product doesn’t think this is important,” you can say “this doesn’t map to our goal of reducing time-to-value for enterprise customers.” And others start talking that way as well.

That subtle shift transforms how the organization thinks about product decisions. Instead of advocating for their pet features, teams start thinking about how their ideas support the broader strategy.

In other words: filtering reduces noise, so prioritization can focus on signal.

How to put this into practice

The good news: you don’t need to overhaul your entire prioritization process. You just need to add one filter before you start scoring anything.

Step 1: Make your strategy concrete and actionable

Check if your strategic pillars are concrete enough to evaluate ideas against. Good strategic goals for prioritization are specific enough to exclude things. They should define a target customer, problem to solve, or area of the product you’re playing in.

For example: “Move upmarket by adding advanced analytics capabilities over the next 12 months.”

Step 2: Create a simple filtering process

For each new idea that enters your backlog, ask one question: Does this clearly map to one of our strategic goals?

• If no: Archive it in a “someday/maybe” list. Don’t delete it entirely — strategies change, and today’s bad idea might become tomorrow’s perfect solution.
• If yes: Move it into your prioritization framework for full scoring.

Make sure there’s a drop-down on your backlog, spreadsheet, or wherever you’re working to designate how this aligns with the strategy (or doesn’t). 

Step 3: Apply your framework to the filtered set

Now use whatever prioritization framework you prefer — RICE, MoSCoW, Value vs. Effort, or your own custom model. (It’s also fine to not have a framework) The key difference: you’re only scoring ideas that have already passed the strategy filter.

This means you’ll spend less time debating scores for things you’ll never build, and more time getting accurate estimates for the things that actually matter.

Step 4: Review and iterate regularly

Strategy filtering isn’t set-and-forget. Schedule regular reviews (quarterly works well) to:

• Evaluate your strategic goals: Are they still the right priorities? Are they specific enough to guide decisions?
• Review archived ideas: Has your strategy shifted in a way that makes previously filtered ideas relevant again?
• Assess the filter’s effectiveness: Are you still drowning in low-value ideas, or has the filter created the focus you need?

Remember: this doesn’t mean ignoring good ideas forever. It means being honest that they aren’t right for right now.

How product ops drives strategy-first culture

Eric’s story illustrates exactly the kind of culture shift that product operations is uniquely positioned to create.

His CPO wanted consistency, so they mandated RICE scoring. But that treated the symptom, not the cause. The real problem wasn’t inconsistent scoring — it was that teams didn’t have clear strategic direction in the first place.

This is how I like to think about product ops: not by implementing frameworks, but by designing systems that embed strategic thinking into everyday decisions.

That’s the power of strategy-driven product operations (yep, this is meta): it doesn’t just make prioritization more efficient — it makes your entire product organization more strategic.

So the next time someone asks you to implement a prioritization framework, pause. Ask the harder question first: Do we have a strategy clear enough to guide these decisions?

Because if you don’t, no amount of scoring will create the strategic focus your teams really need.