Behind every successful product is a product manager. But exactly what is a product manager and what do they do?
A common response is that a product manager is someone who does product management. Take it a step further and one might say that product management is managing a product. But that’s simply not it.
Reducing the role to an autological phrase undermines the intricacies involved. At the core of product management is solving customer problems. And when you think about it, it’s not only the customer’s problems that you’re solving.
PMs have to consider not only who’s using the product, but also who’s investing in it? Researching it? Designing it? Building it? Testing it? Releasing it? Selling it? Promoting it? Measuring it? Supporting it?
That was exhausting to type and we didn’t even begin to talk about prioritization, communication, alignment, process, and methodologies — I’ll save those for another article 😉.
Now I’m not here to define what a product manager is. As you can see, there are multiple elements at play that make it incredibly difficult to do so. Rather, I would like to share the 5 most important resources that helped me on my journey as a PM and maybe it can help you, too.
Disclaimer: I am not affiliated with any of the recommended resources and don’t earn any commission for doing so. This is 100% for the sake of disseminating knowledge.
The 5 resources are:
- [Essay] Good Product Manager/Bad Product Manager
- [Blog] 6 diagrams I use to explain Product Management concepts
- [Wikipedia] Behavior-driven Development
- [Book] How to Win Friends & Influence People
- [Youtube] 20 years of product management in 25 minutes
Please feel free to use them in any way you find helpful.
This is a classic essay written by legendary businessman and investor Ben Horowitz. As the title declares, this is an article that juxtaposes good PM vs bad PM. I originally came across this while reading his book ‘The Hard Thing About Hard Things’.
In the essay, Horowitz is not shy about voicing his opinion on product management — he takes a stance and argues his point boldly. Although it is now more than 20 years old, there are many gems found inside. If you haven’t read this, then I would recommend doing so and if you have read this already, I would recommend you revisit it.
A good product manager is the CEO of the product.
This is a recent blog published on Medium by Curtis Stanier at the turn of the decade and has really great diagrams that are used to explain PM concepts. I frequently cite his diagrams when explaining ideas to my team and find myself revisiting them when I need a quick dose of inspiration. For those who would prefer something more visual, this is an article that you can’t miss.
My favorite is “Product Manager Bottleneck”.
One of the most common mistakes I see Product Managers make is feeling the need to be a part of every discussion. I understand there is a positive intention behind it — you’re the PM and you need to be across everything in case you’re asked about it.
Unfortunately, this has many drawbacks. First, it’s not practical. You will rapidly become overwhelmed — negatively impacting not only the effectiveness of your team but also your own well-being. Trust me, I’ve done it. Second, you undermine the autonomy of your team.
Great Product Managers know when to be involved and when to step back. They know when to let conversations happen without them. The purpose of an autonomous team is to remove as many dependencies as possible.
This is actually a Wikipedia article inspired by Dan North. While it’s quite verbose, my go-to page is the Behavioral specifications section, which I use as the standard for writing user stories in JIRA.
An explicit title.Narrative
A short introductory section with the following structure:- As a: the person or role who will benefit from the feature;
- I want: the feature;
- so that: the benefit or value of the feature.Acceptance criteria
A description of each specific scenario of the narrative with the following structure:- Given: the initial context at the beginning of the scenario, in one or more clauses;
- when: the event that triggers the scenario;
- then: the expected outcome, in one or more clauses.
Formatting my tickets in this way has improved communication and collaboration with business and tech tremendously. This style of writing specifications is known as a ubiquitous language — or a common way to speak about software with developers and nontech people.
Personally speaking, this has made my life much easier as it shifted my energy from writing about how something should be done and instead focus on clearly explaining what should be done.
People think in stories and BDD is one way to tell it.
4) How to Win Friends & Influence People (1936)
If you don’t know about this quintessential self-help book by Dale Carnegie, you are missing out. This is a piece of writing that all PMs should read. Even if you’re not a PM, you should read this book. There are tons of lessons in here infused with anecdotes, idioms, and history that teaches you how to better deal with people.
And as a PM, you’re constantly dealing with people.
I particularly find part 4 to be relevant for product managers and leadership roles in general. Want a sneak peek? Take a look at the chapter names below:
Part 4 — Nine Ways To Change People Without Giving Offense Or Arousing Resentment
1) If You Must Find Fault, This Is the Way to Begin
2) How to Criticize — and Not Be Hated for It
3) Talk About Your Own Mistakes First
4) No One Likes to Take Orders
5) Let the Other Man Save His Face
6) How to Spur Men on to Success
7) Give the Dog a Good Name
8) Make the Fault Seem Easy to Correct
9) Making People Glad to Do What You Want
Does reading this list strike a chord? Good. That’s what it’s meant to do.
5) 20 years of product management in 25 minutes (2017)
Watch this. You won’t regret it.
Please watch this youtube video about product management by Dave Wascha. In it, Wascha talks about mistakes he made along the way and how he became a better PM because of it. But more importantly, he centers the talk around the advice he would give to his younger self after two decades of experience.
I summed up a few of his advice in the following list:
- Listen to your customer
- Don’t listen to your customer
- Watch the competition
- Don’t watch the competition
- Get Paid
- Stop worrying about getting paid
Quite paradoxical, isn’t it? Below is a short explanation of what they mean.
Listen to your customers to understand their problems. Don’t listen to your customers when it comes to building solutions.
Watch the competition because they’re a rich source of information that can help you better understand your customers’ problems. Don’t watch the competition because doing what they’re doing might not actually help.
Get paid or to put it in another way, are customers willing to pay for what you’re creating? Stop worrying about getting paid means that too much business influence can suck the soul out of products.
Wascha shares a story of buying beef jerky from a company in San Francisco that puts dental floss in each bag. He goes on to say —
“Did they have to put it in there? No, they didn’t. Does it increase their cost? Yes, it does. Do you think they can justify or even measure the ROI in terms of increase sales for doing that? No, they can’t. But it made me smile. And if you can make somebody smile, you have the foundation for a lifetime of loyalty.”
All PMs are not created equally
Product management is a mindset. Product management is a journey. Product management is people, product, and profit. You will face challenges and obstacles along the way, but don’t give up! Always remember who you’re doing it for, i.e., your customers.
I hope that you found the information within this article to be helpful.
Thanks for reading.
If you made it this far, here’s a bonus resource — a book called ‘Scrum’ by Jeff Sutherland, one of the original authors of the Agile Manifesto. This inspired me to teach my team about the Agile methodology using paper airplanes, which I wrote about here.