The ProductHarness framework is organized around a specific thesis: the PM provides judgment, and AI handles translation. That distinction is load-bearing. It explains what the harness does, why the repo is the source of truth, and why the PM's accountability doesn't diminish as the translation overhead shrinks. The framework was built around it deliberately. But that thesis inhabits a particular world — one where the product at the end of the loop is a deterministic software system. One that does what it was programmed to do, verifiably, reproducibly, testably. That assumption is becoming optional.
The World the Framework Was Built For
Traditional software products are deterministic. A given input produces a given output. You can specify the behavior in advance, build against that specification, and verify after the fact that what was built matches what was specified. This is the world that acceptance criteria were designed for. "Given a badge in earned state, a checkmark icon is visible" is testable because the system either shows the checkmark or it doesn't. Pass or fail. Always the same answer for the same input.
The AI-First SDLC is built around this. The PM scribes intent. The agent translates intent into structured artifacts. Engineers build against those artifacts. QA validates that what was built matches what was specified. The loop closes. The framework removes overhead from this process without changing what the process produces: a deterministic system built to specification.
This is real, valuable, and worth doing. The translation tax is real. The demo gap is real. The drift between requirements and automated tests is real. The framework addresses all of it. None of that is about to become less true.
But there's a different kind of product coming — or rather, already arriving — that this model doesn't quite reach.
When the Reasoning Is the Product
Consider what actually happens when a user interacts with an AI-powered customer service agent to understand whether they can return a damaged item. They aren't running code that looks up a condition and returns a value. They're interacting with a reasoning system that interprets the question, retrieves relevant policy context, decides how to characterize the situation, forms a response, and judges whether to offer an exception or escalate to a human. None of those steps have a single correct answer that can be verified against a specification the way a checkmark can. The reasoning is the product. The quality of the judgment is what the user experiences.
This is a different category of thing. And the PM role in building it is not yet well-understood — not by the PM community, not by the frameworks that exist to guide PM work, and honestly not by me. What follows isn't a new framework. It's an attempt to name the questions clearly enough that the answers can eventually be found.
Three Things That Break
The first thing that breaks is acceptance criteria. Given/When/Then is a powerful format precisely because it's deterministic — the system either behaves as specified or it doesn't. "Given a user asks whether their damaged item is returnable, the agent provides a helpful and accurate response" is not a test case. It is an aspiration. "Helpful and accurate" is not a binary. It is a quality judgment that varies across users, contexts, and interpretations. The mechanism for assessing it isn't a pass/fail check. It's an evaluation — a structured measurement of quality across a distribution of inputs, producing a score rather than a verdict. Evals are to agentic products what automated tests are to deterministic ones. They serve the same function and require the same discipline. The PM who understands acceptance criteria well is partially prepared. The PM who understands evals doesn't yet exist as a category.
The second thing that breaks is specification ownership. In most AI-powered products today, the behavioral specification of the agent — what it's supposed to do, what it won't do, how it handles edge cases, what its persona is — lives in a system prompt that an engineer wrote, or in documentation that nobody reads, or nowhere in particular. This is a PM problem in disguise. The system prompt is the product spec. It defines the product's behavior, tone, capability boundaries, and failure modes. It should have an accountable author, a change management process, version control, and a review cycle. It currently has whatever it has. Decisions about who the agent is supposed to be are product decisions. Right now they're being made by whoever has access to the configuration.
The third thing that breaks is how we think about capability. In a traditional software product, features define what the product does. In an agentic product, capability is partly defined by what tools the agent can access — what APIs it can call, what data it can read or write, what actions it can take on behalf of the user. The surface area of those tools is a product decision: it defines what the agent can do, and equally importantly, what it can't. Scoping tool access is capability design. Setting the blast radius limits on what the agent is permitted to touch is a product decision with real user consequences. These decisions are currently being made by whoever is building the integration layer, not necessarily by the person who owns the product.
The Inversion
The deepest change is harder to name. The framework's core organizing principle is that AI does translation and the PM does judgment. That distinction explains almost everything about how the framework is structured. The PM's accountability doesn't shrink as AI takes on more work — it concentrates at the judgment layer, where the meaningful decisions live.
In an agentic product, the agent does judgment. That is the product feature. The customer service agent that interprets a damaged-item question isn't translating the PM's intent into a formatted artifact. It's making a decision that has real consequences for a real user. The judgment is not upstream of the machine — it is inside the machine, happening at runtime, at scale, in every conversation.
What this means for the PM role is not that judgment disappears. It means the PM's judgment moves to a different layer. Instead of exercising judgment directly — deciding what gets built, validating that the built thing is correct — the PM becomes responsible for specifying the quality and limits of a judgment function. What should the agent decide? On what basis? With what constraints? In what cases should it not decide at all? How good does the deciding need to be, and how will we know? These are PM questions. They have always been PM questions. But they've never before been the primary artifact the PM was building.
This is what I mean when I say the framework inhabits a particular world. The principle — judgment belongs to people, accountability is clear — still holds. But the mechanism through which that principle gets applied is different in a way the current framework doesn't address. The PM isn't specifying a system that does what it's told. The PM is specifying a system that decides what to do. That is a different job, and I don't think the discipline for it has been built yet.
What I Don't Know
I've spent enough time with these questions to believe they're real, and not enough time to have answers. The artifact types seem obvious in outline — agent behavioral specifications, eval criteria as first-class PM deliverables, system prompt governance with the same change management rigor the framework applies to technical standards. But I've learned to be suspicious of frameworks assembled from first principles rather than built from experience. The shape of what PMs actually need in this environment will be revealed by doing the work, not by reasoning about it from outside.
There are specific things I expect to be clarified by practice that I can't clarify by thinking. Whether the system prompt is a PM artifact or a collaborative one. What the PM's relationship to eval design actually looks like — whether it's analogous to writing acceptance criteria or something structurally different. How governance of agent behavior maps to the org structures that currently own governance of technical standards. Whether the three-tier model that works for traditional software has an analogue for agentic products, and if so, what the tiers are gating.
Engineers are already in this territory. They're building agent backends, designing tool surfaces, writing system prompts, running evals, debugging reasoning failures, thinking about prompt injection. The craft is being assembled in practice. The PM equivalent is a few steps behind — and the gap, right now, is mostly invisible because the engineers are filling it by default. That won't last. The decisions being made inside that gap are product decisions, and eventually product people will need to own them.
Why I'm Not Worried About the Transition
The PM skills that matter most in this environment are not new ones. Outcome clarity — knowing what you're actually trying to change in the world, and being precise enough about it that you'd recognize it if it happened. Failure mode thinking — what goes wrong, how badly, and for whom. Accountability without authority — owning the result of a system you don't control at the level of implementation. Care for users — keeping the actual human at the center when the temptation is to optimize the metric. These don't become obsolete when the product is an agent. They become more important, because the surface area of what can go wrong is larger, and the feedback loop from "we specified this incorrectly" to "a user experienced something bad" is shorter.
What changes is the artifact. The spec becomes a behavioral specification for a reasoning system. The acceptance criteria become eval criteria. The changelog for the system prompt becomes as meaningful as the changelog for the codebase. The PM who already thinks clearly about outcomes, failures, and users will pick up the new artifacts. The PM who was relying on the artifacts to substitute for that thinking will find this transition harder.
I built ProductHarness to solve the problem I could see clearly: the translation tax was real, the demo gap was real, the drift between intent and implementation was real, and the tools to address it existed but the structure to connect them didn't. Those problems are still worth solving. The framework addresses them. But I'm aware that it describes a world in transition, and that the next version of this work — whatever it turns out to be — will be built by doing the thing, not by extending the framework from the outside.
I don't have the answers to the questions this piece raises. I'm genuinely excited to find them.