You Don't Just Specify Anymore.
You Build.
Working in a developer environment with an AI coding agent and ProductHarness context, PMs can now generate working prototypes, iterate on ideas, gather real stakeholder feedback, and produce downstream artifacts from what was actually validated — all before engineering starts. The harness context keeps every output production-aligned. You still own the problem definition and the final call on what ships. What's changed is the leverage you have to get there.
This page is the case for what changes and why. The complete day-to-day workflow reference — the seven-step workflow, prompts, and publishing — is the Product Manager role guide.
Old Way vs. New Way
| Task | Old way | With ProductHarness |
|---|---|---|
| Solution development | PM writes requirements, hands to design, waits for engineering to build something to react to — weeks before seeing working behavior | PM generates working prototypes with the agent in the developer environment, iterates on behavior, gathers feedback, and validates the solution — before engineering starts |
| Stakeholder validation | Feedback on mockups or requirements prose — stakeholders react to a description of the feature | Feedback on working prototypes — stakeholders react to actual behavior, surfacing real usability problems rather than imagined ones |
| Where requirements come from | PM specifies in advance what they believe should be built — accuracy depends on how well they anticipated the solution | Requirements emerge from what was built and validated — they describe working behavior, edge cases discovered in iteration, and data needs that became clear when the prototype ran |
| Writing requirements | In a doc or Jira — PM writes structure and content manually, usually alone | PM works in the repo with an AI coding agent present — the agent reads org standards and actively helps improve the content: gaps, edge cases, testability, data needs |
| Gap and completeness checking | Relies on another person reviewing — often happens too late, or not at all | Agent systematically reviews acceptance criteria for missing scenarios, implicit assumptions, and unstated conditions — before anyone else sees the requirements |
| Edge case coverage | Depends on the PM's experience and what they happen to think of | Agent surfaces empty states, failure modes, permission boundaries, concurrent-user scenarios, and invalid inputs as part of the requirements session |
| Testability of criteria | Subjective, often discovered when QA can't write a pass/fail test | Agent flags criteria that rely on subjective judgment and helps rewrite them as specific, measurable, observable conditions |
| Data and state coverage | Implicit — engineering discovers missing data requirements during implementation | Agent identifies data states, validation rules, and schema questions implied by the requirements and surfaces them before engineering starts |
| Creating backlog stories | Manual entry in Jira, often retyping from requirements | Generated from your requirements file automatically, with case keys linked |
| Writing test cases | Manual, or handed to QA to write separately | Generated as stubs from your acceptance criteria — QA reviews and extends, not writes from scratch |
| Publishing to the wiki | Copying and reformatting from wherever you wrote the requirements | Agent publishes initiative context to Confluence automatically when triggered |
| Keeping artifacts in sync | Manual — updates in one place rarely make it to the others | The repo is the source of truth; downstream systems receive from it automatically |
| Engineering handoff | Verbal kickoff, or pointing to Jira stories | Explicit handoff checklist that both sides can see — what was verified, what's ready |
You are not accountable for less. You are accountable for more — because you can now validate before engineering starts, not after. The agent builds, iterates, and distributes. The judgment is still yours. The leverage is significantly larger.
The PM Workflow
Open your AI coding agent (Cursor, VS Code with Claude or Copilot, Claude Code, or similar) in the harness repo. Describe the feature concept — the problem being solved, the user outcome, the context. Then ask the agent to build a working prototype. The agent reads the ProductHarness steering documents — your org's component library, API patterns, data conventions, authentication approach — and generates code that follows those standards. What comes back isn't a mockup. It's a working implementation you can run, share, and react to.
Iterate in the session: "show the empty state," "what does the error look like," "the user has only partial data — show me that," "the stakeholder feedback was X — make that change." Each iteration produces a refined working implementation. The ProductHarness context ensures that every iteration stays aligned with the org's production standards — the code the agent generates is code engineering can inherit.
"Build a working prototype of [feature] using our component library and API patterns."
"Show me the empty state for this feature."
"Add the error condition for when [X] occurs."
"Iterate: stakeholder feedback was [X]. Make that change."
"What data does this prototype need to read and write?"Share the working prototype with stakeholders before engineering starts. Feedback on something that runs is categorically different from feedback on a requirements doc or a Figma frame. Real usability problems surface. Assumptions get tested. "I keep clicking here expecting to go back" is feedback from someone who used the thing — not feedback someone tried to imagine by reading about it. Gather that feedback, iterate with the agent, and validate until the solution is right.
Once the solution is validated, formalize the requirements in docs/work/<feature>/requirements.md — derived from what was built and tested. Ask the agent to draft the acceptance criteria from the working prototype. The edge cases are the ones that emerged in iteration. The data requirements are what the prototype actually needed. The agent can draft these from the implementation, and you refine and own them. This produces requirements grounded in working behavior — more accurate and more complete than requirements written in advance of building anything.
"Based on what we built, draft the acceptance criteria that describe this behavior."
"What edge cases did we encounter in building this that should be in the requirements?"
"Draft the data requirements from what this prototype reads and writes."
"What states does this feature handle? List them as acceptance criteria."Even requirements derived from validated work have gaps. Run the agent through a systematic review before publishing: missing scenarios, untestable criteria, unstated data validation rules, cross-system dependencies, non-functional requirements. Each pass closes something the prototype session may have left open. You judge every suggestion — the agent can't know your intent. But it can hold more dimensions simultaneously than any single reviewer.
Prompt: "Publish this requirements file to Jira as user stories and to Confluence as an initiative overview." The agent creates the stories with acceptance criteria, links them to the epic, and posts the initiative context to the wiki. Review what was created before moving on — the agent's output reflects the quality of your input.
Prompt: "Generate test case stubs from these acceptance criteria and publish them to the test management system." Each test case maps to a specific criterion, with the Jira story key embedded in the test title. QA receives structured stubs to review and extend — not a blank page. Review the generated cases for completeness before handing off to QA.
As engineering works through the implementation, you can ask the agent to check which acceptance criteria have been addressed and which are still open. This is the connection that makes the engineering handoff meaningful — you can see, at any point, what the implementation covers and what it doesn't.
Before marking work ready for engineering pickup, work through the engineering handoff checklist in the repo. It covers requirements completeness, acceptance criteria format, open questions, backlog stories, test case generation, and Storybook validation status. When you check it off, engineering can see exactly what was verified — and you can see what you're accountable for having confirmed.
When implementation is complete, validate the generated component in Storybook before signing off. Does it match the intended experience? Does it handle the edge cases you specified? Does the error state look right? Storybook renders each visual state defined in the requirements — it's the comparison point between what you specified and what was built. Your sign-off here is the handoff back to QA for final validation.
What the Agent Needs From You
The agent can build, iterate, enrich, and distribute. What it can't supply is your intent, your product judgment, and your knowledge of which constraints are real. The quality of what comes out — prototypes, requirements, downstream artifacts — is a direct function of how clearly you convey what you actually mean, and how decisively you respond to what the agent produces.
Don't just describe what the user does — describe what should be true afterward. "User submits the form" is an action. "User submits the form and receives a confirmation email within 30 seconds" is an outcome. The agent can infer a lot from the action; the outcome tells it what success actually looks like and produces better test criteria.
Don't refer to "the button" when you mean the "Save Changes" button. Don't say "the user's details" when you mean their name, email, and avatar. Specificity in your scribe translates directly to specificity in the generated criteria. Vague nouns produce vague tests.
As you scribe, the agent will suggest edge cases — what happens when a field is empty, what the error state looks like, what happens on a slow connection. Your job is to confirm, correct, or dismiss each one. You know which edge cases matter for this feature and which are out of scope. The agent knows to ask. You decide the answers.
What is this feature explicitly not doing? "Out of scope: bulk editing, admin-only view, mobile-specific layout" is a meaningful signal that prevents the agent from inferring scope you didn't intend. Explicit boundaries save review cycles. When in doubt, say it out loud — the agent will record it.
When you're not sure how to articulate a behavior in requirements, generate a working prototype first and iterate until it's right. Then ask the agent to derive the requirements from what was built. A working implementation is more precise than a prose description — and the agent can extract acceptance criteria, data states, and edge cases from code more reliably than from a paragraph of intent.
When to Start Upstream of Requirements
Not every feature starts with clear requirements. When the problem itself isn't clearly defined — or when competing definitions exist — jumping straight to writing acceptance criteria produces requirements for the wrong thing. The harness includes structured discovery templates for when you need to work through the problem before you can specify the solution.
When: The problem hasn't been clearly defined, or multiple definitions are competing. Produces: A shared problem statement, a clear articulation of who is affected and how, and explicit assumptions that the solution will test. Artifacts live in the feature folder, docs/work/<feature>/.
When: You need to evaluate whether this problem is worth solving before investing in solution discovery. Produces: A structured case for why this problem is a priority — market size, user impact, strategic fit, competitive context.
When: Multiple solution approaches exist and you need to evaluate them before committing to one. Produces: A structured comparison of options, decision criteria, and a recommended direction with rationale.
When: You have a proposed solution and need evidence that it addresses the problem before investing in implementation. Produces: User research synthesis, prototype test results, or other validation evidence that supports or challenges the proposed solution.
Discovery is a menu, not a pipeline. Don't work through all seven nodes for a feature that doesn't warrant it. The judgment about which nodes are necessary is yours — the harness documents the work, it doesn't mandate the process.
Prompts That Make Requirements Better
The most valuable prompts aren't the ones that publish to Jira. They're the ones that improve what gets published. Use these before distribution — work through the enrichment loop until the requirements are actually ready, then let the agent handle the rest.
Enrichment prompts
"Review the acceptance criteria for [Feature]. What's missing?"
"What scenarios aren't covered by these criteria?"
"What questions will engineering have when they pick this up that aren't answered here?"
"What will QA need to write test cases that these requirements don't provide?""What are the edge cases for [Feature] that these criteria don't address?"
"What happens with empty state, partial data, network failure, or invalid input?"
"What are the failure states this feature needs to handle?""Which of these acceptance criteria are not testable as written?"
"Rewrite [criterion] so it's specific enough to generate a pass/fail test."
"Flag any criteria that rely on subjective judgment rather than observable behavior."
"Rewrite the acceptance criteria in Given/When/Then format.""What data does this feature need to store, read, or transform?"
"What data states does this feature need to handle — empty, partial, error, loading?"
"Are there data validation rules implied by these requirements that aren't stated?""What other features or systems might be affected by this change?"
"Are there API contracts implied by this feature that need to be defined before engineering starts?"
"What teams outside this one need to know about this feature before it ships?""What performance requirements apply to this feature that aren't stated?"
"What accessibility and security considerations apply here?"
"What are the rollback or degradation requirements if this feature fails in production?""What open questions need answers before this feature is ready for design?"
"What would block engineering from starting on this today?"
"Score these requirements on completeness, testability, and ambiguity. What needs work?"Distribution prompts
Once requirements are ready, these handle everything downstream.
"Publish the requirements in [filename] to Jira as user stories under [epic name].
Create one story per acceptance criterion group. Include the acceptance criteria
in Given/When/Then format in each story description.""Generate test case stubs from the acceptance criteria in [filename].
Publish them to [test management system] and embed the Jira story key
in each test case title.""Create a Confluence page in [space] summarizing the [initiative name] initiative.
Include the problem statement, the proposed solution, the acceptance criteria,
and a link to the requirements file in the repo.""Walk me through the engineering handoff checklist for [requirements filename].
Check each item and tell me what's complete and what still needs attention
before I mark this ready for engineering."Your First Action
Don't try to migrate everything at once. Start with one feature. Pick something small enough to complete end-to-end in a week, but real enough to produce artifacts you'll actually use.
Git installed on your machine. Access to your org's GitHub or GitLab instance. The harness repo created by your team lead and cloned to your machine. If any of these are missing, your Director coordinates them — ask before the session, not during it.
Open the harness repo in your AI coding tool. Prompt: "Read SETUP.md and finish setting things up." The agent checks Node.js, installs dependencies, copies environment configuration, and prompts you for the values it can't know — API tokens and org identifiers. This takes about ten minutes the first time. You won't do it again unless you set up a new repo.
In your developer environment, describe the feature to the agent and ask it to build a working prototype. The steering docs in context mean the output follows your org's actual standards. Show the prototype to a stakeholder and note what they react to. Then formalize requirements from what was built and validated: create the requirements file at docs/work/<feature>/requirements.md and describe what the prototype did, what was confirmed, and what's out of scope. The agent reads the steering files and formats to your org's standard — review, refine, and iterate once. This is the step that produces the most value.
Publish to Jira. Generate test cases. Publish to Confluence. Complete the handoff checklist. See what comes out. The first run will surface gaps in your criteria and give you a clear picture of where the agent's output matches your expectations and where it doesn't. Use that feedback to improve your next requirements file — not to fix this one retroactively.
The complete PM workflow reference — with every step, every prompt, and every artifact explained in full — is in the Roles section: PM Workflow Guide →