No matter how well-intentioned you are, enacting change within your first 30 days could jeopardize your trust and standing. So if you feel any of those reasons eating at you, please pause. Spend these first 30 days sitting in on team meetings and talking to everybody on the team.
— Lara Hogan, How to spend your first 30 days in a new senior-level role
I recently finished Nest creator Tony Fadell’s book Build: An Unorthodox Guide to Making Things Worth Making (I highly recommend it). I wanted to spend a few moments reflecting on the chapter on product management because it is just so good. I haven’t read something that made me feel this inspired about the importance of what we do in a long time.
First, it’s always fascinating to me how different people define this undefinable role. Here’s what he says:
A product manager’s responsibility is to figure out what the product should do and then create the spec (the description of how it will work) as well as the messaging (the facts you want customers to understand). Then they work with almost every part of the business (engineering, design, customer support, finance, sales, marketing, etc.) to get the product spec’d, built, and brought to market. They ensure that it stays true to its original intent and doesn’t get watered down along the way. But, most importantly, product managers are the voice of the customer. They keep every team in check to make sure they don’t lose sight of the ultimate goal—happy, satisfied customers.
One definition is never enough, though. Every product management book has a few “oh, but also…” sections, and this one is no different:
Product managers look for places where the customer is unhappy. They unravel issues as they go, discovering the root of the problem and working with the team to solve it. They do whatever is necessary to move projects forward—that could be taking notes in meetings or triaging bugs or summarizing customer feedback or organizing team docs or sitting down with designers and sketching something out or meeting with engineering and digging into the code. It’s different for every product.
It’s interesting to read his perspective on product management vs. product marketing (especially since I am also currently reading Martina Lauchengco’s SVPG book Loved: How to Rethink Marketing for Tech Products, which has a decidedly different view on this role):
Most tech companies break out product management and product marketing into two separate roles: Product management defines the product and gets it built. Product marketing writes the messaging—the facts you want to communicate to customers—and gets the product sold. But from my experience that’s a grievous mistake. Those are, and should always be, one job. There should be no separation between what the product will be and how it will be explained—the story has to be utterly cohesive from the beginning.
But my favorite parts of the chapter are the ones that made me feel. There is so much content out there about just how hard the job of product management is, and so little about what an exciting and special role it is. Tony gets to the heart of what makes this work worth doing:
Sometimes they’ll have the final opinion, sometimes they’ll have to say “no,” sometimes they’ll have to direct from the front. But that should be rare. Mostly they empower the team. They help everyone understand the context of what the customer needs, then work together to make the right choices. If a product manager is making all the decisions, then they are not a good product manager.
And:
So the product manager has to be a master negotiator and communicator. They have to influence people without managing them. They have to ask questions and listen and use their superpower—empathy for the customer, empathy for the team—to build bridges and mend road maps. They have to escalate if someone needs to play bad cop, but know they can’t play that card too often. They have to know what to fight for and which battles should be saved for another day. They have to pop up in meetings all over the company where teams are representing their own interests—their schedules, their needs, their issues—and stand alone, advocating for the customer.
He’s right about how difficult the role is to hire for, though:
This person is a needle in a haystack. An almost impossible combination of structured thinker and visionary leader, with incredible passion but also firm follow-through, who’s a vibrant people person but fascinated by technology, an incredible communicator who can work with engineering and think through marketing and not forget the business model, the economics, profitability, PR. They have to be pushy but with a smile, to know when to hold fast and when to let one slide. They’re incredibly rare. Incredibly precious. And they can and will help your business go exactly where it needs to go.
Yes, I know—I just quoted someone who called us “precious,” which is a little obnoxious. But I spend enough time hand-wringing about how we shouldn’t consider ourselves so special (see, for example, The dangerous rise of “crazy-busy” product managers) that I’m going to give myself a freebie here.
Anyway, you should read the book. I have some issues with the parts that lean heavily into hustle culture, but if you ignore those bits it is really fantastic. The ending made me tear up a little bit…
In the end, there are two things that matter: products and people. What you build and who you build it with. The things you make—the ideas you chase and the ideas that chase you—will ultimately define your career. And the people you chase them with may define your life.
In The Importance Of A Clear Career Path For Product Managers the Intercom team links to their Product Manager expectations by level (PDF). It’s a really good resource and fascinating look at their approach to product management. Here’s how they define the role at Intercom:
There are many elements and facets to being a PM at Intercom, but ultimately it comes down to: “Identify the most valuable problems to solve, enable your team to ship and iterate high-quality solutions quickly, and validate market impact.” Underpinning this, there are 5 Skill Areas that we explicitly set expectations for and judge performance against. These are
- Insight Driven
- Strategy
- Execution
- Driving Outcomes
- Leadership Behaviors
The document goes into the expectations for each of those skill areas, at each level.
One of the issues that’s often lamented about the product management profession is that it is not well understood. I think one of the big reasons for that is that we try to put too many different jobs in the same category. I have come around to the viewpoint that product manager roles should be classified in terms of the type of goals they are trying to accomplish. I like Saeed Khan’s breakdown in 5 Steps to Building a Great Product Management Organization:
Roles in Product Management should differentiate between technical and business focus; between short term tactical and longer term strategic activities; between internal (inbound) and external (outbound) responsibilities. These roles should be organized as small teams focused on specific products or product lines, with defined metrics to measure progress and success.
This is what is done with virtually every other department in a company. Why should it be different for Product Management?
Another way to look at it comes from Jonathan Golden. He talks about Pioneers (focused on taking risks and building new things), Settlers (focused on growth and scaling), and Town Planners (focused on infrastructure and platform management), and then makes this point:
Even in an established company, all three types of product managers are critical. “The product team needs each of these PMs to be nimble and responsive. Otherwise the business won’t endure for the long term,” says Golden. “We allocate product resources across three main categories: core initiatives that focus on the existing product, new initiatives that explore possible areas of growth for the business, and platform initiatives that focus on building fundamental technological infrastructure.” Pioneers and settlers don’t become obsolete just because you’re at scale.
I think this type of thinking wil help a lot with the misunderstandings and misconceptions that exist in the product management landscape.
Lenny Rachitsky wrote a helpful and comprehensive guide on How To Get Into Product Management (And Thrive). This is a really good resource for any new product manager. I especially liked his section on seven core skills, and how to get better at each of them. One could certainly argue the validity and importance of each skill, but there are lots of good insights here. For example, on “Leadership through influence”:
In order to succeed you need to be able to build trust with your teammates, make decisions but also give everyone a voice, and keep morale up no matter what’s going on. The best PMs quickly become the de-facto leaders of the team, not because of any actual authority, but because they help everyone on the team do the best work of their lives.
The first article I published on Elezea was called The dangers of “test and learn”. It was about A/B testing, it was badly written, and it went live on August 3rd, 2009. Since then I’ve posted 1,282 links and articles on this site (that’s an average of 2-3 posts per week).
It’s ridiculous to think that Elezea is coming up on being 10 years old. It is not an exaggeration to say that it sparked most of my career development and helped me meet countless people who I now consider friends. Starting this site was one of the best decisions I ever made. I wish I could go back in time and choose a less impossible-to-remember URL, but such is life.
So what do I do now, after all this time? On reflection I realized all I really want to do is keep writing. I took a couple of breaks over the years, but for the most part, this has been one of the few constants in my life. And I’d like to keep that going in a sustainable way.
So today I’m announcing two things to help set this in motion.
For the past few years, the Elezea Newsletter has been simply a list of the articles that went on the site that week. That’s useful as a Twitter/RSS replacement, but not much else. Since my interests extend beyond the product management world into the broader impact of technology on our work and our lives, I am relaunching the Newsletter this Friday to include a wider variety of topics:
If that sounds interesting to you, please sign up!
On the “sustainability” side of things, I decided to launch memberships to help cover the ongoing costs of running a site (and newsletter) like this. I have no ambitions for this to become my main job — I like my job! But I would very much like for the site to at least pay for itself in terms of domain, hosting, and subscription costs.
So if you’ve been reading Elezea for a while and have found it valuable, please consider becoming a member. It costs $4/month, and will help keep Elezea independent and free from advertising.
Whether you’ve been with me from the start, or if this is the second post you’ve ever read, I want to say thank you, thank you, thank you. Elezea is a small part of the internet, but it’s a big part of my life. And it’s your encouragement and support over the years that make it so.
Here’s to the next decade 🤘
(Now go become a member!)
Training company Onfielder published a comprehensive list of learning resources for new product managers called PM Starter Pack. Topics include what the role is about, overviews of the skills required (such as strategy, user experience, and analytics), and how to apply a job hunting strategy. Each section provides an overview of the topic as well as links to external resources. Highly recommended for new product managers.
Marty Cagan posted another great installment in his series on how to be a good manager of product managers. In Coaching Tools — The Plan he describes the different ways he would encourage product managers to skill up in areas where they need to grow.
It’s hard to pick just one quote to post because the whole article is excellent, but these paragraphs on collaboration particularly stood out for me:
Modern product management is all about true collaboration between product, design and engineering. This begins with ensuring the product manager is knowledgeable about the real contribution of product design and engineering.
The PM does not need to be personally skilled in either design or engineering (most aren’t – although many PM’s think they’re great designers) but they do need to understand and appreciate their contributions to the point where they understand that what each of design and engineering brings to the table is just as essential as what the PM brings.
Shaun Clowes shares some really good hiring advice in his post Picking good Product Managers - insightful interview questions. He starts it off with a good reminder that “bad product is worse than no product”:
A product manager without a systematic approach to their discipline has less context than the team members so is less likely to make good decisions naturally. Thus a bad product manager is more likely to cause the team to make mistakes than no product manager at all.
The worst part is that many experienced product managers will be convincing since they’re used to influencing organizations. No matter how convincing the vision a product manager might paint, they need to be able to justify it within the competitive environment, the strengths of the organization, the data that proves the market exists etc.
Marcus Buckingham and Ashley Goodall discuss some fascinating research about how people learn in their essay The Feedback Fallacy:
What findings such as these show us is, first, that learning happens when we see how we might do something better by adding some new nuance or expansion to our own understanding. Learning rests on our grasp of what we’re doing well, not on what we’re doing poorly, and certainly not on someone else’s sense of what we’re doing poorly. And second, that we learn most when someone else pays attention to what’s working within us and asks us to cultivate it intelligently.
As a parent it’s natural to see the elements of “positive parenting” in this research. We (generally) don’t have to deal with tantrums at work, but it still makes sense people would be more motivated by this approach than by reminders of what they’re doing wrong. Something to keep in mind as we work with our teams.