25 Product Management Lessons
27 December 2020 ‧ 7 min read
I've been in product management and product leadership roles for half a decade now, and I've picked up a thing or two along the way. In this post, I am sharing 25 bite-sized lessons that I have learned over time—I hope they can help make you a better product manager, too.
1. Start with Why
A product manager should link the team's work to the vision—both the company vision and a vision for their specific product area. Shared purpose provides intrinsic motivation, so communicate “why” first rather than what or how.
More thoughts on why you should “Start With Why” in this short talk by Simon Sinek:
2. Start Together with the Team
Involve the whole team right from the beginning to build shared understanding, elicit ideas and concerns, and avoid nasty surprises. PM/UX might still drive discovery, but the first steps should be taken together.
John Cutler has written a lot about starting together, for example this article:
Start Together. Finish Together | Hacker Noon
hackernoon.com
3. Understand the Problem You're Solving
Often we latch on to feature ideas without knowing what problem they'd solve. Instead, fully figure out & document the problem. You can start with problem or solution, but must understand both before moving on.
While I've written before about documenting the problem before the solution, I've since softened my stance on this somewhat, especially after reading the below insightful article by Marty Cagan:
4. Get to Know the (Real) Customer
You can never spend too much time with your customers. Don't believe that since you are similar to your target audience, you can stand in for them. You know your product inside out, they don't. So get out of the building.
Get out of the Building is—in case you weren't aware—one of the catchphrases from Steve Blank's “Customer Development” methodology, and here's a short primer what it's all about:
5. Be Ready to Be Proven Wrong
Painful truth: most product improvement ideas fail—even the ones you were most confident of. You won't even know which ones fail until spending lots of time on them. So be ready to be convinced of the opposite you believe.
I call this the Uncertainty Axiom of Product Development, and you can read more here:
6. Have Hypotheses for Your Work
Because most ideas will fail, ensure you have hypotheses about your user's behavior to try and validate (not just “this idea will work“ / “will improve engagement”). That way, you'll learn something even if the idea fails.
Some thoughts on hypothesis driven design and development in this article by Sylvia Lai:
7. Make the Designer Your Ally
Although the whole team should be involved, PM & UX are the key players in product discovery, so it's crucial to make the designer your strongest ally in developing shared deep understanding of the customer & problem.
I've shared more in-depth thoughts on working with product designers in this article:
8. Understand Complexity Drivers
I don't think all product managers must be technical—deep customer & business understanding is more critical. However, PMs must understand what drives technical complexity. Partner with engineers to let them teach you.
9. Be the Voice of the Business
PM is often shown as the overlap of UX, technology, and business—but on the product team, you have designers as UX experts and engineers as tech experts. Therefore, PMs have to represent the business perspective.
It's worth clarifying here that “the business” means “what drives the economic engine of our company”, not “stakeholders in the rest of the organization that we call the business”. In product led companies, the product is the business. Another way to think about this is to think of the risks inherent to product development. Marty Cagan enumerates the risks of value (does it solve the problem?), usability (can it be used?), technical feasibility (can we build it?), and business viability (can we make money from it?), and makes the product manager responsible for value and business viability:
10. Bring the Data
Due to the uncertainty of product work, you have to measure. As PM, ensure you are an expert at the meaning of the data (even in case you have a dedicated analyst), and then teach the rest of the team. Back your decisions with data.
For the nuts and bolts of becoming data driven / data informed, I recommend this piece by Drew Dillon:
11. Bring the Donuts
Product managers are leaders without authority. You can't just tell people what to do, you have to earn their trust. The best way of doing that is going the extra mile to ensure your team is happy—by bringing the proverbial donuts.
How that can look in practice? Here's one example by my former coworker Anna Marie Clifton:
12. Build a Team of Missionaries
As individual product manager, you often can't choose your team—but you can still make it a “real” team with shared vision and purpose. Do that by understanding what drives each team member and distilling a common purpose.
The concept of missionaries and mercenaries was coined by legendary VC John Doerr, who classified entrepreneurs into these categories, and then applied to product teams by Marty Cagan:
13. Protect the Team
Even in empowered product teams, product managers should ensure their teams aren't ground to dust between organizational disagreements and tensions. Act as a buffer between those complexities and the team so they can produce results.
This take might be somewhat controversial because it sounds disempowering, therefore make sure to follow the next lesson…
14. Don't Overprotect the Team
Complementing the previous lesson: Don't overprotect the team. Don't shield them from all organizational complexities & disagreements and bring only cut and dry solutions. That disempowers the team and will burn you out.
Here's more on why you should make sure that your team is empowered in the first place:
15. Do Fewer Things Better
A great product isn't one that does a lot of things in a mediocre way. A great product focuses on a few things and really nails them. So don't move on once you've found something that works—double down and make it great.
In the fable of the fox and the hedgehog, the fox knows many things and the hedgehog knows one big thing (namely, how to curl up into a ball)—and the hedgehog always wins against the fox. In the research for his seminal book “Good to Great” on building long-lasting, great companies, Jim Collins found that great companies tend to be like hedgehogs—they focus on one simple concept at the intersection of what they can be the best in the world at, what they are passionate about, and what drives their economic engine. Read more about the concept here (or of course, just read the whole book):
Jim Collins - Concepts - The Hedgehog Concept
www.jimcollins.com
16. Make strategy the priority (prioritize correctly)
In many companies, product prioritization happens by some measure of ROI. Two problems with that:
- due to inevitable uncertainty, ROI calcs are arbitrary
- max ROI is not a strategy—so prioritize by strategic fit instead.
To read more about how to turn a strategy into a roadmap, read my article on roadmaps:
17. Think Big, Work Small
Successful product teams need to both follow a long term vision and work iteratively to get there. Without vision, you run in circles or make marginal changes. Without iteration, you risk following ideas that fail.
To read more about this idea, I recommend the following post by John Cutler:
18. Don't Throw Stuff at the Wall to See What Sticks
Even if most ideas fail, you can make sure that you test only the ones that have the most potential. Before you test an idea, ensure to collect all the inputs to make the best possible decision.
Focusing on inputs (instead of attempting to validate outcomes) is the more important the longer term your bet is. The following perspective from Marc Andreessen on venture capital, the ultimate long-term innovation bet, is enlightening in that respect:
19. The Proof Is in the Pudding
Even when validating all ideas (since most of them will fail), you can still validate incorrectly. The only real validation is your users behaving measurably different. The strongest validation is customers paying.
20. You Can't A/B Test Your Way to Greatness
Some people believe that A/B testing is the be-all / end-all of product validation. In reality, A/B testing works well only to test incremental optimization. Radical innovation requires qualitative validation.
More on this topic in my eponymous article:
21. Differentiate Between MVP and v1
An MVP is a means to test the currently riskiest assumption. You should de-risk assumptions through several prototypes before shipping v1. A v1, then, should be de-risked and not an MVP (and also be delightful to use).
22. Invest in that v2
Many product managers ship a v1 of a feature, are happy that it works (/ moves metrics), and then move on to the next thing. That leaves a complex product with many half-baked features. So do iterate after v1 and ship a v2.
23. Make Time for Learning
The “lean startup” loop is build–measure—learn, so make sure you actually learn (more than just “well that didn't work”). And document/share learnings—otherwise in a year from now people will have repeat all your mistakes again.
24. Embrace Diversity, Debate, and Discomfort
Teams create the best outcomes through vigorous debates of differing viewpoints and then decide on a common course of action. Differing viewpoints requires diverse team members and can feel discomfortable.
You can find more on this topic and how diversity and discomfort are related in this awesome article by David Rock, Heidi Grant, and Jacqui Grey:
25. Hustle, But Do It With Direction
Product management sometimes feels like an endless hustle—doing whatever it takes to move team & product forward. Great product managers do hustle a lot—but they also make sure to never lose sight of vision and purpose.
I hope you found this article interesting. If you did, feel free to follow me on Twitter where I shared this list originally.