One reason we managed to put together an outstanding team to create the iPod was that our team could get relatively outsized stock and bonus plans that they couldn’t get anywhere else at Apple. The other important reason was that we had Steve Jobs fully behind us. Those two things allowed us to recruit amazing people—even though we couldn’t tell them what they’d be working on before they signed on—and survive the internal antibodies. Steve

gave our tiny team an unfair advantage—gave us air cover and dropped bombs if anyone messed with us. There were times when the internal antibodies at Apple tried to expel us from the organization—we’d constantly hear “We have other priorities, we’ll help you if we have time.” Or “Why are we doing this project—it’s not core to our business.” But as long as our team was making reasonable (or unreasonable but important) requests, the teams who were stalling us would get a call from Steve. “If they’re asking for something, then give it to them for Christ’s sake! This is very important for the company!

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.

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.

The Google teams with whom we’d planned to integrate and codevelop technologies and products were reluctant to work with us. They kept asking their execs for more details to figure out if they really had to help us at the expense of their own projects. Why? Why? Why do we have to help a team that isn’t Google? Over the subsequent months, every time we had to clarify yet again for customers that Nest was separate from Google, our internal reputation took another hit.

I should have remembered what it was like at Apple during the very first months when we started building the iPod. It just didn’t occur to me—Nest was so much bigger and more established than my tiny iPod team, I thought this was a completely different situation. But it was exactly the same. Back then Apple’s executive antibodies saw us coming to take their time and draw away their resources, so they tried to block our way and ignore our requests.

That’s when Steve Jobs gave us air cover, dropped bombs on the teams who were slowing us down, forced the issue, yelled sometimes to make sure we got what we needed. Steve Jobs fighting for us was ultimately what allowed us to succeed.

There are two major errors with that line of thinking. The first is overestimating what you, the manager, are capable of. Yes, it may be within your power to solve a wide variety of issues, but as a single individual, you can’t solve that many of them. The best work comes from those who have the time to live and breathe a problem fully, who can dedicate themselves to finding the best solution.

The second error is assuming that nobody wants to take on hard problems. In fact, the most talented employees aren’t looking for special treatment or “easy” projects. They want to be challenged. There is no greater sign of trust than handing your report an intricately tangled knot that you believe she can pull apart, even if you’re not sure how.