There are two ways I get into a swimming pool. When I’m there to maximize my 1-hour workout before I take the kids to school, I jump in and start swimming as fast as possible.
When I’m at the pool with my kids, I’m the opposite. I’m one of those people who goes in step by step and then walks on my tiptoes until I’m ready to put my shoulders in and eventually get my hair wet.
In the previous article, I talked about how it’s important to get your hair wet to show what’s important to you, and I mentioned briefly the power of demos.
At one company, I pulled data around AI usage for individuals and managers and mapped that against data I collected in 1:1 interviews at all levels of the company. The data showed clearly that regular demos were one of the most consistent drivers of AI adoption across the 50-person product org.
But not every demo helps.
Fancy demos are scary
I have seen some really cool demos of vibe-coded apps, workflows, and tools.
For instance, one product manager at this company built a social listening tool that keeps an eye on all of the App Store reviews across platforms and synthesizes that feedback. It runs sentiment analysis. It groups things by category. It filters comments by release so that any product manager at the company can understand where the user base is complaining and where they’re happy.
It is awesome. It also took him hours to develop. Many, many hours.
On the one hand, I’m glad he showed off his work. It’s great work and deserves the spotlight.
On the other hand, when the team saw this demo, we felt like we’d use it, but we were never going to build something like it ourselves. It looks hard. Maybe even scary. You have to worry about data structures. UX considerations. You need evals and token monitoring.
Awesome demos show you what’s possible, but they can also intimidate people who are watching. They can make people feel, “Oh, this AI stuff isn’t really for me” or “I don’t have time to build something like this.”
Some days I’m not diving into the deep end. You also have to be in the mood for full immersion.
Simple demos aren’t lame
One of my best-received articles this year was about the AI diary skill I built. It’s mostly a write-up explaining how I did it, and the skill is essentially one simple prompt. It creates a file on your computer that logs what you did with AI that day.
One of the reasons is that it was what I think of as a simple demo.
A simple demo meets a few criteria:
It can be explained in a few sentences.
It can be copied in about half an hour.
It is useful enough that people want to try it themselves.
I can explain the AI diary in a sentence. It is just a one-paragraph prompt, so people feel, “Oh, I could do that, and it won’t take me too long.” The applications are clear, and it helps you improve your skills using AI, so people want it.
I demoed the AI diary with this client. A number of people were able to put it into action within minutes of me showing the demo. They saw how useful it was going to be for the next performance review, and how easy it was to get started.
At the companies I’ve been working with, once people try the simple demos, they start to feel like there isn’t a huge buy-in cost to using AI better. Once they’ve found a few first wins, they start thinking about their own ideas and use cases. “If I could do this, then I bet I could also do that.”
I used to call them “dumb demos,” but then I realized they aren’t dumb at all.
Have fun in the whole pool
The teams with the greatest success had both the simple demos and the fancy ones: a mix of what you can try now and where things can go in the future. The point was to encourage people to get wet up to their shoulders and to show that the deep end is really fun. Simple demos show that quality AI use doesn’t need to be fancy or complicated. Fancy demos show that there’s no ceiling to what you can do.
Managers kept it lightweight. They reserved 5-10 minutes at the end of their weekly team meeting for demos. They tapped 1-2 people to share no more than 5 minutes of what they did and a few lessons learned. No slides, minimal prep. They answered questions as they popped up. Occasionally the manager would be one of the people to demo.
You’ve definitely spent these 10 minutes on something less useful.
Simple demos tell your team that you’re building a learning culture. Fancy demos alone can make it seem like only high performance is valued (HT: Cat Hicks’s latest book, go read it). Simple demos communicate that small wins are encouraged. That learning is part of the job.
If you have a company where it looks like everyone is jumping in for a workout, the less confident swimmer won’t want to ease their way in via the shallow end and be there alone. They’re more likely to sit on the deck, dry and worried they’re not skilled enough. The right demos let them know that everyone is welcome, no matter how they get in the water.
Take the last few minutes of your next meeting and find someone who has been in the shallow end. Invite them to share a simple demo to show that everyone can join in the fun.
I didn’t notice that I was saying one thing and doing the other
This summer, I looked up at the beginning of June and could already feel that August sensation of “where did the summer go?” So I made a commitment to take advantage of the season. I wanted to be present with my kids.
One small change I decided to make: if I was going to be at the pool with them, then I was going to really be at the pool with them. Head to toe.
Before that, I was getting in with my kids, but I just often didn’t want to get my hair wet (curly hair, am I right?). Then I realized that a great hair day was not going to make my day a 10/10, while having fun with my kids could.
What happened in the water
My son is 4. He liked being in the water, and he was having fun, but in June he was stuck on the steps. Terrified of actually trying to swim.
I had been on the steps with him, encouraging him to blow bubbles and fetch dive toys. He was digging his heels in, refusing.
The same day I committed to always being fully in the water with the kids, I saw him change how he was playing. I was surprised.
That first day, he was willing to blow bubbles with me and put his eyes under the water with goggles on. The second day, when we came back, I convinced him to put his ears under. The third day, he was putting his whole head under. About two weeks after I started getting fully into the water with him, he was willing to swim to me a couple of feet out from the wall.
What dry hair was telling him
I wasn’t thinking about the signal I was sending. It’s not like I had been ignoring my kids when I was keeping my hair dry. I was in the water, splashing and playing with them.
He needed the commitment signal from me in order to feel ready to do something brave and new.
By not getting my hair wet, I was communicating that going underwater is not fun. It’s not something you want to do.
When I switched, I started silently saying, “This is fun. I like doing it. Swimming is great.”
I couldn’t explain to him the value of a great hair day or that I know how to swim. He didn’t see the choice I was making and what I was weighing when I got in the water. He could only understand what he saw in front of him.
I was telling him “go underwater, it will be fun!” He wasn’t listening to my words.
The shallow end at work
We all do what my son did. We look at what other people are doing and read their feelings and intent from their behavior.
One product leader I talked to was encouraging a lot of AI use but not going deep into it themselves. They were using ChatGPT conversations in the web interface to move their thinking forward or draft something, and then copy-pasting. Meanwhile, they were asking their teams to build prototypes and be deep in the CLI versions of these tools.
By staying in the web interface, they weren’t getting their hair wet.
In the AI transformations I’m working on, I’m seeing lower adoption on the teams where the leader isn’t aggressively using the cutting edge of the tools.
The team sees what the leader does. That holds for any change you’re asking a team to make, whether it’s a new tool, a new process, or a new way of planning.
Show that you’re having fun
How do you actually show that you’re getting your hair wet?
Demos.
I’ve spent the last several months working on AI adoption at a 50-person product organization. I’ve seen that the leaders who include demos in their team meetings (either of work they’re doing or work their team is doing) have better and faster AI adoption and skill growth than teams that use none of their meeting time for demos.
It’s not about one single demo. It’s about continuous demos and repeating the messages. It’s one of the things that got us to 95% meaningful AI adoption (people using it actively, regularly, and to produce better work). If a particular change is important, show that you’ve made it too. That applies whether it’s a new template for product briefs, a new tool for reporting, or a new skill to level up.
Look at the changes you’re asking of others. Then ask if you’re showing them that it’s important to you too and worth your time.
Even if you know how to swim, you need to show that it’s still fun to learn to swim.
AI is still single-player. A Denver panel on what that’s doing to designers, engineers, and PMs.
On September 14 I joined a panel in Denver called “Blurred Lines,” hosted by AI & Product Colorado. The premise came from our moderator, Lauri Hofherr. Over the past year she kept meeting engineers writing PRDs, product managers coding prototypes, and designers doing all of the above. She’d billed the event as “Everyone’s a little bit PM now.”
To kick things off, she read one of my LinkedIn posts back to the room:
Design: Why do PMs think what AI built is usable? Engineering: Why do designers think what AI built is shippable? PMs: Why does engineering not want to move faster and code with AI?
AI is still single-player. Every time one of us reaches for it, we solve our own piece alone — faster, but alone. The trio that used to build the thing together has stopped building it together.
The original post is still open for comments if you want to add your own take.
Lauri’s question to the panel was whether that’s true. Here’s who answered:
Jake Taylor, Senior Director of Product Design and Research at JumpCloud, who spent the past year leading JumpCloud’s move to an AI-native product development process
Riley Scardina, principal technical recruiter at Code Talent, which hires for early-stage and high-growth companies
Jason Fletchall, fractional product and tech for startups with non-technical founding teams, after 15 years in product at companies like eBay and HelloFresh
Me (Jenny Wanger). I coach product leaders through team transformations, including AI adoption.
The conversation below is edited for length and clarity and grouped by topic, so it doesn’t always follow the order of the evening. Questions from the audience are marked.
Has building together turned into building alone, faster?
Jake: I don’t see the speed and efficiency yet. It depends on the organization you’re in and the competencies within the disciplines.
PM has a great perspective on the business and the user. Design still has a focus on experience and the user. I still really want to respect the boundaries of what people are good at.
Snap was one of the more famous companies that only hired product-focused designers, well into hundreds of millions in revenue. You can’t find those people all the time. You can find very good individual disciplines.
I’m more than happy to encourage and grow the individuals who want to cross the lines and do things. And they have to be pretty good to do those things, just to be clear.
So until we get to that point, I think it’s still three in a box, the trio. That’s what it takes, in my mind, to build a successful product.
Jason, you’re basically running the single-player model with your clients. At what point does that stop working?
Jason: With AI tools I can get a lot further with a startup than I used to. It used to be that I could do the research, work out business viability, and understand the customer problems. But if we wanted to prototype something and get it in front of an actual customer, we needed a developer.
Now we don’t necessarily need the developer at that stage. We will need the developer and dedicated design once we’ve gone beyond initial learning with customers, we have a real product with real customers, and we want to grow it and scale it.
Once you’re getting to more users, the decisions you’re making carry much higher risk, and you want to start focusing more with the different disciplines.
Jenny: That’s the exact logic I keep hearing. “We can do the prototype, so we don’t need to involve the developer in customer discovery right now. We’ll pull them in later when we need them.”
I’m seeing that at a client right now. The PM is saying, “I’m not going to bother design with this, because they’re busy. I can knock it out with Claude, get it pretty far, and loop design in later.”
All three roles, talking about the other two, are saying “I’ll call the other person later. I can get this further right now.” But there’s a huge cost to that.
Jake: There’s a debt that you rack up.
Jenny: You are racking up debt. And it feels so easy to do it single player.
I can be on my phone on a walk, throw something out there, and have a prototype when I get home. So I don’t need to be in a meeting, because I can be on a walk. That’s where we’re running into the friction.
Jake, you spent the past year redrawing where design, product, and engineering start and stop at JumpCloud. Did that fix the collaboration problem, or just move it?
Jake: It’s just a different mess.
The process is defined, it’s documented, it’s enabled. What I’m seeing now is that PMs, as they should, are very into the feature they’re building. But they’re investing way too much time in that idea.
By the time it gets to my team, the person who spent 30 hours and loves their prototype made a ton of user experience mistakes along the way. It didn’t get them nearly as far as they thought.
My team now has to backtrack, figure out what they were actually trying to achieve, and align it to the good patterns we have in the product.
They weren’t using the components from the design system we gave them. They went astray with a lot of different flows. So there’s additional tech debt that immediately got tacked on.
The process is supposed to be: get your idea onto the screen, then start being collaborative, and my team will help you build it the right way. Just like engineering helps us when my team messes something up.
Riley, how is this showing up in hiring?
Riley: People are really burnt out, because they’re having to do things they don’t want to do, or that they’re not necessarily the best at.
We work on a lot of product engineering roles, and startups in the Bay Area in particular want the product engineer to get in front of customers, do the designs, and build out everything on the back end.
They’re all looking for that generalist, that builder, so everyone’s competing for the same profile. And not a lot of people want to do it, because they’re getting really burnt out.
If you do that at an early-stage company enough times, either you’re successful with it and you become the founder, or you burn out.
Jenny: The product manager job has always come with unrealistic expectations. Do product marketing, help with design, do the user research, work out business viability, get everybody on the same page, make sure engineering isn’t blocked, and keep everyone updated on status. That’s never been realistic.
Now we’re adding, “And can you also do a prototype? Just make it look nice.” And “Did you see the 10 things Anthropic released into Claude Code last week? Have you tried all of them yet?”
The PMs I work with are falling into two camps. One camp is retreating: “I’ll get to AI eventually. I’m too tired. If you don’t make this easy for me, I’m not doing it, because did you see what’s on my plate?”
The other camp is so scared of being left behind that they’re spending all their nights and weekends learning AI and learning to prototype.
Some of them are saying it’s the most fun they’ve ever had. Others are saying, “I miss my kids.”
Jake: Nights and weekends were the only way I got to where I am, in a position to lead teams through the transformation.
I tell people it’s like any other new skill. The gym is awkward when you first go. You build a routine, you get consistency, the muscle gets bigger.
But I get the other side 100%. I’ve done this for 20 years. I’ve learned 20 new tricks for the 20 years. I have two kids at home. I can’t do it nonstop.
Jason, have you had a client you had to rein in, where AI had convinced them they were more of an expert than they were?
Jason: I had a client who had coded a lot of the first version of their product and was really proud of it. We’re still working through building things a different way, so it isn’t going to fall apart because their version is built with spaghetti string and hopes and dreams.
What’s worked is helping them recognize where their talents and expertise really lie. “You can focus on that area. Don’t worry about the rest. I’ll bring in how companies typically do this.”
Jenny: That ties a few of these topics together. Jake, you described the PM who coded something that’s missing key usability and accessibility pieces, so your team has to rewrite it.
I’m hearing the same thing from engineers: product just handed me this prototype, and the code underneath is spaghetti string and hopes and dreams.
Someone in the audience said earlier that they used to solve coding problems and now just review AI’s output. Nobody becomes an engineer to spend all their time doing code review, and definitely not to spend it fixing somebody else’s hopes and dreams.
It also puts the other person in an awkward position. They’re thinking, “Can’t I just throw all your stuff away and start over? That would be easier.” But now there’s an interpersonal complication, and it feels weird to ask.
It gets worse with hierarchy. The executive codes a prototype over the weekend, hands it to an engineer, and says, “Isn’t this cool? Can we ship it?”
This is threatening people’s identities, the reasons they got into these jobs in the first place. That’s feeding the burnout, the burnout pulls people further apart, and the cycle keeps going.
Nobody decides to join this loop. Everybody’s in it anyway.
From the audience: what about people pushing AI-built work to production before it’s ready?
An audience member asked about AI-built products that didn’t work out. Lauri sharpened it: everyone thinks they’re a coder now, so what happens when people push code to production that isn’t ready?
Jenny: One thing I’ve been working on with my teams is the term “throwaway prototype.” Instead of going to your engineer with “Hey, I made this prototype, what do you think?”, which forces them to look through the code, say “I made this throwaway prototype because I wanted to communicate this idea. What do you think?”
The adjective you put in front of “prototype” sets the scene for what the interaction is.
We don’t ship prototypes. We ship hardened products. But “prototype” standing on its own doesn’t tell anyone what you’re trying to learn.
Do you want to put it in front of users to test usability? Or, as I heard from a couple of PMs, did the engineer say something wasn’t possible in our system, so you got Claude to build it to show it’s feasible, and now you want their opinion on whether it’s a viable approach?
Those are completely different uses of a prototype.
Jake: Figma used to save us here. You were presenting a concept that was nowhere near code-ready, and the engineers got it: “This is a Figma. I’m the one who has to chop it up. I’m the one who makes the core decisions.”
Prototypes are meant to be just that. They can’t go into production. They test a theory.
From the audience: “The simple answer is more collaboration across the triad. What else gets us to a better future state, without piling up more technical debt?”
Jason: I’d love to talk with the frontier AI companies about how their interfaces could better support collaboration. I’ve been working on a client project in Claude Design. It’s very good at getting to a design you can click through and see whether it meets the need.
But when the client wants to make modifications or suggestions, it’s really hard to have the back and forth you used to have on a Miro board or a whiteboard. The tools don’t support that right now.
It’s still individuals working with their own instances of Claude. I haven’t found the silver bullet yet.
Jenny: The guideline I’m using right now is: wait for the other function to invite you in.
At the client I’m working with, design was getting really frustrated by all this. So I worked with them to put together a workshop for PMs on using Claude Design to make prototypes.
We specifically encouraged PMs not to prototype in the actual codebase. Instead: take a screenshot and work in Claude Design, using the design system the design team built and hooked up so you pull in the right components, with the guardrails design wants around it.
Another example: this company is short on data scientists, so they can’t respond to every request.
The data team built plugins with the data dictionary and instructions on which tables to use, so you can ask Claude in plain language, “How many users from the EU tried to access this feature last week?” That replaces “I wrote this SQL query, can you check it?”
You’re going into their territory on their terms, instead of going in on your terms.
From the audience: is any of this producing ROI?
Alex (audience): Moving faster with mid code or mid designs that ultimately get thrown away isn’t ROI. At a bigger company, ROI is reducing costs: fewer people, fewer tools.
Three years in, I’m still asking ROI questions to a lot of leaders and getting mixed answers. Jake, are you hiring fewer people? Or are you telling the C-suite design brought in 3x the revenue?
Jake: We are seeing more productivity. The biggest ROI is in what used to be a handoff from a static Figma prototype. Now it’s working code using our design system components and our vetted layouts, and we’re doing code reviews, which helps engineering with the implementation.
There’s less design churn, because we’re giving engineers the components they would have been creating on their own, instead of “What font was that? What size was that?”
As far as staffing, we’re fairly flat. The hope is to do more with the people and the capacity we have.
Jason: What I’ve been hearing on podcasts is this idea of ambition, which I don’t think a lot of companies have figured out. Making existing tasks more efficient is the low-hanging fruit.
The harder part, with any technological innovation, AI included, is what more a designer, a product manager, and an engineer can now do together.
Startups are having an easier time seeing that. At larger companies, I don’t know if many have figured it out yet.
Jake: JumpCloud’s been around for 13-plus years. At companies at our stage or bigger, the CEOs and stakeholders all want the decrease in headcount and the increase in ARR. I don’t think they understand how far away the rest of the organization is from that.
Startups that began in the last few years built their code with AI, and AI loves AI-driven code. I could go in there without a lot of guardrails and crank out features.
In an environment that’s fragile, with a lot of dependencies, I cannot push to prod. I don’t want that accountability.
We saw that in the market last year with the huge cuts.
I knew people who got cut in those rounds, and I asked them, “Were you AI everywhere? Were you automating everything?” They said, “No, Jake. We weren’t anywhere near the efficiencies they said we were at.”
Lauri: So AI got the blame for a lot of headcount reduction last year.
From the audience: is engineering turning into a gatekeeper that just reviews AI-written code?
An audience member picked up on something Jake had said: his design team now writes working front-end code and hands it to engineering. Does that make engineering a gatekeeper to production, reviewing AI code that’s already been written?
Jake: Engineers are the gatekeepers. My team owns the front end. We don’t own the back-end logic or the dependencies, and we don’t have deep knowledge of all the APIs.
I wouldn’t even trust AI to push in the environment I work in. So engineering ties in the back-end business logic, and we test it, proof it, file bugs, and fix them. We’re not trying to venture into the back-end world at all.
Lauri: That’s especially true in legacy code, and most companies are legacy code.
Jenny: I’m the biggest advocate of engineering setting up systems that enable everybody else to ship code. But that’s engineering’s responsibility, engineering and QA.
When people ask what role to go into in tech right now, I’m excited about SREs, QA, SDETs, the people who think about code quality in a meaningful way.
What all these organizations need is agentic checks: proper test coverage, and real tests. I love when you tell AI the test fails, and it says, “Oh, I guess I’ll just change the test then.” (Cue the sarcasm.)
You want real coverage and AI-driven code review that knows when to say “this one needs a person to look at it” versus “this is a color change on a button, it’s all good.”
Right now the bottleneck is landing on “I made this, can you code review it?” It changes the conversation if everybody feels confident that engineering isn’t going to be the one left holding the bag when you vibe coded something.
Jake: We’re stepping into other people’s turf, and we need their help to tell us what’s right or wrong. That’s where strong partnerships come in.
If you have good engineers who are willing to take the time to educate, put the right guardrails in place, and be on call for questions and code reviews, the more they do it, the more you’ll see [companies like] Linear shipping end to end, regardless of a design role or a PM role.
But people miss that it took so much enablement, so much effort, so much partnership to get to the stage where it doesn’t fail every time.
Jenny: And what do you think, Riley? Should I be bullish on SDETs?
Riley: Evals are such a hot topic right now. Everyone is hiring for it. We’ve even heard of PMs at startups running evals.
And SRE, heavy back-end work, and security are top of mind in hiring, and a rarer skill set for us to find.
From the audience: do organizations need to change in a bigger way to get the most out of AI?
Jake: A traditional enterprise could have been super efficient: ARR going up, product-market fit, listening to customers.
AI came in as the largest curveball it could, and it’s completely unmeasurable at this point. We’re shipping a lot of features, and most of them are stable, but everybody knows more isn’t always better.
It’s created a false sense of urgency. We already had a sense of urgency, and now it has to be a true emergency all the time, at emergency pace.
Jason: I don’t think anybody really knows what future organizations are going to look like.
Big technological innovations tend to create new types of roles and new types of organizations. We don’t know what those are yet with AI.
Jenny: Figuring out how to use AI as a trio is a cultural change, and it’s being forced on us whether or not we want it. The big question is which direction we go.
Do we figure out collaboration patterns that work? Or do we end up with 20 solo builders as the entire product development team, each owning something in a silo?
I’m hearing the ratio question too. It used to be that one PM, four to six engineers, and one designer was the ideal team.
I’ve heard “just get rid of the PMs, it’s an engineer and a designer.” I’ve heard one to one to one. I’ve heard a PM plus an engineer, and, sorry design [to Jake], you’re the ones being squeezed out in the current discourse.
The companies trying to hold on to how they were before are the ones really struggling right now. That’s part of why this is so painful. The change is being forced on us.
Jake: The 20 silo builders is the thing that scares me. Everywhere I’ve built product, other people align to what you just built. You built a new service or a new API, and it pairs with this other thing.
When you hear it from Anthropic and the people shipping code on the train to work, they still haven’t shown us how they coordinate that much solo output at such a crazy rate.
If Jenny shipped something yesterday and Jason shipped something today, I’m already 20 features behind, and my feature should tie into what they just built. I don’t know how they’re doing it. You kind of wonder if it’s all just going to fall down.
Jason: Companies are based around humans. We built these structures not just because they’re the efficient way to run a business, but because we collaborate with other humans really well, and we like to do that.
Maybe in theory the most efficient way to build is to have one solo person in charge of everything. I don’t see evidence of that being realistic yet, and I doubt that’s where we end up. We’re still going to have organizations of people with different areas of expertise, working together to solve problems.
“I’m so busy I haven’t had a chance to think about how to actually do it better.”
Someone tossed that my way near the end of our 1:1. It sounded like a complaint about their calendar. Every product person I have ever managed has said some version of it, and most of the time they are busy. Welcome to product management.
I made a note to talk about priorities and time management next time.
But as I thought about it more, I got the sense that this requires a different kind of attention.
I’ve heard some version of this throughout my career, as have most product leaders. Sometimes the comment arrives with the label attached.
“I’m overwhelmed.”
“I think I’m burned out.”
And sometimes they don’t say anything at all. Yet they look tired in every meeting. The energy has disappeared when they talk about their own work. They’re seeming disengaged in an almost-dejected way.
You noticed. The first feeling that comes up is alarm. This is someone you rely on, someone you would have real trouble replacing, and they’re now a flight risk. That’s worrying about yourself.
Then you start to think about their experience. Logging on every day and dreading it. Feeling tired, some kind of brain fog. The emotional weight of what they’re carrying.
You want to help, and you don’t know how.
Lessening the workload isn’t a real option
The default is to lighten their load. Ask about workload. Cancel some meetings. Suggest they take PTO. Encourage better boundaries. It’s standard enough that it barely registers as advice.
This creates problems.
One problem with it is you still have goals to hit and work to do as a product team. Having one person working lighter than the rest creates inequities and risks resentment that you don’t want to encourage.
The other problem is that lightening the workload frequently doesn’t work for them.
Last week I wrote about the kind of burnout where rest doesn’t help: the exhaustion that comes from the gap between who someone believes themselves to be and how they’re showing up at work.
The data backs it up. In Evie Brockwell’s research with Product Academy, 72% of product people who’ve experienced burnout have experienced it more than once. If rest were a good answer, the return of the burnout would be rarer.
So here’s what I do instead, in the coaching chair, when someone brings me phrases like these.
I’m not a mental health professional, and nothing below is clinical guidance. It’s what I’ve done and watched work with a number of product leaders. You must flag when they need better help than you can offer.
You can also try these same steps on yourself. I’m writing for the manager, but if last week’s piece described you rather than someone on your team, try these questions as a self-reflection.
Believe them
The first move is an acknowledgment.
Burnout is real. And if they’re scared that the person responsible for their professional growth doubts them, it creates additional layers of challenge.
If they’ve used those terms with you, then mirror the same language back. If you’re worried they’re burned out and they haven’t said those exact words, ask questions about their experience and wellbeing to see if you can find their language.
That has to come first because some people who are burned out also experience shame about feeling burned out.
Brockwell’s research puts a number on that too: 43% of product people say burnout is a taboo topic at work.
Once you’ve said it, stop talking. Let them steer the next few minutes of the conversation and confirm that they are willing and ready to talk about it.
Ask about expectations, then listen
Once they’re ready to talk, there are three questions to move the conversation forward. Make it clear this isn’t a performance review. All of them are about internal and external perceived pressure:
Where do you feel like you’re meeting your own expectations?
Where do you feel like you’re not living up to them?
Where do my expectations, as your manager, add pressure? Or where do you feel like you’re not meeting those?
“How do you see yourself? Any internal contradictions?” is an enormous and abstract question to toss into a conversation. Meanwhile, many of us are already carrying a running inventory of where we think we’re falling short, making these three questions easier to answer (hello, high-achieving product managers).
The third question requires you to be vulnerable. It puts your own expectations into the room as a possible source of the pressure, which gives your report permission to be more candid.
In coaching, I’ve seen a lot of my clients mention the pressures their manager is putting on them. But when we peel it back a little bit, it turns out those were fabricated expectations. (I’ve done it to myself as well.) As a manager you can say a small thing and the person hearing it can blow it out of proportion.
Once you’ve asked, again it’s time to listen. What you’re listening for is two things that can’t both be true.
In the last article I introduce Maya who was on the job hunt. She gave me a version of herself as a high performer, and in the next breath told me she was on autopilot at the startup (“I’m holding back over there. I’d rather prioritize my energy on the job hunt”).
I also talked about Jordan, who described himself as a builder and a get-it-done person, and in the same conversation described his work as something happening to him.
Neither of them said “I’m misaligned.” They said things that contradicted each other.
When you hear the collision, stop working the question list and dig in. Say it back to them in their words.
Then stop talking and wait patiently (stopping and letting them speak is a theme here). They’re deciding whether to agree with your observation, and they need to get there at their own speed.
Look for evidence against the story
Once someone is living in that gap, they’ve built a narrative about themselves full of confirmation bias. So the next move is to evaluate the stories against the truth.
For Jordan, that meant an accomplishments log: writing down what he’d done over the previous quarter. His narrative was “I’m not adding value.” The record disagreed. He didn’t get to the transformation he’d wanted to lead, but there was a lot he’d done and subsequently decided “didn’t count”. We walked through those to reevaluate if those wins should be so easily dismissed.
Maya’s version equated the interview pipeline with her performance. She’d accepted job rejections as a verdict on her skill set. Over a decade of building and running teams was sitting right there, discounted.
As their manager, you can bring your own data too. You have review notes, project history, feedback from the rest of the team, and your own memory of the year. You can say “from where I sit, here’s what actually happened.”
One risk is that you skew the bias the other way, lingering too far on the wins without acknowledging the misses. This is an opportunity to be balanced and truthful. They need to trust you and the data.
Narrow the gap
At this point you’ve got a hypothesis about what’s causing the burnout symptoms. Now it’s time to figure out how to narrow the distance between who they are and how they see themselves.
Again, ask permission to move into this space with them. Don’t force these questions on your report if they aren’t interested. As their manager, they’re already going to feel pressure to say yes and be more agreeable. Give them the out.
It might take a few different approaches. Jordan used most of these.
Look directly at the emotional state. At one point Jordan admitted he’d been too busy to look at the frustration and disappointment underneath it all. Naming them out loud seemed like it would be a waste of time. But we tried it anyway, and saying it out loud was the first real unlock to seeing the other side of his burnout. He realized that staying silent about it just let it fester instead. The negativity was building on itself. (Maya also had to admit what was going on to start figuring out how to move forward.)
Define what is temporary and what is enduring. “Until I have the right team to support this scope, I’m going to be doing the operating rhythm work instead of the transformation.” That sentence moved him from “this is who I am now” to “this is where I’m at right now.” We shifted the conversation from a self-definition to a situational assessment. That created space for some conversations without self-criticism.
Reshape the role to better fit the person. Jordan worked out that getting unstuck from the operating cadence meant articulating how under-resourced the transformation work was. He took the opportunity to push, strategically, for staffing the company goals effectively. He made the business case, got headcount, and his report returned from parental leave. With each person he’s onboarded, he’s been able to focus more on the team changes instead of keeping the lights on. The role changed, not just his attitude toward it.
Sometimes the role is not a fit. As a manager, we also have to have the conversation about whether the role itself is a fit. There may be enough factors to realize that this person can’t be set up to succeed in this environment. The kindest thing to do at that point is talk about different opportunities. (and it really, really sucks)
With these steps, in Jordan’s case, the work went from something being done to him to something he gets to do. In his words, he’s “returning to the person I want to be.”
And I’ll be honest, it isn’t a total cure. But if Jordan finds himself saying “I’m too busy to be disappointed about X,” he catches it now as an anti-pattern. We talk through those moments more in coaching. He’s figured out that self-advocacy is a major part of what makes him feel agency in his role, and so he’s been standing up for himself more.
In other words, he has a toolkit.
As the manager, your job through this is thought partner, not fixer. Some of these you can help with directly (Jordan’s hiring case was a business argument that needed a sponsor). Some of them you can only encourage (you can’t force them to name their feelings, or tell them what they’re feeling).
The limits of your seat
You are the manager, neither an uninterested third party nor the person living with symptoms of burnout. And you have to reckon with what it means to be in that seat.
The first is that you’re inside the dynamic. I have no political stake in how my clients show up at work. You do. You’re their manager, you’re invested in a particular outcome (they stay, they leave, they take the role, they don’t), and that stake shapes what they can tell you.
When someone hands you a clean external explanation (the calendar, the reorg, the headcount), take it as the first layer rather than the whole account. And if the deeper version turns out to involve you, don’t get defensive. Accept their explanation and be on their team.
And sometimes the best thing you can do is help them get better help than you can offer. None of the moves above substitute for clinical support. Hand it on to someone better equipped when:
The exhaustion has moved past work. “I’m having trouble falling asleep because work is in my head all the time.” Sleep, health, pulling back from things outside the job.
Anything that sounds like a person in crisis.
If a topic surfaces that your employer is obligated to act on: harassment, discrimination, a medical accommodation, leave. That goes to HR immediately. Running a coaching conversation on top of one of those can do real harm, to them and to the company.
You’ve tried these moves and nothing shifts. Whatever is going on is bigger than a gap the two of you can cover in a 1:1.
Then have the next step ready. Know where your company’s EAP or mental health benefit lives before you need it, not during the conversation. Bring HR in early rather than late. And tell the person plainly why you’re doing it. Handled well, none of that is a betrayal of the 1:1. Handled clumsily, it is.
Escalating doesn’t end your part, either. You’re still their manager. The workload conversation, the role-shaping conversation, and the “I’m glad you told me” all still belong to you.
Back to where this started
Jordan mentioned burnout on a coaching call.
Believing him came first.
The expectations questions are what turned up the contradiction: a builder, a get-it-done person, describing his own work as something happening to him in the same breath.
The accomplishments log is what turned “I’m not adding value” from a verdict into a question. The log was full of decisions he’d made and outcomes he owned that he’d stopped counting.
We narrowed the gap with three moves: naming the frustration he’d been letting stew, separating what was temporary from what he’d started treating as identity, and making the business case for headcount so the transformation he cared about had a real shot.
What all three turned up, in the end: he wasn’t too busy to think about how to do the job better, and he didn’t really need a break. He just felt it was unproductive to admit he was frustrated. Grinding through instead meant he felt his own bar had slipped.
Swallow the frustration, feel like you’re letting the standard slip, feel worse about the work, repeat. Talking to me about this is most of what got him out of it. In his words, that’s what let him start “returning to the person I want to be.”
Because of the sensitivity of this topic, I have changed names and key details of each person mentioned in this article.
If any of this is landing somewhere heavier than reflection, if you’re dealing with depression, anxiety, or exhaustion that reaches past your work, please talk to a mental health professional. Coaching is built for the “I recognize this pattern and want to think it through with someone” moment. It isn’t a substitute for therapy or clinical care.
Maya spent over a decade at a healthtech company. She worked her way up from IC to people manager, running her own team, and she was thriving on the director track. Then she stepped back to deal with a health issue.
Now she’s a fractional product leader three days a week for a startup while job-hunting to try and return to enterprise work. That health situation has since resolved. At three days a week, this is the lightest workload she’s had in many, many years. Yet she’s been struggling with feeling burnt out.
The most common advice I see for product leaders facing burnout is to rest. Take PTO. Meditate. Lighten the calendar. When rest doesn’t work, the next piece of advice is to quit and find a different company. In coaching, I’ve watched enough people follow both playbooks to know they don’t always fix the problem. Maya’s story can help show why.
She came to me for coaching after reading a post of mine sharing my experiences with how rest doesn’t always help. That resonated. She came to me to figure out what was going on under the surface.
On our call, she talked about the interview grind. She’d tried not doing too much prep, then tried a lot of rehearsal. No matter what she did, she’d go into the room and bomb it. The offers weren’t coming in.
She ran a hand over her face as she said: “That’s how I feel with burnout, that I’m doing so many things but nothing is ticking or landing.” She blamed the burnout for blocking her ability to be successful in interviews.
With all these job-hunt failures, a different question surfaced in her mind: was she actually not as good a product leader as she thought? She had recently switched to applying to lower-tier roles — less pay, less responsibility — because she thought that was the market signal. But she still wasn’t seeing success.
She knew she was burnt out. What she didn’t know was what kind, or whether other product leaders were going through it, or what she was supposed to do about it. Something beyond needing some more time off was going on here, so we dug in.
Maya on autopilot
When you listen to Maya describe her prior role, you can hear the joy in her voice. In her words, she could “get into the weeds yet really strategize.”
Leaving a job she loves to deal with a health issue wasn’t an easy choice. And as things stabilized, she didn’t want her skills to go stale. This fractional role seemed like a perfect fit. Not too time-intensive, interesting enough. A startup, so new skills to be gained there.
When talking with me, she admitted that she was on autopilot in her fractional role. “I’m holding back over there. I’d rather prioritize my energy on the job hunt.”
She added, almost surprised to hear herself, that this was the first time she’d actually said it out loud. The startup is on her resume. The startup is what she’s doing with her days. And by her own account, she’s giving less than her full effort.
I took this moment to mirror her words back to her: “You have a belief about yourself that you are a high performing person. I heard it all through your story. And so here you are coasting through this startup, and that doesn’t align to how you see yourself. That’s the gap.”
She took a deep breath before she replied. “Exactly. There’s absolute truth to it because I know I’m not presenting the ideals or the work values that I have.”
She’s not just burned out from the misalignment at the startup. She’s also letting the bad interview rounds shape her self-perception. The gap between who she believes herself to be and the evidence she’s collecting about herself is widening from both sides at the same time.
She’s going into each interview feeling like a liar, presenting a version of herself she’s not currently living up to. That’s hard to sustain. Of course she’s exhausted.
Naming it was the pivot for Maya. Once she could see the gap between how she saw herself and what she was actually bringing to work, she had somewhere to aim.
Not really about workload
Some burnout does come from doing too much. Rest fixes it, and if that’s what you have, take the rest. But over and over in coaching I’ve seen another version of this. Someone comes back from PTO, from a sabbatical, from cutting their hours, and the exhaustion follows them right back into the office. That’s the version I’ve been describing with Maya.
What’s underneath isn’t workload. It’s a mismatch between who you are and what your current role or workplace is actually asking of you.
Sometimes the source is the environment: a role that doesn’t use what you’re best at, an org that keeps your real work off your calendar, a team dynamic that keeps you performing a version of yourself you don’t recognize.
Sometimes it’s you: how you’re engaging with the work, what you’re telling yourself about it, the parts of yourself you’ve been holding back.
Usually it’s some of each. Either way, the mismatch shows up as a gap between the version of yourself you thought you’d be at work and the version that’s actually showing up.
You can be doing very little and be burnt out. You can be doing a lot and not be. The variable is the size of that mismatch.
When you’re living out of alignment, you read everything as more evidence: the slow startup, the failed interview, the operating meeting that isn’t the work you wanted to be doing. The gap feeds itself. The longer it goes, the bigger the evidence pile against the version of yourself you want to be. That’s part of why it’s so hard to rest your way out of.
Maya’s case is one version. Let me introduce you to Jordan.
Jordan drowning in operating cadence
Jordan is a director who describes himself as a get-it-done person. A builder, mover, and someone you can rely on to deliver.
When his company went through a reorg, the executive team put him in charge of leading the transformation of a critical product team. This was the work he was excited about — the chance to build something real and lead through change. Exactly the kind of assignment he’d taken this director role to do.
Then challenges started piling on. His direct report went on parental leave so he started to cover for them. The executive team asked him to support comms for a different product. He still had some of his old responsibilities on his plate.
His day-to-day became focused on keeping the lights on — making sure meetings happened, holding operating rhythms together, keeping everyone informed about what was next. The transformation work he wanted to dig into kept getting sidelined by the operating cadence. At the end of every week he went home feeling like he had gotten nothing done.
Jordan told himself: “I’m not adding value.” What he really meant was “I’m not doing the work I came here to do.” His executive presentation went poorly because he couldn’t tell the story of team transformation he had committed to. He looked at a back-to-back calendar and saw all those meetings blocking him from success. And so that’s the story he told his CPO.
He felt frustrated and disappointed. And busy. So, so busy. So he didn’t really look too closely at those feelings, and instead put his head down to keep trying to stay above water. In coaching, he started mentioning that he felt burnout looming.
We started to recognize the internal inconsistency. Jordan had been narrating his work life as something happening to him: passive voice, victim grammar. His calendar keeping him from doing the work he wanted to do. His boss putting more responsibilities on his shoulders.
He wanted to be the person who’s resilient, who isn’t bitter, who doesn’t dwell on things. And right now he was the opposite of all three.
His burnout looked like overwork. It wasn’t. It was the gap between the leader he believed himself to be and the story he was telling about himself.
The gap they had in common
For both Maya and Jordan, what shifted in their heads wasn’t rest or a lighter schedule. It was the moment in coaching where we named what was actually going on — the gap between who they believed themselves to be and how they were showing up.
For Maya, the gap was between the high-performing strategic leader she believed herself to be and the version of her on autopilot at the startup, unable to land the interviews she thought should be within reach.
For Jordan, the gap was between the builder and get-it-done person he believed himself to be and the version of him buried under operating meetings, telling himself a story of failure.
Their workload looked very different, but a similar pattern haunted both of them.
The bigger the gap, the more exhausting it is to live in. And the more quickly the burnout becomes unsustainable.
Beginning a journey to alignment
As product leaders, busy calendars are part of the job. We can’t often take on a lighter workload or use time management to free up more time to meditate. And even if we could, that isn’t what fixes internal misalignment.
For both Maya and Jordan, the pivot wasn’t rest and it wasn’t quitting. It was naming the mismatch between who they were and what their situation was asking of them. Calling out the gap that had opened between how they saw themselves and how they were showing up.
That’s the first step, and it’s the hardest one to do on your own. In Part 2, I walk through how we worked together to change that gap, and if you’re managing a team, how to help coach others through this type of challenge. Jordan and Maya’s stories continue there.
If you’re seeing yourself in Maya or Jordan, here are some questions I would ask:
What version of yourself did you expect to be at work right now — and how does that compare to who’s actually showing up?
Where’s the mismatch coming from? The role, the workplace, how you’re navigating either, or some combination?
Imagine you were describing the gap to a friend. What would you say?
Set a 10 minute timer and write your answers down. When you read them, what do you see?
If what you’re reading is landing in a heavier place than “this makes me want to reflect” — if you’re struggling with depression, anxiety, or exhaustion that’s affecting more than your work — please talk to a mental health professional. Coaching is a good fit for the “I recognize this pattern and want a thought partner to work through it” moment. It’s not a substitute for therapy or clinical support. Both matter, and they do different work.
If a thinking partner would help you work through the questions above, that’s what coaching is built for. Reach out.
Because of the sensitivity of this topic, I have changed names and key details of each person in this article.
Many thanks to the pre-readers who helped me make sure this article treated this delicate topic with the care it deserves: Marcus Blankenship, Steven Hicks, George Sudarkoff.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
It’s often hard to see the stories we’re telling ourselves without outside help.
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?”
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.
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.
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?
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!
