Product managers need a harness too
The core job of product management hasn't changed. You create value for the customer and for the business. You do that by surfacing the right insights and then testing to make sure what you build actually works. That's it.
Every artifact a PM has ever produced served that job: interview notes, personas, PRDs, roadmaps, prototypes. And under almost all of them sat the same problem, which is context.
The job was always context
A big part of being a good PM was making sure engineers heard the right customer voice. Not every customer voice, and not your summary of it with the edges sanded off. The right one, at the right moment, in enough detail that the person building could make a hundred small decisions the way the customer would want.
You did that by bringing engineers to customer calls, pasting the perfect quote into a ticket, and opening sprint planning with a two-minute clip of someone struggling with the product. The PRD was a context document. So was the user story. The best engineers I've worked with didn't need a spec as much as they needed to understand the customer, and my job was to get that understanding into their heads.
That job is the same. What's changed is whose heads.
You're not working with engineers anymore
More precisely: you're working with the systems engineers work through.
More and more, code gets written by agents that engineers direct, review and steer. Engineers have built themselves a harness for this: the repo instructions, the skills, the tools and integrations, the tests and checks that keep an agent on track. That harness decides what the agent knows and what it can do. An agent working inside a good harness does good work. An agent working inside a thin one guesses.
Look at what's usually in that harness, though. The codebase, the style guide, the architecture docs, the test suite. Almost never the customer. The agent knows exactly how the system is built and nothing about who it's for or what's hurting them.
So the PM's job of making sure the builders hear the right customer voice now means making sure the agents hear it. You can't do that by bringing an agent to a customer call or pasting a quote into a ticket and hoping it gets read. You do it the same way engineers did: by building a harness.
Product managers need their own product management harness, one that feeds customer context into the systems engineers and agents already use.
That harness has two jobs:
- Deliver the right context. Not all the feedback, not a vague summary, but the customer voice that's true, relevant and traceable.
- Make that context repeatable throughout development. Not a one-time handoff at kickoff, but context that shows up on its own at every step: when the work is defined, when it's built, when it's reviewed, and after it ships.
The old way was mostly a handoff. You did discovery, wrote it up, walked the team through it, and from then on the customer voice lived in whatever people remembered. By the time code got reviewed, nobody was checking it against what the customer had actually said. With agents doing more of the work, that gap gets worse. Every new agent session starts from zero, and nothing in it remembers your kickoff meeting.
What that looks like in discovery
Discovery is the clearest place to see the shift, so I'll start there.
When I started in product management, a customer interview cost me an afternoon. I'd sit with the recording, headphones on, playing it at 1x because 1.5x made me miss things. I'd pause every few minutes to type notes, rewind to get a quote exactly right, and flag anything that sounded like pain. Two hours later I had a page of notes from one conversation with one customer. The context lived in my head and my notes, and I carried it to the team by hand.
Today I have a digest. It holds about 150,000 customer calls, support tickets and public reviews. I can ask it a question and get an answer in seconds. "What are people saying about onboarding since the last release?" "Which enterprise customers have mentioned permissions in the last 90 days?" "Show me every time someone described exporting data as painful, in their own words."
The important part is that my agents can ask it too, and so can the agents my engineers use. An agent building a change to the export flow can pull up what customers have actually said about exporting before it writes a line. That is the modern version of bringing an engineer to the customer call.
The harness has to deliver the right voice
Volume was the old problem: there were only so many recordings one person could sit through. That's solved. The new problem is quality.
When everything gets processed, the risk isn't missing a signal. It's a confident, well-written, wrong insight. A theme inferred from similar wording rather than a real pattern. A pain point that "40 customers mentioned" when really three of them did and the model filled in the rest. A summary that quietly turned a customer's problem into the fix they happened to suggest.
There's a quieter version of this mistake, and it's ours, not the model's. With 150,000 pieces of feedback, you can always find a wonderful quote that fits what you're pitching perfectly, even if only one person ever said it. It used to take real work to dig up the perfect quote, and that work kept us somewhat honest. Now it takes one query. Put that quote in a spec, hand it to agents that build in hours, and you can confidently build the wrong thing at an extraordinary pace.
A quote shows that the pain is real for someone. Only the numbers behind it show that it matters. The harness has to carry both.
Those mistakes used to mislead one PM in one meeting. Inside a harness, they flow straight into specs, prototypes and code. Teresa Torres made this point in a Product Talk conversation about how Vistaly rebuilt its product around AI interview synthesis: if the interview snapshot is wrong, every layer above it inherits the error.
So the harness needs guardrails, the same way a coding harness has tests. These are the ones I've found matter most.
Every claim traces back to quotes, and to a count
A pain point isn't real unless you can open it and see the customers behind it: who said it, where, when and in their own words. And it doesn't matter until you know how many said it. "Customers are frustrated with exports" is a summary. One perfect quote about exports is an anecdote. "Sixty-two customers across calls, tickets and reviews in the last 30 days described exporting as painful, and here's what they said" is evidence. The quote never travels without its count. If an agent cites customer pain to justify a decision, it should have to cite the actual quotes.
Problems, not solutions
Customers are good at describing pain and unreliable at prescribing fixes. "I wish there was a bulk edit button" is a signal that repetitive changes take too long, not a requirement. Keep pain points written as problems from the customer's side, and track solutions separately, linked to the pain they address. Otherwise the harness becomes a feature-request voting board, and your agents will happily build whatever got the most votes.
Know who's talking
One review from someone who churned after a day means something different from a theme that comes up in every call with your largest accounts. Every signal should carry who said it: their segment, their plan, whether they're a customer at all. One loud customer who files the same ticket six times is one signal, not six.
Humans own the structure
Clustering is where models are most useful and most likely to drift. They'll merge two different problems because the wording sounds alike, or split one problem into five versions. What counts as one pain point and what counts as two is a call a person makes on purpose. Split themes that are too broad, merge ones that are the same, and archive rather than delete so you can see how your understanding changed.
Themes have to hold up
A theme that appears once and disappears on a rerun is probably noise. Real problems show up across sources, across time and across reruns. If a big new theme appears overnight, check whether something changed in the product or in the pipeline before you act on it.
One source, every reader
I don't keep one version of the insights for me and another for the agents. We all read the same digest through the same interface. That's how PM judgment scales. You don't review every agent's output. You shape the source every agent reads from, and your calls (splitting a theme, marking something won't-fix, adding context) become part of what they see.
Making it repeatable
Guardrails get the context right. The second job is making sure it shows up every time, without anyone having to remember to ask for it.
Engineers solved this for code a while ago. They don't hope an agent reads the style guide. They put the instructions in the repo, wrap common work in skills, and run checks on every change, so the context is there by default. Customer context should work the same way. Here's how it shows up at each stage:
- Defining the work. Every piece of work starts from a pain point in the digest, not a one-line ticket. The spec or prompt links to that pain point, so whoever picks it up, person or agent, can open the quotes behind it.
- Building. Before an agent changes a flow, it pulls what customers have said about that flow. That's a standard step in the harness, the way running the tests is, not something an engineer has to think of.
- Reviewing. A PR names the pain point it's meant to address, and the review checks the change against it: does this actually solve what customers described, in the way they described it?
- Shipping. The release links back to the pain points it covers, which tells you who to follow up with.
- Learning. Every change ships with the metrics that show whether customers actually use it: who tried it, who came back, and whether the workflow it was meant to fix got faster or less abandoned. Those adoption numbers flow back into the harness next to the new feedback, attached to the same pain point. Now the next round of decisions starts from both what customers said and what they did, and the cycle starts again.
The key word is repeatable. A great customer insight that reaches the team once is a nice moment. The same insight showing up at definition, build, review and release is how a team, and its agents, keeps building for the customer instead of drifting toward whatever's easiest to build.
Closing the loop: did it work?
The other half of the job, testing that what you build actually works, needs the harness too.
Every pain point should know what's happened to it. Which solutions are linked to it? Are they in the backlog, in progress, shipped or canceled? How much of the pain do the shipped ones cover? Solutions can live wherever the team works, like a Linear issue or a GitHub PR. What matters is that the link back to the customer's pain is explicit.
That gives you three things that used to be hard:
- An honest view of coverage. Not "we shipped 40 things this quarter," but "we addressed most of the top pain points for our core segment, and here are the ones we haven't touched."
- A way to close the loop with customers. When something ships, you know who asked, what they said and where. Telling them is one of the highest-trust things a product team can do, and it used to be too much work.
- Proof it worked. After you ship, two signals should move together: adoption goes up and the pain goes quiet. If nobody uses the fix, or customers keep describing the same problem in the same words, it didn't work, whatever the launch post said.
Same job, new interface
I don't miss the two hours with the headphones. But the instinct those hours built matters more now, not less. You still need to recognize real pain when you hear it, tell a problem from a suggested fix, and notice when a theme sounds too neat.
The difference is where that instinct goes. It used to go into one engineer's head at a time, once, at kickoff. Now it goes into the harness: what counts as evidence, how themes are structured, and how pain links to what ships. From there it reaches every engineer and every agent working on the product, at every step, every time.
Engineers figured out early that agents are only as good as the harness around them. Product managers are figuring out the same thing. The job is still creating value for customers and the business. The way you do it is making sure everything that builds the product hears the right customer voice, and keeps hearing it from the first spec to the last release.
Further reading: Product development in the agentic era (Anthropic) · The new PRD is not a document · Generating opportunity solution trees with AI (Product Talk) · How to validate AI-driven customer insights (Chattermill)