The customer's reason has to travel with the work

Every task on a product team got faster this year. The team didn't.

Earlier this month I gave the last hour of a training day to the product organization of a large retailer. I thanked them for staying until the end of the day and promised to keep it practical. That morning their trainer had walked them through a PM's week with AI: saved instructions in a Gem, tickets sorted in Sheets, patterns found in NotebookLM, user stories checked against a rubric, a prototype in Stitch and documentation written through Copilot. Every step was faster than it used to be.

My hour was about what happens to the team when all of those tasks speed up at once. I opened with one sentence and kept coming back to it: the customer's reason has to travel with the work. By the customer's reason I mean the why. Why does someone need the thing we're building?

Building is no longer the hard part

At Zentrik, Pablo and I went from 14 merged pull requests a month to 1,657 in a year, working with agents. I told that story in part one. Building stopped being the hard part. What's left is deciding what to build, and finding out quickly whether you got it right. Most product people already feel the first half of that. The second half is still on its way.

Product Focus asked 677 product people about their work for its 2026 report. 97% say AI made them more productive. Only 64% say it improved their product's outcomes. And 71% don't spend enough time with customers and the market. Among heads of product and directors, the people who set direction, it's 75%.

Tasks change before the org chart does

When every person goes faster, the work that's left moves from doing things to connecting them: what each person knows, what the customer said and what the team decided.

Sort a PM's week and the tasks fall into four piles. Six get help: the customer interview, problem framing, backlog prioritization, the PRD, session replays and A/B tests. Four leave your hands: forty interview summaries, finding the accounts behind a request, bug triage and release notes. Two don't change at all, and those are the ones to protect, because AI fills every gap you give it: the no to your biggest account, and owning the wrong call.

The fourth pile is new. AI adds work of its own: keeping product context current, reviewing what the model drafted, writing the evals that say an agent's work is good enough, and deciding what an agent may do alone. Nobody has those on a job description yet. In your squad, does each of them have a name next to it?

Where the reason gets lost

Of everything the room saw that morning, prototyping changes the cycle most, because it moves the moment the user comes in. It used to take a week of sketches, wireframes and clickable mockups before a user saw anything, and by then changing course was expensive. Now a live prototype a user can actually try takes hours, so users come in while the team is still deciding.

But the prototype lives in its own world, without the design system, the permissions or the real constraints. What you learn there only counts if it makes it to production. That's usually where it breaks.

Follow one PM through the morning's six steps and you get six contexts. The tickets know what customers said. The notebook knows which patterns turned up. The story knows its acceptance criteria. Somewhere between them, questions stop having answers. Which tickets mattered most? Which pattern did we drop? Why this criterion? What did the user say when they tried it? Is any of it still true?

Nobody did anything wrong. Each tool kept its own context, and the team needs a shared one: the sources, decisions and criteria it keeps together, each with an owner and a date. When every step was slow, we fixed this in meetings. At this speed there's no time for the meeting.

A loop where the reason travels

Our loop has four steps around that shared context. Learn what customers would pay for, always linked to its source. Decide on the bet with the evidence in front of you; a person decides, never a model. Define the outcome, the limits and the why, written for people and agents. Build with agents, and have a person review. What ships comes back as evidence for the next decision.

Forward, it's a funnel. In an example workspace, forty signals become twelve insights, five opportunities, eight ideas and two initiatives. Those are our names; every team has its own. The new part is the way back. Anyone can pull on an initiative and ask where it came from: an engineer on day one, a director at the quarterly review, or an agent before it writes a line of code. The trail is still there: which ideas competed, which problem it solves, which insights support it and which evidence started it.

Who keeps the shared context current?

In a session with Esther Salinas in September, Amalia Gómez asked the question every team reaches eventually. Once every PM, designer and engineer has their own setup around an agent, who keeps the context they share up to date? Esther followed with the harder version: when a meeting changes a decision, how does the shared memory change?

That question marks the hinge in how teams adopt agents. Below it, each person speeds up and the team drifts apart: prompts, shared assistants, an agent for everyone. Above it, context belongs to the team: business context with owners, repeatable operations, and eventually a system that keeps itself current. Most of what I saw teams build this year sits below the hinge, and that's fine. Place one workflow on the ladder, not the whole company.

Capture can be automated. Acceptance can't. An agent can notice that a meeting note contradicts the current plan and propose the update. A named person accepts the new state, and the earlier reason stays findable for the day someone asks why the plan changed. In a large company that person sits in product operations. In a small one, it's the PM with an engineering manager. Jorge Zavala added the part I now repeat to every team: the system around an agent should limit it, not only enable it.

Why a smarter model won't fix it

An agent can't read every conversation. It reads a few and tends to agree with whoever asked. The answer sounds sure, it's well written, and it can be wrong. The morning's tools work fine. The risk shows up when a team decides with only what the model happened to read. The fix is shared context the agent has to read from, checks that can stop the work, and a person who decides.

Everything around the model is the harness. The morning had used the four Ds of AI fluency: description, delegation, discernment and diligence. We didn't bring a new framework to replace them. A harness is where the four Ds live once they belong to the team instead of one person.

It has four parts and one habit. Context is what is true and where it came from. The model reads the mess and proposes. Code checks, and stops the work before it crosses a line. A person owns the decision. The habit is the loop: every decision goes back in as context, so the next run starts from what you already decided. It's the part almost everyone skips.

Put the morning's tools into those boxes and a gap appears. Saved instructions, NotebookLM sources and Confluence are context. Gemini, the AI formulas in Sheets and Stitch are model. The PM and the squad are the person. Code holds the Atlassian MCP connector and nothing else, while the rubric for user stories sits in the model's box. A rubric inside a prompt is the model grading itself. A real check lives in code, where it can stop the work. Change tools and the boxes stay the same, which is why the harness outlives the agent.

Four moments in the sprint

You don't need another methodology. You need four moments inside the sprint you already run.

At the start of the week, take fifteen minutes to review what came in, already grouped and linked to its source. During the sprint, test with users before the demo instead of at it. At every delivery, review with the why in front of you. At the retrospective, a correction you've made twice becomes a rule, with an owner and a date.

Someone has to own the shared context. If nobody does, in three months it's an attic full of documents.

Take one workflow home

We ended the hour with an exercise, three minutes per team. Here it is, so you can run it with yours.

Pick something your team does every week and answer five questions before you write a prompt. What outcome do you want, and where does the agent stop? Where does the truth live, and which source wins when two disagree? Which steps need judgment and which are rules? Judgment goes to the model and the person, rules go to code. What must never happen without you? Make that a real stop, not a sentence in a prompt. And where does the result get saved, so the next run starts from it?

Then hand the same workflow to a second agent. If all you redo is an instruction file, a login and a connector, your system is portable. The things that are expensive to lose are where the truth lives, what the agent may do, the checks that catch mistakes and what you learned last time. That's the part you own, and the part worth building.

To start on Monday you need four things: one decision, one source, one owner and one date to come back to it. The system grows from the first loop.

Where Zentrik fits

Zentrik is where that shared context lives for product decisions. It reads the sales calls, support tickets and research a team connects, ranks the ideas already in the backlog against that evidence, and flags needs the backlog doesn't cover yet. People decide what to test, test it with customers, and hand engineers and agents a brief that carries the customer's words. When the work ships, the evidence comes back into the same place, so the next decision starts from what the last one taught.

The customer's reason has to travel with the work. AI prepares, rules check, people decide.

Part one: A year ago we came for horsepower, the story of how we built our own harness and the number we watch. Try the loop on your own evidence: from customer evidence to initiatives.