Here is something that is now technically true: a PM can write acceptance criteria in structured, machine-readable format — Given/When/Then — without knowing what Given/When/Then means, without understanding BDD, and without ever having thought seriously about test case structure. The AI agent handles the translation. The PM provides the intent. The output is usable by a test framework.
Here is the part that's less often discussed: the PM generating the output is the easy part. The org consuming it is the hard part.
What the Generation Chain Actually Does
The traditional path from PM intent to automated test looks like this: PM writes requirements in plain language → QA engineer reads requirements and manually authors test cases → test cases get formatted for the test management system → some subset of those test cases get coded as automated tests by an engineer who may or may not have been present for the original requirements conversation. At every step, a human translates context from one form to another. At every step, something is lost or misinterpreted.
The AI-assisted path compresses this. The PM scribes their intent — what the feature should do, what conditions should hold, what should not happen — in a structured requirements document. The AI agent generates acceptance criteria in Given/When/Then format directly from that intent. Those criteria, because they're already structured, can be consumed by a BDD test framework with significantly less human translation than the traditional path. The PM never authored test syntax. The QA engineer didn't manually retype intent into a different format. The test structure emerged from the same source as the requirements.
This is a real capability. It works. The generation fidelity is high enough, when the PM's requirements are clear, that the output is usable without significant manual correction. This is not a demo scenario — it's a production workflow that teams are running today.
The Gap Nobody Talks About
When product leaders hear about this chain, the question they almost always ask first is: does the PM need to understand how to write Gherkin? The answer is no, and this answer lands as liberating. But it immediately obscures a different question, which is the important one: does the engineering org have a BDD test framework in place that can consume the output?
The answer to that question, in most organizations, is no. Or: yes, partially, in some services. Or: we have the framework installed but the coverage is low. Or: we have coverage in unit tests but not integration tests. Or: the tests exist but they're not running in CI on every merge. Each of these is a different version of the same structural gap: the generation is ready, the consumption infrastructure isn't.
This matters because the value of the generation chain is entirely downstream of consumption. A PM who generates high-quality Given/When/Then acceptance criteria into an org where those criteria never feed an automated test has improved the readability of their requirements — a real but modest benefit. The compounding value — requirements that become automated tests that run on every merge that catch regressions before they reach production — only materializes when the consuming side is built.
The Two-Sided Investment
Getting from "our PM can generate structured AC" to "our acceptance criteria drive our automated test suite" requires investment on two sides simultaneously, and they are different kinds of investment.
On the generation side, the investment is behavioral. PMs need to work in structured requirements format, in the repo, with enough specificity that the agent can produce accurate AC. This is a habit change — meaningful, but achievable in a sprint or two with the right scaffolding in place. The harness provides the scaffolding. The PM practices the habit.
On the consumption side, the investment is structural. Someone needs to choose and configure a BDD framework. The test suite needs to be built or migrated to a structure that can consume Given/When/Then scenarios. CI needs to be configured to run those tests on the right triggers. Engineers need to write step definitions that wire the scenarios to actual implementation code. None of this is the PM's work. None of it happens because the PM improved their AC format. It requires a deliberate engineering investment, justified on its own terms, that happens to unlock the full value of what the PM side is producing.
The organizations that successfully run this chain typically got there because a senior engineer or QA lead saw the opportunity and made the case for the infrastructure investment — not because leadership mandated "everyone will write Given/When/Then now." The PM workflow improved first. The consumption infrastructure followed. The value compounded when they met.
What "Ready to Consume" Actually Requires
The minimum viable consumption side has three components. First, a BDD framework that can parse structured scenarios — most mature language ecosystems have at least one. Second, a library of step definitions that map scenario steps to runnable test code — this is the engineering work that bridges structured language and implementation. Third, CI integration that runs the relevant scenarios on every change to the affected code paths. Without all three, the chain is incomplete.
The step definition library is where most orgs underestimate the work. Writing a step definition for "Given a user is logged in" requires that the test framework knows how to create a test session, authenticate a test user, and set up the right state. That's not trivial engineering. It requires decisions about test data management, environment configuration, and state isolation. The PM's "Given a user is logged in" scenario is three words. The step definition that makes it executable might represent days of infrastructure work the first time it's written.
Once it's written, though, it's reusable. Every future scenario that includes "Given a user is logged in" draws on the same step definition. The library accumulates. The marginal cost of adding a new scenario drops. This is the compounding return on the structural investment — but it only materializes after the initial investment is made.
Why This Is Still Worth Pursuing
The honest case for this chain is not "your PM can generate tests without understanding testing." That undersells the capability and sets up disappointment when the consumption gap becomes apparent. The honest case is: this is the path to requirements and automated tests that share a source of truth, maintained by the same process, that closes the drift between what was specified and what was tested.
In most organizations today, requirements and automated tests are maintained separately, by different people, with no structural connection. A requirement changes. The test that was written against the old requirement doesn't update — because there's no process that links them. The test passes. The requirement is no longer being tested. The team believes they have coverage they don't have.
The chain described here doesn't have this problem. When the PM updates the requirements, the AC updates. When the AC updates, the scenarios that feed the test suite update. The tests stay connected to the intent. The coverage stays real. This is a significant structural improvement over the disconnected alternative — but it requires the consuming side to be built, maintained, and taken seriously as infrastructure.
The PM's Actual Role in All of This
The PM who participates in this chain has one job on the generation side: write requirements that are specific enough for the agent to produce accurate acceptance criteria. This means clear preconditions, unambiguous expected outcomes, and explicit edge cases. It does not mean understanding the test framework, writing step definitions, or managing CI configuration. Those are engineering concerns.
What changes for the PM is earlier in the process. Writing requirements specific enough to generate accurate AC requires more precision than writing requirements specific enough to get a story into a sprint. The edge case that a human test engineer might catch and add to the test suite manually has to be in the requirements, because the agent is working from the requirements, not from institutional knowledge. This raises the bar for requirements quality in a way that benefits the whole delivery loop — even if the BDD infrastructure never gets built.
Better requirements, generated from structured intent, with explicit acceptance criteria that could theoretically become automated tests: that is the value of the PM side of this chain, available immediately, regardless of what the consuming side looks like today. The full chain — from PM intent to production-gating automated test — is the long-term possibility. It is worth building toward. It is not something a PM can build alone.