Building a Real Engineering–Product Partnership

The problem

A team can build a feature exactly to spec, ship it on time, and watch almost no one use it. That’s not an execution failure; it’s a partnership failure. When engineering owns only the how, it never sees the problem — only the solution someone already chose — and can’t push back when the solution is wrong.

We shipped a “Bulk Export”: configurable CSV, column selection, date filters, a genuinely nice progress bar, delivered on the day we promised. Three weeks later a handful of accounts had touched it once. There was no bug. Customers had never wanted a configurable CSV — they wanted their data in a spreadsheet they already had, which meant a scheduled sync. Product knew customers were frustrated about “getting data out”; somewhere between that and the ticket, the real problem got compressed into a spec, and my team treated the spec as the truth. We had been excellent order-takers, and not one engineer was in a position to say so.

The model

The healthiest engineering–product setup is not a clean handoff; it’s shared ownership of the outcome. Product deciding alone loses the feasibility instinct engineers have from inside the system — the cheaper adjacent fix, the constraint that kills the elegant version, the thing that’s two days instead of two months. You earn a seat in defining the problem, not just solving it, by being useful upstream rather than fast downstream. Nobody hands that seat to a team that has only ever taken tickets.

What to do

• Put engineers in discovery. Two on every meaningful initiative — not to estimate, but to help frame the problem and argue the success metric before anyone writes a ticket.
• Change what you measure. Retire throughput as the headline. Track whether shipped work moved the metric it was supposed to, and review that with product.
• Write one shared definition of done that includes the outcome, not just acceptance criteria. “Built and merged” stops counting as finished on its own.
• Trade context before commitments. A standing weekly forum where product and engineering exchange constraints, leverage, and known risk — so the cheap-adjacent-fix conversation happens before the roadmap hardens, not after.

The results

Over two quarters, scope churn — work thrown away or substantially reworked after the fact — dropped to roughly half. The Bulk Export pattern stopped repeating; we caught two would-be tickets in discovery and reframed them before they cost a sprint. Time from idea to something customers actually used got shorter, though more honestly than the dashboards suggested: some initiatives took longer to start, because we argued about the problem first — they just failed far less often once they shipped.

The caveat: shared ownership blurred accountability for a while. When everyone owns the outcome, it gets murky who owns the call when product and engineering disagree. I had to draw the line explicitly — engineering owns how and has a real voice in what, but product still owns the final prioritisation. Co-ownership is not consensus, and pretending it was cost a few slow, frustrating weeks before I named it.

Further reading

• The Archives — problem-first design in BlueRobin, in practice.
• About — how I think about engineering leadership.