The Product Management Triad

What roles belong among the famous leadership “triad” of PM/Engineer/Designer? That question came up for me recently, and it was also…

What roles belong among the famous leadership “triad” of PM/Engineer/Designer? That question came up for me recently, and it was also tackled in a thread over on Twitter by Peter Merholz: https://lnkd.in/dXQta6NH

I’ll tell you my answer: I’m not sure. Let’s discuss.

In a previous role, I was on a product team that was outstanding, but I’d have to admit that we could have been stronger on data. We had no dedicated data people on our team, and we had limited access to the data gathered by the centralized data function in our company.

On that team, I think user research often stood in for data. We calibrated most product decisions with a very deep connection to our customers, and by most accounts this worked pretty well for us.

Since then I have used research in a much different role to inform product decisions than data. For example, on that team I think we could have been much better at measuring impact, using quantifiable criteria to prioritize projects, personalizing the experience using first-party data, and assessing the financial impact of our choices.

Thinking about data science as the fourth leg of our Product table might have really improved our outcomes. If I back-test the idea, I can think of some specific problems where a more disciplined data-driven approach might have changed our attitudes.

Lumping data strategy in with PM or Engineering is tempting, if we don’t expect much more than reports. But there have been so many advances in this area, I think it’s worth revisiting. If we elevate the role on our teams, could it help us make better decisions?

Having the right data partner can make a huge difference. I like to say that it’s hard to make a bad product decision based on a good user interview, but bad decisions are made based on good data all the time. Here’s an aphorism about that:

“Everyone who confuses correlation with causation, eventually ends up dead.”

You’ll be thinking about that one all week.

The point is this: It’s easy to look at a sea of data and see things that aren’t really there. It’s also easy to decide to do things with data because you have it, instead of using it to solve a user problem.

I try to approach to every product discussion with a customer focus, isolating a particular need or problem to solve. I try to watch out for the assumption that we should do some particular kind of thing because it uses a tool in our belt.

I think that a big part of the design and engineering leaders’ roles on a product team is to ensure that their disciplines are utilized appropriately in the approach to customer problems. Making sure that data leaders are similarly situated could help with this as well.

I’m eager to hear how the product leadership “triad” (or whatever!) is constructed in your company, and how other roles like data are represented. Let me know!