The Point of PMs
Tony Fadell on Product Management
In Chapter 5.5 of his recently published book Build, Tony Fadell — of iPhone and Nest fame — writes about the point of having PMs. His writing about the job and the state of the discipline is very accurate, and it reignited my flame for PM; this is the job I love, and love to do well.
His perspective on the discipline of PM is unique as he is able to draw an analogy to the discipline of Design coming of age in the eighties. This is a good reminder that “my” (our?) craft of PM is still in it infancy, and this provides partial explanation about why things around PM can sometimes feel fuzzy and confusing. This is exciting; so much to discover and find out still!
Tony also makes some arguments that are great food for discussion, such as that product marketing and product management should not be separated into two jobs because “Your messaging is your product. The story you’re telling shapes the thing you’re making.”.
Other points he makes have been made elsewhere, such as why you might not want to call the product manager the ‘product owner', and the analogy between the product manager and the producer of a band.
My aim here is to promote Tony’s work — get Build here— and I believe the best way that is to share it in its original form too. First, I will provide a summary of the chapter, and then you will find the chapter in full.
TL:DR
For Tony, the current state of Product Management resembles the state of the discipline of Design in the eighties:
most tech companies in the eighties didn’t have designers to architect the user experience.
There was no school for design. No formal training.
Designers reported to engineering. They didn’t have the authority to push back on engineers.
Apple, Frog, David Kelley, IDEO, and design-led thinking elevated design in the nineties.
The profession came into its own as a formal discipline—understood, respected. Product management is on that path now. But not there yet.
In 2021, Google has moved to give product managers more power for the first time. Google has always been engineering-led, but now Search is being rearranged, empowering product managers. It’s a dramatic cultural shift.
The majority of companies misunderstand the role of the product manager, due to the fact that PM lives at the intersection of many specialties, and the job differs from company to company.
The abbreviation ‘PM’ adds to the confusion, as other roles are also abbreviated to PM. And then there are some companies who use different titles for the job of Product Manager.
Since the advent of the iPhone and the app economy, certain companies have begun to really understand product management and appreciate its value. Many still don’t.
At a startup, the founder or team lead often plays the role of the product manager in the beginning. They define the vision and work with all parts of the business to make it a reality.
When the team grows—to 40, 50, 100 people— the leader has to step away from the day-to-day business of building the product and hand over the reins to someone else. But they can’t imagine handing over their baby.
The same thing happens at big companies. The engineers figure out what to build or the sales team tells them what customers need. Where does product management fit in?
The customer needs a voice on the team. Engineers like to build products using the coolest new technology. Sales wants to build products that will make them a lot of money. But the product manager’s sole focus and responsibility is to build the right products for their customers [in a way that works for the business]. That’s the job.
The tricky thing is that the responsibilities of a product manager are completely different at different companies. Product management is less a well-defined role and more a set of skills. It lives between everything, a white space that morphs based on the customer, the needs of the business, and the abilities of the humans involved.
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. That’s a grievous mistake.
PM and PdM 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. Your messaging is your product. The story you’re telling shapes the thing you’re making.
The spec shows the features, the details of how a product will work, but the messaging predicts people’s concerns and finds ways to mitigate them. It answers the question, “Why will customers care?” And that question has to be answered long before anyone gets to work.
Figuring out what should be built and why is the hardest part of building. And it’s impossible to do it alone. Product management can’t just throw a spec over the fence to the rest of the team—every part of the business should be involved.
That doesn’t mean the product manager should build by consensus, but engineering, marketing, finance, sales, customer support, and legal will all have ideas and useful insights that will help shape the narrative before the product is built. And they’ll continue to improve that narrative as the product evolves.
A spec and messaging aren’t instructions that are set in stone. They flex and change, shifting as new ideas are introduced, or new realities slap you in the face.
Building a product is like making a song.
The band is composed of marketing, sales, engineering, support, manufacturing, PR, legal.
And the product manager is the producer—making sure everyone knows the melody, that nobody is out of tune and everyone is doing their part.
The PM is the only person who can see and hear how all the pieces are coming together, so they can tell when there’s too much bassoon or when a drum solo’s going on too long, when features get out of whack or people get so caught up in their own project that they forget the big picture.
But the PM is also not directing everything. Their job isn’t to be CEO of the product—or, God forbid, what some companies call the “product owner.” They can’t single-handedly dictate what will and will not make it in. 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. It’s the contributions of everyone on the team that ultimately define the melody, that turn noise into a song.
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. They have to tell the story of the customer, make sure everyone feels it.
The thread that ties all people and teams and pains and desires together is product management. For every successful product and company, all parts of your business end up leading back to them—it’s all hinged together in one central point.
This is why product managers are the hardest people to hire and train. It’s why the great ones are so valuable and so beloved. Because they have to understand it all, make sense of it. And they do it alone. They’re one of the most important teams at a company and one of the smallest.
Check out the next article in the series of Tony Fadell on Product Management:
The Point of PMs
[Below is Chapter 5.5 of Build by Tony Fadell]
The majority of companies I work with misunderstand the role of the product manager—if they even know it exists. They think it’s marketing (nope), it’s project management (nope), it’s press relations/communications (nope), it’s design (nope), product finance (nope), it’s the founder or CEO’s job (not really). The confusion mostly stems from the fact that product management lives at the intersection of many specialties and can look very different at different companies. But it’s also because of the stupid abbreviation. A PM can refer to:
Product manager or product marketing manager—Product marketing and product management are essentially the same thing—or at least they should be. 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.
Project manager—Coordinates tasks, meetings, calendars, and assets to enable individual projects to get done on time. It’s important to note that project managers are more than just glorified note takers. If the product manager is the voice of the product, the project manager is the voice of the project—their job is to alert the team to potential problems that could stall or derail the project and to help find solutions.
Program manager—Supervises groups of projects and project managers, focusing on both long-term business objectives and short-term deliverables.
To complicate matters further, some companies use different titles for product managers. Microsoft, for example, calls them program managers. There are also jobs that are adjacent to product management but not quite the same, especially in the world outside technology. CPGs (consumer product groups) like Colgate-Palmolive employ brand managers who don’t write the spec for the product, but are still the voice of the customer and responsible for shaping what the product will become.
In the interest of eliminating the confusion around what PM stands for, let’s use the following abbreviations:
PdM = Product manager
PjM = Project manager
PgM = Program manager
When yet another CEO tells me they have no idea what a product manager does, it always makes me think of design in the eighties.
Because most tech companies in the eighties didn’t have designers.
Things were obviously designed and those designs were just as critical as they are today, but nobody employed designers to architect the user experience. Designing meant making something look nice, and that just happened as you developed the product—a mechanical engineer would draw something up, or if you wanted to get fancy, you’d outsource those drawings to an agency.
There was no school for design. No formal training. And any designers who managed to get hired were second-class citizens. They didn’t have the authority to push back on engineers who’d cut corners with a shrug and say, “Well, we got most of what the designer asked for. But we can’t do it all—too much time, too expensive. Ship it as is!”
And then Apple, Frog, David Kelley, IDEO, and design-led thinking came along in the nineties and elevated design. Designers stopped reporting to engineering. Design schools were founded. The profession came into its own as a formal discipline—understood, respected.
Product management is on that path now. But unfortunately we’re not there yet.
It’s only in the last five to ten years, since the advent of the iPhone and the app economy, that certain companies have begun to really understand product management and appreciate its value. Many still don’t.
It’s an issue I see at a lot of startups and project teams at larger companies—the founder or team lead often plays the role of the product manager in the beginning. They define the vision and work with all parts of the business to make it a reality. The trouble comes when the team grows—to 40, 50, 100 people. [See also: Chapter 5.2: Breakpoints.] That’s when the leader has to step away from the day-to-day business of building the product and hand over the reins to someone else.
But they can’t imagine handing over their baby. How could anyone understand it or love it or help it grow as well as they could? And how would that function even work? Where would it live? How could the founder retain influence over the product if they’re no longer the manager of that product? And then what would the founder’s job even be? [See also: Chapter 6.1: Becoming CEO.]
The same thing happens at big companies. They’re also flummoxed. The engineers figure out what to build or the sales team tells them what customers need. Where does product management fit in?
As we write this in 2021, Google has moved to give product managers more power for the first time. Google has always been technology and engineering-led, but now Search is being rearranged to favor product managers over engineers. It’s a huge move and a dramatic cultural shift.
And the reason for it is simple: the customer needs a voice on the team. Engineers like to build products using the coolest new technology. Sales wants to build products that will make them a lot of money. But the product manager’s sole focus and responsibility is to build the right products for their customers.
That’s the job.
The tricky thing is that the responsibilities of a product manager are completely different at different companies. Product management is less a well-defined role and more a set of skills. It lives between everything, a white space that morphs based on the customer, the needs of the business, and the abilities of the humans involved.
A good product manager will do a little of everything and a great deal of all this:
Spec out what the product should do and the road map for where it will go over time.
Determine and maintain the messaging matrix.
Work with engineering to get the product built according to spec.
Work with design to make it intuitive and attractive to the target customer.
Work with marketing to help them understand the technical nuances in order to develop effective creative to communicate the messaging.
Present the product to management and get feedback from the execs.
Work with sales and finance to make sure this product has a market and can eventually make money.
Work with customer support to write necessary instructions, help manage problems, and take in customer requests and complaints.
Work with PR to address public perceptions, write the mock press release, and often act as a spokesperson.
And then there’s the even less well-defined stuff. 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.
Sometimes product managers need to be extremely technical—usually in B2B settings where the user of the product is extremely technical, too. If you’re selling brake systems to a car company, you’d better really understand brakes. Having a deep well of knowledge about brakes is the only way you’ll connect with your customer and understand what they care about.
But if you’re building a car for a regular person, you don’t need to know every detail about how the brakes work. You just need to know enough to communicate with the engineers who build them. And then you need to decide if those brakes are an important part of the marketing story you tell customers.
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.
Your messaging is your product. The story you’re telling shapes the thing you’re making. [See also: Chapter 3.2: Why Storytelling.]
I learned storytelling from Steve Jobs.
I learned product management from Greg Joswiak.
Joz, a fellow Wolverine, Michigander, and overall great person, has been at Apple since he left Ann Arbor in 1986 and has run product marketing for decades. And his superpower—the superpower of every truly great product manager—is empathy.
He doesn’t just understand the customer. He becomes the customer. He can shake off his deep, geeky knowledge of the product and use it like a beginner, like a regular person. You’d be surprised how many product managers skip that hugely necessary step—listening to their customers, gaining insights, empathizing with their needs, then actually using the product in the real world. But for Joz, it’s the only way.
So when Joz stepped into the world with his next-gen iPod to test it out, he fiddled with it like a beginner. He set aside all the tech specs—except one: battery life.
Nobody wanted their iPod to die in the middle of a flight or as they were DJing a party or going for a run. But as the product evolved from the classic iPod to the iPod Nano, we were in a constant tug-of-war—the smaller and more elegant it became, the less room there was for a battery. But what’s the point of a thousand songs in your pocket if you have to keep taking them out of your pocket to recharge?
One charge had to last days, not hours.
Battery life mattered to customers. And it mattered to Steve Jobs. You couldn’t just come to Steve and say, “The next version of the iPod is going to have a twelve-hour battery instead of fifteen like the last version.” You’d get thrown out of the meeting.
So Joz and I didn’t bring Steve numbers—we brought him customers. Commuters like Sarah only use the iPod going to and from work, students like Tom use it throughout the day, but in short bursts between classes or basketball games.
We created typical customer personas, then walked through the moments in their life when they used their iPods—while jogging, at parties, in the car. And we showed Steve that even if the number engineering gave us was twelve hours, those twelve hours actually lasted most people all week long.
The numbers were empty without customers, the facts meaningless without context.
Joz always, always understood the context and was able to turn it into an effective narrative. It’s how we were able to convince Steve. And reporters. And customers. It’s how we could sell iPods.
And that’s why product management has to own the messaging. The spec shows the features, the details of how a product will work, but the messaging predicts people’s concerns and finds ways to mitigate them. It answers the question, “Why will customers care?” And that question has to be answered long before anyone gets to work.
Figuring out what should be built and why is the hardest part of building. And it’s impossible to do it alone. Product management can’t just throw a spec over the fence to the rest of the team—every part of the business should be involved. That doesn’t mean the product manager should build by consensus, but engineering, marketing, finance, sales, customer support, and legal will all have ideas and useful insights that will help shape the narrative before the product is built. And they’ll continue to improve that narrative as the product evolves.
A spec and messaging aren’t instructions that are set in stone. They flex and change, shifting as new ideas are introduced, or new realities slap you in the face. Building a product isn’t like assembling an IKEA chair. You can’t just hand people instructions and walk away.
Building a product is like making a song.
The band is composed of marketing, sales, engineering, support, manufacturing, PR, legal. And the product manager is the producer—making sure everyone knows the melody, that nobody is out of tune and everyone is doing their part. They’re the only person who can see and hear how all the pieces are coming together, so they can tell when there’s too much bassoon or when a drum solo’s going on too long, when features get out of whack or people get so caught up in their own project that they forget the big picture.
But they’re also not directing everything. Their job isn’t to be CEO of the product—or, God forbid, what some companies call the “product owner.” They can’t single-handedly dictate what will and will not make it in. 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.
It’s the contributions of everyone on the team that ultimately define the melody, that turn noise into a song.
But of course it doesn’t always flow beautifully.
The engineers may want more say in what they’re building—they may claim the product manager isn’t technical enough or simply that engineering knows best. The marketers rarely want to stick to the playbook—they want to stretch and be creative, using words or images that may unintentionally misrepresent the product. People won’t always get along. Opinion-driven decisions will be debated ad nauseam. Teams will get out of step, individuals will get angry, the product will get pulled in opposite directions.
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.
They have to tell the story of the customer, make sure everyone feels it. And that’s how they move the needle.
The other day I was talking to Sophie Le Guen, an incredibly sharp and empathetic product manager at Nest.
She told me about a very early meeting she had with the engineering team to discuss the “why” for the new Nest Secure security system. For the mostly male engineering team, the “why” was simple: I want a security system to protect my home when I’m away.
But Sophie had been interviewing people and noticed that while men usually focused on empty homes, women focused on full ones. When they were alone or alone with the kids, women wanted extra protection. Especially at night.
Sophie’s job was to tell their story—to help a single engineer who lived alone understand a parent’s perspective. And then her job was to turn that perspective into features that worked for the entire family—a family that wanted to be safe, to turn on the security system when they walked in the door—but who didn’t want to feel like prisoners in their own home. So when Nest Secure launched, the motion sensors had a single button. A homeowner (or their kid) could push the button and open a door or window from the inside without having to deactivate the whole security system or cause a blaring false alarm.
The customer story helped engineering understand the pain point. They built a product to address that pain. Then marketing crafted a narrative that gave every person who had experienced the pain a reason to buy the product.
The thread that tied all these people and teams and pains and desires together was product management. For every successful product and company, all parts of your business end up leading back to them—it’s all hinged together in one central point.
This is why product managers are the hardest people to hire and train. It’s why the great ones are so valuable and so beloved. Because they have to understand it all, make sense of it. And they do it alone. They’re one of the most important teams at a company and one of the smallest.
Because the needs of each product and company are so different, these are incredibly difficult jobs to describe (See also: the previous three thousand words), never mind actually hire for. There’s no set job description or even a proper set of requirements. Many people assume product managers have to be technical, but that’s absolutely not true. Especially in B2C companies. I’ve met many great product managers who are able to build trust and a rapport with engineering without any kind of technical background. As long as they have a solid basic understanding of the technology and the curiosity to learn more, they can figure out how to work with engineering to get it built.
There’s no four-year college degree for product management, no obvious source you can hire from. Amazing product managers usually emerge from other roles. They start in marketing or engineering or support, but because they care so deeply about the customer, they start fixing the product and working to redefine it, rather than just executing someone else’s spec or messaging. And their focus on the customer doesn’t cloud their understanding that ultimately this is a business—so they also dive into sales and ops, try to understand unit economics and pricing.
They create the experience they need to become great product managers.
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.