Your Team's Real AI Question Isn't Which Tool, It's How They Work

Something shifted in how product work actually gets done, and it happened faster than the org charts caught up. Coding agents went from smart autocomplete to systems that build a working thing overnight. That changes the daily mechanics of PM, design, and engineering, not just the tooling budget. Let me catch you up on what moved and what you should do about it.

Build first, decide second

The old logic said building was expensive, so you front-loaded everything before you wrote a line of code. Research, specs, design reviews, scoping. That whole order flips when a task that took an engineer ten hours now takes ten minutes. You build first, then look at the real thing and decide.

The numbers behind this are hard to ignore. Codex started with two PMs, one designer, and about 40 engineers covering 10 to 12 product surfaces. Cursor scaled past $4 billion in ARR with 40 engineers and one PM. When Codex ran a hackathon with a large enterprise, two engineers finished a modernization project scoped at 10 engineers and 12 months in three days.

The practical shift for your team: stop asking "should we build this?" about a spec. Ask "we built this overnight, should we ship it?" in front of a working product. That one change moves your decisions from arguing about a document to reacting to something real.

The gap that shows up at the top

Here is the catch nobody warns you about. These agents want to deliver before they understand the job. Matt Wensing, VP of Product and Design at Customer.io, compares Claude to a talented junior hire who races to the finish before they have context. It generates something that looks complete and misses the point.

He calls it the slop problem, and it gets worse the higher up you go, because the people reading your work get sharper. Senior leaders read documents for a living. They filter out a clean seven-slide deck that flattens months of real complexity into a shadow of the problem.

Wensing's fix is slower on purpose. Feed context in layers, kill the eager suggestions, stay in control of the pace. He says a 200-iteration session with a great deliverable beats saying yes to the first draft. When he built a pricing philosophy doc, he opened with an abstract biology metaphor and only revealed the real domain deep into the session, after the model had a clean mental model to stress-test.

Skip the tool war

Your team will fight about Codex versus Claude Code. Don't let them. Abhi Muchhal, an International Growth PM at OpenAI, makes the point that the harness matters more than the model. The harness is the connectors, the folder structure, the permissions. Without it, you are paying a lot for autocomplete.

A clean permissions model is the norm worth setting. Muchhal runs three levels: reading tasks get full autonomy, drafting and synthesis get full autonomy, and anything going to another human needs his approval. That last rule is your quality gate. He also never takes a non-deterministic answer at face value for an executive report.

The automations pay for themselves. Muchhal built a Slack triage that runs daily, flags what he missed, and skips the FYI noise. A market dashboard that pulls from seven or eight sources and refreshes at 9:30 every morning. Ask your team a plain question: what do you check by hand every week that could be waiting for you with a machine-written TLDR?

Where the real leverage lives

The boring, repetitive work is the easy win. Enzo Avigo at Amplitude open-sourced five playbooks for exactly this: a weekly market research digest, interview scheduling off real power-user behavior, competitor monitoring every Monday, support triage, and release notes from closed tickets. His advice is sane. Start with one workflow, test repeated runs by hand before you turn on the scheduler.

But the harder gains come from proximity and memory. Customer.io built a scanner that watches dozens of Slack channels and surfaces threads where a product person should weigh in but isn't. It gives Wensing back the ground-level view leaders usually lose as they climb. Their CEO built a bot called Chiefys that checks new work against the company's core operating documents and flags contradictions.

The memory gap is real too. Agents forget yesterday's great PRD by this morning. Aakash Gupta built a memory layer for Claude Code after finding that Garry Tan's GBrain cited invented numbers on his setup and Karpathy's Second Brain went stale fast. The lesson for you: a session with no memory repeats work and a session with sloppy memory launders bad data as fact.

The deep cut

Marty Cagan just changed a position he held for two decades. He now says the foundation models can coach product creators about as well as most managers, and he is worried about something specific: AI is exposing product theater. If your PM is only using AI to aggregate feedback, generate roadmaps, and crank out PRDs faster, an engineer or a designer can do that themselves now. That work no longer proves the role.

So the thing to bring to your next review is not a tool rollout. It is a harder question about what your PMs actually add once the busywork is free. Point your team's AI at their own growth, their market, their customers, their metrics, and use the freed hours on judgment the model can't fake. The teams pulling ahead are not collecting more, they are synthesizing what they have with more precision.

Three questions for your team

1. What weekly task is each PM still doing by hand that a scheduled agent could hand them every morning, and what's stopping us from turning one on this week?
2. What is our approval line? Which agent outputs ship on their own, and which ones need a human before they reach another person?
3. Once the aggregation and drafting work is automated, what is the specific judgment each PM adds, and can they show it in front of a working prototype rather than a doc?