Who is better at Product Management — MacGyver or Scully-Mulder?

In season 1 of X-files — “Squeeze”

MULDER: What did we learn in our first day at the academy, Scully? Each fingerprint is unique, these are a perfect match.

SCULLY: Are you suggesting that I go before the Violent Crime Section and present a profile declaring that these murders were done by aliens?

MULDER: No, of course not, I find no evidence of alien involvement.

SCULLY: Well, what then? That, that this is the work of a hundred year old serial killer who is capable of overpowering a healthy six foot two businessman.

MULDER: And he should stick out in a crowd with ten inch fingers.

SCULLY: Look, bottom line, this is Colton’s case.

MULDER: Our X-file dates back to 1903, we had it first.

On the other hand, MacGyver (as wikipedia describes) has an extraordinary knack for unconventional problem solving and an extensive bank of scientific knowledge that he believes can best be put to use saving lives

Upon watching X-files and MacGyver, suddenly a question arose within me — what is a better approach to solving problem — MacGyver or the pair (Scully and Mulder ) in X-files? In the context of a product organisation — is it Product Manager or ‘Product Managers’? I wondered if Pair Programming is an acceptable concept, why not Pair Product Management!

The emergence of a T-Shaped Product Manager

Brian Balfour wrote a great post on the skills required for a growth product manager. He outlined the kind of skills that a product manager requires, which goes broad and deep. Since its not possible for one to go deep in all areas, based on the interest of an individual or what a product demands, the product manager deepens his expertise in that area.

One product manager might be a data wizard, whereas another one might be a detail junkie and a design aficionado. Have a look at the above image once more — somewhere it feels like in todays day and age, we are looking for a super man/woman in the role of a product manager expecting him/her to be jack of all and a master of one (or two).

Concerns with this approach:

• Too many skills demanded from just one person
• Not all areas will be of interest to one person.
• T-shaped may be over-rated.

Experimentation with Pair Product Management

The concept of pair product management may be controversial. My endeavour is to kick start a discussion of how pair product management works through this post.

Inspired by the concept of pair programming where engineers are trying to solve the problem together, can the same concept be extrapolated to product management?

Extrapolation of benefits of Pair Programming to product management

Pair Programming Benefit 1: Increased code quality:”programming out loud” leads to clearer articulation of the complexities and hidden details in coding tasks, reducing the risk of error

Product Management Benefit 1:Increased product quality: “Discussing the problem loud” leads to clearer articulation of the complexities, holistic thinking and better attention to details reducing the risk of bad decisions.

Pair Programming Benefit 2: Fusion of knowledge: 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

Product Management Benefit 2: Leveraging complementary skills: better leverage of knowledge among the pair so that each of them play to their strengths.

Pair Programming Benefit 3: Better transfer of skills: better transfer of skills, as junior developers pick up micro-techniques or broader skills from more experienced team members

Product Management Benefit 3: Better transfer of skills: pairing with a seasoned product manager can help junior product managers pick up better product sense.

Pair Programming Benefit 4: Better resilience: 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

Product Management Benefit 4: Better resilience: As a PM there will be constant meeting with stakeholders and sometimes work may or may not progress. Having 2 persons may bring better resilience and hence a continued focus on problem at hand.

My biggest hypothesis is that businesses today struggle on the getting the right product out. Hence they spend a considerable time iterating faster and faster to get the solution right. Perhaps 2 minds at one can increase the probability of success and reduce the iteration required?

Concerns to be addressed:

• Concerns of cost: While it may look like double the cost, studies have estimated 15% of overhead costs in the case of pair programming which could be typically compensated with increase in code quality. In product management, hopefully the impact on the business can compensate this cost. Impact on business in this context mean better product/feature discovery leading to business favorable outcomes ‘faster’ than the existing approach.
• Active engagement: If there is a lack of active engagement then this arrangement may not work
• Complimentary skills is a must: Having similar skill sets may do more damage than good.
• Time: there is a possibility that the time to take decision may increase but I am assuming that this may alleviated over the long run if the probability of success is increased.

Rules for pairing

One of the interesting events in my career happened when I had the chance to meet Scott Cook, founder of Intuit. He was conducting a product management workshop and the room was filled with PMs from the likes of Google, Amazon and top Internet companies. He gave us a problem statement for a product and asked us to describe the value proposition. At the end while we were discussing the solution, it was amazing to see how diverse the answers were. Not all of us perceive the problems the same way. Even if we do, we dont think of the solutions in the same way!

In one of my all time favourite book, Wisdom of Crowds, James talks about the power of individuals coming together to solve the problem. Its astonishing how the crowd can not only solve problems but also predict. Taking cues from another seminal work The Difference, we can learn the theorem of how diversity trumps ability. However, the theorem works only in certain conditions where a random collection of problem solvers outperform any best individual problem solver. So the rule for pairing the product managers should be based on

a) Product PMs fit: I earlier wrote a post around how to evaluate Product PM fit. Its imperative that the fit should be based on the strength of the product managers.

b) The more diverse the better: The more the diversity in the pair, better the chances of problem solving. Abstract vs details, analytical thinker vs collaborator, strategic vs execution and so on.

The Beginning

Many a companies struggle with repeat success in product management. They mostly have a core product (in some cases core products) which keeps them alive. Lean methodology reduces the cost of failure and doesn't increase the probability of success. In the current era of hyper-competition, the answer may not lie with searching the next MacGyver, perhaps its Scully & Mulder that we need!

I will be happy to hear your feedback on this. Feel free to comment here or tag me on twitter @viveckpkumar or mail me at viveckpkumar@gmail.com