Building an Effective Partnership Between Product & Engineering

Problem

As companies grow to be more than a handful of people, communication no longer takes care of itself, and silos emerge. Silos between Product, Engineering (and Design & Data) are the worst kind because almost nothing gets done if that's the case. It's also common for unhealthy tensions to rise. One of the reasons is that putting together roadmaps and wishlisting product features is a lot easier than actually building them. Another reason is people not speaking the same language by default.

Actions taken

• There are key four levers that can facilitate the alignment and a good collaboration between Product and Engineering: org design, people, culture, processes.

• The organizational design should fundamentally be cross-functional and should include product, design, engineering, and data unless you have really strong reasons for a functional setup.

• Alignment starts at the top: heads of product and engineering need to be (and remain) on the same page at all times. Nip issues in the bud, set and manage expectations continuously at that level and always overcommunicate. Make that part of the culture and ensure it downstream.

• Culture of accountability and ownership: don't tolerate blame games. Everyone is trying to figure it out. At all levels (again, starting at the top), Engineering must understand the priorities, and Product must understand the trade-offs. If this is not solid, nothing else is.

• Pursue the culture of objectivity and participation: remove gut feeling and opinion as much as possible. Experimentation and data level the playing field and democratize it, so everyone can contribute with ideas regardless of who they are.

• Process - bake collaboration into how the tech org is run. Most rituals including elements of both sides, learning together from each sprint, knowledge sharing sessions, etc. But be respectful of activities to be done in isolation (e.g. engineers need long stretches of uninterrupted time -- (maker vs. manager schedule)[ http://www.paulgraham.com/makersschedule.html])
  

• Constant knowledge sharing towards a common language. In slightly bigger companies, the use of Domain-Driven Design is helpful, particularly in creating a common language between business, product, and engineering (all the way down to the code).
  

Lessons learned

• If product and engineering leaders are not fundamentally on the same page, the gap on the front lines will be massive. You have to make sure that alignment remains at the top and is actively pushed down.
• Don't try to be too sophisticated with processes, don't enforce rules beyond cultural ones. Make sure everyone understands how product and engineering depend on each other to make the company successful and keep reinforcing it.
• As engineers and engineering managers, you should go out of your way and use empathy to make sure product understands the engineering challenges, and vice-versa.
• Have a clear set of cultural norms or principles for product development, over-communicate them, and stick to them. For example, if a/b testing is king, then everyone needs to understand experiments must be small to learn quickly and often. Engineering must understand why, enable it in the short-term, and make sure technical debt is managed. This may not satisfy everyone, but not all companies are going to be for everyone.