Cross Functional Pairing: An experience report

With Ehren Murdick

Successful product teams have the autonomy to change the product with no one person becoming the bottleneck. To achieve this, it’s important for the whole team to own the product collectively. Cross functional pairing is when people from different disciplines pair together on their work, and we believe it’s a great way to improve collective ownership. In this post, we’ll discuss Product Manager (PM)-Engineering pairing.

PM and Engineering pairing on Product Management

Successful product direction is one that maximizes value while minimizing cost. Engineers are good at seeing and interpreting effort but not as much value, and PMs are good at assessing value but may need engineering input to assess effort.

Diana (Product Manager):

Understanding complexity is not always straightforward, especially within large enterprises with complex infrastructures. While working at a large financial institution, I soon started to pair more with my technical lead, Alex, to help define the direction of the product. Alex would advise on the high level complexity of large features sets while I would bring knowledge of the user and business needs. We soon were able to better advise stakeholders of when to pull away from an idea or to push forward. Moreover, we kept pairing on occasional story writing to make sure we were balancing breaking down the story in a way that delivered value to the user while keeping complexity low for all the developers. We had to do this in order to balance doing right by the user with doing right by the engineering team. As a result, Alex and I were able to better provide a product direction that balanced user value against complexity. We also shared the ownership of the product direction.

Engineering and PM pairing on Development

Implementing a story involves negotiating scope between the engineering and product teams. Good engineering, like product planning, is often about minimizing effort while preserving value. An engineer should point out opportunities to cut scope at every stage of working through a story without sacrificing user value.

Ehren (Engineer):

While on a recent project, I found that the scope of some stories was changing while the story was being implemented because we had a very short feedback cycle with our stakeholders. The team was very small and agile and we were doing lots of experiments. To incorporate this feedback in real time, I paired with Lex (a PM) to work on implementation. In one example, a story was to create a interactive error page. As the story was estimated, it implied lots of interaction which we later learned was not needed. While pairing together we were able to quickly integrate that feedback, and we saved a lot of engineering time by cutting out the extraneous interactions. This is a process that we have always gone through asynchronously. Instead we actively negotiated scope while working, saving the time it would take to interrupt the development flow and wait for a response. As a side effect, Lex also learned how to make changes to our html templates, learning to share some of the code ownership responsibility with the engineering team.

Better product planning!

When a PM understands the complexity of different product decisions, they can more easily weight them against their user value. This is important for deciding what thing to build next.

Better code!

By pairing across disciplines, we found that we could reduce the turn-around time for negotiating scope. We can be more creative in our approach because we are drawing from more diverse perspectives.

Better Empathy!

By learning more about what everyone else is doing, it becomes much easier to have empathy for each other. This creates better team harmony.

Conclusion

We think that pairing across disciplines adds a lot of value to the projects that take the leap. Product planning can be improved by Cross Functional Pairing when your product has a lot of technical complication like in the case of Diana and Alex’s product. Engineering can be improved by Cross Functional Pairing when your project has a very short feedback cycle like what Ehren and Lex encountered. We’re sure there are other cases where it makes sense to, those are just the ones with which we have first hand experience.