A Structured Approach to PM for AI-Driven Projects
In my last post, I argued that product management gets more important as AI speeds up development. The skip-forward problem is what happens when nobody treats it that way. This post is about the five-step process we actually use to do PM for AI-driven projects.
The PM’s Job Is to Stress-Test the Brief
The most common misunderstanding I run into is that PM in an AI project is a coordination job. Gather what stakeholders say they want, structure it into a document, hand it to the coding agent. That is a description of a note-taker, not a product manager.
We were building an AI-powered Q&A system for a client. They provided sample data, a list of example questions the AI should answer, and one non-negotiable requirement: no hallucinations. Fact-based answers only, or nothing at all.
When we tested the system, it returned nothing. We investigated and found that the sample data they had provided did not contain the answers to their own example questions. The system was doing exactly what they asked, refusing to make things up, and that meant it could not answer anything they had put in front of it.
The conflicting requirements were sitting in plain sight. Nobody had asked the question that would have surfaced them: where in your data would the answer to this question actually live? That is the PM’s job. Not to document what the client says they want, but to find the place where two stated requirements cannot both be true at the same time.
A second example. In a compliance discussion with another client, we asked about regulatory requirements. The answer: comply with all possible standards. That is not a requirement. It means nobody has thought through which standards actually apply to this product, which means nobody has decided what the system concretely has to do. A note-taker writes it down. A PM opens it.
The Industry Solved Spec-to-Code Long Before It Solved Client-to-Spec
By 2026, the industry has largely converged on an answer to how AI should build software: write the spec first, then generate the code. Thoughtworks called it one of the most important practices to emerge in 2025. AWS built an entire agentic IDE around it. Kiro, launched May 7, 2026, produces three documents before an agent writes a line: requirements.md, then design.md, then tasks.md. GitHub’s version, Spec Kit, has picked up more than 111,000 stars since its release: Constitution, then Specify, then Plan, then Tasks, then Implement.
Both tools open with a step that has nothing to do with what the customer wants. Kiro calls it Steering; Spec Kit calls it Constitution. Either way, the first thing you do is lock in the tech stack, the testing conventions, the coding standards. TypeScript or JavaScript, which libraries you allow, how you organize the codebase. That is a team that has already decided what it is building and is now telling the agent how to build it.
Every one of these tools assumes you already know what you want, right down to the language you will build it in. They take a prompt or a brief you write yourself and turn it into working software fast, and at that they are genuinely good. What none of them do is produce the brief. Sitting with an organization that has not yet articulated its own intent, let alone its tech stack. Turning that into something committed enough to spec against, is work no tool on the market covers. It is still, entirely, a human problem.
Skip that step anyway and you still get an answer. It is just an answer to a question nobody actually asked, delivered with total confidence.
That is the Brief layer. It is what makes spec-driven development usable for a client engagement instead of a solo builder who already knows exactly what they are making.
Every serious AI coding tool can turn a clear brief into working software fast. None of them can produce the clear brief in the first place.
Refusing to Guess Silently Is Harder Than Asking Questions
Refusing to guess when nobody has answered is the hard part, not asking the question. Left alone, AI fills the gaps and moves forward confidently, without flagging what it assumed, exactly the failure from Post 1. Three problems shaped how we built the tooling behind our process, and each is a version of that same failure.
The first is context confusion: treating something true in one place as true in another. It shows up in documents, where two clients with similar scope produce near-identical proposals and an ungoverned model fills a gap in today’s brief with someone else’s fact. It also shows up in configuration. A phrasing rule built for a heavily regulated client’s formal, legal-department language once carried into a startup client’s session. It fought the conversational questioning that client actually needed. Both are the same failure, and it is not unique to us. Any AI system that carries context across engagements is prone to it. Instead, we scope documents and rules to the engagement they belong to, and never assume they carry over.
The second is what happens when something needs to change after work has already moved past it. PM work is not linear. You are sometimes three sections into the spec when something surfaces that belongs back in the brief. Handled badly, that means reopening everything already agreed, or amending it and letting a contradiction or a downstream gap go unnoticed. The fix is an amendment check: the system tests any change for contradictions and for dependencies, so it flags anything built on top of it rather than letting it go stale without anyone noticing. Whatever the client already signed off on stays untouched, and the PM decides what reopens.
When the System Cannot Decide, It Asks
The third is what a system does when it hits something it cannot resolve on its own. Two stakeholders disagreeing, a requirement that could mean two things, a risk nobody has classified. Left alone, AI resolves this kind of ambiguity on its own and moves on. That is how a spec drifts away from what was actually meant without anyone deciding it should. This is the failure Thoughtworks calls spec drift. Instead, the system surfaces the conflict and lets the PM make the call. The only defense against drift is refusing to guess, every time.
Five Steps Turn a Brief Into Running Software
At A-CX, PM for AI-driven projects runs on five named steps, the same ones on every engagement. They are Deliver Brief, Deliver Spec, Deliver Plan, Deliver Code, and Deliver Deployment. This post focuses on the first two, the PM-owned steps. From there, the engineering process takes over.
Deliver Brief is the facilitated engagement itself. The PM arrives at the session with context already read in, not a blank page, and the session runs on one rule throughout. Propose an answer and let the client confirm or correct it, never leave a blank for someone to fill in later.
Underneath, a tracker most clients never see follows completeness section by section, flags what still needs asking, and knows the difference between a PoC, an MVP, and a full product, since a gap that blocks one does not necessarily block another. It also tracks who answered a question against who actually has the authority to commit the organization to it.
Brief ends when the client formally commits to it.
A requirement without a named owner is still a draft.
Deliver Spec translates that committed brief into something a build can run on: user stories, acceptance criteria, non-functional requirements, technical design choices. A-CX proposes; the client confirms or corrects, the same rule as Brief. The spec draws a clear line between what the client required as stated, which we build exactly,, and what A-CX chose on its own, where the client is informed but not deciding.
Once the client confirms a section, it locks against silent overwrites. The lock holds because everything downstream stays traceable to it. Every task in the plan (aka. ticket) links back to the spec section and the brief requirement it serves. A change can never flow back up on its own. If work on the plan surfaces something that means a confirmed section needs to change, that is a deliberate reopening, never a task-level edit: the PM decides, and the client comes back in when the change is theirs to approve.
Where Documents Become Tickets
Deliver Plan and Deliver Code sit on the engineering side of the hand-off. That hand-off is physical, not just organizational. Brief and Spec live as version-controlled documents the PM owns. Plan, Code, and Deployment run as tracked work in GitHub or Jira. Deliver Plan is where committed intent becomes tickets an agent can actually run. What gets built in what order, what depends on what, what can happen in parallel. Deliver Code is the agent executing that plan, each task carried to a merged pull request through enforced test-driven development, code review, and security review. With Brief and Spec solid, both stages move fast and clean. This is where AI-driven development actually delivers on its promised speed.
Deliver Deployment is the one I want to pause on. I is where this model and the tools that inspired it part ways. Kiro, Spec Kit, every serious spec-driven tool on the market, stops the moment code is generated. What happens between generated code and something actually running in production gets left as somebody else’s problem.
A tool that stops at generated code has not finished the job. It has finished the easy part.
Deliver Deployment does not treat production as somebody else’s problem. Its shape depends on what you are shipping. A web app, a mobile release, an SDK, and an internal tool all land in production differently, but the principle stays constant. Same process, same accountability, carried through to whatever production means for your system, not a handoff to a different team once the code exists. The API story below shows what it costs when nobody owns that last stretch.
Planning Generates Requirements You Did Not Know You Had
Structured facilitation does not just capture requirements faster. It surfaces ones nobody knew existed. Each round of questioning tends to reveal something the previous round missed, not because anyone was unprepared, but because a thorough question uncovers a decision neither side realized it needed to make. The value is in the planning, not the plan: the document at the end can be short, what matters is that the conversation happened before anyone committed to a direction.
The cost argument is simple on the surface: catching a gap during the Brief costs a conversation, catching it after the build costs a rebuild. But it compounds. Once you commit to a build, attention drops, so the odds of catching a gap yourself only get worse the longer it runs unnoticed. The rebuild itself is rarely the real cost anyway. The real cost is the time the system was supposed to be working and was not. And if the process is time-critical and you cannot fully trust it, the actual bill is building a second process, or adding a person, to back it up.
What a Missed Question Costs
A closer look: the API that kept changing
We integrated with BambooHR early on, to move the job applications we receive through our own hiring process. In one year we rebuilt that integration three times. Our code never broke; BambooHR changed something on its end, without warning and without documentation.
One failure was a silent drop: updates quietly stopped going through, and nothing flagged it. The fix took a few hours. The real cost was the time in between: applications kept arriving, and the process that moves them forward did not keep pace.
When a process is time-critical, the actual fix is not patching the integration. It is deciding whether the process can still run unattended, or whether it now needs a person watching it.
All three rebuilds could have started as one question up front: does this integration carry a stability guarantee, and what happens to us if it does not.
One Level of Rigor Does Not Fit Every Project
Not every project needs the same amount of rigor, and treating them all the same fails in both directions. Apply full production discipline to something small and early, and everything slows down for questions nobody needed answered yet. Treat something headed for real production like a quick early test, and gaps that would have blocked a real build ship anyway, because nobody flagged them as blocking.
We keep this explicit with three tiers: proof of concept, MVP, and full product. Which tier an engagement sits in is decided at the start, before facilitation even begins, not assumed. Once it is set, the completeness threshold follows from it: the sections and questions required for a proof of concept are not the same as for an MVP, and a gap that blocks a full product does not automatically block a proof of concept. The PM decides the tier. The system enforces whatever that tier actually requires, not one standard applied to every engagement regardless of what it is.
Apply full-product rigor to a two-week prototype and all you add is time.
This is how we do PM for AI-driven projects today, on our own Agentic AI engagements: the tracker, the protected sections, the tiering, all of it built and running, not just described here. A methodology that never changes is not being used on anything real. If you want to see the actual tooling in action, reach out.
