CPOs, VPs of Product, and CTOs are experiencing a common challenge: while agentic coding tools accelerate product development, they also introduce new friction between product and engineering. A product manager (PM) creates a spec that tells engineering what they want built, and then one of two things happens:

• The engineer appropriately asks the agentic coding tool what questions it has. The agent immediately surfaces 15 questions, 12 of which need input from product. You have a cycle time hit and more context switching.
• The engineer doesn’t surface the questions and builds it anyway. After PR reviews and QA, they realize the implementation does the wrong thing.

One theme for the first half of 2026: product and engineering leaders need to reduce this new friction.

What changed

A PM’s spec has two audiences.

First, people:

• Reviewers (customers, leadership, other PMs) who need to confirm the product intent.
• Engineers who need to reason about tradeoffs, durability, and how it fits the architecture.

Second, agents:

• The agentic coding tool that will try to execute what you wrote, literally, at speed.

So what do we do?

PMs should use codebase-aware tools before handoff

I would highly recommend that product leaders and product managers try out the new Claude Desktop app, which bundles Claude, Claude Cowork, and Claude Code into a more PM-friendly interface. You can use it for a LOT more product needs than creating specs – see the additional reading below.

To get your PMs onboard, consider using the tool to ask:

“What does the product do today in scenario X?”

If you have Claude Desktop connected to your code, it often can answer those types of questions. It also will provide you the answer to:

“Given this draft spec, what questions do we need to answer before someone starts work?”

This helps PMs clarify ambiguity so you avoid the new friction points.

It’s time to change the default from “PMs don’t have visibility into the repo.” That policy actively works against speed and alignment. By giving the AI tooling access to the code base, PMs are empowered with insight while maintaining the separation of responsibilities with engineering.

Side note: Markdown is quickly becoming the shared format for specs because it’s easy to diff, easy to reuse, and plays nicely with repos and agent workflows. Pick a Markdown editor you like (Obsidian is a good choice) and make it part of the standard toolkit.

PRDs and Tickets => Specs

You may want to start calling PRDs / Tickets or other definitions of what’s to be built “specs” internally, not because PRD is wrong, but because it communicates a shift: the output is meant to be fed into an agentic coding tool w/ more specifics.

The upcoming virtual mini-conference and the additional reading has lots of help on this front, for example – acceptance criteria and edge cases are critical.

AI supports PMs but does not replace their judgment; it should enhance decision-making efficiency. Use AI to accelerate drafting, decomposition, and edge case discovery. But the final tradeoffs, priorities, and product decisions still belong to the PM. And us engineers still get to rely on PM judgment to know what to build.

Engineering still has to engineer

A clear spec does not eliminate engineering responsibilities. Strong teams do two things consistently:

1. Architecture and technical planning: fit the spec into the system in a durable way (constraints, data flows, integration points, performance, security).
2. Task shaping: break the spec into finer-grained development tasks that are independently testable, so agentic execution stays controlled and reviewable.

A good spec allows the engineers to focus on the work that actually requires engineering judgment.

Reading list

• Agentic workflows for software development – A good overview of agentic workflow design, especially the idea of deterministic checks and evaluation gates that keep speed from turning into chaos.
• How to write PRDs for AI Coding Agents – A practical reframing of PRDs as “spec architecting” so agents (and engineers) can implement reliably with fewer missing assumptions.
• How to Write a PRD with AI (Claude Code tutorial) – Template-forward guidance on assembling a PRD/spec from known context files (including a prd-template.md style approach) so your spec is consistent and agent-friendly.
• How to write a good spec for AI agents – The clearest explanation of “spec as prompt”: why big docs fail and how structure plus constraints drives correct execution.
• Claude Code for Product Managers – A PM-oriented walkthrough of exploring a repo in plain English to tighten tickets/specs and surface the right questions before handoff.
• Claude Code for PM work – Grounded notes on where PM workflows break today (docs are incomplete, reality lives in code) and how codebase-aware tools can reduce that gap.
• The Definition of Ready in the AI Era – A strong argument for shifting DoR from “can dev start?” to “if built exactly as written, would we be satisfied?”