What This Requires of You
ProductHarness changes how your team works. Your job is to set expectations, own governance, and remove the blockers that keep your PMs from adopting it successfully.
The Model in One Paragraph
ProductHarness is a structured repo harness that enables product teams to work with AI coding agents inside the developer environment. PMs generate working prototypes, iterate toward validated solutions, and gather real stakeholder feedback before engineering starts. The repo encodes your org's standards — component library, API patterns, auth approach, data conventions — in steering documents the agent reads as context, so every prototype and every generated artifact follows your actual conventions. Requirements, acceptance criteria, and test cases emerge from that validated work; the agent distributes them downstream automatically. Accountability stays with your team. The mechanical work moves to the agent.
Your PMs don't build the harness from scratch. There is a template — the ProductHarness Template — that installs the structure. The engagement gets them up and running on a real initiative, with the governance model in place for keeping it current.
Right-Sizing the Harness to the Work
The harness activates incrementally. Three stages match three stages of thinking — exploring, stakeholder-ready, and shipping. Stage selection is not a technical decision. It is a forcing function that helps PMs right-size their work. Your job is to help them calibrate: don't over-engineer early ideas, and don't under-engineer work headed to production.
| Stage | When to use it | What it activates | Director's role |
|---|---|---|---|
| Starting Out | Exploring a problem, early discovery, stakeholder alignment work | Full steering document infrastructure, PM workflow, discovery templates | Ensure PMs aren't over-engineering early initiatives. Exploration work doesn't need production-level process. |
| Production Connection | Work that will go to engineering — requirements headed to implementation | Adds connection to the production codebase, so generated components follow the patterns engineering uses | Confirm engineering team is ready to receive harness-generated scaffolding. This is a workflow change for engineering, not just PM. |
| Full Integration | Sync pipeline between design workspace and production feature branches | Adds the sync pipeline that moves validated components from the design workspace into production branches | Two additional conditions apply: (1) work is low-risk; (2) engineering team has the cultural maturity to accept non-engineer-originated code in the production repo. Default recommendation: Production Connection stage until engineering buy-in is established. |
Teams with strong codebase ownership identity will resist Full Integration until agentic workflows are the norm for them. Pushing it before the team is ready creates friction that stalls adoption. Start at Production Connection and move to Full Integration when engineering leads it, not when it's mandated.
Steering Documents Are Your Responsibility
Steering documents are the org's engineering and product decisions encoded for AI. They define what requirements look like here, what done means per node, how work is organized. When a PM writes requirements against a steering document, and an engineer generates code against a steering document, and QA generates test cases against a steering document — those three people are all working from the same standard. That only works if the standard is current.
A steering document that reflects how the org worked eighteen months ago is not neutral — it actively steers the agent in the wrong direction.
Steering documents need leadership review when organizational standards change — not after the agent has been applying the old standard for a quarter. Designate who owns the review, at what interval, and what triggers an out-of-cycle update. Quarterly is a reasonable starting cadence for most orgs.
An individual PM should not unilaterally update a steering document that encodes an org-wide standard. Changes to standards have downstream consequences — for every engineer generating code, every PM writing requirements, every test case being produced. The review process needs to match the blast radius.
If the authentication steering document encodes the old auth provider, every piece of generated code will use the wrong auth approach until someone catches it in review. Stale steering documents don't announce themselves — they produce subtle, consistent errors across everything the agent generates. Regular review is a risk management practice.
Roles Don't Change. How Work Gets Done Does.
The accountability model in ProductHarness is identical to the accountability model your team has today. Engineers own implementation. Designers own the experience. PMs own what gets built and whether it meets the acceptance criteria. QA owns sign-off. What changes is where the mechanical work happens.
| Role | What stays the same | What the agent handles |
|---|---|---|
| Product Manager | Defining the problem, building and iterating on working prototypes, gathering stakeholder feedback, validating that solutions are correct before engineering starts, writing acceptance criteria | Building code that follows org standards (via steering docs in context), publishing to backlog and wiki, generating test case stubs, keeping artifacts in sync |
| UX Designer | Design decisions, interaction patterns, visual hierarchy, experience quality judgment | Translating Figma designs to component code, generating Storybook stories |
| Engineer | Implementation quality, architecture decisions, business logic, security hardening, code review | Scaffolding from specifications, applying production patterns, pre-flagging common review issues |
| QA Engineer | Triage judgment, edge case identification, sign-off decision, quality standard interpretation | Generating test stubs from acceptance criteria, executing test suites, reporting results to test management |
The clearest way to communicate this to your team: AI raises the quality floor of what arrives at every decision point. It does not replace the decision. Every artifact the agent generates, a human on your team owns.
What to Watch For
The backlog is downstream. This is the most significant mental shift your team will make. Requirements live in the repo. Jira and Confluence receive from the repo — they don't define it. PMs who have spent years thinking of Jira as where work lives will default back to it under pressure. Your job is to hold the frame: the repo is where work originates. Jira is where you track status.
Before writing requirements, a PM should ask: is the problem clearly defined? For larger, more ambiguous work, the harness includes structured discovery templates — Problem Framing, Opportunity Assessment, Solution Discovery, Validation and Evidence. PMs don't need all four for every initiative. Your read of the work tells you how much upstream rigor is warranted. The scaling principle: small, well-understood features can go straight to requirements; large or exploratory work benefits from working through the relevant discovery nodes first.
The most common adoption failure: a PM running Full Integration-level process on an exploratory initiative. Or the reverse — a PM skipping the production connection stage for work that's going to engineering. Stage selection is a calibration question you're well-positioned to answer. Build a habit of asking your PMs which stage they're working at and why.
Early adoption indicators worth tracking: Are PMs working in the developer environment with their AI coding agent, or still drafting in Docs and pasting to Jira? Are prototypes appearing before requirements documents — or are PMs jumping straight to story-writing? Are requirements being revised because a prototype revealed something that changed the solution? Are test cases generated automatically rather than written by hand? These behaviors precede the outcome improvements — they're what to look for in the first quarter.
What You Need to Have in Place
Before your PMs can start, two things need to be in place. Both are your responsibility to coordinate.
Each PM needs Git installed on their machine and access to your org's GitHub or GitLab instance. The agent handles Git operations on their behalf — commits, pushes, branch management — but the tooling needs to be present. This is often a ticket for IT. Start it early.
Someone on the team needs to be able to create a new repository in your org's GitHub or GitLab. This is the team lead who sets up the ProductHarness repo that PMs then clone into. Usually an engineering lead or a Director-level person. Identify this person before the engagement begins.
The setup sequence: the team lead creates a new repo, and an agent generates the harness in it from the ProductHarness specification — inside your source control, yours from the first commit → a PM clones that repo and opens it in their AI coding tool → the agent reads SETUP.md and finishes configuration automatically → the PM assigns remotes and starts working. The only human inputs required are values the agent can't know: API tokens and org identifiers. You need to understand this flow well enough to unblock your team when they hit a step that requires access or permissions you control.
Want the gist without the engineering detail? See one feature, in plain terms →
Ready to walk through this with your team? Get in touch →