The Product Owner in Engineering-Heavy Teams: Making It Work

The Product Owner role was designed for feature teams building user-facing products. The PO talks to customers, understands their problems, writes stories that describe desired outcomes, and the engineering team figures out how to build them. When it works, it's a clean separation of concerns: the PO owns the what and why, the team owns the how.

Then you try to apply the same model to a platform team, an infrastructure team, or any team where the majority of the work is deeply technical and invisible to end users. The PO writes stories like "Improve database performance" because they don't understand the specifics. The team ignores the stories and works off a tech lead's mental backlog. Sprint reviews become awkward theater where engineers demo things the PO can't meaningfully evaluate. Nobody is happy.

I've seen this pattern play out dozens of times. The problem isn't the PO and it isn't the engineers. It's that the standard PO model wasn't designed for this context, and nobody adapts it.

The Core Tension

In a feature team, the PO brings domain knowledge the engineers lack. They know the customer, the market, the business constraints. The value exchange is clear: the PO provides context about what to build, the engineers provide expertise on how to build it.

In an engineering-heavy team, this dynamic breaks down. The "customers" might be other engineering teams. The "product" might be an API gateway, a CI/CD pipeline, or a data platform. The domain knowledge lives with the engineers, not the PO. The PO is now the person with the least context about what the team should be working on, which is exactly the opposite of how the role is supposed to function.

This creates three specific failure modes:

The rubber-stamp PO. The PO defers entirely to the tech lead, approving whatever the team proposes without meaningful input. Sprint planning is a formality. The PO exists on paper to satisfy the process but adds no value.

The frustrated PO. The PO tries to apply their product instincts but keeps getting shut down. "You don't understand the technical constraints." They feel excluded and respond either by disengaging or by asserting authority through the one lever they have: priority.

The blocking PO. The PO insists on controlling priority without technical context. They deprioritize critical technical work because it doesn't map to visible business outcomes. Tech debt accumulates, the platform degrades, and eventually something breaks in production.

Communication Patterns That Work

The solution isn't to remove the PO from engineering-heavy teams. It's to redefine what the PO contributes and how the team communicates.

Translate technical work into business impact

Every piece of technical work has a business reason. The team's job is to make that reason explicit. Not as a political exercise -- as a genuine effort to connect what they're building to why it matters.

Bad: "Refactor the message queue consumer to use batch processing." Better: "Reduce order processing latency from 12 seconds to under 2 seconds, which directly affects checkout conversion."

Bad: "Migrate from Jenkins to GitHub Actions." Better: "Cut our deploy pipeline from 45 minutes to 12 minutes, enabling teams to ship 3x more frequently with the same confidence."

This isn't dumbing things down. It's completing the thought. Engineers who can articulate the business impact of their technical work are more effective, regardless of who their PO is.

Use spike stories for uncertainty

When the team doesn't know the right approach, don't pretend they do. A spike story is a time-boxed research task with a defined output: not working code, but a recommendation.

"Spike: Evaluate three approaches to real-time event processing. Output: ADR with recommendation. Time-box: 3 days."

The PO can understand and prioritize this. It has a clear deliverable and a clear time investment. When the spike completes, the team and PO discuss the recommendation together, and the implementation stories that follow are better scoped because the uncertainty has been resolved.

Establish a tech stories budget

This is the single most effective pattern I've seen for managing technical work within a PO-led process. The team and PO agree on a fixed allocation -- typically 20% of sprint capacity -- dedicated to technical improvement that the team prioritizes independently.

The rules are simple:

1. The team chooses what goes into the 20%. No PO approval needed.
2. The team communicates what they're working on and why (transparency, not permission).
3. The 20% is non-negotiable. It doesn't get raided when a deadline approaches.
4. The remaining 80% follows normal PO prioritization.

This works because it removes the constant negotiation. The PO doesn't have to understand why the team needs to upgrade the ORM or refactor the auth middleware. They've already agreed that 20% of capacity is the team's to allocate. And the team doesn't have to justify every technical decision to someone who lacks the context to evaluate it.

Decision Rights: Who Decides What

Ambiguity about who decides what is the root cause of most PO-engineering conflict. Make it explicit:

The PO decides:

• What business problems to solve and in what order
• Release timing relative to business needs
• Scope trade-offs when time is constrained ("ship with manual workaround now, automate later")
• Whether a feature is "done enough" from a user perspective

The tech lead decides:

• How to implement a solution
• Architecture and technology choices
• Technical quality standards (test coverage, code review requirements)
• Whether something is technically ready to ship (no known critical bugs, acceptable performance)

They decide together:

• What's feasible within a given timeframe
• When technical debt should be prioritized over features
• How to handle incidents and their follow-up
• Team capacity allocation between feature work and technical work

Write this down. Put it on the team wiki. Reference it when conflicts arise. Most disagreements between POs and tech leads stem from one party making a decision that the other believes is in their domain. An explicit framework prevents that.

When the PO Says "Just Make It Work"

Every engineer has heard this. A PO who doesn't understand the technical complexity waves it away: "I don't care about the implementation, just make it work by Thursday."

The temptation is to get angry or to comply and cut corners. Neither helps. What works is translating the constraint into options.

"I understand you need this by Thursday. Here are three options:

1. Full solution: 2 weeks. Handles all edge cases, is well-tested, production-ready.
2. 80% solution: by Thursday. Covers the main flow, needs manual intervention for edge cases, adds 3 days of tech debt we'll need to address next sprint.
3. Prototype: by Wednesday. Demonstrates the concept, not production-safe, would need to be rebuilt."

Now the PO has a real decision to make. They might choose option 2, which is fine -- but they're making an informed trade-off, not an ignorant demand. And the tech debt is on the record, not hidden.

The Partnership Model

The best PO-engineering relationships I've seen work as a partnership between the PO and the tech lead, not a hierarchy where one reports to the other.

They talk daily, not just in ceremonies. The tech lead gives the PO a heads-up about emerging technical risks. The PO gives the tech lead early signals about shifting business priorities. They present a unified front to the team and resolve their disagreements privately.

This requires two things: a PO who genuinely respects engineering complexity without needing to understand every detail, and a tech lead who genuinely respects business context without dismissing it as "non-technical."

At Conectia, our engineers join teams that have all kinds of PO dynamics -- from perfectly functioning partnerships to teams where the relationship needs work. Because our engineers are senior, they know how to communicate technical decisions in business terms, how to push back respectfully when priorities don't account for technical reality, and how to build the trust that makes the PO-engineering relationship productive. That's not a process skill -- it's a seniority skill.

The PO role in engineering-heavy teams isn't broken. It just needs to be adapted. And the adaptation isn't complicated: clear communication patterns, explicit decision rights, and two leaders who respect each other's domain.

---

Need senior engineers who know how to work with product owners, not around them? Talk to a CTO -- our LATAM engineers bring the communication skills and technical depth that make cross-functional teams actually work.