Early in my career, I was told it was an unforgivable sin to let engineering get blocked on product.
This was hammered into me in unconventional ways. I was once sent to an engineer's house to help him build furniture so he could keep coding instead. The job of a PM was simple. Keep the pipeline full. Never be the reason the build slows down.
So it has been genuinely surreal to watch that dynamic flip.
Engineering at Tern ships so fast that product is now the constraint. Not because we're slow or disorganized, but because the things that are actually hard to scale are judgment calls. What do we build? What order does it go in? Does this solve the right problem or just a version of it? Is the thing we're about to ship actually going to make a customer's day better, or just check a box?
Those questions don't get easier with AI. They get more important.
The Saturday that changed how I think about this
A few months ago, I had convinced myself I was failing as a product manager if I wasn't writing code.
So I spent a full Saturday in Claude Code. One prototype. Getting increasingly frustrated as things weren't going quite right, completely lacking the expertise to debug it, and at some point I looked up and realized I'd been at it for hours with basically nothing to show for it. I ended up roping in my husband, who also happens to work at Tern, because I had hit a wall I couldn't get through on my own.
And then I thought: why am I doing this?
If you're a designer or PM who has ever told yourself "this will take 20 minutes" and looked up at 4pm with the same error on your screen... you know exactly what I mean. One more tweak. Just one more tweak. And then when you finally send it to engineering, it turns out the code was fundamentally wrong from the start.
That experience didn't make me feel like I was behind. It made me clarify what I'm actually here to do.
What I'm actually good at
It's not writing code. It's customer taste. It's watching someone work through their back office for 5 hours and understanding exactly why they're frustrated. It's knowing that a feature that looks simple on a spec sheet will create 4 new support tickets if you don't think through the edge case. It's the judgment to say "not right now" to a good idea because a better one is waiting.
That's the work I want to protect. And it turns out AI is incredibly useful for everything around it.
There is one place where I've found prototyping genuinely useful, and it's worth naming. When I have something in my head that's easier to visualize than describe with words or a recording, being able to spin up a quick prototype helps. Our engineering team has built something that makes this much easier now: I can ask Atlas (our AI coding agent) to build it for me and get a review app with real data already populated, so I can actually click through and test the idea. That's a real unlock in the right situations. But it's a tool for getting clarity on a specific visual concept, not a substitute for how product and engineering actually work together day to day.
Where AI has changed everything
Here's where it's actually changed how I work:
Customer feedback, automatically captured and routed
Every customer call is recorded with Granola. Claude automatically posts a summary to our user feedback Slack channel, and we use a separate tool to surface trends we review as a team each week. The same happens with customer emails. Claude also creates Linear cards for bugs and quick wins directly from those calls and emails. What used to be manual triage after every conversation now just happens. Engineering even has agents scanning for quality-of-life wins they can pick up autonomously, with engineers doing a quick review rather than waiting on me to write it up.
PRDs in 10 to 15 minutes instead of an hour
Once I have a clear picture of what we need to build, I record a quick Loom walking through the product, talking through how I'm thinking about the feature and what matters. I use the transcript to generate a PRD and do a fast audit to make sure nothing's missing. We take it to a team kickoff to poke holes in it, and engineering and design takes it from there.
That process used to take over an hour for most projects. It now takes 10 to 15 minutes.
The work to build up that clear picture in my head? Hundreds of hours of customer calls and on-sites throughout my time at Tern. 4+ customer calls per week at a minimum to augment gaps in my understanding. Providing office hours for new users experiencing the product for the first time, and seeing through their eyes what is confusing and overly complex. That time is precious and will never go away.
Help documentation from the same recording
I do the same thing for help docs. Customers love a visual walkthrough of new features, and I use the Loom transcript to generate the help center article at the same time. One recording, two outputs. A process that used to take an hour is now done alongside the PRD.
Enterprise project tracking without the overhead
We do full implementations with agency customers, checking in every other week on progress. Claude creates detailed project trackers of every feature we need to build, including all the customer-specific nuances. We audit our understanding live with customers in those check-ins, rather than spending the time rebuilding context from scratch.
What I haven't solved yet
Honestly, most of my time right now goes to testing.
Engineering is shipping so fast, and this is the one area we haven't cracked. Manual QA doesn't scale at the pace we're moving. We have work in flight on this, but I want to be honest: generating 5x the output only works if there's a quality gate that keeps up with it.
Beta rollout is the other one. Today it's manual: collecting feedback, enabling betas, managing the rollout. I think there's a lot we can do here with AI. We just haven't gotten there yet.
The bigger point
A lot of people right now are following what's trending about how to use AI, and accidentally drifting away from the things they're great at. The things that got them the job. The things they genuinely enjoy.
Why should a product manager write code when that's not their craft? Why should a designer spend a full day in a codebase instead of making the product feel right for the people who use it?
At a company like ours, with a complex marketplace and advisors switching from legacy systems with years of habits and expectations baked in, the hard work is keeping things simple while building in the depth people actually need. That takes taste and judgment, not just throughput.
I'd rather generate 5 times the PRDs, 5 times the help docs, and 5 times the customer context than write a single PR. Not because PRs aren't valuable. Because our engineering team is better at that than I am, and my time creates more value somewhere else.
Try this before your next AI experiment
Before you go looking for the next tool or workflow to test, do this first.
Map out your job end to end. Every recurring task, every output, every meeting and deliverable. Then split it into 2 columns.
Column one: the things you are genuinely good at and actually enjoy. The work that feels like yours. The stuff where your judgment, taste, or relationships make the outcome better than anyone else could.
Column two: the things you do because they have to get done. The work that takes a lot of your time, drains your energy, and honestly could probably be done just as well, or better, by something else.
That second column is your AI roadmap.
Not the trendy use cases. Not the things that look impressive in a demo. The specific work that sits between you and the stuff you're actually here to do.
That's where AI pays off. And it looks different for everyone.
The 20-year-old version of me who assembled furniture so an engineer could keep coding would be thrilled to know she eventually got her own army of desk-builders. They just happen to run on tokens instead of coffee.
—
I’m hiring a second product lead to join my team at Tern. If you read this article and are excited by the way we work, shoot me a DM with a couple sentences on what resonates and why you'd be a good fit.