The Boston Product Management Association hosted a meetup at HubSpot yesterday about the collaboration between Product Management and Engineering. Chatting with a few people before the start of the event, it sounded like there was a need for a productive tension between the two roles. Here are a few notes from the discussion about that productive tension.
Michael Woonton facilitated the panel composed of Sophie Higgs and Stuart Layton from Hubspot, Adam Buggia and Bryan Dunn from Localytics, and Kylie Brennan and John Siemering from Wayfair.
In the first 5 seconds, a panelist explains his role as ensuring that every member of the team understands what the “North Star” was. They are using OKRs (Objectives and Key Results) to reach that shared understanding and to ensure the focus on the customers.
For context, all the panelists are working with self-directed small teams. The vocabulary differs from each other, some are calling them agile teams, others scrum teams, and others squads, but the focus of one team delivering end to end a specific area is similar.
Another panelist highlighted the fuzzy separation of roles between the product manager and the engineering manager. The blurred separation makes their collaboration better and avoids the “threw over the wall” effect of a more classic division of the roles.
Investing in the relationship between the product manager and the engineering manager is crucial to make the collaboration sustainable and effective. Learning to speak each other language helps to find common ground on aspects that seem to traditionally opposed product management and engineering. “Do we want more new features?”; “Do we want to resolve our technical debt?” are not questions they are asking. They are not working on technical debt for the sake of it, but for advancing the resolution of a problem for a customer.
Speed is the critical aspect highlighted by all. Speed to get problems solved faster. Speed for the users of the products.
One of the product managers mentioned that with his engineering background, he noticed that his own technical knowledge could be a limiting factor. When he believes something is not possible, he could even avoid submitting the problems to the engineering team. He realized that as technology evolves fast, his limiting beliefs were sometimes wrong.
The roadmap represents the best guess at solving the right problems right now. Adjusting regularly the assumptions and continuously evolve the roadmap is part of the game. The roadmap will not present a list of features, but the business outcomes positioned in the business context, and they nearly all agreed that OKRs is the way to share objectives between teams and foster collaboration. The only caveat was on being cautious not to lose the vision and the associated narrative [which is the way OKRs are supposed to work anyway].
Dependencies between teams are a lack of communication. The communication needs to make visible the connection between the business outcomes and the contributions of the different teams. Once again, OKRs are a way to ensure that several teams understand their contributions to the same Key Result.
On the topic of dependencies, one of the panelists mentioned Conway’s law, as a reminder of the connection between your organizational structure and the product you build.
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
Conway’s Law
Continuing on dependencies, I appreciate the honesty of one participant explaining how her team tried to solve by itself a problem that should have been addressed by another team. The process of learning the skills they did not have was at the same time interesting, and a big waste for the company as the other team could have solved the problem faster, if only they understood how important it was.
Who gets to hear the feedback of the customers, was another question unifying the panelists. Having the team hearing directly the feedback from the customers is beneficial. Having the team working directly with the support organization, and feeling the pain of customers help them to find a faster way to solve important pain points.
A question from the audience was around legacy and technical debt. Hearing the question, I thought it was more a “legacy organization” question in a company where product management and engineering were in opposition instead of collaborating on shared goals.
What are your thoughts on this productive tension between product management and engineering?