Tech

WTF is a product manager?: Follow-up, part one...

I received way more feedback to my post explaining what exactly a product manager does than I had anticipated—a huge thank you to everyone who took the time to share thoughts, feedback and questions.

And speaking of questions, there were lots of good ones, the majority of which touched on a few recurring themes. I had originally intended to post one all encompassing follow-up in which I addressed each of them, but, given how long it’s taken me to get through just one answer, I decided to go ahead and publish my responses piecemeal. Apologies for the glacial pace of my replies!

Before diving into my first piece of follow-up, however, I wanted to share two film recommendations as we head into the weekend. The first, which is still in theaters, is called BALLET 422 and it “takes us backstage at the New York City Ballet as Justin Peck, a young up-and-coming choreographer, crafts a new work.”

I’ve never been a particularly big fan of ballet, but I found this film exhilarating, both in its depiction of the remarkable artistry and athleticism of the dancers, and in the way it captures the process of creation: its loneliness, its conflicts, its demands for partnership and its glorious moments of shared discovery. I think anyone working in product management will see parallels with their world and may come away with learnings that can be applied to their day jobs, particularly around the ability to balance individual vision and group collaboration.

If you’re a product manager in search of filmic inspiration this weekend, I’d strongly suggest BALLET 422, which is in theaters now, and Steve Jobs: The Lost Interview, which is available on Netflix streaming. Images from BALLET 422 (left) and …

If you’re a product manager in search of filmic inspiration this weekend, I’d strongly suggest BALLET 422, which is in theaters now, and Steve Jobs: The Lost Interview, which is available on Netflix streaming. Images from BALLET 422 (left) and Steve Jobs: The Lost Interview (right).

The second film is Steve Jobs: The Lost Interview. Though it hit theaters in the wake of Steve Jobs’ death in late 2011, the interview in question actually took place in 1996. The interviewer, Robert X. Cringely, captures his subject at a unique moment in time, when Jobs—who was never one for retrospection—was willing to talk candidly about his history at Apple, and the formative experiences that shaped his views on product creation, technology and leadership. What’s remarkable, given how long ago the interview took place, is how timely it remains in content, if not in video quality. Unfortunately, Steve Jobs: The Lost Interview is no longer available for purchase via any of the leading digital media services, but it is available for streaming on Netflix [Note: Sadly, The Lost Interview is no longer available on Netflix].

Okay, so on to follow-up, part one...

This is a really interesting question from Ryan Singer at Basecamp, formerly known as 37signals (my old stomping grounds!).

For people who’ve only ever worked at start-ups or very small companies, the answer may seem self-evident: If you need resources you ask the founder, and he or she will give you a yea or nay right then and there. But for anyone who’s worked at a larger firm—whether that firm deals in bits or in bolts—Ryan’s question will no doubt conjure dark memories of the Rube Goldberg-esque organizational apparatus nestled at the heart of most megacorps.

I have plenty of stories I could share about navigating that maze, but that’s another topic for another time. Getting back to Ryan’s question, I’ll start with the first half: The force that most frequently constrains a product manager—from above or otherwise—is inertia. This is because most individuals dislike change and, barring a strong opposing force from above, this individual antipathy seeps into a corporation’s broader culture, smothering any inclination towards innovation.

Even in companies with a history of risk-taking, it can be incredibly difficult to get a new idea over the top. That’s because, while many people love to talk about innovation and taking chances, very few have the courage to act when that action might jeopardize their personal financial security or career prospects. It’s also true that there are simply a lot of fucking intellectually lazy people in the world who can’t be bothered to learn anything new.

Sadly, our culture gives these people plenty of cover: Expressions like “Don’t rock the boat,” and “A bird in the hand is worth two in the bush,” and “If it ain’t broke, don’t fix it,” cloak inaction under a veneer of wisdom. But these bromides no longer hold water—I never thought I’d quote Mark Zuckerberg, but he’s spoken powerfully on this topic and, critically, has shown a willingness to back up his words with actions:

“The biggest risk is not taking any risk... In a world that’s changing really quickly, the only strategy that is guaranteed to fail is not taking risks.”

It’s important to emphasize that I’m not suggesting companies take risks willy-nilly. As someone who co-managed a micro start-up in 37signals, I know that everything a company does comes with very real costs in time, attention and capital. And, as someone who’s managed multi-million unit product lines at Nike, I’m well aware that product leaders must thoroughly consider the pros and cons of any potential opportunity before acting. But too many companies today are in perpetual harvest mode, seeking to eek out every last drop of value from existing products and processes before investing in better, higher value solutions.

Spend any time studying Apple’s product cycles and it quickly becomes evident that the company maintains a highly structured approach to its cadence of evolutionary and revolutionary updates. The strong sales of established lines enables investment …

Spend any time studying Apple’s product cycles and it quickly becomes evident that the company maintains a highly structured approach to its cadence of evolutionary and revolutionary updates. The strong sales of established lines enables investment in new, high-risk products that start at low volumes, but grow to subsume previously established franchises. Their offset invest/harvest/divest cadence also helps to mitigate any downside impacts associated with weaker-than-anticipated adoption within any one product line. This willingness to invest in new concepts and, just as importantly, divest of older ones, is a critical contributor to Apple’s continued success in the hyper-competitive consumer electronics space.

The problem with this seemingly prudent approach is that, by the time they’re done sucking blood from their precious stones, the marketplace has moved on and left these risk averse companies in the dust. Just ask the folks at Kodak or Blockbuster how well a strategy of perpetual harvest (the corporate euphemism for this is, “we’re focusing on our core businesses”) worked out for them. And yet, though cautionary tales illustrating the risk of not taking risks abound, sticking with the status quo remains the default mode within most organizations.

This may lead you to ask a new question, namely, how can I convince my company to be more open to risk? This has become a popular topic amongst business journalists and management consultants in recent years, with leading players like Accenture, The Economist, Harvard Business Review and McKinsey devoting much brainpower to the discovery of an answer. I know this is going to sound defeatist, but, in my experience, if a company’s leadership doesn’t already have a healthy appetite for risk, no amount of kicking, screaming or reasoned argument from below will be sufficient to effect change. As such, my advice to those who feel consistently hamstrung by organizational inertia is to find a new job at a company that’s shown a willingness to take smart chances or take the plunge and start a company of your own.

Now for the second part of Ryan’s question: How do products get resources? The specifics will vary from company to company, but the CliffsNotes version is pretty straightforward: Make a compelling case for your product.

In some companies this will entail lots of quantitative research, such as data on historical sales of related products, sales or usage trends across your broader market or important behavioral trends. For example, during my time in the ad world, my team successfully persuaded a large client to pursue a big-budget second-screen marketing campaign based in large part on behavioral research showing that second-screen viewing was exploding in popularity amongst their target audience. This supporting data gave our client the confidence to fund what was initially viewed as a risky proposition, and their return was an innovative campaign that delivered engagement levels far beyond industry norms.

Oftentimes, however, you’ll need a blend of facts and feelings to get a new product concept funded. For instance, at Nike, a pearl of wisdom from Phil Knight that anyone involved in product creation lives by is: “Always listen to the voice of the athlete.” This maxim is part of the bedrock of the company’s culture, so qualitative feedback from athletes (i.e. customers) holds tremendous sway at the Swoosh—much more so than it would at a more analytically driven company, such as Google. But, that being said, in order to get the highly unconventional Nike LunarGlide+ running shoe concept through the company’s organizational matrix, I had to buttress the positive feedback we received from early focus groups and wear tests with copious data on marketplace trends, as well as findings from our Sport Research Lab, which showed that the shoe offered quantitatively unique performance benefits.

You may be surprised to learn that there was no product manager’s handbook at Nike that walked me through the steps to success. Perhaps at some companies there is, but my experience tells me that it wouldn’t have been much use anyway, because I’ve yet to see two product creation scenarios play out in precisely the same way. I think this ability to empathize with and address the needs, questions and doubts of internal stakeholders is as crucial to the success of a product manager as is his or her ability to empathize with and address the needs of prospective customers. Because, if you can’t do the former, you’ll never get the opportunity to deliver on the latter.

I hope this helps and, as ever, let’s keep the conversation going on Twitter @edotkim.

Why CarPlay is a dead-end & how Apple can turn it around.

For the benefit of the TL;DR crowd, here’s the gist of this piece: CarPlay is a fundamentally flawed product that should be scrapped to give the engineers in Cupertino the space to come up with an in-car concept that’s actually better than the status quo.

Now, for the Android partisans who’ve landed here in the hopes of finding an Apple hit piece, I believe Android Auto suffers from the same fundamental issues, so: These aren’t the droids you’re looking for … move along … move along.

Okay then, for the four of you who are left, part of the reason I’m calling Apple out on their in-car initiative rather than Google is that Google has not published a manifesto claiming that “every idea we touch enhances each life it touches” (see the video below). Nor has Google CEO Larry Page publicly declared that “We’re not in the junk business,” as Apple CEO Tim Cook has on multiple occasions (suggesting, not so subtly, that others are).

It’s fair to say that I’ve found the tone of Apple’s recent pronouncements more than a little off-putting in their tendency towards narcissism and passive-agression. And yet, I’ve been a longtime fan of the brand and its offerings, so what truly inspired me to write this overlong treatise on CarPlay was my deeply disappointing experience with the product itself. I might even go so far as to call it a junk product, Tim Cook’s protestations to the contrary notwithstanding. Before diving into why it’s junk, however, I feel a quick primer on CarPlay is in order, starting with Apple’s own description:

“CarPlay takes the things you want to do with your iPhone while driving and puts them right on your car’s built-in display. You can get directions, make calls, send and receive messages, and listen to music, all in a way that allows you to stay focused on the road. Just plug in your iPhone and go.”

Note that that last line is meant literally. Even if your car supports Bluetooth audio and hands-free control, CarPlay requires a physical connection via a Lightning-to-USB cable. Now, if you’re a Mac geek, you may have read rumors indicating that the latest beta release of iOS 8.3 includes support for something called “wireless CarPlay,” but that tidbit comes with a caveat the size of an Escalade: By all accounts, wireless CarPlay will only work in vehicles equipped with both CarPlay and in-car WiFi connectivity. So, those hoping for CarPlay over Bluetooth to ever be a thing are almost certainly out of luck. And, given the slow rate of replacement for automobiles, this means the overwhelming majority of CarPlay users will be stuck with a wired connection for years to come.

This image, courtesy of Mercedes-Benz, shows an as yet unreleased implementation of CarPlay that should be available in C-Class models before the end of this year. Note that all incarnations of CarPlay demonstrated to date require a wired conne…

This image, courtesy of Mercedes-Benz, shows an as yet unreleased implementation of CarPlay that should be available in C-Class models before the end of this year. Note that all incarnations of CarPlay demonstrated to date require a wired connection to an in-car USB port, as illustrated here. I think many will find this to be a step backwards from existing Bluetooth hands-free systems, which are completely wireless. Worse yet, unless the manufacturer of your ride offers a post-purchase upgrade to in-car WiFi (something that’s laughably unlikely), you’ll be stuck using CarPlay with a wired connection for as long as you own your vehicle.

Speaking of wired connections, astute readers may have noticed the specific callout for a Lightning-to-USB cable in the paragraph above. That’s because CarPlay requires a Lightning-enabled iPhone, meaning the iPhone 5 or later. Putting these bits together, the minimum requirements for CarPlay are a recent vintage iPhone and a set of wheels with a CarPlay-compatible infotainment system (including a USB port). The shaded region of the Venn diagram representing the intersection of these requirements is pretty small today, but it is growing.

Rough Edges
Right then, now that you know what CarPlay is meant to do, what’s so bad about it? Well, for starters, it has more rough edges than a coal mine. For example, nearly every review I’ve read has criticized CarPlay for lacking the real-time responsiveness we’ve come to expect from our devices—a problem I experienced first-hand when I tried CarPlay on a Pioneer aftermarket head-unit (the Pioneer AVIC-5000 NEX to be exact, which retails for $750). Here’s how Zac Hall put it in his review of CarPlay for 9to5Mac:

“CarPlay can also be sluggish at times. Tapping an icon to launch a function could sometimes result in 5 or 6 second delays, which isn’t long once it works, but seems like ages while you’re waiting and not knowing if a touch was received.”

Consider that a car traveling at 60 mph would cover anywhere from 440 - 528 feet over the course of this 5 - 6 second delay (for reference, an American football field is 360 feet long, including the end zones), and you realize how problematic an unresponsive in-car system can be. But more on distraction and safety in a minute.

Reviewers have also noted that the few third-party apps available today via the CarPlay interface are, at best, problematic and, at worst, wholly unusable. Longtime Apple watcher Jason Snell highlighted this issue on his recently launched Six Colors blog:

“Apple’s site lists eight third-party apps that work with CarPlay, but I could only get two to work: iHeartRadio and Overcast. Both of them provided simple interfaces a la the [Apple] Podcasts app, but I found them to be slow and unreliable. In my testing, both iHeartRadio and Overcast sometimes failed to display any menu at all. Other times, there would be long delays between menu items. And the apps frequently just crashed, stopping playback and taking me back to the home screen.” [Note: You can see this in action at the 5:30 mark in Snell’s video review embedded above.]

Snell goes on to note that, “If one of the apps worked great, I could lay this at the feet of the other app developer, but since both of them are buggy I’m more inclined to blame CarPlay itself.” It’s worth calling out here that an app must be specifically approved for use in-car by Apple before it can appear within the CarPlay interface. For example: I’m a fan of the Downcast podcast player and had it installed on my iPhone when I took CarPlay for a test drive, but the app did not appear on the car’s screen because Apple has not yet approved it for use in-car. At least there’s a good chance that Downcast will eventually earn Apple’s “Works with CarPlay” blessing, but there are classes of third-party apps—maps and messaging being two biggies—that will almost certainly never make it to the CarPlay screen.

So it’s obvious to anyone who spends time with the system that CarPlay suffers from issues with interface lag, stability and third-party app availability. But most reviewers conclude that these foibles will be addressed soon—a fair assumption given the rapid development cycles that are the norm for consumer electronics companies like Apple. Indeed, this is one of the leading arguments mooted in support of systems like CarPlay: While mainstream automakers measure iteration cycles in units of years, tech companies live by a culture of constant iteration that industrial firms simply can’t match. The problem with this assumption, though, is that CarPlay doesn’t actually replace the underlying hardware or operating system powering a car’s infotainment system.

Mirror, Mirror
Apple has been characteristically tight lipped regarding the inner workings of CarPlay, but a few automakers have let slip that it’s essentially a variation on AirPlay Mirroring. In other words, your iPhone uses your car’s built-in display as the equivalent of an external monitor, with all CarPlay-related computing tasks handled by the phone. That sounds pretty straightforward, until you realize that the car’s infotainment system still needs its own OS so that it can, among other things, relay inputs made via the car’s touchscreen and other physical controls back to the phone for processing. This bit—the layer that sits between the car’s hardware and your phone—is not controlled by Apple, and probably never will be for a range of reasons that aren’t worth getting into here.

With each passing model year, cars are becoming less mechanical and more digital. And while purists may bemoan “advancements” like electronic stability control, electric power steering and in-car infotainment systems, there’s no question&n…

With each passing model year, cars are becoming less mechanical and more digital. And while purists may bemoan “advancements” like electronic stability control, electric power steering and in-car infotainment systems, there’s no question that the transition to digital has led to improvements in safety, efficiency and convenience. Electronics have become so pervasive, in fact, that it wouldn’t be an overstatement to describe the modern car as a computer on wheels and, like any computer, your car needs an operating system. The in-cabin OS of choice for most automakers today comes from a company called QNX, which is a subsidiary of Blackberry (yes, that Blackberry). Illustrated above is a high-level overview of QNX’s real-time operating system, called Neutrino. As you can see, it’s designed to be highly modular, working atop a range of processing architectures and supporting a wide array of user-facing inputs and outputs.

The bottom line is that, while all CarPlay-related computing tasks are offloaded to your iPhone, the overall system must still work within the compute and memory constraints of your car’s built-in hardware—constraints that are typically defined years in advance of a vehicle’s launch and remain fixed over its 10-plus year lifespan. Because of this, it’s far from a sure thing that a customer adopting CarPlay today will see dramatic improvements in the speed or stability of the system over time. Just ask anyone who’s cursed under their breath at the crapshoot that is AirPlay Mirroring to an Apple TV—a platform that Apple fully controls—whether Cupertino deserves the benefit of the doubt when it comes to AirPlay performance.

And yet, all this being said, these rough edges are merely peripheral to CarPlay’s core problem, which is that the platform as conceived today is attempting to answer the wrong question. Macworld’s Susy Ochs hinted at this fundamental disconnect after spending 72 hours with the system, ultimately concluding that “CarPlay can’t do anything my iPhone doesn’t do on its own, and obviously the iPhone has a lot more apps.”

That’s Not What I Asked
It’s clear that the goal for CarPlay was to improve upon existing in-car infotainment systems. And there’s no question that existing in-car systems leave a lot to be desired on the usability front. In fact, according to Consumer Reports’ most recent Annual Auto Survey, “The area that garners the largest number of complaints by far is infotainment systems and associated electronics.” So it might seem that this is a great question to tackle: Build a better in-car infotainment system, and the world will beat a path to your door!

The problem is, a better alternative already exists, and Apple created it: It’s called iPhone (or, more broadly, the modern smartphone). An iPhone in your pocket or purse linked to your car wirelessly via Bluetooth is superior to any built-in system on the market today—it’s always connected to the Internet, offers access to over a million purpose-built apps and already contains all of your personal data and media. Yet, rather than improving on this alternative, CarPlay hobbles it by limiting the availability of apps; delivering its few supported apps via a laggy, unresponsive interface; and forcing users to physically tether their phones to their cars.

For those who’ve been following Apple for a while, this may stir memories of Steve Jobs’ take on the smartphone market prior to the introduction of iPhone in mid-2007. From his celebrated Macworld keynote in January of that year up till the phone’s launch in June, Jobs repeatedly highlighted the limited capabilities of competitors’ devices—particularly in terms of their Internet connectivity. For example, here’s an excerpt from Jobs’ conversation with Walt Mossberg at the D5: All Things Digital conference in May of 2007:

“You’ve used the Internet—or you’ve tried to use the Internet—on your phone, and it’s terrible. They have lousy browsers ... I mean, you don’t get the Internet, you get the baby Internet or the “mobile” Internet or something bizarre. And what people want is the real internet on their phone.”

To paraphrase Jobs, what Apple is offering today in CarPlay is the baby iOS—underpowered and mystifyingly limited in functionality—when what people want is the real iOS, made better for use while driving.

As an observer looking at this from the perspective of a product manager, my conclusion is clear: Apple needs to shift from their current question, which asks: “How can we improve on today’s in-car infotainment systems?,” to a much tougher—but also much more meaningful—question: “How can we improve on today’s in-car iPhone experience?”

Focus Means Saying No
So, where to begin? Based on a review of the in-car infotainment landscape, if I were calling the shots, I’d focus on two fronts: safety and convenience. And, to enable my team to pour all of their efforts into delivering real benefits on these fronts, I’d shut down any work related to integration with in-dash displays—in other words, I’d kill CarPlay as it exists today.

Why? For starters, as outlined above, this attempt to piggyback on in-car systems shackles Apple to embedded hardware that’s already years out of date by the time it reaches dealers’ lots. But, more importantly, anything that takes drivers’ eyes off the road—such as in-dash displays—increases the likelihood of an accident. I’m sure that sounds terribly obvious, but the statistics are striking: According to data from the National Highway Traffic Safety Administration (NHTSA), distraction was a factor in 10 percent of fatal crashes in the U.S. in 2012, which translates to 3,328 souls lost to entirely avoidable circumstances. Furthermore, related research suggests that 15 - 20 percent of all in-car distractions involve drivers interacting with technology. This is a real problem, and adding another screen-based experience in the form of CarPlay does nothing to solve it.

The obvious alternative is voice control, and those familiar with CarPlay will note that the system already makes extensive use of Apple’s Siri voice recognition platform. It’s true that independent research has shown that “driving performance is better … and there is less time spent looking away from the road when using speech as opposed to manual [i.e. touch based] interfaces to operate an in-vehicle system” (Barón & Green, 2006). The problem is, not all speech interfaces are created equal, and a damning study by the AAA Foundation for Traffic Safety suggests that Siri is at the bottom of the heap when it comes to in-car performance.

The chart above is based on data from a rigorous study published by the AAA Foundation for Traffic Safety in October of 2014, and titled Measuring Cognitive Distraction in the Automobile II: Assessing In-Vehicle Voice-Based Interactive Technolo…

The chart above is based on data from a rigorous study published by the AAA Foundation for Traffic Safety in October of 2014, and titled Measuring Cognitive Distraction in the Automobile II: Assessing In-Vehicle Voice-Based Interactive Technologies. I highly recommend downloading the full study if you want to dig into the details, but, in a nutshell, this infographic depicts the levels of in-car cognitive distraction associated with several of the most widely used automotive infotainment systems. It’s important to note that all of the systems, including Siri, were used in fully hands- and eyes-free mode, meaning that they were entirely voice driven. Higher bars are worse and, as you can see, Siri fared very poorly.

Just how bad is Siri? According to the University of Utah researchers who authored the AAA study, even though Siri was configured to work purely hands- and eyes-free, “the [cognitive] workload ratings exceeded category 4 on our workload scale—the highest ratings that we have observed for any task … Moreover, there were two crashes in the simulator study when participants used Siri (the only other crash we observed was when participants used the menu-based [touchscreen] systems).”

This might seem unbelievable, but the researchers highlighted specific aspects of the Siri experience that contributed to these results:

“Common issues involved inconsistencies in which Siri would produce different responses to seemingly identical commands. In other circumstances, Siri required exact phrases to accomplish specific tasks, and subtle deviations from that phrasing would result in failure … Some participants also reported frustration with Siri’s occasional sarcasm and wit.”

I think that last point captures the core of the problem with Siri—as smart as the system may seem on the surface, it lacks the critical element of contextual awareness. Whereas research has shown that a flesh-and-blood driver and passenger will dynamically modulate the complexity of their conversation based on driving conditions, Siri is as verbose in a car speeding along at 60 mph as it is on a couch doing zero. Both Apple and Google have been using real-time location data pulled from our phones to display traffic conditions in their respective Maps apps for years, so the technological underpinnings for a contextual Siri are already in place—Apple just needs to connect the dots.

Apple has been polling location information from iPhone users for years to support the real-time traffic feature of the Maps app bundled with iOS. This means that, so long as you have the “Routing & Traffic” setting turned on (it’s on by default…

Apple has been polling location information from iPhone users for years to support the real-time traffic feature of the Maps app bundled with iOS. This means that, so long as you have the “Routing & Traffic” setting turned on (it’s on by default), your iPhone can determine that you’re in a moving vehicle, and know the road you’re traveling along. As far as I can tell, however, Apple is not using this data to inform the performance of Siri, which is a big miss, as this added layer of context could significantly enhance the utility and usability of Siri while driving.

To be fair, there are indications that Apple is limiting some aspects of Siri functionality when an iPhone is paired with an in-car Bluetooth interface. But, in my experience, the company has done nothing to limit Siri’s verbosity while driving, nor have they addressed the system’s penchant for inconsistent responses, as highlighted in the AAA study. I think it’s crucial that Apple prioritize these sorts of contextual enhancements to Siri alongside the company’s ongoing work to improve recognition accuracy.

One other Siri-related feature I’d be lobbying for if I had the keys to Apple’s in-car efforts would be the introduction of an API for third-party developers. This is by no means a new idea—the Apple developer community has been pining for a Siri API since the platform was introduced back in 2011. Sadly, anyone who’s been holding their breath has either passed out by now or completely given up hope, but this needs to happen for Siri to be accepted as a go-to in-car companion. Even a limited API reserved for certain classes of apps, such as audio and messaging, would be a huge step forward because it would enable drivers to use their favorite apps (as opposed to a tiny assortment of apps hand-picked by Apple) while keeping their eyes on the road—something that isn’t possible today with an iPhone.

Addressing these two Siri shortcomings is where I’d apply most of my energies as Apple’s in-car czar, because I believe fixing them would deliver the biggest real world safety gains. Now, I say “most” of my energies because, as noted at the start of this section, my efforts would be focused on two fronts: safety and convenience. And, when it comes to convenience, I’d go all in on improved Bluetooth performance (please, hold your applause … no, really, you’re all too kind).

It’s no secret that Bluetooth has been a bugbear for Apple since Bluetooth has been a thing (if you’ve been under a rock for the past few years, just Google “Apple Bluetooth problem” to get up to speed). And to those who say that the fault lies with the automakers, that fails to explain the explosion in Bluetooth issues that always seems to coincide with major releases of iOS and Mac OS X. The bottom line is that the implementation of Bluetooth on Apple devices today is far from great, and improving it is essential to answering the question of an improved in-car iPhone experience.

Fail Forward
There are many other features Apple could implement to enhance the experience of using an iPhone while driving, such as rich integration with the upcoming Apple Watch and its “Taptic Engine.” But I believe the work areas outlined above must take precedence if the company is serious about delivering a “smarter, safer and more fun way to use iPhone in the car,” which is how CarPlay was described in the press release announcing its launch exactly one year ago.

As it stands today, CarPlay is none of those things. This may explain why, 365 days on from its premiere, exactly one CarPlay-equipped vehicle—the Ferrari FF—is available for purchase (assuming you have roughly $300K to spare). Meanwhile, Toyota, which is the world’s largest automaker and was cited in Apple’s original press release as a CarPlay partner, has done an about-face, telling the New York Times that “it currently had no plans to adopt Android Auto or CarPlay in the United States.” Perhaps engineers at Toyota read the aforementioned AAA study, which found that Toyota’s in-house Entune hands-free system was significantly less distracting than Siri?

This is all conjecture on my part, but these signs suggest that CarPlay is running on fumes before it’s even passed the start line. The one thing that gives me hope for the future of Apple’s in-car efforts is the company’s unusual willingness to kill or fundamentally re-conceptualize products that it deems wanting. One example is the Apple TV, which started life in 2007 as a $299 media center PC with its own 40 or 160 GB hard drive (for those who don’t remember, it looked like a slightly smaller Mac mini), but was then completely re-imagined for 2010 as a $99 streaming media puck. More recently, Apple announced the discontinuation of the company’s long-lived iPhoto and Aperture apps for Mac, with both due to be replaced by an entirely new Photos for Mac OS X app within the next few months.

The “Designed by Apple” manifesto I referenced at the start of this piece includes a line that reads, “There are a thousand ‘no’s’ for every ‘yes,’” and I very much hope Apple has the institutional fortitude to attach one of those “no’s” to CarPlay. I don’t claim that the approach I’ve outlined above is necessarily the answer, but it’s clear that the CarPlay of today is headed in the wrong direction. And Apple needs to get it right because, unlike an Apple TV or Apple Watch, getting it wrong can be a matter of life and death.

Agree? Disagree? Have questions? Let’s continue the conversation on Twitter @edotkim.

WTF is a product manager?

It’s a good question. Before joining Nike back in 2007 as a product line manager, or PLM, within the company’s Running Footwear category, I had no idea that such a job existed. What a designer does is pretty straightforward: he or she designs a product, which includes a strong say into how that product works. What an engineer or developer does is also largely self-evident: he or she figures out the best way to realize a product concept, whether it’s with bits or with bolts. But a product manager: WTF?

My business card from my first stint at Nike, during which I served as a global product line manager, or PLM, in the company’s Running Footwear category. FYI: My phone number has changed since this card was issued—if you want to get in touch, the be…

My business card from my first stint at Nike, during which I served as a global product line manager, or PLM, in the company’s Running Footwear category. FYI: My phone number has changed since this card was issued—if you want to get in touch, the best way to reach me is on Twitter @edotkim.

Before diving in, I should note that this piece is based largely on my experiences at Nike. But my years in the digital design and advertising worlds gives me the confidence to say that the description below applies across industries, and spans the digital/linear divide as well. In other words, the broad strokes of what I describe below are as applicable to a product manager at a physical goods company, such as Proctor & Gamble, as they are to a product manager at a digital goods company, such as Twitter.

Okay, so if a designer designs and a developer develops, what does a product manager do? The most succinct answer I can give is this: A product manager defines the job that a product must do in order to succeed.

What does this entail? Usually, this definition is captured in the form of a brief, which defines the what of the job, along with relevant information regarding the target audience, context on market positioning and an indication of success measures (e.g. brand impact, sales, downloads, engagement, etc.).

Critically, what a good brief does not do is address the how of the job. That’s because any good product manager recognizes that the how must be left to the designer and developer to define. This is an enormous oversimplification, but one way to think about this is that the product manager outlines a job opportunity in the form of a question—e.g. Can we solve problem X for customer Y?—and the designer and developer apply their domain expertise towards answering that question in the most compelling way possible.

An example I’ve used in the past is that the designers and developers at Nike are so good that they could create a shoe that looks like a boat, yet still offers the performance and comfort of cutting edge athletic footwear. But if it turns out that there’s no market for shoes that look like boats, that product would fail—regardless of its beauty or functionality. In short, it doesn’t matter if the answer is right if the question you set out to answer is wrong. It’s the job of the product manager to ensure that the product team is working to answer the right question(s).

+++

Now, a question you may be asking at this point is: Does a company really need a person dedicated to the product manager role? Couldn’t a designer or developer figure out the job that their product must do on their own? Well, yes and no.

Say you’re a very small operation with an equally small product line that doesn’t change very often—for example, the boutique watchmaker Autodromo, which introduces just one new product per year. In such cases it’s often necessary for staffers to wear multiple hats, and it’s also very often the case that people who start passion projects like Autodromo enter into such endeavors with a clear preconception of the products they intend to create. A dedicated product manager would be superfluous in this context.

But then you have bigger companies—e.g. Nike, Apple, Facebook, et al.—that offer a wider range of products, in higher volumes and in fast moving industries. In such cases, if a designer or developer were to try to keep up with all of the inputs underpinning the job that their product must do on a version-by-version basis, he or she wouldn’t have any time left to design or develop. It’s in these contexts that a dedicated product manager becomes essential.

Before moving on, I’d like to dispel a couple of common misperceptions about the product manager role. First, the product manager doesn’t simply hand-off a product brief and then kick up his or her heels until the designer and developer come back with a concept. Creating a product is an iterative process—a path that seems promising one day may prove to be a blind alley the next, and it’s not unusual for a team to debate the core tenets of a brief well into this journey. A good product manager will remain engaged from start to finish, answering questions as they arise, re-assessing assumptions when warranted and doing whatever it takes to get his or her team the resources they need to effectively deliver on the brief.

On the flip side, the designer and developer aren’t just passive consumers of the product manager’s brief. In every successful project I’ve been part of, the ultimate product brief was created in collaboration with my teammates in design and development. As noted above, it’s impractical to expect the designer or developer to keep up with markets and user needs to the degree that a product manager must, but it is imperative that the designer and developer believe the core question they’re being asked to answer is the right one. And the best way I’ve found to cultivate this shared belief is to formulate that question in partnership with the people who will be asked to answer it.

+++

Okay, so a product manager defines the job that a product must do in order to succeed, and his or her primary deliverable is a product brief. What kind of knowledge base is required to deliver on these responsibilities? I’m glad you asked. The product manager role demands expertise across a few key domains, as illustrated below:

The product manager role sits at the intersection of three key domains of knowledge and expertise: your marketplace, your target end-user and your company’s brand.

The product manager role sits at the intersection of three key domains of knowledge and expertise: your marketplace, your target end-user and your company’s brand.

I know, I know, Venn diagrams are très cliché, but it’s a useful construct to illustrate the fundamentally multi-faceted nature of the product manager role.

Know Your Market
As mentioned above, a product brief typically includes context on market positioning. In some cases a product may create an entirely new market segment, but, most of the time, it will compete against other, similar products within an existing segment. For example, as innovative as Apple’s iPhone was on its introduction in 2007, it was entering a pre-established smartphone segment within the larger mobile phone marketplace. Steve Jobs’ original iPhone keynote made it clear that he recognized this, as his argument for the superiority of iPhone was built atop a dissection of the shortcomings of the existing market leaders, with Jobs specifically name-checking products from Motorola, Blackberry, Palm and Nokia.

This is a screengrab from Steve Jobs’s introduction of iPhone at the MacWorld exposition in 2007. Jobs was a fan of the 2x2 segmentation matrix and used it to great effect here to illustrate—some might say exaggerate—the benefits of iPhone relative …

This is a screengrab from Steve Jobs’s introduction of iPhone at the MacWorld exposition in 2007. Jobs was a fan of the 2x2 segmentation matrix and used it to great effect here to illustrate—some might say exaggerate—the benefits of iPhone relative to its competition.

While a company’s sales and merchandising teams typically develop the deepest marketplace expertise, it’s essential for a product manager to understand the overarching dynamics of the segment that their product will occupy. For example, what are the leading brands and products in a given market segment, and why are those players succeeding? What are the opportunities within that segment—i.e. are there needs that aren’t being met, price points that aren’t being served? Are there key gatekeepers within the segment that stand between your product and your customer? A good brief will be informed by answers to questions like these because marketplace dynamics can play a huge role in the ultimate success or failure of a product.

Know Your End-User
Next, a product manager must develop a deep understanding of their target user. Why do they buy the type of product you intend to create? What job does it fulfill in their lives? Do they have functional or emotional needs that aren’t being met by existing products in the marketplace? This may all sound a bit fluffy, but small nuances in the motivations of your end-user can mean the difference between success and failure.

I can provide an example here from my own time as a product manager, or PLM, in Nike’s Running Footwear category. I was the PLM for what would eventually become the Nike LunarGlide+ and, in the early stages of that project, my team and I struggled to deliver on our shared brief for a no compromise running shoe targeting a new generation of runners.

The fundamental insight that enabled the success of the original Nike LunarGlide+ was the outgrowth of countless hours of engagement with our target runner. As an aside, I mention in the accompanying piece that the product manager’s primary delivera…

The fundamental insight that enabled the success of the original Nike LunarGlide+ was the outgrowth of countless hours of engagement with our target runner. As an aside, I mention in the accompanying piece that the product manager’s primary deliverable is a brief, but that is by no means his or her only responsibility. For example, as the frames above depicting me in “talking head” mode illustrate, the product manager must serve as the evangelist-in-chief for their product, both inside their organization and out.

Our “Aha!” moment finally arrived after several months of on-the-ground research: We realized that, when our target runner told us she wanted a “simple” shoe, she actually meant she wanted a shoe that was “understandable.” We then had to dig into what “understandable” meant in the context of a running shoe, but this seemingly subtle distinction in the meaning behind a word completely changed our design direction and—I’m not exaggerating here—enabled us to progress from prototypes that runners hated in one round to samples they loved in the next.

We would not have reached this epiphany had we not spent an enormous amount of time engaging with our target user. As in the case of marketplace expertise being “owned” by sales and merchandising departments, some large companies will have consumer insights teams dedicated to the study of consumer needs and behaviors; but even in these instances, a product manager must develop a profound familiarity with their intended end-user within the context of the product they intend to create. In the case of the LunarGlide+, I had to understand the role running and running gear played in the life of our target runner, but I also had to know her well enough that I could appreciate the meaning behind her words. This connection was fundamental to the ultimate success of the product.

Know Your Brand
Finally, a product manager must maintain a deep understanding of the values underpinning their own brand. This probably sounds incredibly obvious, which may explain why so many product managers seem to forget it.

A good recent example is Amazon’s Fire Phone, which is widely recognized as having been a flop of epic proportions. Fast Company magazine was so interested in understanding why it failed that their February 2015 issue devotes 5,425 words to explaining what went wrong. They identify a number of factors, but it really boils down to this conclusion:

“Bezos, insiders say, was ‘the product manager’ on the Fire Phone [and] what makes the Fire Phone a particularly troubling adventure is that Amazon’s CEO seemingly lost track of the essential driver of his company’s brand. ‘We can’t compete head to head with Apple,’ says a high-level source at Lab126 [Amazon’s secretive R&D division]. ‘There’s a branding issue: Apple is premium, while our customers want a great product at a great price.’”

So, Jeff Bezos, a very smart man who is the CEO of Amazon and, according to many insider accounts, was the de facto product manager for the Fire Phone, failed to recognize that a successful product must embody the values of its brand. Goes to show you that this can happen to the best of ’em.

For counter examples, witness Apple’s refusal to offer a sub-$500 Netbook, which many industry “experts” insisted the company must do to remain competitive in the PC space back in the late-2000s (meanwhile, Apple just keeps setting Mac sales records, while the rest of the PC industry shrinks). Or their continued refusal to offer a cheap smartphone, again, against the entreaties of armchair pundits who exclaimed that Apple “would be stupid not to” release a low-cost phone (meanwhile, Apple just keeps setting smartphone sales records, while also growing market share).

Apple has refused these calls to go low-end because the company’s leaders know that to do so would be antithetical to the promise of their brand, which is founded on aspiration, innovation and a desire to surprise-and-delight. Tim Cook, the company’s CEO, made it very clear that he understands this in an interview with Bloomberg Businessweek:

“There’s always a large junk part of the market,” [Cook] says. “We’re not in the junk business ... There’s a segment of the market that really wants a product that does a lot for them, and I want to compete like crazy for those customers. I’m not going to lose sleep over that other market, because it’s just not who we are.”

Cook’s forthrightness is doubly impressive to me because this interview took place in September of 2013, at the height of the “Apple is doomed if they don't release a cheaper iPhone” mania. It reflects a deeply internalized understanding of the truth at the core of his brand—something every good product manager must develop and have the discipline to stick to.

+++

This post has ended up far, far longer than I had intended, but, for the two people who’ve actually made it this far down, I hope it’s helped you to better understand what a product manager does, and the areas of expertise that he or she must develop to be successful in the role. In a future post, I’ll answer the question I most often get from people who already know what a product manager is: How do I become a product manager?

In the meantime, I’ll leave you with a video of the best product manager of our generation brilliantly demonstrating all of the skills and domain expertise I’ve outlined above. Note how the presenter begins with an overview of his company’s target market (starts at the 1 minute mark), moves on to a discussion of user needs (starts at about the 8 minute mark) and then closes with a discusses of the attributes that set his product and brand apart from the competition (starts at about the 14 minute mark). This is going to sound terribly geeky, but I periodically re-watch this video to remind myself what it means to be a great product manager. Enjoy!

Agree? Disagree? Have questions? Let’s continue the conversation on Twitter @edotkim.