The Translation Tax

The Translation Tax is the accumulated cognitive overhead of converting context from one format to another at every handoff in the SDLC. A customer insight becomes a problem statement. A problem statement becomes a requirements doc. A requirements doc becomes a spec. A spec becomes a design brief. A design brief becomes engineering stories. Stories become test cases.

Each conversion step is necessary. None of it is judgment work. None of it requires a senior product mind — it requires time, consistency, and attention to detail. But it falls on the PM, because the PM is the one who understands the intent well enough to translate it accurately. The result: PMs spend a significant fraction of their working hours doing sophisticated clerical work.

The tax compounds as organizations scale. More features means more handoffs. More handoffs means more translation work. More translation work means less time for the things only humans can do: framing the right problem, making judgment calls, validating that what was built matches what was meant.

AI coding agents are becoming standard. What was a workflow curiosity two years ago is now a baseline capability expectation across engineering organizations. Agents generate code, scaffold tests, implement designs, and handle boilerplate that used to take engineers days.

Here is the critical implication that most product orgs have not yet fully reckoned with: the quality of inputs into those agents is now the primary variable in engineering output quality. A well-specified requirement with clear acceptance criteria and a connected design reference produces usable, production-realistic output. A vague story or a disconnected spec produces hallucinated features, misaligned implementations, and expensive rework.

The Translation Tax is no longer just a productivity issue. It is now an output quality issue. A PM buried in conversion work produces worse inputs — less specific, less connected, written for human readers rather than structured for agent consumption. Those worse inputs produce worse outputs from the agent downstream. The tax cascades through the entire delivery loop.

The Demo Gap is a related but distinct problem: the distance between what stakeholders saw in a demo or prototype and what engineering actually built. Every PM has experienced it. The Figma mockup looked right. The stakeholder signed off. The shipped feature didn't match.

The Demo Gap accumulates from the same source as the Translation Tax: handoffs without structured connections. A design that references conventions the agent doesn't know about. Requirements that describe behavior but not context. Stories that capture what to build but not why — or what not to build. Each gap in the handoff introduces drift, and drift compounds across the delivery loop.

At scale, the Demo Gap is not a communication failure. It is a structural one. Stakeholders approved a thing. Engineering built a different thing. Both teams followed the process correctly. The process had gaps. ProductHarness closes those gaps by making the repo — not email, not Figma comments, not memory — the continuous thread of context from first intent through final delivery.

When translation work is handled by the agent — formatting, routing, converting — PMs reclaim time for the work that actually requires them. Three specific shifts follow immediately:

The Translation Tax names the problem. The Double Loop describes the complete lifecycle model — two self-contained loops, Discovery and Delivery, connected at the crossing point — and shows where AI-enabled translation work sits at every stage.