I wrote a one-paragraph feature. The estimate came back at a month.

Part 1 argued that AI is moving the PM bottleneck past execution and toward judgment: deciding what to build rather than how fast to build it. I still think that’s right. It also isn’t the whole story, because judgment only pays off if the thing you decided survives the trip to production.

That trip is where the second bottleneck lives, and it is much older than AI.

A few years ago I wrote a PRD for a feature I was sure about. Let customers upload sample data before deployment, so they could see real value from the product before committing to a rollout. Clear customer problem. Obvious value. The description fit in a paragraph.

The estimate came back at roughly a month of engineering effort.

I knew it wouldn’t be free. I did not expect a month. Here is what I didn’t know when I wrote it:

Our engine was a streaming platform, built for small chunks and individual events rather than whole data sets. There was nowhere to put an uploaded file, so we needed a storage layer that didn’t exist yet.

That storage couldn’t hold plain text, because sample data from customers could contain sensitive material. So we also needed encryption at rest and a retention policy.

And the uploaded data had to be parsed and chunked before any of it could move through the engine at all.

Three architectural facts, none of them in my PRD, all of them decisive. The spec wasn’t wrong. It was incomplete in ways I had no way to see.

The oldest problem in product management

It isn’t prioritization, strategy, or discovery. It’s translation.

A PM writes a spec. An engineer reads it. What gets built is not quite what the PM meant. Weeks later the PM sees the result and says “this is not what I asked for.” The engineer pulls up the spec and says “this is exactly what you asked for.”

Both are right.

The gap isn’t there because PMs are bad at writing specs. It’s there because specs cannot contain everything. They cannot say “remember we have a 10MB limit on this endpoint because of a 2019 decision nobody documented.” They cannot say “our frontend team has a convention for error states you’d only know by working with them.” They cannot say “our compliance review takes six weeks, so plan around it.”

A human engineer fills those gaps with tribal knowledge. Sometimes. Inconsistently. After a few rounds of clarification, and usually after the estimate has already surprised somebody.

What is actually changing

AI is collapsing part of that gap. Not all of it, and the part it doesn’t touch matters more than most of the takes admit. But the part it does touch used to cost weeks.

Three things are compounding.

AI can read your codebase. Point a coding assistant at your repo and it can reason about what’s in there. Asked about my upload feature, a tool with repo context would very likely have said: this is a streaming pipeline, there is no persistence layer, you are asking for one.

AI can surface your team’s patterns. Testing framework, file structure, error-handling conventions, review norms. This used to be tribal knowledge that arrived through osmosis. It’s now queryable.

AI can stress-test a spec before any code exists. This is the part that matters most. Give it your acceptance criteria and it will generate edge cases you didn’t think of, flag ambiguous language, and point out where the spec contradicts itself.

The workflow

It’s simple enough to run this week.

Write the feature description in plain language. Don’t try to make it engineering-ready.

Then prompt: “You are a senior engineer on this team. Here is the feature description. Here is our codebase. Identify any architectural constraints I should know about, any edge cases I haven’t covered, any ambiguous language, and any acceptance criteria that would be hard to test.”

Read what comes back. Some of it is obvious in hindsight. Some of it is architectural fact you didn’t know. Some of it is noise. Update the spec, then take it to engineering.

What you’re buying is having the surprise before the PRD ships instead of a month after.

The objection I’d raise against my own argument

AI invents constraints. It will tell you the auth layer can’t support something when it can. And you, the PM, have no way to evaluate that, because not knowing is the entire reason you asked. A confidently wrong architectural fact is worse than silence: it enters your spec as a constraint and quietly reshapes the feature around a limit that doesn’t exist. Treat the output as questions for your engineers, not answers from them.

Pointing an AI at your codebase is a security decision, not a productivity one. I work in security. Indexing a proprietary repo into a third-party service is a vendor review, a data-residency question, and an IP question, whether or not anyone filed a ticket for it. Some of these tools run locally and some don’t. Find out which before you paste anything, and don’t be the PM who caused an incident trying to save a week.

And it wouldn’t have caught everything in my example. Go back to my three surprises. A tool with repo context almost certainly catches the missing persistence layer, because that’s a fact about the code. It probably catches the parsing and chunking, because that follows from the first. It would most likely have missed the encryption requirement, because “customer sample data might contain sensitive material” is not a fact about my codebase. It’s a judgment about my customers, my industry, and my obligations. Nothing in the repo says it.

That’s the real shape of the tool. It closes the gap between your spec and your code. It does not close the gap between your spec and your context. The second gap is still your job, and it’s the one that was always hard.

Requirement realization

Which points at the thing PMs should be watching. Call it your requirement realization rate: the share of what you planned that ships as you intended it.

Nobody’s is 100%, and it shouldn’t be. Some of that loss is healthy, because discovery invalidates assumptions and priorities move for good reasons. But some of it is pure translation cost, and that portion has been treated as a fixed cost of doing business for about twenty years.

It isn’t fixed anymore.

I don’t have a credible number for how much AI moves it, and I’d be skeptical of anyone who claims one. What I can tell you is that the specific failure I described, finding out the real cost after the PRD instead of before, is now a fifteen-minute check I didn’t run rather than a fact of the job.

What to do Monday

Take the spec you’re about to write. Write it in plain language. Run it past a model with your codebase as context, ask what’s missing, and read the answer as a list of questions rather than a list of findings.

Then go ask your engineers those questions. The AI’s job is to make sure you know what to ask. Theirs is still to tell you the truth.

What’s the last estimate that surprised you, and what did you not know when you wrote the spec?