Pair programming is by now a quite well known development technique. Developers that have tried it out and chose to go with it, report that they learn more, feel more productive and in general get more satisfaction out of their work.
Since I am not a developer I thought I would never be able to have the “pair programming” experience. Luckily, I was wrong. For the past year I shared the Product Management role for our internal CI/CD setup tool, with my good colleague Dominik Finkbeiner and we did what I can only describe as “Pair Product Management” sessions.
How we paired
Firstly, we chose a single idea or a feature request that we wanted to bring to the rest of the team. One of us would start talking about what we should do, more like talking out loud, while the other would pay attention and take notes. Once the first person had let everything out, we would go over it and start asking “what about?” and “what if?” and the second person continued filling in the information. Then, we would reverse the roles and try to see the problem from the second person’s perspective repeating the exercise. By the end of our meeting that was about 45 minutes long, we usually had a very solid understanding the best way to go forward, disregarded some options and identified our constraints.
Why it worked
Our skillsets are quite complementary. Dominik has a vast technical knowledge, can suggest pragmatic solutions to complicated problems and is the visionary that can pivot to a totally new direction when needed. I can find patterns in what users are saying, like to provide as much information to them as possible and because of my testing background, question ALL the things.
Another reason is that we both had the same information before starting the pairing session. Every developer doesn’t necessarily want to know all the background that brings a feature forward. But since we were both product managers we had a common understanding of the implications and the constraints of the topic we were working on, making it much easier to reach a result.
But none of this would have been enough, without mutual trust and respect. We challenged or even confronted our ideas and beliefs only to come up with better ones, rather than satisfy our own ego. And even if it got intense at times it was always a fulfilling collaboration.
What were the benefits
The benefits we experienced were similar to the ones reported by pair programmers. Every feature idea was conceptually well designed as it would go through two levels of refinement, one from our pairing session and then one from the entire team.
Since we defined the features together, we had a common knowledge which meant that neither of us was a bottleneck if the team needed to change direction during the implementation.
And finally, it significantly improved our mental health. Sometimes as a Product Manager you feel you have the weight of the world on your shoulders. Having each other as a sounding board and sharing the weight of the responsibility and the decision on the course we would take made it everything so much less stressful. And indeed fun.
When we started pairing, we didn’t do it consciously or had a name for it. It was something that evolved over time as we kept at it, seeing its value. Even if you don’t formally share the role with someone, pairing on certain topics might bring you some of the benefits described here. Maybe it’s worth giving it a try.
More Questions Than Answers 
One thought on “Pair Product Management”