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.
Product management is confusing. Sometimes you need to use the voice of the customer as the source of truth, and sometimes you don’t. One day you’re striving for high-fidelity design perfection, the next day a hand-drawn sketch will do.
There’s no single PM recipe because generic answers ignore the context and complexity of the work. “It depends,” is the reasonable answer to almost any product management question but that gets tired pretty quickly when you need to make decisions.
“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.
Imposter syndrome has forced me to outsource my decision-making to a trusted process, or mental model, and not trust myself. Using an objective method to seeking answers, I’m able to move forward with confidence. Below are the models and inquiry-based approaches I use to cut through the fog of the daily ambiguity facing product leaders like me.
Let’s break down some of the most common activities of product management and see how these contradictions can be turned from confusion into frameworks for clearer decisions.
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?”
Where consensus can be important is in internal team discussions about adding new team members, shaping a process for work, changing reporting structures, or seeking outside help on projects or initiatives. Aligning on what the changes might mean for the current team roles and responsibilities is important.
“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.
The Pareto Principle is at work here too. A high percentage of decisions are inconsequential decisions. These are referred to as Type 2 decisions by Jeff Bezos. Type 2 decisions are reversible. In contrast, Type 1 decisions are impossible to reverse. I like to describe Type 1 decisions as driving off a cliff. If you don’t have a flying car, you ain’t coming back. The challenge is to know which are Type 1, and which are Type 2.
“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.
The nuance here is the scope of the experiment. A prototyping experiment doesn’t need to take weeks. It’s extremely rare that a high-fidelity prototype will give you significantly better data than a lo-fi mock-up. Regardless of the size of the organization, or the stage that you’re at, small experiments can generate the confidence you need to move forward. Just because you’re a billion-dollar business, doesn’t mean you need an expensive 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.
Be very careful not to show customers your solutions prior to identifying really important problems that they want to be solved. If you hold up a solution customers will say, “That’s great, you should make that.” You rush off to make the thing and a few months later return to proudly announce you’ve done what they asked. Unfortunately, when it comes time for the customer to actually pay for the solution, the customer will take you on an endless journey of integration, security, and procurement concerns. Someone liking your solution doesn’t confer product-market fit.
“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.
As Jeff Gothelf asks, “What do satisfied customers do in our product? The answers your team comes up with will be customer behaviors — outcomes.” The answers also tell you where to look for the right metrics.
In general, hearing what your customers and users think about your product is a good thing. Taken with a grain of salt, there’s always something useful in feedback. You have a better chance of delivering something of value than if you just ignore feedback. But, you also want to distinguish between feedback that describes a very real problem and feedback that is a subject opinion.
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.
Prioritizing discovery and learning will also be necessary when you’re exploring new territory with adjacent offerings or features that may not be core to the product. Even if you have an established product in the market, the map you’ll have will be missing new opportunities. No map is perfect and existing knowledge can actually be a blocker to learning. Remember, that the map is not the territory.
“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.
As mentioned, growth provides its own learning benefits. Even as you work through the discovery phase consider how you’ll grow into new insights. Expanding your beta releases to increasingly larger cohorts allows you to scale and learn simultaneously.
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.
Our minds are not designed to make objective choices. Biology is incentivized to get our genes into the next generation, by all means possible. That means we’re willing to lie to ourselves and create narratives that make us feel better. Product management is complex enough without adding in the misbehavior of our brains.
