A smart product manager learns from their mistakes. A wise product manager learns from the mistakes of others. If you're reading this blog post, it's safe to assume you're a wise PM.
A lot of the playbooks that you studied tend to fall apart in the real world. And trust us, we've seen our fair share of torn and missing playbook pages. Today we'll help you update your playbooks with a quick overview of real world mistakes product managers (of any experience level!) can make.
Some of the mistakes we've seen new PMs make are:
- Disconnecting experiments from reality
- Narrowing their focus too far
- Ambitiously building lots of features
- Assuming they're the end-user
- Poorly defining the problem
Even if you're a battle-tested PM, consider this blog post a refresher on some common pitfalls. Or at the very least, a humbling walk down memory lane.
Disconnected Experiments
Experiments are crucial to testing assumptions. They help you minimize the number of question marks you have before you invest your resources into the development of any product. An overreliance on experiments, though, can be risky.
Product managers must be mindful of the fact that experiments are slightly disconnected from reality. Although the experiment you conducted might yield very promising results, you may have conducted it in a controlled environment with a small sample size.
Worse– you might discover that you made an error setting up the original test.
Of course, we know that experiments can get tricky when they're multivariate tests. When running an A/B test, take your time to play with each variable on their own.
Go the extra mile to have multiple approvers of your experiment before it goes live. You might even want to test your test to ensure that all the required steps are there.
When you receive test results that seem too good to be true, it's probably because they are. Be wary of anything that seems like a silver bullet. It's best to use experiments as a leading indicator– not an absolute source of truth.
Too Narrow of a Focus
You know the problem you're working on better than anybody. That's what happens when you're a passionate PM! As you become more of an expert, though, be wary of developing tunnel vision.
We've spoken to many product managers that have found themselves the victim of this tunnel vision. In fact, they often become the blockers themselves on their teams. This happens in every profession! So, you're not alone.
You might get used to doing things a certain way. Ironically, strict reliance on a set process can sometimes be an obstacle itself. Our PMs have told us that sometimes, for example, they become too comfortable just listening to customers without bringing the customer context to the rest of their team. Over time, they find that they've cornered themselves into one very narrow role rather than meeting the broader needs of their teams.
PMs are great at critiquing the work of others. But it's even more important that they carve out the time to critique their own thinking just as often. We know your time is in demand and you hardly find the time to breathe between all the meetings that somehow spawn on your calendar. Sometimes the most underrated skill in a PMs arsenal is saying “no.” Guard your time vehemently to reflect on strategy and think holistically.
Ambitiously building lots of features
“If you build for everyone, you build for no one.” It's hard to attribute this saying to someone, but we've all heard it at some point in our product management journey. It's admirable, of course, when a team wants to build anything and everything their customers might need. There's a fine line, though, between meeting all your customers' needs and boiling the ocean.
Early-stage startups are especially prone to trying to build too much. In an effort to “disrupt” the market, founders and PMs at startups leap at the opportunity to ship the shiniest new thing. A key takeaway we've seen product teams at early-stage companies learn is that when they rush to launch features they actually end up missing the root problem their customer really cares about.
Our advice? Slow down. The objective of a startup should be to take their time and validate ideas before pushing new features. Through thoughtful testing, you might even find that you're tackling the problem in the wrong way. And don't be afraid to pivot! Your learning compounds. Iterate on your learning from day one.
Assuming they're the end-user
What happens when “put yourself in the shoes of the customer” goes too far? You miss how the end-user will actually use your product.
As a PM, your empathy for the customer can misguide you sometimes. It can even lead you think that you are the customer you're building for. When this happens, you'll find yourself on a slippery slope of building things that you would enjoy– not features that are necessarily valuable (or wanted) by your customers.
This is where that reflection time we mentioned earlier comes in handy. After a full day of talking to customers, take a step back and read between the lines of what you've heard from them. Remember, our customers often don't have the right vocabulary to describe what they're experiencing or what they desire. You might be tempted to prescribe a solution here. Stop yourself from doing the thinking for them, though. Instead, take your assumptions to them to receive feedback.
Poorly defining the problem
As you gain more experience in your career, you'll realize that product management is sometimes the art of asking open-ended questions and following up on the answers you receive. Like journalism, great product managers use questions as a way to investigate further and arrive at the root problems.
This practice helps PMs to ensure they're defining problems accurately before arriving at a solution. It's easy to fall in love with a solution, but it's more productive to get married to a problem. Sometimes the best way to do this is to poke your head out of your product management tools and sit down with a customer. You may even want to work with your customers to build out a problem statement.
What are the outcomes they want? Why do they want those outcomes? Once you have these two questions answered, work with your product team to understand how you can best position your product to deliver these outcomes.
