Why Product and Engineering Keep Drifting Apart
Product and Engineering are two sides of the same coin.
They are the Yin and Yang of building great software products.
Too much Yang and we build a product nobody wants. Too much Yin, and we're blowing hot air.
A balanced partnership is required. We need to bring Product and Engineering closer together to have effective collaboration. That's well understood.
But what's often not so clear is exactly why these two partners keep drifting apart.
What is that magnetic force that repels the partners and almost naturally pushes them into silos?
The first thing we need to understand is that both halves look at software products from a different angle. Product is outward-facing. They look at the users, the market, the problems. Engineering is inward-facing. They look at the quality, features, and the solutions.
That gives them different incentives.
So while we want to bring them close together, we must accept that they remain Yin and Yang, interconnected but opposing forces. It takes energy to keep them together and balanced.
A pattern I often see is the desire for Product-specific tooling. Once the development team is up to speed, some product manager will come up with the idea to buy another tool. They want to ditch the dev-centric Jira and move all product-related work to Aha!
It's an understandable reflex. They'll look at those tools and see how their favorite PM app is much better. They'll see a backlog full of technical stories that drag down the grooming sessions and have little to do with the product strategy. They want to plan new experiments without keeping room for that damn Kubernetes migration. Breaking up the tooling feels like it will make life easier.
More often than not, that's an expensive mistake.
Having separate tools for Product and Engineering increases the repelling forces and pushes both partners further apart. While such a separation is technically possible, it comes at a price: more energy is needed to keep the balance.
Someone needs to keep these two systems in sync, and even with automatic integration, this requires a lot of manual work. When developers encounter an urgent vulnerability and drop everything to patch it, someone needs to update the PM tool as well. When Product discovers an opportunity and changes its roadmap, they must make sure the engineers are aligned. They'll have to read through two systems if they want to investigate why certain decisions were made.
But even if we manage to keep both systems in sync, it's impossible to guarantee that they are. By definition, some potentially expensive mistakes will slip through the net.
So, it's important to make the business case when Product starts dreaming of splitting up the tools. What can Aha! do that Jira can't? Is it worth adding yet another tool to the mix? Is it worth the hassle of syncing these two platforms? Is it worth the occasional expensive mistake? How will we plan operational work on the roadmap? How do we make sure the product roadmap aligns with reality and isn't pure fantasy?
Sometimes this business case can be positive. Some environments might benefit from splitting up the tooling. But in most cases, this will be a net loss. The cost to keep the two tools in sync will be indefensibly high.
In that case, the teams are better off finding a compromise when it comes to tools. Buy that Jira plugin for advanced road mapping and RICE scoring. Create a hierarchical plan and filter out all the "too technical" stuff.
Keeping those two halves together is an often overlooked responsibility of a technical leader. When Product wants their own tools or Engineering wants to “refactor the whole thing”, someone needs to make a business case and come up with a compromise. Without such a leader, the company breaks apart into silos.
Energy spent on keeping tools in sync is energy not spent looking outward or inward.
Let’s make sure we spend it well.