How to Improve Collaboration Between Product Management and Engineering

Problem

As a VP of Engineering, I manage all the technical people in our company. There is also a VP of Product and a PM who reports to the VP. However, this situation was not created by design but emerged through practice. Only three years ago we had numerous separate organizations. For example, product and design were separate while today design is a part of the cross-functional structure. The same goes for front-end development that is now part of our cross-functional team that sits under me. It was a long journey merging different organizations and coming up with this structure.

Actions

We foster an approach that we refer to as a two-in-a-box approach, though we don't call it explicitly that. It implies that everything we do should involve a product owner and a technical lead and we try to encourage a strong relationship between the two. We try to get away from the concept of a technical task and we don't differentiate between product features and technical tasks. Our goal is to align any technical innovation with the business call. In the last 18 months, we did a great job stabilizing our team structure and putting in place OKRs. We consolidated engineering and product into a technology team that is led by a VP of Product and VP of Engineering. We are still facing challenges on how to improve our relationship with marketing and sales but we are in the process of solving that soon. Another new approach was to push ownership down to the teams. VP of Product serves as the Northern Star for the business need but teams articulate solutions to that business need. For example, when we identify that we need some innovation around the purchase order system, we let the team articulate some solutions. As Steve Jobs said It doesn't make sense to hire smart people and tell them what to do.

Lessons learned

• Prior to any department and/or team restructuring, you have to reduce your focus. You can't solve every problem in every business. Further, to evaluate the effort you're about to put into something you should evaluate the impact to the business, internally or externally.
• The reasons we do retrospectives is to identify things that are broken and try to experiment and do something differently. We experimented with creating a technical team by applying the two-in-a-box approach. We incubated this approach and after positive outcomes were praised by the senior leadership, we rolled it out to the whole business.
• Stop thinking us versus them when you refer to product and engineering people. Take a Head of Product for lunch and nurture communication with him/her. Lead by example as people under you will have to bond with their counterparts as well.
• Instead of a project team, go with a product team. Project teams don't own anything. You can't just do a feature, you need to iterate and maintain the product. You have to acknowledge that in 12 months time feature that you wrote will be out of date and broken and will need a framework update or API that is attached to will be out of date.