About
The framework comes from practice, not theory.
Why This Exists
ProductHarness came from a question that became impossible to ignore: why are product managers still writing documents when AI coding agents can build things?
The early observation was simple. Engineering teams adopted AI coding agents and got dramatically faster. Product teams didn't change. The result was a widening gap — not because engineers were moving too fast, but because PMs were handing off speculative requirements documents and expecting engineering to sort out what they meant. The agents were faithfully implementing those documents. That was the problem. The documents described what someone hoped would work. Nobody had checked.
What changed my thinking: realizing that the capability already existed for PMs to work the way engineers had started working. A PM in a developer environment with an AI coding agent could generate a working prototype of a feature in the time it used to take to write a requirements document. They could show stakeholders something real. Get real feedback. Iterate in the same session. And then — only then — write requirements that described what was built and tested.
I built ProductHarness to make that model work in practice. The missing ingredient wasn't capability — it was structure. Working prototypes generated without org context are throwaway. ProductHarness encodes the org's actual standards — component library, API patterns, authentication approach, data conventions — in steering documents the agent reads as context. Every prototype the PM generates follows those standards. Every requirement that emerges from validated work is production-aligned. The delivery loop that follows is starting from something real.
Stated Plainly
The PMs who will thrive are the ones who spent their time on defining problems, synthesizing evidence, and making calls about what to build. The ones who spent most of their time formatting user stories and updating tickets are in a harder position — not because AI replaced them, but because it exposed what they were actually doing.
This is not a prediction. It is already happening. A PM who can generate a working prototype, validate it with stakeholders, and produce requirements from that validated work is operating at a fundamentally different level than a PM who writes intent documents and sends them to design. The capability gap is real and it is widening.
The code is usually correct. The feature usually works. The problem is that the wrong thing was built, or the right thing was built wrong, because context degraded between when it was captured and when it was used. Fixing handoffs fixes most failures. Engineering capacity is not the constraint most orgs think it is.
This is not a technical preference. It is a decision about where the authoritative record of what gets built lives. When it lives in the backlog, it is owned by project management tooling. When it lives in the repo, it is owned by the work itself — version-controlled, auditable, and AI-navigable. That distinction matters more than most product leaders realize.
When I say "accountability stays with people," I mean it as a governing principle, not a legal caveat. The value of the framework is precisely that it keeps humans in the judgment chain while removing them from the translation chain. An AI that makes decisions is a liability. An AI that implements decisions — structured, specified, and validated by humans — is leverage.
What This Stands On
ProductHarness didn't appear from nowhere, and pretending otherwise would be both dishonest and a missed signal about what it actually is. The hypothesis/experiment separation in the discovery templates comes from the Strategyzer school — a hypothesis and an experiment are different documents, and keeping them separate is what makes evidence-driven work real instead of ceremonial. The continuous discovery posture — discovery as a standing activity rather than a phase — follows the modern product discovery tradition. The Given/When/Then structure for acceptance criteria comes from behavior-driven development. And the framework's central move — encoding an organization's standards as version-controlled files that machines read and act on — is the infrastructure-as-code idea, applied to product work.
What ProductHarness adds is the synthesis: those practices, installed together, in the one place an AI coding agent can act on all of them at once. The lineage is the credibility; the combination is the contribution.
Background
I spent 17 years at Thomson Reuters learning the financial technology space — specifically brokerage processing — and figuring out how to be a product manager before that role had much gravitas. Then I switched industries entirely. Fitness and wellness, with all of its healthcare adjacencies, for a little over seven years. Along the way: a pandemic, a people leadership role, a VP seat, returning a struggling business line to growth, and a growing fascination with AI.
I started where most practitioners start — solving my own problems. Building software to get out from under the work that was crowding out the work that actually mattered. Then better software. Then something shifted. I started leading others toward that same moment, and found that more rewarding than the building itself.
That's really where ProductHarness came from. Not from frustration with product teams, but from watching what happens when someone who's been grinding through the translation work finally sees a different way to operate. The a-ha is real, and it's repeatable. But a moment that has to be discovered one PM at a time isn't adoption — it's luck. An org needs that moment to scale, and scale is exactly where ungoverned AI use breaks down.
That's the part most AI-tooling conversations miss: proliferation requires constraints. Orgs don't get durable AI adoption by handing PMs a tool and hoping. They get it by encoding the org's standards, accountability gates, and governance into the environment where the AI operates — so every PM's output lands inside what the org can actually absorb. ProductHarness is that constraint set. The constraints aren't the brake on AI adoption; they're what makes it safe to go fast. The difference between a hundred PMs experimenting in a hundred directions and a product org compounding in one.
If that sounds more like people leadership than tooling, that's because it is. The framework came out of the years I spent leading people, not out of a build backlog: caring about what each person spends their day on, protecting the work only they can do, and refusing to let a technology shift quietly sort my PMs into the ones who happened to figure it out and the ones who got left behind. ProductHarness is that mindset, encoded. Developing it — and seeing it through the lens of someone who owns the whole Product org — has given this work a sense of purpose I didn't see coming.
Training Engagements
New here? Read the full overview → — what ProductHarness is, what it delivers, and what your organization needs to adopt it.
I run training engagements for product organizations that want to install ProductHarness and start using it. A typical engagement is a single workshop that installs the framework, runs the team through the workflow for each role, and leaves them with the living reference they'll return to during and after the session. The reference is this site.
Who it's for: product teams at organizations where AI coding agents are in use or being adopted — and where PMs are still writing documents while engineering builds. Directors of Product who want their PMs working in the developer environment, building and validating before engineering starts. CPOs who see the gap between how fast engineering moves and how slowly product work originates — and who want their teams not just moving faster, but arriving at build decisions grounded in what customers actually need.
To start a conversation: davidj@outlook.com →
You can also find me on LinkedIn: linkedin.com/in/david-jones-9772864 →
How This Site Was Made
This site was researched, written, designed, and deployed working in the model it describes: in a developer environment, with an AI coding agent, from versioned plain-text files in a repository — design system encoded as a steering document, content built and iterated in-session, structure validated before publishing. The method made the site. That's the quietest evidence on offer here, and the most honest.