ProductHarness at a Glance

PMs can generate functional implementations — not mockups, not wireframes — in the same session they're thinking through the product problem. Those prototypes follow the org's actual conventions because the steering documents are in context. Stakeholders react to working behavior, not to descriptions of it. Decisions that used to happen after engineering built the wrong thing happen before engineering starts.

When requirements emerge from an iterative build-and-validate loop rather than pre-engineering speculation, they describe what was built and tested — not what was hoped would work. Edge cases appear when something is built and the edge is encountered. Acceptance criteria written after stakeholder validation are more accurate than criteria written before the first prototype exists. Test cases generated from those criteria are executable from day one.

Requirements are authored once in the repo. The agent publishes them to the backlog as stories, creates test cases linked to acceptance criteria, and updates the wiki — without the PM opening any of those systems. The Translation Tax — converting intent into the right format for each downstream system — is eliminated. Distribution is the final step in the workflow, not the primary one.

Speed matters less than making the right call before committing engineering capacity. The framework structures discovery and validation as first-class activities — hypothesis records, experiment records, decision logs — so the team arrives at build with evidence, not intuition. Instrumentation and validation approach are declared at spec time. The decision to build is grounded in what customers actually need, not in what seemed right in a requirements session.

ProductHarness is built for organizations where engineers are already working alongside AI coding agents, or where that adoption is underway. Any agent that reads a local repository works — the framework is tool-agnostic. If agents are not yet part of engineering's workflow, the prototyping and distribution capabilities won't have a foundation to build on.

The harness lives in a Git repository. PMs need to be able to open that repository in an IDE or CLI tool with an AI coding agent attached. They do not need to know how to code — but they need to be willing to work in that environment. For Tier 2 and above, Node.js is required for Storybook and Playwright. For Tier 1, only Git and an AI coding agent are required.

The steering documents — the files that encode the org's API patterns, authentication approach, component conventions, and CI/CD requirements — need to be filled in with the org's actual decisions. This requires someone with engineering context: typically a Director of Engineering, a senior engineer, or a tech lead. The training engagement walks this person through what each document needs and why. A harness with blank steering documents is not a harness.

The workflow only holds if requirements authored in the repo are the originals — not copies of what was typed into a backlog ticket. This requires an organizational agreement, backed by the PM's Director, that the backlog is a tracking mirror, not the place where requirements are authored. Teams where the backlog is culturally the source of truth will resist this, and the workflow will degrade to a documentation exercise rather than a capability shift.

PMs changing how they work requires permission from someone with authority over how the team works. Without a Director or executive sponsor who has explicitly aligned on the shift, PMs will revert to familiar patterns under pressure. The training engagement includes a Director-level session specifically for this reason — to align on what changes, what stays the same, and what the sponsor needs to watch for.