Why Product & Engineering Can’t Be Separate Islands

It’s always better when we’re together

Lorraine Valera
Product Coalition

--

Photo by henry perks on Unsplash

When I entered the wondrous world of product & engineering for the first time, I did not understand why there was a split between Product & Engineering. It took me a while to understand it and honestly the more I learn about product development the more I think that split creates more friction than clarity.

Here’s usually how the division is made:
Product determines what needs to be built and in what order.
Engineering decides how and executes.

While both of these things are incredibly important, I still find this a very reductive definition for both sides. Furthermore, splitting the responsibility is a slippery slope to the blame game — 'Product created an unachievable roadmap' , 'Engineering isn't delivering what they say they will'.

Product & Engineering are co-dependent. One cannot exist without the other. You can have a great roadmap on paper but if you have no one to work on it, it’s worthless. You can have an amazing team of engineers but if you’re working on the wrong thing, you lose as a company.

The reason that scrum and other agile frameworks describe product teams as composed of product, engineering, designers, data analysts (where needed) in one team is that the combination of all these specialties is what leads to a great roadmap.

Think of a product team like you think of the X-Men or The Avengers, each team member has a superpower but it’s when you bring them all together that you can save the world.

While every role has a main focus — product brings the problem (with help from data), UX prototypes solutions, engineering determines feasibility and technical architecture — it is the discussion that happens between those roles that brings the most value. As a PM I can have the right problem, be looking at amazing solutions but if the engineers don’t have a say, we may be spending hours of discovery on features that are technically unreasonable to build. I've been in teams where presented with the problem, we came up with super simple solutions that were easy to test thanks to the engineers (who know the product intimately!!). Similarly, if engineering doesn’t flag scalability initiatives on time so that the PM knows to make room for them on the roadmap, all work might be halted at a later date due to outages.

A roadmap should be the product of a negotiation between all the members of a product team.

There is no deciding party or executing party.

Accountability and responsibility for the conception and delivery of the roadmap should be shared.

I'm not normally into sports quote but I think this one is fitting, so I'll leave you with this, which I think embodies what I am trying to say.

We win together as a team, we lose together as a team.

--

--