The False Dichotomy
The framing of "product vs engineering" is already wrong. It assumes these are opposing forces — product wanting to move fast and add features, engineering wanting to slow down and build properly. Some companies operate this way. They shouldn't.
The most effective product and engineering organisations I've seen (and tried to build) operate as a single integrated team with a shared mission: build the right thing, build it well, and learn from what you built.
Getting there requires work from both sides — and clear, honest alignment at the CTO/CPO level.
What Engineers Get Wrong About Product
Engineers often underestimate the difficulty of prioritisation. When a product manager says "we're not building that right now", it rarely means they don't understand its importance. It means they've made a judgment about relative priority across a landscape of competing demands — many of which engineers aren't fully aware of.
The most effective engineers I've worked with treat product priorities as inputs to understand, not outputs to resent. They ask "why is this the priority?" and engage genuinely with the answer.
Engineers also underestimate the value of user feedback. The instinct to build something technically correct can override the instinct to validate that the technically correct thing is what users actually need. Product's insistence on user research, A/B testing, and feedback loops is valuable discipline — not bureaucracy.
What Product Gets Wrong About Engineering
The most common mistake: treating tech debt as a negotiating chip. "We'll deal with tech debt in Q3" — said every Q1, every year, never arriving. Engineering capacity spent on debt reduction is capacity not spent on features. It's a real cost. But unaddressed debt compounds. The conversation needs to be honest about what debt costs long-term, not just this sprint.
Product sometimes underestimates the cognitive overhead of context-switching. Rapidly shifting engineering focus — "actually, we need to prioritise X, not Y" — is more costly than it looks on the Jira board. Engineers need sustained focus to work effectively. Stable priorities (even for 2-week sprints) matter.
The Practices That Work
Shared understanding of technical constraints: Engineers should have a voice in technical feasibility during discovery, not at delivery. "We could build that, but here's what it costs" is a valuable input to product decisions — if delivered early enough to matter.
Engineering involvement in user research: Some of my best insights have come from engineers observing user research sessions. When engineers understand the users' pain directly, their technical decisions are better.
Explicit tech debt investment: We allocate a fixed percentage of engineering capacity to improvement work every sprint. It's not negotiable. It's not "Q3". It's this sprint. This predictability makes the product roadmap more reliable, not less.
Honesty about estimates: "We'll need 3 weeks for this" spoken in a room where saying 1 week would reduce pressure is a small act of integrity that compounds over time. Engineering cultures where estimates are distorted by social pressure produce consistently late projects.
The Pennies Award Moment
In October 2024, I received the Unsung Hero Award from Pennies, the micro-donation charity. Freddie's Flowers had won the Partnership Breakthrough Award in the same ceremony. The award recognised quiet, consistent technical work that enabled something meaningful — customer donations rounded up at checkout, with no friction, supporting UK charities.
That kind of work — unglamorous, technically careful, quietly impactful — is exactly what good engineering culture enables. It happens when product and engineering are genuinely aligned around outcomes rather than outputs, and when the team trusts each other enough to work without needing credit.