25 Product Management Lessons

Some things I've learned along the way

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 NoonStart 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:

Discovery - Problem vs. Solution | Silicon Valley Product GroupDiscovery - Problem vs. Solution | Silicon Valley Product Group
To continue with the series on common misunderstandings about product discovery, in this article I’d like to discuss a very fundamental…svpg.com


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:

The Uncertainty Axiom of Product ManagementThe Uncertainty Axiom of Product Management
Regardless of your initial confidence in product ideas, most of them won't deliver the hypothesized value. Read why and what to do…Jens-Fabian Goetzmannwww.jefago.com


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:

5 steps to a hypothesis-driven design process5 steps to a hypothesis-driven design process
It’s important to slow down and take a moment to understand the questions and assumptions we have about our product.www.invisionapp.com


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:

PM 101: Working With Product DesignersPM 101: Working With Product Designers
Working well with designers is crucial for product managers, but not always straight forward. Here's how to improve the collaboration.Jens-Fabian Goetzmannwww.jefago.com


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:

The Four Big Risks | Silicon Valley Product GroupThe Four Big Risks | Silicon Valley Product Group
In the first edition of my book, INSPIRED, I discussed how successful products are valuable, usable and feasible, where I defined “feasible”…svpg.com


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:

Running a Data Driven Product OrganizationRunning a Data Driven Product Organization
Somewhere between launch and IPO, consumer tech companies become data juggernauts. These companies measure everything, turn those metrics…Drew Dillonmedium.com


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:

What it really means to ‘Bring the Donuts’What it really means to ‘Bring the Donuts’
It’s about having a servant’s heart.Anna Marie Cliftonmedium.com


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:

Missionaries vs. Mercenaries | Silicon Valley Product GroupMissionaries vs. Mercenaries | Silicon Valley Product Group
One of my all-time favorite quotes in our industry comes by way of the legendary VC, John Doerr, where he argues that “we need teams of…svpg.com


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:

The Case for Empowered Product TeamsThe Case for Empowered Product Teams
Why empowered, cross-functional product teams assigned customer problems to solve outperform feature teams that build features from a…Jens-Fabian Goetzmannwww.jefago.com


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:

  1. due to inevitable uncertainty, ROI calcs are arbitrary
  2. 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:

How Do You Create a Product Roadmap?How Do You Create a Product Roadmap?
Modern product roadmaps should not be a list of features and dates. How should you go about creating a roadmap in a lean, agile product…www.jefago.com


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:

TBM 46/53: Think Big, Work SmallTBM 46/53: Think Big, Work Small
Successful product teams figure out how to think big and work small. Doing both is an art. Some teams end up leaving their waterfalls for…John Cutlercutlefish.substack.com


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:

The Observer Effect – Marc AndreessenThe Observer Effect – Marc Andreessen
Marc Andreessen on how he spends his time, learns, the 'build' essay and much more.www.theobservereffect.org


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:

You Can't A/B Test Your Way to GreatnessYou Can't A/B Test Your Way to Greatness
A/B testing is a great tool to validate the impact of product changes—but it doesn't lead to great products. Read why.Jens-Fabian Goetzmannwww.jefago.com


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:

Diverse Teams Feel Less Comfortable — and That’s Why They Perform BetterDiverse Teams Feel Less Comfortable — and That’s Why They Perform Better
Homogenous groups aren’t as effective as they seem.hbr.org


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.

Share this post: