Product Empathy

Building a good product is really hard. The strange thing about that observation is that it’s somewhat counter-intuitive, and I think it’s because using good products is really easy. So what do you need to build good products? There’s often some key technology, for example PageRank is what made Google amazing. But even with good technology (eh, BetaMax vs VHS, hello?) it’s not a sure-fire thing that the product will succeed. I believe a large part of it comes down to having strong product empathy.

Now, before you think I’m going all new-age on you, I’m not talking about emotional empathy for your users, but rather the ability to truly put yourself in the shoes of the user who is using the product you’re building. As I write this, I realize that this may all sound trivially simple, but it’s not.

At the core, the challenge arises because of information asymmetry (or perhaps it might be called knowledge or ability asymmetry) – you, the one building the product, know so much about how to use your product, that you can’t see it the way your user will. You have massive product experience blindspots.

Let me give you an example. I have a camera that uses a rechargeable battery, although I’ll admit I don’t use it that much anymore. In any case, it comes with a battery charger that’s custom made for the camera’s battery, and I’m always puzzled by it. It has a single LED that can display different states and colors. There’s one color for the “the charger is on”, another for “I’m charging now”, and another one for “the battery is full”. The light state also changes for “the battery is pretty empty” and yet another one for “the battery is almost full”. In total, the light can show blue, red, amber, slow blinking and fast blinking. Here’s an exercise for the reader: with no further information, assign these light color and state combinations to the functionality I described earlier. Easy? You see, the product designers got so used to “of course blue means fully charged” that they completely forgot that the user has no idea. There’s nothing on the charger indicating any of this, and it’s a source of major frustration for me every time I charge the battery. My workaround, which I really don’t like, is to simply charge the battery overnight every time I need it.

This is what I mean by lack of product empathy.

The camera is great, or at least was great for its time. I’m sure the battery and the charger are also good technology for their respective purposes, or at least I haven’t had real problems with battery life and such. But the experience is frustrating. There are literally hundreds or thousands of these tiny mismatches in every person’s lives, all because the people building the products we use could not overcome their own user experience blindspots.

The world would be a better place if people building products had more product empathy.

Discuss on Twitter.

Naked in front of people

This is another in my series on product development, and this time I wanted to talk a little about the stress that accompanies launching new products, or even updates to existing ones. I like the way Reid Hoffman’s put it: “If you’re not embarrassed by the first version of your product, you’ve launched too late“, mostly because it’s usually true. Launching a product can feel as hard as standing naked in front of people. But what goes through people’s minds as they are putting their hard work in front of complete strangers?

I’m about to exhaust my repertoire of stories from the early days at Google, but one that particularly sticks with me is when we were going live with the product, early November, 2005 (oddly enough, Wikipedia thinks Google Maps for mobile launched in 2008) In order to fully appreciate what the world looked like back then, you have to forget that you have an iPhone or an Android phone, and squint really hard to picture your old Motorola Razr (if you thought thin flip phones were cool), Nokia 3650 (if you liked weird keypads) or Nokia 7650 (if you really understood that phones were just computers… well, sort of). These phones sucked, of course, but more importantly, there were hundreds of them, and they were all different.

As part of the launch, we wanted to have broad support since we were Google and everyone was supposed to be able to use Google products. Forget that nobody had data plans, and those plans were expensive, and the screens on phones were small and pixelated, and there was no GPS and… well, you get the picture. The goal someone made up – maybe it was me, I don’t remember – was to support one hundred different phone models. We started trying all these different phones in our Skylab (really just a big cabinet of mobile phones) and I kept track of which ones worked and which ones didn’t. I also hounded the team to support all kinds of obscure phones that nobody probably owned anyway, but it was ok since we wanted to be able to say we supported 100 phones at launch.

As the launch got closer, and everything was locked and loaded, it started to become clear that supporting 100 phones was going to be difficult. In fact, a lot of the “supported phones” were able to maybe launch the app in a few minutes, but then it became useless because of the tiny screen, lack of memory or other factors, because you know, phones sucked back then. I know this is borderline ranting, but if you don’t remember anything but iPhones and Androids, you have no idea how hard it was to build an app for phones that ran a busted version of J2ME.

This haunted me. I knew we were technically correct in claiming hundred supported phones, but I was worried that reporters might dig into this in detail, or users might have questions about this list. A lot was going through my head the weekend before the launch, I spoke with some of the team members about this and we concluded it was probably going to be ok so everything went ahead as planned. But I didn’t sleep well the night before the launch date. And then dawn came.

Google Maps for mobile went live and I spoke with reporters about what I thought was a revolutionary product that worked on so many phones and… nobody asked about the phones. Nobody cared!

In fact, there’s always something to worry about at launch, and many things will go differently from what you expect, but it’s usually not the stuff you worry the most about. You should anticipate a bunch of stuff happening – I really like the pre-mortem method of role playing a disaster launch ahead of time – but obsessively worrying about specific items is a waste of energy and sleeplessness.

The funny thing is that as I’ve gone through more and more launches over the years I’ve stopped worrying, and I remember specifically when we were launching Siri on the iPhone 4S the whole team was, probably rightfully, very stressed out and they kept wondering why I wasn’t as nervous as them. I really couldn’t explain it back then, but I knew we were well prepared for anything so everything was ok.

Discuss on Twitter:

The “idea”

Usually when someone approaches me with an idea for a new product or a new business, they blurt out something along the lines of “but don’t you go stealing my idea!” (yeah yeah, they’re all old men sitting on a porch) to which I always respond “but of course I will!” – and so will everyone else.

Everyone knows execution is key, and that ideas are worth a dime a dozen, but I’m talking about something deeper here. Ideas are important and in fact a crucial ingredient in making something amazing, world-changing happening. Without an idea, you’ve got… well, you ain’t got shit. So why do we discredit ideas so heavily?

The most obvious train of logic is exactly that point about execution: if you don’t bother turning that idea into reality with toil and sweat (and sometimes tears, usually not blood) it just won’t happen. We all ponder about all sorts of stuff while taking a shower or brushing our teeth, and we all had that same great idea months if not years earlier, you know, the one which made that young techie so rich and famous. Unfair. Or not.

However, the harder truth about ideas is that they aren’t static. You don’t get an idea and then just make it happen. Going again back to the days when I joined Google and became the product manager for Google Maps for mobile, I met Mark Crady who was the tech lead, and one of the founders of Zipdash, where he and his team had built a mobile mapping application. Mark is awesome, so was he the idea man behind Google Maps for mobile? Well… there was also Mike Chu, who was the other founder of Zipdash, working alongside Mark… and then there was Matt Waddell, who led marketing for the product… and Sanjay Mavinkurve who did the beautiful and highly intuitive design work… and the list goes on (Josh, Jerry, etc etc) – did you really think this product was built by one person?

The point is, I worked with a team of amazing engineers, designers, marketing people and other talented crafters. They all had great ideas, and it was the collective work – hard, hard work, mind you! – of all of us who made the product what it became. Believe me, the very first version looked nothing like what eventually shipped, and then it also changed rapidly post launch, as all good products do! That’s why an idea is worthless, because it’s like dough: it’s necessary to make something but you don’t want to eat it raw. Unless you’re 5. And then you get a stomach ache and hopefully learn.

If you think you’re the idea person, you lose. However, if you have no idea, you also lose. Tough world.

As always, discuss on Twitter.

Engineers and Sales People

I remember before I moved to Silicon Valley and started working as a product manager at Google, I always experienced work as being primarily done by two groups. There were the ones making stuff, and they were simply the engineers. And then there were the ones who were trying to sell the stuff engineers made, namely sales people, marketing, or just business people in general. I just called them sales people. I’m pretty sure there are a lot of people, especially technical people such as myself, who still see the world roughly along those contrasting lines. But boy was I wrong.

When I came to the valley in 2005, I had never heard of the role product manager. The description made sense to me, sort of. Someone who understands technology, but isn’t going to work in a technical role, can be highly analytical, understands users, thinks about features, vision, direction, coordinates among various stakeholders, blech! It sounded super exciting, but I remember when my friend Gokul Rajaram, who initially convinced me to apply at Google, described the role to me and a group of fellow newcomers: after everyone else in the team has done their job, it’s your responsibility to catch everything important that didn’t get done and make it happen. I still think it’s true, but it didn’t make it any easier for me to figure out this new job I had just signed up for.

I once heard that if you think some role is unnecessary, it simply means you haven’t worked with a person who’s good at that role. You think marketing is a joke? You probably haven’t spent any meaningful time with a good marketer. You see, as I was working on the initial version of Google Maps for mobile I realized that my highly simplified view of the world was simply wrong. There’s a big difference between people who are selling stuff and those laying out corporate strategy or doing the finances. There can even often be big differences within those groups: there’s frontline sales, sales engineering, sales support and so on and so forth. You get the picture, and the same is true for engineering; there’s testing, designers, back-end, front-end, site reliability and it goes on and on. But it how does product management fit into this whole picture?

Of all those roles, product management is the one that’s hardest to map out, and I think it’s because it’s the one that lies between the engineers and the sales people, if we go back to my old worldview. Their primary allegiance is with the product and its users, not any particular part of the company or function. In fact, the word manager in the title has confused a lot of people: product managers usually don’t manage people until they’re very senior, but instead literally manage the product! Duh!

Getting to the heart of what a product manager does is not at easy task. In fact, it’s not enough to simply describe what a product manager does you need to really understand how to do product development in user centric manner. That’s why there are no books about product management, or degrees that teach it.

I strongly believe every company should apply a product development centric approach to building their business. It doesn’t matter whether you are building physical hardware products that are sold through various channels, or you’re offering services to a particular consumer audience, or really anything else. Thinking about what the company does in terms of products being offered to your users and customers (there can be a distinction) is a very healthy way to ensure you are offering something of value and making the world a better place.

Over the next weeks I will be writing about the various parts of product development based on my experience building several large consumer products from ground up, including Google Maps for mobile, Google Voice Search, Siri, and Google Assistant. If you’re interested in joining along, be sure to follow me on Twitter. I don’t have a mailing list, but if you’re worried you might miss updates, just DM me your email address and I’ll be sure to email you whenever I post something new.

Have comments? Use my Tweet about this post.

All the time in the world…

After some back and forth shuffling, going to Medium and now leaving it again, I’m going to start writing again. Old posts might migrate over time, but I’m not in a hurry to take care of that.

So what will I writing about? Mostly just all sorts of stuff that I like writing about. You’ll probably see some thoughts on product development, startups, and of course all kinds of ideas around artificial intelligence. You can expect something perhaps once a week, although I’m not going to make any promises.

This introductory post isn’t going to be very interesting. One thing I’ve decided is to disable comments on the site, and instead direct people to a Twitter thread for each post in case people have thoughts. It’s an experiment, let’s see how it goes.

Finally, if you want to get notified about new posts, just follow me on Twitter.

Comments? Discuss at