Counteracting The Counterintuitive Nature of Product Management

Product management appears to be full of contradictions and conundrums, but it’s not as messy as it seems.

“there’s a person in my life I just do not trust. Even though I spend a lot of time with this person, I just do not trust them. Like, it’s embarrassing to say, but I don’t trust their motives, I don’t trust them to follow through on anything. And that person is me.” — Sendhil Mullainathan

Sendhil makes me feel seen. In spite of decades of experience, multiple books, and daily conversations with the world’s top product people, I have crippling doubt about my own abilities as a product leader. I’m sure I’m not alone.

Decision-Making

Every PM will have moments where they are required to make on-the-spot unilateral decisions and other moments when consensus is more important than speed. Knowing when to collaborate on decisions, and when to move forward without discussion might be the single hardest part of the job.

“When should I seek consensus?”

As social animals, it’s natural to seek social proof from others on how to behave. Counterintuitively, a consensus is almost never the best outcome. Understanding different perspectives, hearing everyone’s concerns, and discussing the research or findings is more useful than pushing for universal agreement. It’s okay to have differing opinions and still find a path forward. I’ve learned from my friend Nate Walkingshaw that using the customer’s perspective can be a good way to break the tie. “What would the customer experience and how would that impact them?”

“When is a quick decision better than a consensus-driven decision?”

Almost always. Most decisions don’t need discussion, but they do need consensus about how those quick decisions get made. Having a decision stack or a mental model to make decisions is the real work. Spend time figuring out how your team will make decisions when others aren’t around or are too busy to be interrupted.

“Type 1 decisions are not reversible, and you have to be very careful making them. Type 2 decisions are like walking through a door — if you don’t like the decision, you can always go back.” Jeff Bezos

The speed and accuracy of decision-making are a product of the confidence your team will have in how decisions are made. Knowing how to contextualize decisions gives teams confidence. By giving teams a decision-making framework, the Type 2 decisions can be made without much discussion. That leaves precious time to discuss important Type 1 decisions.

Experimentation

I’m a big fan of experimentation. I even wrote a book about doing experiments. Then I wrote another one about doing experiments in enterprises. But I also don’t believe experiments are an elixir for all problems. Running a full design sprint or a research spike every time you need to find an answer to a question is a waste of everyone’s time.

“So when should I run experiments?”

Only when you have a high-risk problem that needs to be solved to move forward. If a gnarly question is blocking progress, and it can’t be answered by existing data or observing a competitor, you’ll need to build a prototype or design a mock-up and get in front of customers as quickly as possible.

“Okay, so when should you avoid experiments?”

When you want to test a small change. An entire experiment is not necessary to test an idea. Tests are not experiments. Tests are a part of an experiment. By creating a prototype you might be testing several things. The design, the flow, the value proposition. To test the effectiveness of a button color change, you don’t need to run an experiment.

Voice of the Customer

Ensuring we make space for what customers think is a battle that product creators have been fighting for a very long time. But, in our enthusiasm, I think we might have gone too far. Too many companies are allowing customer feedback to drive their roadmaps. Don’t get me wrong, customer-centric products are better than products that ignore the customer’s needs entirely. The challenge is to balance the needs of the customer, with the needs of the business.

“When should I listen to customers?”

Customers and users (there’s a difference and you should know what it is) are good at describing their problems and preferences., but they are awful at describing the solution to these problems. Engage customers when you’re framing the problem to be solved or seeking new opportunities to exploit. Asking customers for feedback just so you can generate new features results in the Red Queen Effect, and can lead to lots of activity that doesn’t move you significantly forward.

“When can I ignore customers?”

If you can derive high confidence in your decisions through data analysis, you can skip the VoC interviews. If you build everything your customers ask for, you’ll be perpetually reacting to singular perspectives instead of building a product that is broadly valuable to a big market. The challenge is having the right data and the right measures of the data to guide your thinking. If you’re asking the wrong questions of your data, you’ll get the wrong answers. Understanding your customer’s behavior in the product points to the nature of your questions.

Discovery and Learning

In many ways, a product organization is a learning organization. Teams work best when they can learn quickly and apply that new insight to the next round of work. Learning is necessary, but sooner or later the product needs to ship. Too much time spent on learning can slow down the opportunities to take market share or deliver value to the customer base. In another counterintuitive twist, growth brings its own learning opportunity.

“When should discovery and learning be prioritized above growth?”

Early in the product or feature lifecycle, you’ll have more questions than answers. Learning quickly is the priority when there’s lots of ambiguity. Growing on the other hand can create second and third-order consequences that you can’t possibly foresee.

“When should growth be prioritized over discovery?”

Growth matters when you have product-market fit and you have a clear GTM strategy that can be executed at scale. Growing doesn’t mean you aren’t learning, but it does mean the majority of your time spent on squashing bugs, creating a consistent UX/CX, and working closely with your sales and CS partners to deliver a product that is consistent with expectations.

Overcoming Your Own Imposter Syndrome

Whether you’re seeking a better way to make decisions or escaping the build trap, mental models are super useful in overcoming the reality that life is complex. Instead of trusting yourself, overcome your natural biases and doubts by outsourcing your decisions.

Dad, husband, cyclist, product and design transformation leader. I write books on design & product.