Skip to main content

Pair product management

One head is good, two heads is mutant
Pair-programming is a well-known development methodology. With many followers and critics, this technique has proven its viability. Some major companies even made it their philosophy.


Recently I thought if pair-programming concepts could work for product managers. Spoiler alert: they could.

You still here? Ok, let's see what could make or break Pair product management.

First principals

Pair product management is two PMs working together on the same problem. While developers mostly sit at one work station, PMs can stand at one whiteboard. A PM that holds a marker can be called a "driver", while another PM is a "navigator". PMs should swap roles frequently.

Pitfalls

Agile Alliance outlines the following possible pitfalls of pair-programming.
Both programmers must be actively engaging with the task throughout a paired session, otherwise no benefit can be expected 
Could that be applied to pair product management? Surely! Both product managers should work on the same problem, otherwise, it will be merely co-location.
A simplistic but often raised objection is that pairing “doubles costs”; that is a misconception based on equating programming with typing – however, one should be aware that this is the worst-case outcome of poorly applied pairing 
Product managers are often evaluated by the quality of the decisions they make. Following this logic, paired PMs have greatly increased chances to take better-quality decisions. And therefore bring more value to the business.
At least the driver, and possibly both programmers, are expected to keep up a running commentary; pair programming is also “programming out loud” – if the driver is silent, the navigator should intervene 
I think PMs will not have a problem with that. Show me a single PM who doesn't like the sound of his voice.
Pair programming cannot be fruitfully forced upon people, especially if relationship issues, including the most mundane (such as personal hygiene), are getting in the way; solve these first! 
This is a big one. No way of working will succeed if people involved don't personally believe in it and want to make it a success.

What do you need to run Pair product management? 

Collaborative space

Your office (or wherever PMs meant to be doing their work) should promote collaboration. Yes, it means sticky notes. Lot's of sticky notes. But also whiteboards, stacks of paper, big touchscreens and markers.

Pair product management probably could work for remote PMs, if both are manic about video conferencing or hyper-active messaging. However, co-located PMs are likely to have an edge over remote pairs.

Watch out for each PMs looking at their own screen or wearing headphones, those are sure signs Pair product management doesn't work.

Office layout that controls the noise level

Paired product managers need to think out loud. This will create a noise level potentially disturbing the work of other people in the office. Hence the working space should be designed in a way that will allow controlling the noise level and would enable comfortable work.

Expected benefits of Pair product management

Let's compare those with pair programming.
Increased code quality: “programming out loud” leads to clearer articulation of the complexities and hidden details in coding tasks, reducing the risk of error or going down blind alleys 
Product managers might get increased decision quality by working together. They will challenge each other during the paired sessions and reduce the risk of major mistakes or getting stuck.
Better diffusion of knowledge among the team, in particular when a developer unfamiliar with a component is pairing with one who knows it much better
A very important benefit for a product team. Often, product knowledge is siloed in individual PMs' heads, which creates all sort of risks. When a PM leaves a company or just absent from work - the rest of the organisation might miss the vital knowledge. By pairing PMs we can expect knowledge to be equally distributed between at least two people.
Better transfer of skills, as junior developers pick up micro-techniques or broader skills from more experienced team members 
Pair product management might be an effective coaching tool. In terms of direct PM skills and organisational context. There is no better way to learn practical PM skills than to work directly with a more experienced pro.
Large reduction in coordination efforts, since there are N/2 pairs to coordinate instead of N individual developers
Yeap. Product directors - take note.
Improved resiliency of a pair to interruptions, compared to an individual developer: when one member of the pair must attend to an external prompt, the other can remains focused on the task and can assist in regaining focus afterwards 
Last but not least - handling interruptions are much easier as a pair than as an individual. It became so hard to concentrate in a modern office that any help is much appreciated.

Potential costs

The keyword is inconclusive. Even in pair programming that appeared years ago and now adapted by many dev groups - the costs are subjective and the evidence is empirical. Here's what they say:
While empirical studies have yet to yield definite results on either benefits or costs, a commonly cited best-case estimate of 15% overhead is claimed for systematic pairing, relative to individual work; this overhead, it is claimed (again with some empirical support, though not entirely conclusive), is compensated by gains in code quality which usually entails significant maintenance penalties down the road.

I don't know any product team yet that pair PMs for a substantial time. We can probably expect some costs of this approach, however, the quality of outcomes might overweight the costs greatly.

In summary

Pair programming concepts might well be applied to product managers. A pair of PMs might achieve better quality decisions, a wider spread of knowledge and it might make the overall product team better. To try Pair product management an organisation needs to have a collaborative space where PMs can work comfortably.

Like any agile work method, Pair product management could and should be experimented with.

Product management is a vital role in modern businesses, however, often it's a lonely role. Paired PMs could be not only more productive but also more satisfied with their work.

Popular posts from this blog

Fogg Behavior Model

Have you ever wondered why you do certain things? Why are some behaviors easy and joy to do while other not so? And your customers - have you ever struggled to understand their behavior? BJ Fogg , from Stanford University, has created simple and powerful behavioral model for persuasive product design.

Product Vision: an elevator pitch for your product

On this blog, I write a lot about making data-driven decisions . But what if you just starting to think about your product? You have a vague idea and nothing more. No point to go for prototyping or even talking to customers as you don't know yet who to talk to and what to talk about. In such situation - start from creating a product vision.

7 steps of Product Discovery

Before building a product - how do you know what product to build? While building a product - how do you know what features are the most valuable? After you've built a product - how do you know if to tune stuff or add a new one?