In our second interview with Mina Radhakrishnan, startup advisor and former Head of Product at Uber, Mina shares valuable insights from managing product development at a young, quickly-expanding company.
Wizeline Product Director Matt Pasienski digs into the following with Mina:
- Why it’s important to use “no, and here’s why” instead of “no, but” with stakeholders
- Allocating product development resources to balance short-term and long-term priorities during rapid growth and international expansion
- The importance of getting user research directly from field/operations folks
- A common trap that product managers fall into
If you missed Part 1, watch it here and don’t forget to check back soon for our final interview with Mina!
Matt Pasienski: When you're talking about planning, it's the ability to say no to the ... I've met a couple of your field teams. These are hyper, focused, type A, their out there. They're just ripping things up in random cities around the world. How do you tell no ... These people that ... No, you can't have what you want. When they get what they want. That's why they were hired by Uber.
Mina R.: It's a question that I think you face in a lot of product talent. Generally, you have a number of different stake holders. Some people are going to be happy and some people aren't going to be happy. I think the difference is not just saying ... Not leaving it at no. Saying no and here's why. Rather than saying the no, but here's why. But is a very negative term. It tends to make people think that it's already going to be a bad thing for me. Whereas when you say, "No, and here's what we're doing instead." People generally are pretty reasonable, Everybody is out to sort of make sure the company is doing things as well as it can. It's growing as a whole. Not that people, obviously, don't want things for themselves. If you can explain the context in which things are situated in, people have a much easier time being able to accept no.
I think the other thing too that we try to do, not always as successfully as we could have, but things that did work are that we would have occasionally these fixed days. Fixed days are kind of a thing where, hey, take your day off. Look at different cities. See all of the stuff that's there. We log everything. We have all of the stuff that's available for us to work on. Pick something that you think is going to take you five or six hours to do. Go do it. People will be so happy as a result. These small things that you do really change how people feel on a day to day basis about their work.
Matt Pasienski: You said that you have to leave in this buffer. I think that if you go out and do product management for a while and you actually do deliver to dates. You know that whatever you plan to do you've got to leave someone a buffer. You have these fixed days. You have the twenty-five percent allocated towards whatever. I think at Google they said they would do seventy percent towards core product, twenty percent towards innovative stuff and ten percent towards putting balloons all over the planet or things like that. What do you think was the right allocation at Uber for those types of mixed of work?
Mina R.: I don't know that we always did that perfectly. I would break it out in several different areas. Google is in a slightly different place these days, obviously. When you're a really fast growing, young company there still so much that needs to be built just from a pure infrastructure standpoint. Not infrastructure just like DevOps. Basic infrastructure like, hey, you have to be able to support payments in multiple different parts of the world. You have to be able to internationalize and translate into languages. At Google, I definitely took some of those things for granted. I was like, "Oh, yeah, four new languages. No big deal. We got that." Whereas when you have a giant build out yourself, the process of creating it is a huge thing. If you don't look forward to, okay, this is the time to when we're going to have 200 cities and fifty countries and all these other languages. We have to start building now for that. You're just never ... By the time it gets there, it's too late.
There's a decent amount of time allocated towards just building core platforms and infrastructure for us to be able to expand and for us to be able to grow. Then, there's that layer of like, well, there's a level of maintenance and movement on things, right? For example, having ... One of the really big projects that we worked on, in early to mid 2012 when we built out car types. Up until July 2012, you could only ever call a black car in the Uber app. We had these random hacks that we would put in every once and a while. Really, there was no easy way to do it. We'd actually have to sit down and create everything from scratch each time. That was easily a six month project. Our entire system had to be over hauled.
It was built with this idea, similar to I'm sure how Amazon was back in the day when it was just books. It was, "Oh, all we're going to is sell books." All we're going to do is transport black cars. Once you start thinking about all the other things you can do, you actually have to start planning ahead. Not even for what's going to happen in the next three to four months, but what's going to happen two years from now. When you have all these other cities, you have to think about it.
Matt Pasienski: The crazy challenges of organizing fleets of cars all over cities. You also have the challenge of there's too many cars at the bottom of our app. We're going to run out of space.
Mina R.: Yeah. Yeah. Exactly. This is a problem that ... If you look at the Aparna, you'll see the evolution of how the slider went. It used to be this weird little thing at the top of the map. Sitting on the map. It would cover the cars. We moved it down to the bottom. It turned into a slider. Then it turned into a multi-tiered slider. It keeps on growing. You can't always know. You have to find that balance. You're not planning for four years ahead, but, you're also just not planning for three months ahead. What is the middle ground that you have to build?
Matt Pasienski: What do you do for user research? When you have so many different cities across the globe. Do you have user research coming from your field teams? Is it something where there's a systematic approach? Is it so consumer that you can just look at it and understand the basics as a product manager? You're almost a user yourself. You're probably a user all the time, right?
Mina R.: Yeah. Everybody at Uber uses Uber a lot. Yes, you're definitely your own consumer. I think where the challenge comes in with user research ... This is something that I would love for us to do more of and do better, is when it comes localized, right? How people use the app. It's always surprising to us. "Oh, that's what people do?" You totally don't realize it because it's just a very different market. A very different mind set. Thinking about how your international users use it is a different feel.
Another example of this is we always optimize the app so that it was based on the first name of people. Whereas, you go to Europe, that's a no no. It's a cultural faux pas. You don't address people that you don't know by their first name. It's very important then to make sure that people's last names were in there. Sometimes people have really long last names. How do we now redesign this so that we can account for long last names or make sure that a driver's first name isn't shown. The drivers felt the same way too. "Hey, you don't really know me. It's not your place to address me by my first name." Those are the kinds of things that you don't know until you know them. You can be a consumer. You can be a user. You can understand how people use the app. I think understanding the cultural norms is a different story.
We definitely relied on our operations team. I think they did a great job of being able to explain some of those things to us. Sometimes, you also need to hear it for yourself. It's good to have people trained in user research that can actually go out and get those ideas. A lot of times, I think that all product managers fall into this trap where they think they are the user. Sometimes, they are, but not always.
Matt Pasienski: Is it more than just a change in mind set or is it a weekly call that you have?
Mina R.: We weren't that formal about it necessarily. People would come in and out of headquarters pretty often. We would try and make sure that we were talking to people in teams. We would have, sort of, liaisons in different areas that we would set up with. We had community managers and marketing managers. We'd sit in on their weekly calls and talk to them. Especially when we were in the process of trying to get out new features or thinking about things.
Matt Pasienski: How do you manage the tension between two things that have to happen but one needs to happen first? Is it something that happens within the organization where the CEO manages all these different factors or a product manager? Is there some kind of formal way of everybody getting their turn? Are you waiting by the strategic opportunity? How do you make decisions about what needs to happen next when so many people want so many different things and you're not going to be able to build them all?
Mina R.: I think ruthless prioritization, right? You have to. You can't do everything.