Category: Articles

  • Influence doesn’t come with the promotion

    Influence doesn’t come with the promotion

    Influence earns the title, not the other way around

    A head of product I coach sat on the executive team with one exec who almost never listened to them. That exec frequently neglected to factor their product concerns into decisions that affected the roadmap. That left the head of product constantly cleaning up the exec’s messes. The only way an idea of theirs reached that exec was through the CEO: if the CEO repeated it and put real weight behind it, the exec listened. If the CEO didn’t say it, the head of product got ignored.

    This person’s ideas were good, they could defend them, and they still didn’t land.

    Their first instinct was to sharpen the argument: better logic, better slides, more evidence. Reach out to the ignoring exec ahead of team meetings to present their arguments. If they could just make the case tighter, surely the exec would hear it this time. It was the wrong lever.

    When sharpening the argument didn’t work either, they landed on a theory I hear from almost every person I coach in this spot: the real problem was title. That exec outranked them, and that was why the exec always listened to the CEO but not them. If they just made Sr. VP, or CPO, surely people would start listening to them too.

    Persuasion is the event. Influence is the system.

    Persuasion is what happens in the room. You make the case, and the person in front of you either agrees or doesn’t, right there, based on how well you argued it. It’s a single event.

    Influence is what happens after you leave the room. It’s whether the person you persuaded goes on to make your case to people when you’re not there, because they’ve decided supporting you is the right call. Influence is the system that makes your next persuasion event easier to win.

    That distinction matters because you can be very good at persuasion and still have almost no influence. You can win argument after argument in the room and watch every one of them get relitigated in the next meeting. If every idea has to survive fresh persuasion each time, you don’t have influence.

    Influence is reputational. It’s the standing you build over time as someone who thinks clearly, listens seriously, and will really listen to others, not just be polite about it. You gain influence by proving you care about their goals, not just your own.

    Two cards contrasting persuasion, which produces agreement once inside the room, with influence, which produces someone who carries your case after you leave
    I spent years getting very good at the left column.

    That head of product had this backwards. They thought a bigger title is what would finally get them heard. Over time, they realized it was the reverse: influence earns the promotion, not the other way around. If your voice is getting ignored now, no promotion is going to fix that on its own.

    Where I over-indexed on persuasion and it cost me

    Early in my career at SpotHero, one of the things that made me good at the job was sweating the small details and looking far enough ahead to catch a little issue before it became a big one. In one meeting, right before lunch, I saw something in how a certain set of properties were being attached to other objects in the system that I thought would turn into a real, expensive problem later. I wanted the engineering team to see it too. I went to the whiteboard and started mapping it out. I asked each engineer to walk me through their reaction. I stayed at the board.

    Eventually one of them handed the marker back to me and said something like “fine, whatever, I’m just going to go eat.” I “won” the meeting. I persuaded them. A few weeks later, they went and built what they thought was best anyway, a version that was probably better than what I’d been arguing for. I didn’t have influence.

    The instinct to catch it early was right. How I handled the room wasn’t. I burned credibility on something that didn’t ultimately matter that much, in a rushed pre-lunch meeting where nobody had the bandwidth to engage.

    I was holding on too tight to being the one who’d spotted the problem, because I didn’t trust my engineers enough to let them work it out themselves. I got the persuasion “win” and a dent in my influence in the same afternoon. Looking back, I was a bit of a bully that day.

    That pattern is what eventually cost me a promotion at SpotHero: I kept over-indexing on being right, then handling the room so badly that whether I was right or not stopped mattering. (Longer version on Andrew Capland’s podcast.)

    That’s what happens when persuasion is the only tool in the box. You can technically get people to agree in the moment and still lose ground on whether they’ll listen to you next time.

    What influence looks like when it works

    Years later, I was brought in to help a fintech founder-CEO who was functionally running the product team. This time, I led with questions instead of the whiteboard.

    When I joined, there was no articulated product strategy. Everyone had a different perspective on where to play, and that division was showing up in weak product delivery.

    I ran discovery interviews with everyone I could: engineering, sales, ops, the executive team. Every stakeholder had a chance to shape the picture I was building. By the time I sat down with the CEO to walk him through what I’d found, everyone felt heard. He agreed with my proposed direction. One meeting. That was the persuasion event.

    But the influence work had started weeks earlier, in the discovery interviews. Everyone who’d felt heard in that process already trusted the picture I was building, which is why the CEO didn’t need extensive convincing. He’d already watched me get it right with the people who knew the business best.

    For a couple of months after that meeting, the CEO would surface new ideas that didn’t fit the strategy. “What if we did this instead?” Instead of reopening the strategy from scratch each time, I’d ask two questions: does this get you to the goals you’ve said you want? Is it more important than what we’re already doing? We’d have a short back-and-forth about the tradeoffs, and conclude, together, that staying the course was the right call.

    Critically, we’d agreed on the goals up front in that first meeting. When he found a new idea to explore, my job wasn’t to fight him on it. My job was to keep pointing at the gap between what he proposed and what he’d already said he wanted, and let him close it himself.

    A couple of months in, other people started bringing him ideas outside the strategy. He started saying no without me there, using the reasoning we’d built together. He didn’t need me in the room to hold the line. That’s influence.

    The persuasion event was one meeting. The influence took weeks of discovery beforehand and months of small, patient conversations afterward.

    Sometimes the point isn’t to win

    At Linux Foundation Public Health (LFPH), I believed the org needed to broaden its remit: pivot from a pandemic-specific mandate to a broader healthtech mandate, something with room to survive the post-pandemic funding environment. I brought the case to the board, explained why I thought it could help us thrive in the future, but I wasn’t expecting them to say yes that day. A change that big wasn’t going to happen on the first ask.

    By the time I brought it, I’d already invested in building relationships with the board: showing up prepared, listening, becoming someone they had already learned to trust. What came next built on that foundation.

    I was bringing them an argument I expected to lose. Best case, I’d get a “not yet.” Worst case, a flat-out no.

    I tried to persuade them. As expected, the board said no and I let that be the answer. They also opened a door: here’s why now isn’t the right time, and here’s when we might revisit.

    I went on maternity leave not long after, then left LFPH before the reconsideration window came around. I never found out if the board would have said yes the second time.

    The move was still right. Accepting their timing instead of fighting it was what told the board I cared about the org’s interests, not just mine. Had I tried to push for a decision before my maternity leave, I would have been signaling that I cared more about my career than the organization. I extended that trust without ever getting to collect on it myself.

    A flow diagram branching from an ignored idea: sharpening the argument wins the room but loops back to relitigation, while building the relationship holds
    From the inside, both of these feel like doing the job well.

    Why letting yourself be influenced builds influence

    None of this works without one thing underneath it: trust has to run in both directions. In the fintech story, people trusted me because I’d spent weeks proving I was tracking their goals, not mine. At LFPH, the board trusted me more after I fully accepted their “no” response on their terms.

    In both cases, the influence wasn’t something I earned by being persuasive. It was something I built by being persuadable, in front of the people whose trust I needed.

    That only works if two other things are already true: you show up the same way often enough that the trust has something to attach to, and you come to the relationship curious about what the other person needs instead of waiting for your turn to make the case.

    Being persuadable isn’t about whether you turn out to be right. At SpotHero, the technical call might have been fine. What cost me was how hard I pushed to make it stick instead of trusting my engineers to get there themselves. At LFPH, I never found out if the pivot itself was the right call, and it didn’t matter. What built trust was letting the board’s timeline stand instead of pushing past it. The test isn’t whether you were correct. It’s whether you let anyone besides you decide how it plays out.

    How much do you lean on persuasion versus influence?

    If your ideas keep getting ignored, the temptation is to sharpen the persuasion. Better logic. Sharper framing. More evidence. Say it again.

    But what I’ve found over and over is it’s better to dive into influence, which means relationship-building. Look at the last time you got resistance: a meeting, a comment on a doc, a proposal that died due to nobody really pushing it forward. Did you sharpen the argument, or did you step back and think about the relationship? How much of your last week was spent making cases you needed to win, versus showing that you were caring about others’ goals?

    If the answer is “almost all of it was making arguments,” you already know which lever you’ve been pulling. The other one is still sitting there, unused. Put the argument down, and go find out what they need instead.

  • Your AI Should Keep a Diary

    Your AI Should Keep a Diary

    A few months ago I asked Claude to read back through my entire AI activity log and tell me how I was using AI, and where I could be using it better.

    The answer was more useful than I expected. I had built some good skills, and I was using AI as a thought partner every day. But the record showed I was still doing most of the execution myself. I would think through a problem with AI, then go do the work by hand. I wasn’t yet trusting it to carry things out on its own.

    I’d had a rough sense of that pattern, but no language for where I could get better. When sessions evaporate the moment I close the terminal window, I’m left with a nagging feeling that I’m either a power user or a fraud, depending on the day.

    If some version of “am I actually using AI the right way?” is taking up space in your head, you know the feeling.

    The reason I could get a straight answer is that I had a record to point at. I make my AI keep a diary.

    What the log actually is

    At the end of each working session, the AI writes a short entry into a running log: what was built or changed, key decisions and the reasoning behind them, mistakes or errors, and follow-ups. Plain markdown files in a folder. Sessions where nothing meaningful happened get skipped.

    Each entry reads in about thirty seconds. This one is real, pulled from my log in July:

    # Fixed empty WordPress site title
    **Date:** 2026-07-10
    **Workspace:** work/webmaster
    ## What Was Built or Changed
    - Diagnosed missing "Jenny Wanger" prefix in browser tab titles across jennywanger.com (reported on /blog as `| Blog`, but affected every page — homepage was rendering ` Product Team Transformations`).
    - Root cause: WordPress **Site Title** field was empty. The theme title template is `{site_title} | {page_title}`, so an empty site title dropped the prefix everywhere.
    - Fix: `POST https://jennywanger.com/wp-json/wp/v2/settings` with `{"title": "Jenny Wanger"}` using app-password auth. Verified via cache-busted fetch: `/blog` now renders `<title>Jenny Wanger | Blog</title>`.
    ## Key Decisions Made
    - Pushed the setting change directly rather than routing through `drafts/` first. The project rule to draft-before-deploy is aimed at content edits; this was a single-field config restore for a bug Jenny explicitly reported and asked me to fix. Reversible via the same endpoint.
    - Skipped the `public-api.wordpress.com` v2 settings endpoint (returned nulls silently) and the v1.1 endpoint (unauthorized with the bearer token). Used the site-hosted `jennywanger.com/wp-json/wp/v2/settings` endpoint with app-password auth per `docs/wordpress-api.md` — matched the pattern that works elsewhere.
    ## Mistakes or Errors
    - First two API attempts (`public-api.wordpress.com` v2 and v1.1) failed silently or with unauthorized before I checked the vault's own `wordpress-api.md`, which specifies the site-hosted endpoint as SSOT. Should have opened that reference first instead of guessing endpoints.
    ## Next Steps
    - Consider adding a note to `docs/wordpress-api.md` that `/wp-json/wp/v2/settings` is the working endpoint for site-wide settings (title, description) — currently the doc only covers pages, blocks, and global styles.

    Look at the mistakes section. Claude guessed at two API endpoints before it thought to check my own reference doc, and it wrote that down.

    I wasn’t watching it work, and the entry told me something about how I hand off tasks. I’d turned Claude loose without pointing it at the right reference. Either I need to prompt Claude to put in better guard rails so Claude knows to find that file, or I need to flag to Claude when there are reference files to review. Patterns like that are easy to spot once there are dozens of entries to read in a row.

    I use a Claude Code skill that writes the AI Log automatically at the end of every session, and I’ve published it if you want to steal it. But nothing about this requires Claude Code. Any AI tool can follow the format if you ask.

    Another nudge to drive AI adoption

    If you lead a product team, you’re probably trying to figure out how to improve AI adoption across your team. The AI Log is more than a personal productivity trick.

    I’ve been driving AI adoption across my client’s 50 product managers. I’ve found much more success with nudges (lots of them, running at once): show-and-tells, office hours, shared skills, pairing sessions. An AI log belongs in that pile.

    Keeping a log builds awareness of how we use AI. That awareness is what opens someone up to coaching, and to going deeper on their own.

    I’ve set some boundaries around how it gets used: it stays opt-in, and it stays private. It is essentially a professional diary. Each entry is your AI writing a little note to its future self. You don’t read other people’s diaries, and you don’t make anyone publish theirs. If this is going to drive self-improvement, people have to trust that no one else is reading over their shoulder.

    Infographic framing the AI log as a data-driven feedback loop for a product team
    What product manager doesn’t like a good data-driven feedback loop?

    Your weekly update gets a first draft

    Before the log, my weekly client update started in one of two places: a running notes file I maintained in Slack all week, or a Friday session of calendar archaeology, scrolling back through the week and trying to reconstruct what happened.

    Now AI drafts the update from the log, and I edit. I still amend, enhance, and reframe (the judgment about what my client needs to hear is still mine). But I start from a first draft instead of a blank page, and the draft already knows what I did on Tuesday.

    This is the use case that pays off most quickly. If you’re like me, you’re doing most of your work in AI at this point, so the log becomes a solid record of where your attention went. Turning that into a client or stakeholder update is a small step.

    And it’s not just me. I rolled the log out to those product managers as an optional practice a few weeks ago, and a couple of them have already messaged me unprompted. Asking their AI to look back over the log showed them what they use it for and where they could be getting more from it. A couple have started using it to prep an agenda for their weekly one-on-ones with their managers.

    Some of my other favorite use cases include:

    • Session recovery. When a session crashes or won’t resume, the log holds what was decided and where things stood. You start from the last entry instead of from zero.
    • Self-reviews stop being guesswork. Come annual review time, you have a year of receipts, written down at the moment things happened.
    • Proof you’re growing at this. Using AI well is now a skill people expect you to develop. The log gives your manager conversations evidence instead of vibes.

    The ask here is small. Set up the habit, let it run for two weeks, then ask your AI to read the log and tell you how you’re using it, and where you’re selling it short.

    Compounding payoff

    Which brings me back to that review of my log.

    Once Claude showed me that I was thinking with AI but not delegating to it, I knew where to push. I put stronger guidelines and structures in place so AI could do more of the work without me. I connected it directly to the tools I use every day so it could act in them instead of handing me instructions. I started building multi-step workflows instead of one-off prompts.

    My newsletter now publishes end-to-end. Once I’ve finished a draft, AI handles the rest (formatting, WordPress, the email broadcast, the social posts) instead of me or my assistant clicking through each step manually. None of it would have happened without a record for Claude to review.

    You can’t improve what you can’t see. Most AI use is invisible. It happens in private sessions nobody remembers a week later. The log is what makes it visible: to the person doing the work first, and to the leader coaching them to more effective use.

    Just don’t ask to read anyone’s diary.

  • What I tell CEOs who want a product team scorecard

    What I tell CEOs who want a product team scorecard

    How to have a conversation about something you can’t measure

    “How do I know if my product team is actually doing well?”

    The CEO had called me in to help figure out whether they had the right number of product managers. But within the first hour, the conversation shifted. The real question wasn’t headcount. It was whether the team was delivering. How could we tell? What should we be looking at?

    I had to tell the CEO what I’ve told dozens of leaders before: there’s no clean answer. No dashboard that tells you “your product team is a B+.” No DORA metrics equivalent for product management.

    My answer understandably received pushback. Engineering had velocity metrics. Sales had quota attainment. Why couldn’t product use something concrete?

    Fast forward six months. By the end of our engagement, the product development team was operating noticeably better: shipping more consistently, communicating more clearly, making decisions with less thrash. But we never found the metric. We didn’t need to.

    That’s the paradox of product team health. You can’t put a number on it. But you can talk about it.

    Why measuring product teams is so hard

    In product, we measure outcomes: conversion rates, retention curves, CSAT scores. We can build dashboards for everything our products do.

    But measuring whether our product managers are performing well as a team? That’s a different problem entirely.

    Sometimes an idea takes months to reach the market because the team iterated thoughtfully. Sometimes the best product work never ships at all. It dies in discovery because the team learned it wasn’t worth building. Both of those can be signs of a healthy product team, but neither shows up in a dashboard.

    It’s not because we haven’t tried. It’s because measuring product team performance is hard. The signals that matter are cultural, contextual, and specific to each company.

    So instead of a scorecard, I use a set of discussion prompts. The conversations usually happen with the people closest to the work (product managers, designers, engineers). But some of these questions also belong in a different room: with the CEO who wants to know how the team is doing, with finance, with operations. The people in the room change. The questions don’t.

    Those closest to the work already have intuitions about what’s going well. They just haven’t had the space to articulate it.

    The four lenses and their underlying questions

    I organize these prompts around four lenses for product team health. They cover the full cycle of product work: how teams gather information (data and user understanding), how they collaborate internally to ship (ownership), and how they coordinate with the rest of the company (communication). Weakness in any one area tends to create problems that show up elsewhere.

    1. Using data: Healthy product teams make decisions with data in the room. Perfect analytics aren’t required. What matters is whether data is consistently part of the conversation, and whether everyone trusts it enough to use it.
    2. Understanding users: Strong product teams have built systems for staying close to users, not just occasional practices. Research flows somewhere useful, and findings connect to future work.
    3. Team ownership: Gone are the days where product decides what to build, design figures out what it looks like, and engineering makes it. All three roles need a say in the direction. High ownership shows up when everyone feels invested in the problem — when a QA engineer pushes back on a feature idea because it doesn’t actually solve the underlying issue, or when a PM doesn’t need to detail every last requirement because the team already has shared understanding.
    4. Cross-departmental communication: Strong communication allows stakeholders to feel invested in product success and reduces busywork for PMs. It comes from shared language, effective async communication, and processes that make alignment easier over time. More meetings won’t fix it — back-to-back syncs aren’t sustainable anyway.

    Different product cultures will emphasize different lenses. A data-driven culture might invest heavily in the first. A customer-obsessed culture might prioritize the second. Start with whichever one feels most urgent for your team right now.

    Each lens has two parts. The observable signals are examples of what “good” tends to look like in that area. They’re meant to spark your own thinking, not a checklist to follow religiously. Bring the questions into the conversation, whether that’s a 1:1, a team retro, or a meeting with your CEO.

    Four lenses for product team health: using data, understanding users, team ownership, and cross-departmental communication

    Using data

    Healthy product teams make decisions with data in the room. Not because data always has the answer (it often doesn’t), but because it’s always part of the conversation.

    It comes down to whether the team reaches for data when making decisions, whether they trust what they find, and whether there’s enough shared understanding of metrics that people aren’t talking past each other. A perfect analytics stack isn’t required.

    Observable signals to watch for:

    • How often are decisions driven by data versus gut instinct, seniority, or internal politics?
    • Is there shared language around metrics across product, engineering, and stakeholders, or does everyone define success differently?
    • When a product decision is made, can the team articulate what they’d measure to know if it worked?

    Discussion questions:

    • Think of the last three significant product decisions your team made. What drove them?
    • What would it look like at your company if data was consistently in the room, even when it doesn’t give a clear answer?
    • Where does your data create more confusion than clarity? What’s one thing you could change about that?

    Understanding users

    Two things matter here: how often the team talks to users, and whether what they learn actually changes anything. For research to make a difference, it has to be easy to find, easy to apply, and shared widely enough that it doesn’t live in one person’s head. Plenty of teams do research. Fewer do it often enough, and fewer still let it shape what gets built.

    Observable signals to watch for:

    • Is there a clear path from a product idea → research → documentation of insights → connection to future planning?
    • Does engineering participate in user interviews? How often?
    • Can anyone on the team point to a decision that changed because of something users said?

    Discussion questions:

    • Walk me through what happens to a user insight after a research session. Where does it go, and where does it get lost?
    • What would it look like if engineering felt as close to users as product does?
    • What’s one thing your team has learned from users that surprised you, and how did you use it?

    Team ownership

    High ownership feels different from low ownership. It’s whether people feel like partners in what they’re building, or order-takers executing someone else’s vision.

    You can usually sense ownership levels within minutes of joining a team meeting. People say “we’re building” or “they want us to build”. Engineers ask clarifying questions about the problem or just wait for specs. When a launch goes sideways, the room goes quiet, or everyone leans in.

    Observable signals to watch for:

    • Does the relationship between engineering and product feel like a partnership or a handoff?
    • How much time does a PM spend detailing requirements versus co-creating direction with the team?
    • When something goes wrong, does the team investigate together, or assign blame separately?

    Discussion questions:

    • Describe a recent project. Did it feel like a team built it, or like someone designed it and others executed?
    • What does product-engineering partnership look like at its best here, specifically?
    • Where is ownership clearest on your team, and where is it murkiest?

    Cross-departmental communication

    Product doesn’t build in a vacuum. Sales needs to know what’s coming so they can set expectations. Marketing needs lead time to craft messaging. Customer success needs to prepare for support tickets. When communication breaks down, launches feel chaotic, stakeholders feel blindsided, and PMs spend half their time in status update meetings instead of doing product work.

    Strong cross-departmental communication shows up when other teams feel informed: when they understand what product is building and why. More meetings and longer emails don’t get you there. When it works, alignment gets easier over time.

    Observable signals to watch for:

    • Can sales, marketing, and customer success accurately describe what’s coming next, without asking a PM?
    • When a feature launches, do other teams feel prepared, or blindsided?
    • Does stakeholder feedback have a clear path back to product decisions, or does it disappear into inboxes?

    Discussion questions:

    • Think about your last major launch. Where did communication break down, and where did it work well?
    • What do stakeholders misunderstand about how product decisions get made? How does that create friction?
    • What would it look like if every team felt informed about the product roadmap, not just notified?

    After the conversation

    You won’t walk out of any of these conversations with a scorecard. That’s the point. What you’ll have is sharper language for what you’re noticing, and a few signals worth paying attention to.

    Resist the urge to turn all of this into a project plan. The value is in the conversation itself: the places where you agreed, the places where you didn’t, and the things someone noticed that you hadn’t articulated before. You may have identified a place or two where you want to start measuring. Take it slow.

    If the conversation got stuck on “we don’t have good answers to this” — that’s the answer. That’s where to focus next.

    Don’t push for consensus. Surfacing disagreement is as useful as finding alignment. It gives you an opportunity to dig deeper into what the organization values from its product managers.

    A few prompts for product leaders to reflect on during these conversations:

    • What surprised you?
    • Which lens felt most urgent for your team right now?
    • What’s one signal you’ll watch for over the next 60 days?

    Come back to these conversation prompts in six months. Or sooner, after a reorg, a leadership change, or a strategy pivot. The answers will be different.

    What the CEO got instead

    Remember the CEO who wanted to know if the product team was doing well? We never got the requested metric. But by the end of our engagement, we didn’t need it anymore. I could walk into a planning meeting and sense whether the team was aligned. The CEO could read a product brief and tell whether the PM understood the problem. We could feel the difference.

    That’s what these prompts are for: not a score, but a sense.

    You won’t get a number. You won’t get a letter grade. You’ll get shared language for what you’re trying to become.

  • The podcast I almost wasn’t on

    The podcast I almost wasn’t on

    I was silently saying no to an open invitation

    Andrew Capland kept posting in the Reforge community looking for podcast guests. He wanted vulnerable career stories. The kind where something went wrong and you figured your way through it.

    I kept scrolling past. Every time his post came up, my reaction was the same: why would he want to hear from me?

    I’d look at the other guests and start sizing them up. Their titles were bigger. Their companies were more recognizable. They had 5x my LinkedIn following. My newsletter subscriber count wasn’t anywhere close to theirs. I let my internal critic run the numbers and it was clear that I didn’t have anything meaningful to share.

    Every six months, Andrew would mention again that he was inviting us to be guests. And at some point, something clicked. He wasn’t looking for the most accomplished person in the room. He was looking for someone willing to be honest about the messy parts. The thing keeping me from volunteering (the self-doubt, the comparing, the “I’m not enough”) was exactly the kind of story he wanted people to tell.

    That was the irony that broke it for me. I reached out. He said yes immediately. He’d never been the one saying no. I’d been the only one with an objection, and I’d been making it on his behalf for months. Had I just trusted him in the first place, we would’ve done this a year ago.

    I had been removing myself from consideration before anyone else got a vote. I was contributing to my own gatekeeping.

    The backup speaker who used to pick the speakers

    The irony doubled when I realized I had done this before. I recognized a pattern. I’d done this before.

    Last September, I was invited to keynote at INDUSTRY, the product conference in Cleveland. Except I have been telling myself that “invited” is generous. Someone had pulled out, and I was the backup. Which meant I spent the weeks leading up to it wondering whether I would have been chosen if it weren’t an emergency.

    The other keynotes were Bobby Moesta, John Cutler. Leaders from Peloton and Carta. People I admire enormously. People whose work I’ve followed for years. I understood why every one of them was on that stage. I could not figure out why I was. They had bigger audiences, bigger brands, more name recognition (sound familiar?). I’m just me.

    The ridiculous part is that I know exactly how this works. I started my career as a conference planner. I’ve been on the other side of that lightboard, choosing speakers, managing the lineup, scrambling when things fell apart. I know you don’t pick a keynote by accident. And your backups? Those matter even more. You need someone you trust to deliver something great on short notice, with less prep time and no room to stumble. That’s a higher bar, not a lower one. I knew all of this. I’d lived it. And I was refusing to apply any of it to myself.

    The only thing that got me through it was a mantra I kept repeating: if I was invited, I belong here. Not “I’m the best person for this.” Not “I’m going to crush it.” Just: I was invited. That’s real. I belong here.

    Two stories, same pattern. And calling it imposter syndrome misses the point. This wasn’t a feeling I needed to abstract away. The issue was that I kept holding myself back: it was a behavior I needed to stop. I was opting myself out, deciding on behalf of other people that I wasn’t worth their consideration. Belief wasn’t my problem. My behavior was my problem. I didn’t need a mindset shift. I needed to catch myself in the act.

    The story I never bothered to test

    Both times, I was completely convinced I was reading the situation correctly. “He doesn’t want to hear from me” didn’t feel like a story I was telling myself. It felt like an observation. A reasonable read of the situation. “I don’t belong on that stage” felt like a fair assessment based on the lineup. Both were fiction. I never tested either one.

    There are already plenty of external filters in your career. You don’t need to add your own. But our brains are great at manufacturing excuses. Really, embarrassingly great at it. They’ll construct an entire narrative (complete with evidence, supporting arguments, and a confident conclusion) and present it to you as fact.

    And that’s what makes this so hard to catch. The fiction doesn’t feel like falsehood. It feels like you’re being realistic. It feels like you’re reading the room correctly, assessing the situation, being appropriately humble. Your brain isn’t saying “here’s a wild guess.” It’s saying “here’s what’s obviously true.” And because it feels so reasonable, you don’t question it. You just act on it. You scroll past the post. You don’t raise your hand. You apply for the safer role.

    When you notice yourself opting out of something (not applying, not volunteering, not speaking up), pause and ask one question: am I working from legitimate data or from a story I made up?

    The data was right there both times. Andrew had been inviting us for over a year. The conference had asked me to keynote. The other party had already said yes. I was the only one with an objection, and I’d manufactured it entirely on my own.

    The reframe is blunter than “believe in yourself.” Look at what’s actually in front of you. What did the other person actually say? What actually happened? What do you know for certain versus what did your brain fill in? Start there, not with the story.

    Infographic: three questions to ask before you remove yourself from consideration — What did they actually say? What actually happened? What did your brain fill in?
    It’s often hard to see the stories we’re telling ourselves without outside help.

    She confused the company’s story with her own

    I see this pattern constantly in coaching.

    One client had been living in fear of getting laid off for months. And the thing is, the fear wasn’t irrational. The company had been through multiple rounds of layoffs. The business wasn’t in great shape. There were real reasons to be worried about her job.

    But she’d taken the company’s performance and made it about her own. “The company might cut my role” became “They’re just looking for an excuse to fire me in the next round.” There was no data to support that. No PIP, no warning, no difficult conversations with her manager. The company was struggling; she was not. But she couldn’t see the difference anymore, so every project became a test: pick the safe thing, the visible thing, the thing that proves you deserve to stay. She’d traded doing work she was excited about for work that felt like it wouldn’t get her fired.

    When she started looking for new roles, the fear followed her there too. She was applying a level below where she’d been. Same logic: if I’m not good enough to keep, why would I be good enough for a role at this level somewhere else?

    That’s self-gatekeeping in action. She was removing herself from consideration, just like I was scrolling past Andrew’s posts.

    The first thing we had to do was separate the data. The company’s performance was the company’s performance. Her performance was a different question, and there was nothing in the data to suggest she was underperforming. Whether or not she got laid off, it wasn’t going to be because she wasn’t good enough. Once she could see that, she stopped shrinking. The projects she chose were based on her best judgement, not fear. She started applying for roles she was actually qualified for, showed up as herself in interviews, and landed a role where she’s been challenged, growing, and contributing in ways she hadn’t felt in a long time.

    I tell a lot of clients who are shrinking their own reach the same thing: what got you here will get you there. There’s a reason you’re in the role you’re in. Actually do the role.

    Recalibrate, don’t cure

    I’m not fully past this. I still catch myself doing the math, comparing my credentials to someone else’s, constructing a story about why I don’t belong. The difference is that now I know to check the story against the data before I act on it.

    Some amount of “do I belong here?” keeps me grounded. It keeps me preparing. It keeps me honest about what I actually know versus what I’m guessing at. The goal isn’t to eliminate self-doubt entirely. That would make me a different kind of problem.

    The goal is to stop letting fiction make my decisions for me. The real question was never “am I good enough?” It’s “what’s the story I’m telling myself, and is it actually true?”

    This article is based on a conversation I had on Andrew Capland’s Growing Forward podcast. You can watch the full episode here:

  • I thought I was a product builder. My own records said something else.

    I thought I was a product builder. My own records said something else.

    The 15-minute monthly habit that shaped my career pivot

    A few years ago, I decided to leave my in-house role and go independent. I’d done a values exercise where freedom and flexibility came out on top. Working for myself was the obvious answer.

    What wasn’t obvious was the niche. “Product management consulting” was too vague. It could mean anything to anybody. So I went back to my accomplishments log.

    Since my first product job, I’ve been keeping a monthly list of my wins — three or four bullet points, ten minutes at the end of every month. I’ve also been collecting praise: Slack messages, emails, or quotes from a stakeholder that recognized something I’d done. Screenshots, mostly. The whole thing started because Steph Ryter, the kind of professional aunt every early-career person should be lucky enough to find, taught me to keep a file. So I did.

    Most senior leaders don’t have that longitudinal career data when they need it. They hit a transition and try to reconstruct it from memory. At senior levels especially, the wins become more diffuse — you navigated a political situation, you built a team that hit its stride, you unblocked a stuck initiative. There’s no clean feature launch with a dashboard to point to. And even the details that do exist — the exact words someone said, the context of what you changed, the proof that something shifted — fade fast.

    By the time I was making this decision about going independent, I had the data going back to 2017. I sat down and read through it.

    I was sure the through-line was going to be product building. I’d shipped features. I’d led launches. The story I told about myself was that I was someone who got products out the door.

    But that story didn’t match what I was most proud of. What I got the most compliments for.

    What I saw, scrolling back through years of wins, was systems and culture. At SpotHero, it was the PM new-hire onboarding, the roadmapping process I’d redesigned with the executive team, the internal talks that had quietly reshaped how other functions worked. At the Linux Foundation — where I had no authority over anyone (you can’t tell open-source contributors what to do) — the work I was proudest of was the structure I put around welcoming in new open-source projects.

    Product launches were on the list, but they weren’t the spine. The spine was the systems work, the work that changed how a team thought about itself. I knew I liked culture. I hadn’t realized how completely it was tangled up with building processes in everything I did.

    That pattern became my consulting positioning.

    Here’s how I run my accomplishments log system – nearly the same process I’ve been running since Steph first taught me.

    Creating your general ledger of accomplishments

    The accomplishments log has two parts: an actions log and a praise log. Together they take about fifteen minutes a month to maintain. The format doesn’t matter. Mine has lived in Excel, then Google Sheets, then Coda, and at some point it’ll move again.

    The idea behind it is to create a record of your work: the accomplishments you’ve had, metrics you’ve hit, and projects you’ve enjoyed. The praise log highlights the wins others have seen you do, and the actions log highlights the moments that you think are worth remembering.

    Diagram showing what goes into an accomplishments log — the praise log and actions log
    The structure is quite simple and the value compounds over time.

    What others say about you: Praise log

    My brain keeps better records of what went wrong than what went right. The embarrassing flubs, the difficult conversations — those (unfortunately) stay sharp. Meanwhile, the wins fade or I discount them: that wasn’t really me, that was just luck.

    The praise log is the counterweight.

    Whenever someone sends you a thank-you or a shout-out, screenshot it and file it away. It might come from anywhere: a Slack message after a tough meeting, an email from a stakeholder, peer feedback from a review cycle, a passing comment from your CEO.

    I screenshot mine because the screenshot carries the exact words in a way that paraphrasing never will and reminds me that it’s authentic. “Ben said I was helpful to the Platform team” is not the same as the screenshot that’s been in my praise log since 2019:

    “Over the past few weeks Jenny has jumped in to help the Platform team in a number of areas. First, she’s volunteered to help us review our roadmap and reevaluate our priorities, outside of her day to day responsibilities. This help has been critical in helping us reevaluate our priorities and question some stale assumptions. Jenny has also been putting herself through the engineering onboarding process in an effort to help us understand what is working and not working. Her documentation of that experience will be indispensable for us as we revise the onboarding experience ahead of a surge in engineering hiring. Finally, Jenny also provided important feedback on our latest V2 API designs which were helpful in identifying areas where our language was unclear or were conceptually malformed. Thanks for going above and beyond to make sure that the overall engineering and product teams at SpotHero continue to do a great job!”
    — Ben Goldberg, SpotHero

    What I would have remembered: something vague about talking to Ben around a decision he was facing. Not three specific contributions. Not those words.

    Memory fades unevenly. The hard things stay sharp; the good things blur. And even when you do remember, you’re remembering your own version — what you thought you were doing, not what landed for the other person. The praise log is the only way to get that other version. Over years, it surfaces your own strengths more accurately than any amount of self-reflection can.

    What you say about yourself: Actions log

    Metrics are harder to retrieve than you’d think. You improved conversion on a key flow, you hired someone who ramped in record time, you hit a milestone that shifted the team’s trajectory. Six months later, the exact number is buried in a dashboard you no longer have access to, a Slack thread you’ll never find, or just gone. Capturing it in the moment is the easiest way to have it later.

    That’s what the actions log is for. It’s an investment in being able to tell your story — specifically, precisely, with the numbers still attached.

    On the last weekday of each month, I set aside a ten-minute calendar block and write down three or four wins. One lesson I’ve learned over time: don’t just write the win down, but to connect it to a goal I was pursuing and add enough detail that I can look back years later and know what I was talking about. For example, a few years ago I wrote down that I “delivered the premortem workshop.” I didn’t write down who I did it for, why it was happening, or what came of it. Luckily, I can piece that one together, but I’ve learned it’s better to just write down enough detail in the moment.

    I format it as a table with a few columns: what I did, what month it happened, how it connected to my goals, and any additional notes. Very simple. Each accomplishment gets its own line in the table.

    I also capture significant setbacks as context. If I was sick for two weeks, if a market shift blew up the roadmap, if a reorg consumed the month, I’ll note that. The reason isn’t to dwell on what went wrong. It’s so that when I’m reading back through years of entries and hit a month with almost nothing in it, I know why. Without that context, I’d be left wondering what was wrong with me that month, when the answer was just life.

    Compiling the logs is the first thing, but then the question is where to use it. Once you’ve got this data, you’ll find a number of different places where it’s extraordinarily high value. I found it so useful when it comes time to performance reviews, writing resumes, and we’re making career pivots. And it’s something very nice to have on a rainy day.

    This takes some of the stress out of performance reviews

    You can keep the accomplishments log for years before you ever do the big career-pivot exercise I did when exploring consulting. Long before that, it earns its keep every review cycle.

    When preparing for an annual review, most people spend the first chunk of their prep just trying to remember what they did. Digging through old emails. Skimming Slack. Looking over their calendar.

    The accomplishments log allowed me to skip that step. The stories were already there with the specifics intact. The praise log had exact quotes I could pull in.

    This let me jump to the framing phase — deciding which stories made the strongest case, how to position them, and what to emphasize. That’s where the actual leverage of a performance review lives.

    It also corrects for recency. One spring at SpotHero, my mind was fixated on a difficult incident from December, just a few months prior. My accomplishments log showed I’d led a major product launch the previous summer. I almost glossed right over it. I caught myself, pulled the launch into focus, and built the review around it. The December incident still got addressed. It just stopped overshadowing everything else.

    The same is true for resumes. Most people update their resume reactively, when they’re already in job search mode. But if you’ve just been let go, you’ve also just lost access to the data: the dashboards, the Slack history, and the emails with the numbers in them. I’ve been there. The accomplishments log was what I had left. Every specific I could put on a resume was already written down, from before the door closed.

    In both cases, the value is the same: you’re not reconstructing. You already have it.

    Visual showing the identity gap — the difference between the story you tell about yourself and what your data reveals
    What I see about myself and what others see in me tend to be quite different.

    Finding your through-line

    Performance reviews are the immediate return. But if you keep up this habit for years, you see even more value during the major transitions.

    When I was trying to figure out if I should go back into consulting, the values exercise told me how I wanted to work: independently, on my own terms. My actions log told me what I should actually be doing. They showed me a pattern about myself that I couldn’t easily see otherwise.

    I pulled out the wins I was proudest of. Looked at them together. What gave me energy? What kept showing up? What kind of work did I keep choosing, even when nobody asked me to?

    I now advise the senior product leaders I coach to keep their own logs. Sometimes we go through it together to create a clear pattern of their strengths over time.

    The answer might not match the story you tell about yourself. Mine didn’t. I thought my strength was as a product builder. The accomplishments log said systems and culture. That gap between identity and reality is the thing the wide-angle view exposes so well.

    Either way, you’re making the decision with data instead of gut. And as product people, how could we ask for anything more?

    Three moments where an accomplishments log pays off: performance reviews, job searches, and career transitions
    Here’s where I’ve always found the most value from the accomplishments log.

    The hard days

    There’s one more thing the praise log does that I didn’t expect at the beginning.

    On the days when it feels like nothing is quite right, I open the praise log. Not to feel better in some abstract way, but because the evidence is right there: even on the days that feel like everything went sideways, the log is still being written.

    At senior levels, impact is indirect and lagging. The conversation you had today won’t show its effect for weeks or months, if at all. You just have to have faith you’re headed in the right direction. The praise log is external evidence that the work has been landing, even when you can’t see it immediately. And that can help you keep going, despite the challenges of leadership.

    Start before you need it

    The accomplishments log only works because it exists before you need it. It’s near-impossible to build the data retroactively.

    Fifteen minutes a month. A recurring calendar block. Whatever format is easiest to maintain. Don’t over-engineer it. Just start.

    Mine has been running since my first product job, and that depth is what made the career pivot as clear as it was. I had years to scan when the moment came.

    You can’t see the pattern from the short term of what has happened recently. That’s not a flaw — it’s just how our brains work. The value of the log compounds over time, and the only way to have it later is to capture it now. Three months in, it’s a short list. Three years in, it starts to tell you something you might not otherwise notice.

    The story I told about myself was wrong. Not entirely, but enough to matter. I found that out because I had the data. Start collecting yours.

    If you want to try an AI version of this, Alexandre Cartier built a skill to run as a routine. I’d recommend still doing it yourself too, but an automated supplement might catch some things that you’d otherwise miss!

    Want articles like this in your inbox? Subscribe to The Next Iteration.

  • Build an AI edge your competitors can’t copycat

    Build an AI edge your competitors can’t copycat

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

    By Michael Goitein and Jenny Wanger

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

    “What AI features should we ship?”

    IBM asked a radically different question:

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

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

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

    Capabilities, explained

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

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

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

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

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

    Roger Martin's strategy cascade framework
    Capabilities need to connect to the rest of the strategy cascade.

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

    The four types of AI-enhanced capabilities

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

    Speed

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

    • Writing PRDs and product briefs
    • Code completion

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

    Consistency

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

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

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

    Scale

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

    • Monitoring all network traffic for anomalies
    • Tagging and pattern-matching based on every customer support ticket

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

    Skill

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

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

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

    The four types of AI-enhanced capabilities: speed, consistency, scale, and skill
    Lasting value comes when you cross categories.

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

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

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

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

    What makes AI capabilities compound

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

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

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

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

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

    Diagram of the capability flywheel — internal AI capabilities compounding into strategic advantage
    The flywheel accelerates. Each cycle funds the next, and the advantage compounds.

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

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

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

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

    How IBM turned internal capabilities into an advantage

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

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

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

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

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

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

    AI-enhanced capabilities exist to execute your strategy

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

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

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

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

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

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

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

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

  • I built an AI that critiques me after every call.

    I built an AI that critiques me after every call.

    Building AI automations that make you better, not just faster

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

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

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

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

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

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

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

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

    Deliberate practice in the age of AI

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

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

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

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

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

    The four components of deliberate practice mapped to AI workflow design
    Deliberate practice used to require a coach; now it requires a workflow.

    When a workflow tool is the right choice

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

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

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

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

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

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

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

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

    Enabling the four components of deliberate practice

    Use AI sparingly. Use deterministic workflows aggressively.

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

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

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

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

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

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

    Yes, I know this is a different example than what I use in the text, but the other one isn’t as easy to read.

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

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

    The feedback should be continuously improving

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

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

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

    Storing AI prompts externally in Coda for version control and iteration
    Seeing how my prompts evolve over time helps me make sure that I can always revert if need be.

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

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

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

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

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

    Know your Job To Be Done, singular

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

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

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

    I had lost track of the job to be done.

    I recently refactored it into several separate workflows:

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

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

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

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

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

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

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

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

    Loops are complicated in workflow building and code.

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

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

    Start with the feedback you wish you had

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

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

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

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

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

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

  • Your Offshore Team Is Probably as Frustrated as You Are

    Your Offshore Team Is Probably as Frustrated as You Are

    How to fix a low-trust relationship across an ocean

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

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

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

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

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

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

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

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

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

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

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

    The disconnect goes both ways

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

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

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

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

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

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

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

    Two overlapping circles showing that the frustration with offshore teams runs in both directions — the US team and the offshore team share the same problem from different vantage points.

    The decision guide: Match the symptom to the intervention

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

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

    Radio silence: You get finished work only

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

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

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

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

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

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

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

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

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

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

    The waiting game: No action without explicit direction

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

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

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

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

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

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

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

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

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

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

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

    The cold shoulder: Everything just feels extra hard

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

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

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

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

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

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

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

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

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

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

    Three patterns that break offshore team relationships: radio silence, the waiting game, and the cold shoulder.

    What has never worked for me

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

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

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

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

    What I do differently now

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

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

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

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

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

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

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

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

  • Earning the right to focus: Reader Mailbag

    Earning the right to focus: Reader Mailbag

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

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

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

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

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

    —Buried in Tickets

    Dear Buried in Tickets,

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

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

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

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

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

    Here’s how.

    Track your time and do the math

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

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

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

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

    Your time disappears quite quickly each week when you’re spending so much of it on ticketing.

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

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

    Write down your strategy

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

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

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

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

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

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

    Escaping the tickets

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

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

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

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

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

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

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

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

    Get organizational buy-in

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

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

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

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

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

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

    When the answer is no

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

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

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

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

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

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

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

    One win at a time

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

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

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

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

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

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

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

  • The product-first approach for hiring a coach

    The product-first approach for hiring a coach

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

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

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

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

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

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

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

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

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

    Why most coaching searches fail before they start

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

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

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

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

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

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

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

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

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

    What it is:

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

    What it’s not:

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

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

    The core sections of a CRD

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

    The questions you can ask yourself to find a great coach (source)

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

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

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

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

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

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

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

    One document, two critical problems solved.

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

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

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

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

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

    Use your CRD to get better clarity on whether a coach is needed.

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

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

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

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

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

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

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

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