Every Translation Is a Lie

A founder tells her operations lead: "We need to know which listings are underperforming."

Clear enough. The operations lead writes it up in a meeting summary. The product manager reads the summary and creates a Jira ticket: "Dashboard — listing performance metrics." A designer interprets the ticket and mocks up a screen with twelve filters, a date range picker, and a comparison view. A developer reads the mock, makes a few assumptions about the data model, and builds it.

Six weeks later, the founder opens the dashboard. It's polished. It's functional. And it doesn't answer her question.

Nobody was incompetent. Nobody dropped the ball. The intent simply passed through five mediums — and each one was a lossy translation. What arrived at the other end was a reasonable interpretation of an interpretation of a summary of what someone meant.

This is the default in product engineering. And the tools we've built to manage this process don't fix it. They formalize it.

The Translation Chain

Every product organization runs a version of the same pipeline:

Conversation → meeting notes → ticket → spec document → design handoff → code.

Each arrow is a translation. Each translation compresses some context, adds some assumptions, and drops some nuance. The person writing the ticket wasn't in the original conversation — or was, but remembers it differently. The person reading the ticket fills gaps with their own mental model. The spec interprets the ticket through the lens of technical feasibility. The developer interprets the spec through the lens of the existing codebase.

By the end, you're building a plausible interpretation of an interpretation of a summary of what someone meant.

This isn't a failure of process. It isn't a skill gap. It's a structural property of systems that separate thinking from building across multiple mediums. The intent starts in one format (a conversation), gets transcribed into another (text), reorganized into another (a ticket schema), expanded into another (a document), visualized in another (a design tool), and finally expressed in another (code).

Six mediums. Six translations. Six opportunities for the signal to degrade.

Why Project Management Tools Make This Worse

Jira. Linear. Asana. Notion boards. They're presented as solutions to the coordination problem — and in a narrow sense, they are. They track what's been assigned, what's in progress, what's blocked, what's done.

But they don't carry intent. They carry tickets.

A ticket is a translated artifact. Someone took a complex, context-rich idea and compressed it into a title, a description field, acceptance criteria, and a priority label. The tool then optimizes the movement of that compressed artifact — through columns, through sprints, through workflows. It says nothing about whether the compression was faithful.

Adding more fields doesn't help. Custom workflows don't help. Epics that link to stories that link to subtasks don't help. You're adding more structure to the translated artifact while doing nothing about the translation itself. More surface area for assumptions to hide in.

The deeper problem is subtler: these tools exist in a different medium than either the strategic thinking that produces intent or the codebase that implements it. They are a third language — neither business nor engineering — that both sides have to translate into and out of. The project management layer becomes the lingua franca of product development, and like all lingua francas, it's excellent for basic coordination and terrible for conveying what actually matters.

Teams end up optimizing for the tool. Velocity goes up. Ticket throughput goes up. The tool reports progress. Meanwhile, the gap between what was meant and what gets built stays exactly the same — or widens, because the tool's metrics create the illusion that the process is working.

The Signal-to-Noise Thesis

In our first article, we wrote about the distinction between grounded and ungrounded AI output. The same principle applies here, but to the entire product engineering pipeline, not just AI.

Every translation is an opportunity for the signal to become ungrounded.

The original intent was grounded in business reality — a real problem, observed by someone who understands the domain. The meeting notes are grounded in the note-taker's attention. The ticket is grounded in the product manager's interpretation. The spec is grounded in the spec-writer's technical understanding. By the time code is written, you're four or five layers removed from the original grounding.

The number of mediums a decision passes through before it becomes software is a direct predictor of how much waste the engineering process produces. Not because people are careless — because translation is inherently lossy, and each lossy step compounds the one before it.

This is why "better process" rarely fixes the problem. Better process optimizes what happens within each translation step. It doesn't reduce the number of translations. A well-run sprint with carefully groomed tickets still has the same structural issue: the ticket is not the intent.

The only way to materially improve signal fidelity is to reduce the number of mediums the signal passes through. Fewer translations, less noise. Ideally: zero translations. The medium that captures the intent is the same medium that informs the build.

What Zero Translation Looks Like

This is the architecture we've built at Reformance — not as a theoretical exercise, but as the system we use to deliver operational software for our clients.

The foundation is a structured knowledge layer that holds institutional context: business rules, operational patterns, strategic decisions, domain logic. This isn't a wiki. It isn't a pile of documents. It's a governed knowledge infrastructure where every object is structured, searchable, and machine-readable.

When a new capability needs to be built, the feature spec is written as a structured artifact within this same knowledge layer — not exported to another tool. The spec references existing knowledge objects: business rules it must respect, operational patterns it must follow, capabilities that already exist.

Before any code is generated, a contradiction detection step validates the spec against the full body of existing knowledge and functionality. Does this new feature conflict with something that's already built? Does it duplicate an existing capability? Does it violate a business rule that was established three months ago? These aren't questions a project manager can answer from memory. They require structured knowledge and automated validation.

Then the coding agent builds the feature. The agent reads from the same knowledge layer — the same business rules, the same architectural standards, the same domain context. It doesn't interpret a ticket. It doesn't guess at requirements from a spec document that was written in a different tool by a different person. It has the full context, because the context never left the system.

Here's what this looks like on an ordinary afternoon.

A property management company we work with identifies that their pricing decisions are reactive — they adjust rates after occupancy drops, instead of before. This observation is captured in the knowledge layer, not in a meeting note that gets forgotten. It becomes a structured knowledge object with context: which properties are affected, what the current decision pattern looks like, what "proactive" would mean operationally.

A feature spec takes shape in the same system: a pricing intelligence agent that monitors market signals and recommends rate adjustments before occupancy declines. The spec doesn't just describe what to build — it references the existing booking data pipeline, the property configurations already in the system, the team's established review workflow. It's grounded in everything the system already knows.

Contradiction detection runs. Does this new agent conflict with existing manual override rules? Does its recommendation format align with how the operations team already reviews decisions? Any tensions surface before a single line of code is written.

The coding agent builds the feature with full context — not just the spec, but the architectural patterns, the design system, the integration conventions, the permission model. What gets deployed fits the existing system because it was built with complete knowledge of the existing system.

No ticket was created. No sprint was planned. No standup was held to synchronize status. The intent moved from observation to deployed capability in a single continuous medium.

What Dies, What Lives

It's worth being honest about what this approach eliminates and what it doesn't.

What dies: The ticket as unit of work. The standup as status synchronization ritual. The sprint as artificial time boundary. The product manager as human translation layer between business and engineering. The spec document that lives in a different tool than either the knowledge it references or the code it produces.

These aren't sacred. They're workarounds — solutions to the coordination problems created by having multiple disconnected mediums. When you collapse the mediums, the workarounds become unnecessary overhead.

What lives: Product thinking. Prioritization. The human judgment to decide what matters and what doesn't. Quality review. The decision to ship or hold. The strategic perspective that no system can replace. The conversation with a customer that reveals something the data doesn't show.

The human role doesn't shrink. It shifts — from translator to decision-maker. Less time reformatting intent into the shape a tool requires, more time exercising judgment about what to build and why. Less coordination overhead, more actual thinking.

This is a meaningful upgrade for everyone involved. Engineers stop building things that don't match what was meant. Business stakeholders stop feeling like their intent gets lost in translation. The gap between "what we need" and "what we got" narrows — not because anyone works harder, but because the structural cause of the gap is gone.

The Compounding Effect

In a traditional setup, each project starts from near-zero context. New tickets, new specs, new onboarding. The developer who built the last feature might not be available for the next one. The business context that informed the original decision lives in someone's memory, or in a Confluence page that nobody will find.

In a knowledge-first architecture, every cycle deepens the system.

The feature that was just built gets documented — not as an afterthought, but as a natural consequence of the process. The business rules it respects, the patterns it follows, the decisions that shaped it — all structured, all searchable, all available to the next build cycle. The next feature spec is richer because the knowledge layer is richer. The contradiction detection is sharper because there's more existing functionality to validate against. The coding agent is more effective because it has more context.

The second feature is faster and more accurate than the first. The tenth is dramatically faster. Not because the team grew or the tools improved — because the system remembers. It remembers what was built, why it was built, what the business actually needs, and what has already been tried.

This is the compounding loop: build → knowledge deepens → next build is faster and more faithful → knowledge deepens further. Each cycle makes the next one better. The system gets better at writing itself.

Traditional project management doesn't compound. The hundredth Jira ticket doesn't make the hundred-and-first easier to write. The tickets are isolated artifacts in an isolated tool — they don't build on each other, they don't inform each other, they don't improve the system's ability to produce the next one.

The difference between a system that compounds and a system that doesn't is, over time, the difference between a company that accelerates and a company that just stays busy.

The Question Worth Asking

The standard question in product engineering is: "How do we manage this process better?"

Better standup cadence. Better ticket templates. Better sprint retrospectives. Better tooling for the existing pipeline. These improvements are real, but they're optimizing within a structure that is itself the problem. You can run a perfect sprint and still build the wrong thing, because the ticket that entered the sprint was already a lossy translation of what mattered.

The better question is: "How many mediums does a decision pass through before it becomes software — and can we reduce that number?"

For most companies, the answer is five or six. And each one is a lie — not a malicious lie, but a well-intentioned compression that drops something essential.

We've reduced it to one. The same medium that captures the intent is the same medium that informs the spec, validates it against what exists, and provides the context for building it. Nothing is exported. Nothing is reformatted. Nothing is translated.

Every translation is a lie. The architecture that tells the fewest lies wins.

This is the second article in Reformance's perspective series on building AI-native organizations. The first — "Why Your AI Tools Aren't Making Your Company Smarter" — explored why individual AI adoption doesn't move the needle for organizations.