Why, when, and how product managers should collaborate with a pair.
At Pivotal Labs, our engineers pair program. Pair programming is a practice in which two engineers work together. They share a single computer and one engineer acts as the driver while the other acts as the navigator. We practice pair-programming because it leads to more productive teams. These teams tend to write better code and have a stronger sense of shared ownership.
What it’s Like to Pair for a Year
As product managers, we often get asked “do you pair as well?” The answer is yes and no. On a typical Pivotal Labs engagement, we’re not pairing as strictly as our engineers do. But, we do spend a good part of our day working with another PM or Designer, sharing a computer or a whiteboard.
I recently had the chance to pair with another Pivotal PM on a more extensive basis. I also got a chance to speak with other PMs at Pivotal about their experiences “pair PMing”. As it turns out, a lot of the benefits we see from pair programming also apply to pair PMing.
Make Better Decisions
One of the reasons we pair program is that two engineers tend to make better decisions than one. One of the most important things we decide as PMs is what problem we should tackle next. To arrive at this decision, we conduct user research and interviews with stakeholders. Through this, we gain a deep understanding of the problems that exist and form opinions about their relative priority. Our understanding of those problems is richer and less bias-prone when information and data is processed by more people. One PM might bring to the table a more user-centric view, while the other may have a really good strategic mindset. One may notice important details that the other PM overlooked.
Identify Assumptions
Another important task PMs have is to identify the risky assumptions we should test. Two PMs tend to do a better job identifying those assumptions. They also come up with better experiments to test those assumptions. The result is that we can get more value out of each iteration, arriving at more valuable software faster. These experiments are the kinds of decisions that can make or break a product, so it’s important to consider when you might want two heads instead of one.
Learn More
One other oft-touted benefit of pair-programming is that it helps engineers learn from one another. Even seasoned engineers say they learn something new almost every time they pair. This goes for PMs as well. When another PM, who has context on your team and product, observes you work, they are able to give you high quality feedback. On top of that, when you are pairing, you are repeatedly contrasting how you approach problems with how another PM approaches those same problems. This leads to increased self-awareness of your strengths and weaknesses as well as your “style” as a PM.
How to Pair PM
So how do you actually pair as PMs? I don’t think there’s a clear formula. When working at a computer writing stories, or constructing a product update, it can follow a driver-navigator model: one PM types, while the other identifies errors and omissions or suggests better ways of phrasing things. When running a stakeholder check-in, one PM might facilitate the conversation while the other PM captures notes and action items.
You must also have faith that your pair can bring things to the table that you can’t.
Just like with pair programming, the role that each PM plays can be fluid and the precise mechanics that work best may differ based on the activity and the pair you’re working with. When you and your pair get good at collaborating, it will feel organic.
Practice Patience
I’ve talked a lot about the benefits of pair PMing, but like pair programming, pair PMing is difficult. And it’s not for everyone. It requires patience, empathy toward your pair, and a willingness to change your mind. You must also have faith that your pair can bring things to the table that you can’t. Without these ingredients, pair PMing can go awry and become detrimental to the team and product.
When to Pair PMs
Pair PMing is costly. As a result, we tend to limit pair PMing to specific scenarios. For example, onboarding new hires, transferring a product from one PM to another, or managing a product with large scope. In my experience, pair PMing has benefits beyond these scenarios. For example, I was working on a product and I formed a strong opinion that a particular feature wasn’t needed because it wasn’t valuable to users. After a long debate with my pair, we decided to build it. While I was right about the users, it turned out that the feature provided a lot of value to the business. It really impressed our stakeholders and helped garner their support. My pair had read into the needs of the business in a way that I had not.
Does this mean we should always pair PM? I’m not sure. I think there’s more exploration to do to figure out when pair PMing makes sense and when it doesn’t, but I suspect we’d benefit from doing more of it.
Do you have experience pair-PMing? If so, I’d love to hear about it.
Thanks to Ash Hathaway, Alvin Hsieh, Ankit Jain, Colin Jackson, Eleanor Millman, Jim Thompson, John Martin, Liz Morris, Jaron Parnala, Kiel Levy, Matt Curry, Sameer Vohra, Somesh Baldawa, Sean Ho Lung, Tiffany Jordan and Tim Lombardo for sharing your thoughts on this topic.
Pairing for Product Managers was originally published in Built to Adapt on Medium, where people are continuing the conversation by highlighting and responding to this story.
