The Product Owner Is Not a Communication Problem. The Translation Gap Is.

There is a common argument on Hacker News that goes something like this: PMs talking directly to engineers is a recipe for scope creep, complete requirements misses, and misallocation of valuable engineering time. The solution, implied or stated, is to put a product owner in between — someone who translates business requirements into engineering language and engineering constraints back into business language.

The problem is that this solution just moves the failure point. The PO becomes the translation layer. And translation requires fluency in both languages — business strategy and system architecture — simultaneously. Most product owners are fluent in one and conversational at best in the other. Every requirement that passes through them loses something. Every engineering constraint they relay back to leadership loses something. By the time a business goal becomes a shipped feature and the outcome gets reported upward, the chain of translations has introduced errors that no one on either end can see.

The answer to this is not "hire better communicators" or "run more grooming sessions." It is giving product owners direct access to system reality so they can stop translating and start verifying.

What product owners are actually being asked to do

The job description says: define requirements, prioritize work, communicate progress, represent the business to engineering and engineering to the business. What that actually means in practice is: translate in two directions simultaneously, in real time, without making mistakes, in domains where you have uneven fluency.

From business to engineering: take a stakeholder's goal — reduce churn, increase conversion, fix this customer complaint — and turn it into a Jira ticket precise enough that engineering can estimate it, implement it, and ship something that matches the intention. This requires understanding what the system currently does, what it would take to change it, and which constraints are real versus negotiable. Most POs know the goal but not the system.

From engineering to business: take what engineering shipped — a feature flag rollout, a permission model change, a service refactoring — and translate it into status updates, launch readiness assessments, and stakeholder communications that are accurate and actionable. This requires understanding what was built well enough to explain it clearly to people who are making decisions based on that explanation. Most POs can relay the message but not verify it.

These are two different translation tasks, running in parallel, dependent on each other, and both requiring system knowledge that the PO largely does not have. The structural expectation is unreasonable. Not because POs are underqualified — but because the information they need to translate accurately has never been accessible to them in a usable form.

Why translation at every hop loses fidelity

Every time information passes through a translator who does not fully understand the source language, it degrades. This is not a communication problem. It is a physics problem. You cannot transmit information you do not have.

The translation chain — and what gets lost at each hop:

  Business goal (what leadership needs):
    "We need to block free-tier users from exporting reports."
    (context: competitive pressure, pricing strategy, contract obligations)
        |
        v  [hop 1: business → PO]
  PO's interpretation:
    "Free-tier users should not have access to the export feature."
    Lost: which export feature? API export? CSV download? Scheduled reports?
    Lost: does this apply retroactively to existing free-tier accounts?
    Lost: what happens to users mid-upgrade when the feature toggles?
        |
        v  [hop 2: PO → engineering]
  Jira ticket:
    "Remove export button for free-tier users."
    Lost: the conditional edge cases the PO wasn't aware of
    Lost: the three places in the codebase where export is handled differently
    Lost: the permission model that actually controls feature visibility
        |
        v  [hop 3: engineering → PO]
  Engineering response:
    "Done, but we made it a feature flag so we can roll back."
    Lost: what 'feature flag' means for the rollout timeline
    Lost: which accounts the flag is currently on
    Lost: how the flag interacts with the billing service check
        |
        v  [hop 4: PO → business]
  Status update to leadership:
    "Export is now restricted for free-tier users."
    Lost: the three edge cases still unhandled
    Lost: that the flag is not yet enabled in production
    Lost: that API export is controlled by a different code path entirely

By the time a business goal completes the round trip — from leadership to PO to engineering to PO to leadership — the fidelity loss at each hop has compounded into something that can produce materially wrong decisions. Leadership thinks the feature is live for all free-tier users. The feature is live for new downgrades only. The PO could not transmit the distinction because they did not understand the flag mechanism well enough to preserve it in translation.

This is not negligence. It is the structural result of routing information through a node that cannot fully parse it. The PO translates faithfully based on what they understood. What they understood was partial. The output reflects the gap.

The three places where PO translation fails most expensively

Translation failures are not evenly distributed. They concentrate at three specific points in the product development cycle — scoping, estimation, and stakeholder updates — and the cost at each point is distinct.

Three places where PO translation fails most expensively:

  1. SCOPING (requirement → ticket)
     PM asks: "Can we limit data exports for free accounts?"
     What PO writes: "Disable export for free tier users"
     What engineering discovers in sprint:
       - There are four export surfaces (UI button, API endpoint, scheduled reports, webhook)
       - The ticket only covers the UI button
       - The other three were not considered because the PO did not know they existed
     Cost: three unplanned tickets, a rushed sprint, partial launch, stakeholder confusion

  2. ESTIMATION (engineering constraint → business timeline)
     Engineering says: "The billing service is tightly coupled to the subscription model,
       so changing how permissions are checked requires a migration."
     PO translates to leadership: "Engineering says it's more complicated than expected,
       maybe a couple extra days."
     Reality: 'migration' means a coordinated deployment with a two-week rollback window
       and a freeze on other billing changes during that period.
     Cost: a missed launch date that leadership did not see coming

  3. STAKEHOLDER UPDATES (system behavior → business language)
     Customer asks: "Why can I still export even though I downgraded?"
     PO asks engineering: "Is the export feature restricted for downgraded accounts?"
     Engineering: "The feature flag is on for new downgrades, but legacy accounts
       went through a different path and don't have the flag."
     PO communicates: "There's a technical issue with some older accounts,
       engineering is looking at it."
     Lost: the scope (how many accounts), the root cause (flag vs. permission model),
       the timeline (unknown), and the workaround (none communicated).
     Cost: customer trust, support escalations, a support team operating blind

In scoping, the PO writes requirements without knowing the full system surface, so tickets miss entire categories of behavior. In estimation, the PO relays engineering constraints to leadership without the technical context to make them legible, so timelines land wrong. In stakeholder updates, the PO communicates system behavior without understanding it precisely enough, so decisions get made on inaccurate information.

Each of these failure modes is recoverable individually. When they compound across multiple sprints, the cost accumulates into chronic misalignment between what the business believes the system does and what it actually does.

Why "work more closely with engineering" does not fix this

The standard prescription is better collaboration: more frequent touchpoints, clearer handoffs, tighter feedback loops, embedded POs in engineering teams. These interventions are not wrong. They are just insufficient for the actual problem.

Collaboration improves the quality of individual conversations. It does not solve the underlying asymmetry. At the end of every conversation, the engineer goes back to the codebase and the PO goes back to the ticket board. The information the engineer has — the actual behavior, the real constraints, the live system state — does not transfer into a form the PO can hold onto, query later, or use independently. The PO leaves every engineering meeting better informed than they were, and still without the system access they need to do their job without the meeting.

"Work more closely with engineering" also has a cost ceiling. Engineers' time is the most constrained resource on a product team. Increasing the surface area of PO-engineering collaboration means increasing the tax on engineering time. At some point the collaboration overhead eats into the time that was supposed to be freed up by having a PO in the first place.

What direct system access gives POs that better collaboration cannot

When a product owner can query the codebase directly in plain language, the translation problem changes shape. Instead of receiving a translated answer from an engineer and re-translating it for a stakeholder, the PO can verify the system state themselves, ask follow-up questions without scheduling a meeting, and communicate upward with confidence that the information is accurate — because they checked it.

This is not about making POs more technical. It is about giving them a layer of system access that does not require technical fluency to use. The gap between "I was told the export restriction applies to all free-tier accounts" and "I can see that the restriction is applied via a feature flag that does not cover accounts created before 2024" is not a gap in communication skill. It is a gap in access. The PO who could verify that directly would write a better requirement, give a more accurate status update, and catch the edge case before the customer does.

The verification gap — the distance between what a spec said and what the code actually does — is exactly what compounds when POs cannot check the implementation. Direct system access closes that gap without requiring an engineering meeting every time a PO needs to confirm something.

Kognita's Jira MCP integration takes this further by connecting codebase reality to the work already captured in tickets. A PO can ask which open Jira epics touch the billing service, see which in-progress tickets share a dependency with the one they are writing, and understand the blast radius of a proposed change before it goes into sprint planning. This is not theoretical system access — it is the specific information POs currently have to extract from engineering conversations, made directly available in the planning context where they need it.

What Kognita's Jira + codebase integration gives a product owner:

  Instead of translating, the PO can verify directly.

  Query: "How many places in the codebase handle data export?"
  Kognita: ExportController (UI), /api/v2/export (REST endpoint),
    ScheduledReportJob (batch), WebhookService.onDataChange (event-driven).
    Four export surfaces. Permission checks differ across all four.

  Query: "Which Jira tickets in progress touch the billing service?"
  Kognita: PM-441 (export restriction), PM-489 (plan upgrade flow),
    PM-502 (invoice generation refactor). PM-489 and PM-441 both modify
    BillingService.checkEntitlements — sequential merge required.

  Query: "What does 'feature flag' mean for the export restriction rollout?"
  Kognita: FeatureFlags.exportRestricted is currently false for all accounts.
    Enabling it affects 4,312 active free-tier accounts.
    Legacy accounts (created before 2024-03) use a separate entitlement path
    not covered by this flag.

  The PO is no longer translating. They are reading the system directly —
  in plain language, without needing to ask engineering to explain it.

The difference between translation and verification is consequential. A PO who translates is dependent on the accuracy of what they were told and their ability to convey it. A PO who verifies is dependent on the system — which does not forget details, does not simplify under time pressure, and is always current.

Final take

The product owner is not a communication problem. The translation gap is. POs are structurally positioned to be the information conduit between business and engineering, and the tools they have been given to do that job — Jira tickets, documentation, engineering meetings, intuition — are inadequate for the job's actual requirements. Every hop in the translation chain loses fidelity, and the cost compounds across sprints into chronic misalignment that shows up as customer bugs, missed timelines, and planning surprises.

The fix is not improving the translation. It is eliminating the need for it. When product owners have direct access to system reality — can query what the code actually does, understand the real constraints, see what is in progress and what it touches — they stop relaying information and start verifying it. That single shift changes scoping, estimation, and stakeholder communication in ways that no amount of better collaboration can replicate.