ProductHarness — How It Works
The framework connects discovery through delivery through a single, AI-navigable source of truth — so product teams spend their time on judgment, not translation.
What It Is
ProductHarness is a framework for product organizations operating in the age of AI coding agents. It encodes an org's standards into a structured repository — component library, API patterns, authentication approach, data conventions, node definitions — so that when a PM works with an AI coding agent in the developer environment, every prototype and every generated artifact follows those standards by default. PMs build working prototypes, validate them before engineering starts, and produce downstream artifacts from what was actually tested.
The framework spans the complete product lifecycle as two connected loops: the Discovery loop (framing the problem, designing and validating the solution, authoring acceptance criteria) crosses into the Delivery loop (implementation, verification, deployment) and around to impact (did we solve the problem we set out to solve?). At its center is a governing principle: the repo is the source of truth. Backlog, wiki, and downstream systems receive from it — they don't define it.
The Four Principles
AI can draft, generate, suggest, and synthesize — but every output requires a human decision before it moves forward. The PM owns what gets built. The designer owns the experience. The engineer owns the implementation. QA owns the quality signal. AI accelerates those decisions; it never makes them.
When AI can translate a design into working code, the line between design work and engineering work gets fuzzy. That's a feature, not a problem. What doesn't change is who is accountable for what. The designer is still accountable for the experience being right. The engineer is still accountable for the technology being sound.
Requirements, designs, test criteria, and implementation all converge in version-controlled artifacts inside the repo. Downstream tools — backlogs, wikis, project trackers — receive from the repo; they don't define it. This makes AI more effective and makes decisions auditable.
Generating a user story from acceptance criteria is mechanical. Deciding what the acceptance criteria should be is meaningful. Scaffolding test cases from requirements is mechanical. Determining whether a test failure reflects a product risk is meaningful. The framework is organized around this distinction — AI owns the mechanical so humans can focus on the meaningful.
Explore the Framework
The Translation Tax
Every handoff requires a human to convert context from one form into another. That overhead compounds. The PM carries most of it. Here's the full argument — and what removing the tax makes possible.
The Double Loop
Two self-contained loops — Discovery and Delivery — connected at the crossing point. Each cycles independently; together they form the complete model. Discovery runs signal to acceptance criteria; Delivery runs implementation to impact, and back again.
Discovery
Seven nodes, signal to acceptance criteria — walked as a menu, not a mandatory pipeline. Right-size the rigor to the scale and risk of the work. The complete discovery reference for PMs navigating ambiguous or high-stakes initiatives.
Delivery
Six nodes, implementation to impact, one source of truth. Delivery begins at the crossing point — by the time work enters, the PM has already built and validated. What engineering receives is derived from a tested prototype, not a speculative document.
The Repo
The directory structure that makes AI-navigable context possible. Annotated file tree, key steering documents, and activation levels — from starting out to full integration.
Governance
A harness that's never updated stops working. Two modes — scheduled cadence and event-driven reviews — and the AI-generated Governance Health Report that flags drift before it compounds.
The Adoption Path
ProductHarness installs in a day. The org behavior it enables takes longer. Essential, Value-Add, and Mastery — what's available at each stage, and how to sequence progress without waiting for perfect conditions.
The Worked Example
The whole framework inhabited by a fictitious product team — standards filled in with real decisions, one feature walked end-to-end through the Double Loop, and the full adoption arc across branches. The proof it's real, not aspirational.
In Plain Terms
The same worked example, told in plain language for product leaders, designers, and anyone who isn't going to read a file tree. One real-shaped feature, start to finish, and what it changes.