The Spec Is The Hard Part.

What Good Looks Like For A Product Org.

We didn't open by talking about AI. We opened by writing what every product team I've ever met says they want:

• Build the right things — not just what's easiest to build.
• Quality output — designs that bake in user understanding, research, and judgment.
• Focus on the work — the problem, not the PowerPoint.
• Move fast — not queue behind three other teams' cycles.

Then we wrote what was actually in their way, in their own words:

• "Staying on top of everything — meetings, Slack, Teams, emails."
• "Nothing is automated."
• "I don't have the vocabulary to use an AI agent effectively."
• "Recreating content takes a lot of time. Requirements aren't always clear."

Those are verbatim from the room. They were already using AI. They were still describing the same problems product teams have always had.

The Question That Reframed The Workshop.

Halfway through, one of the PMs asked the question that's been rattling in my head since:

Notice what's not in that question. Not "how do I get a better answer from Claude?". Not "which model should we use?". The question is structural. It's about how a hundred-person product org turns one PM's good prompt into the rest of the org's leverage.

I think this is the question. Most companies are still optimizing the wrong layer.

Code Isn't The Hard Part Anymore.

I wrote this on a panel a couple weeks earlier and it's the lens I keep coming back to: the spec is now the hard part, not the code. Models can write the implementation. The unsolved problem is writing requirements clear enough — and durable enough, and shared enough — that a model or a team can act on them without the PM standing over its shoulder.

Which means the bottleneck for product orgs has moved one layer up. The discipline that used to live in a PM's head — "this product is for these users, the goals are these numbers, here's how we usually write a PRD, here's the org map for getting it shipped" — that discipline used to be sufficient when it stayed in the PM's head. It isn't anymore. Now it has to be readable by something that isn't the PM.

The Folder Is The System, Not The Editor.

What an AI-native product organization actually needs isn't a fancier IDE or a better chat UI. It's a foundation of plain-text files — boring, machine-digestible, source-controlled — that answer the questions a PM asks themselves before any work begins.

Six files, in my current draft of the product operating system¹:

1. Product Overview. A clear, generic definition of what the product is. (Done at scale across all products, you accumulate a library.)
2. Goals & KPIs. Current 3-, 6-, 12-month targets, in plain English and hard numbers.
3. Raw Inputs. Unfiltered context from clients, support, sales, marketing.
4. The Ledger. Past decisions, reviews, and crucial learnings about what not to do.
5. Style Guides. The exact standard for how your team writes a PRD, a test plan, meeting notes.
6. Org Reality. The unwritten map of who works with whom, which VPs to loop in, how decisions actually get made.

Once that foundation exists, two things become composable on top of it:

• Skills² codify how specific work gets done — the equivalent of a well-written runbook, executable by a model.
• Agents³ (invocable lenses like @skeptical-pm, @customer-voice, @data-realist) scale how much gets done.

Codification plus multiplication. That's the shape.

This Is A Project, Not A Tool Choice.

The thing I want to be honest about: a system like this isn't built in an afternoon and rolled out at all-hands. The PMs who asked the sharing question were already three steps ahead — they understood that codifying their own work was the easy part. The hard part is making it so that a marketing manager, a designer, a data scientist can plug into the same system without being PMs themselves.

That's a real organizational project. It's designed, experimented with, expanded; leadership has to be brought along at every step. It looks more like rolling out a new operating model than installing a new tool.

And the companies that figure this out — the ones that build a real shared operating layer for product work, not just give everyone a Claude license — are going to be the ones whose product orgs feel an order of magnitude faster three years from now.

Who I'm Talking To.

If you're a product leader whose team is already using Claude Code, and you can feel the gap between "individual sparks" and "shared operating infrastructure" — that's the conversation I'm spending most of my time on right now. Email's at the bottom. Whether or not it turns into anything formal, I find these conversations the best way to pressure-test the pattern in public.