A reflection on my time as an Uber Associate Product Manager
Nothing could have prepared me for my time at Uber. Even after six internships, over a dozen hackathons, and an engineering degree, I wasn’t ready for my Uber ride. But to be fair, no one should ever feel ready to join Uber. It usually just happens and you get used to the discomfort of never feeling ready.
Fast forward to today, my Uber journey has officially come to an end. The last two and a half years carried me across three Uber teams, four cities across the globe, and a rollercoaster ride filled with learnings and memorable moments. As I officially end this crazy ride, I wanted to reflect on my time at Uber and share a glimpse of some of those moments and learnings.
The APM Bootcamp Firehose
Okay, maybe this APM bootcamp will prepare us to be product managers…
The APM boot camp squeezes decades of learnings and experiences into two weeks. We had dozens of tenure leaders across the company take time out of their day to talk to us. Breaks were rare, but so were dull moments. It reminded me of the days before final exams when students crammed months of knowledge during finals, hoping to become experts overnight.
Some sessions were supplemented with homework. Some were more entertaining and involved seeing who spent the most money on Ubers. Others were tedious but necessary and involved resolving a hundred support tickets.
We ended boot camp with a hackathon where everyone put their learnings to the test and presented in front of many product leaders. I worked on a solution to help facilitate the selection of a restaurant for a group order. Users would be able to join a group order, and then a restaurant would be selected based on the order history of each participant.
Once our bootcamp was over, we took a professional selfie jumped right into our first rotations.
Building for Cities
So Bootcamp was fantastic and we learned a ton. But diving straight into PM work was like trying to play Quidditch after reading Harry Potter: you generally know how it works, but you’re still nowhere near ready (and maybe never will be).
I worked on the Cities Platform team. Our work focus was to help policymakers and city planners make more informed decisions through the use of Uber’s city data.
PMs are the voice of the customer and I got to experience that first hand by organizing and leading user research interviews to understand user needs. My manager and I traveled to Seattle and London to talk to different city officials and learn about how people think about city development. These insights were important when deciding how our products should work. It hit me when I was talking about an engineer about how some data should be used and they said they wanted to lean on me because I was the one who’s actively talked to users.
I learned that one of my core responsibilities was to gather the needs and perspectives of internal and external stakeholders and make decisions and plans based on that. Decisions should always be made based on data, not opinions. The worst thing a team could do is make a decision based on uninformed instincts or loud opinions.
Around the world in 14 days
After our first rotation, our APM class traveled across four cities to learn from local operators to understand how Uber works in different types of cities. This was undoubtedly one of the coolest parts of the APM experience.
The philosophy behind the trip was that we needed to build a global solution for local problems. Everyone needs to move but how each city moves is different. As a product manager at Uber, we shouldn’t bias our product decisions based on where we’ve lived or the cultures we were exposed to. By thoughtfully understanding how each city moves, we’re better equipped to make informed decisions on a global product that serves our users.
We collectively took away so much from the trip. After the trip, we spent a month compiling our learnings and shared it out to the entire product org. The trip also gave me a lot of personal takeaways that I want to share:
- In Los Angeles, we saw the behind the scenes of having operational scooters across the city and learned about all of the vandalizing and thefts that happen with the different scooter parts. Building products that are both digital and physical is incredibly hard but who doesn’t love a hard problem to solve?
- In Mexico City, one of the Uber drivers shared that he was in a tough spot in life and was feeling suicidal. His friend introduced him to Uber and he credits Uber for saving his life and helping him get out of his state. Hearing this person’s feelings gave meaning to our work at Uber.
- In Amsterdam, we put on our courier hats on and tried to deliver Uber Eats meals across the city. We discovered a tad too late that many couriers camped at popular restaurants like McDonalds to increase their chances of getting dispatched and ended up with no dispatches. People are clever and tricks spread like wildfire.
- In Cairo, the road was basically a game of Mario Kart. There were bikers and cars all crammed on roads with no concept of a lane. Crossing the street as a pedestrian involved raising your hand while taking baby steps, hoping that the next car chooses not to run you over. Traffic and driving in Egypt are hectic as hell and we even got caught in a minor car accident while there. Although most cities have similar types of infrastructure components like cars, bikes, and roads, cities across the world move wildly differently.
I also recorded a fun video to recap our adventure across these four cities :)
Improving the marketplace through Driver Incentives
Once I came back from the APM trip, I started my second rotation on Driver Pricing. My team’s goal was to increase the Marketplace’s efficiency by optimizing hours that drivers are online. We accomplished this by providing daily incentives for the following week. By informing drivers when and where there would be incentives ahead of time, drivers can plan ahead of time and shift their hours to earn more.
Throughout the rotation, I had learnings in three areas: improving how the team collaborates, defining plans, and presenting.
Product managers should facilitate, not relay
Improving how the team works together took a lot of tries. It meant being very intentional with meetings and ensuring that the right people were involved. I learned that although product managers are frequently a central node for gathering information for decisions, they should not be a middle man when it comes to execution.
For example, product managers usually decide the scope of a project. But when engineers are implementing designs, product managers shouldn’t be playing a game of broken telephone between engineers and designers. Instead, they should focus on connecting the dots and make sure that the right stakeholders are talking. This feels obvious in hindsight, but hindsight is also 2020. I realized that it’s important to continuously challenge the “how” and “what” to find better ways to do things.
Planning becomes much harder when you realize you have limited resources
The hardest part about defining a plan wasn’t deciding what was included. It was deciding what will be excluded from the plan. There’s merit behind all ideas which is why it’s important to do brainstorms with the team during planning. When we took an initial pass at our H2 plan, it was easy to ambitiously bloat the plan. Once sizing estimates were made on all of the projects, then the real challenge began.
Prioritizing projects started with understanding our team’s strategic goals for the half. It was easier to align on a goal first than to align on projects. Once it was clear which metrics we were focused on for the half, it became easier to collaboratively cut down projects that weren’t aligned with our goals.
Q&A is more of an art than a science
Within Marketplace, teams present their work to Marketplace leadership. This was a great way for tech leaders within Marketplace to learn about a team’s focus within a short session and ask questions. For these sessions, hard questions were a given. Given the limited amount of time, we needed a strategy to handle questions effectively.
It’s easy to get caught in a rabbit hole or go on tangents when answering questions. My skip manager and I had a great conversation about different strategies to handle difficult questions and she helped me challenge the idea of a question.
Questions are usually followed by a response, but the response doesn’t have to be an answer. In other words, before answering a question, there are a lot of meta-questions in between such as:
- Is this question important or not?
- Am I the best person to answer this question?
- Does anyone in the room know the answer to this question?
- If we can’t answer the question, can we follow up after?
By understanding the intention and context of the question, it‘s’ easier to form the right response. Questions should aim to be resolved instead of answered. If the question is relevant and important, then the right response may be an answer. However, the right response is not always an answer.
Understanding the engine behind Uber
One of my favorite parts about my second rotation was my exposure to the Marketplace team. I developed a deeper interest in economics and really enjoyed thinking about the chain of effects that can happen due to product changes. Economics was no longer just a supply and demand black box concept. Instead, I got to see a lot of it in action.
Throughout my rotation, I really enjoyed learning about marginal benefits and costs and understanding how these concepts were applied to optimize driver incentives. If you’re interested in learning more about the Marketplace, you can read more about it here!
Launching Uber Eats for Businesses
For my last team, I worked as the first PM on Eats for Business, also known as E4B. We focused on unlocking a new business segment by providing meals for work.
When our team was first formed, we didn’t have a proper solution for employees. Uber Eats was previously designed for consumer which meant that the person ordering was always paying out of pocket. The initial problem our team faced was how could we bootstrap the existing consumer product to make it work for businesses?
The solution wasn’t trivial. There were so many different types of users, there were endless lists and sheets of feature requests from many sales reps, and there was only so much we could do in a short little time. The biggest challenge when tackling this project was managing all of the stakeholders. We needed a timeline to get an MVP out the door. This also meant establishing expectations and a timeline for when we would have things ready.
Getting a timeline was tricky. It required defining the scope of the feature and then investigating the tech effort required for the feature. Tech effort typically included design, engineering, testing, and rolling out. And this was only for one feature.
A plan for a plan is better than a rushed estimate.
A need for a timeline doesn’t have to be resolved with an actual timeline. Any estimates for a timeline at that point would have been purely intuitive and not based on research. Instead, we opted to provide a plan for a plan. In other words, we provided a date for when we would have a timeline ready instead of providing the actual timeline immediately.
The scenario that this avoided was if the timelines changed last minute. Stakeholders could have lost trust in our future timelines but more importantly, many customers we had relationships with may have lost trust in our team.
There’s pressure to get things out early in a competitive B2B space. Many competitors already had a competitive solution suite. I frequently heard from sales reps that if we didn’t get a feature out by a certain date, we might have lost a large deal. Our team was playing catch up with competitors and we needed to move both fast and strategically.
The MVP is the minimal change required to solve the use case.
But that wasn’t the approach we took unfortunately. Our MVP was defined by cutting corners from the long term vision of the feature. We were trying to make our product run at 50% before it could walk at 100%. Once we started scoping the long term engineering work, that’s when we realized that our features were not complementary. In other words, any long term work would have replaced our MVP. This would have been fine if we were a small startup, but throwaway work was not an option for us.
Be thoughtful with how plans are made and communicated
This was key to good stakeholder management. A good litmus test to see if you’re doing something wrong is if someone is surprised by a plan. Instead, it’s important to ensure that the right stakeholders are looped in at the right times so that they can help inform any decisions.
Scope fast, plan better.
We ended up spending more time scoping projects to get them out the door faster and didn’t focus enough time on getting a plan ready. Luckily, our final plan was mostly aligned with what we had scoped but we still had to cut some corners on our original scoping, leading to some lost work.
The best product managers are able to sustainably maximize impact with minimal resources.
Always talk to your users
In March, no one knew how long quarantine would last. Should we build for this pandemic state of the world with the risk of it being over by the time we finished any features? Should we continue building for the normal world if that might be years away?
We knew so little about what was going to come in the following months because of COVID. What we did know was what our users needed as a result of COVID. After hearing this feedback, we quickly pivoted our roadmap to focus on a new product called Uber Vouchers for Eats.
This product saw immediate product market fit and caused business growth immediately after launch. This was because we listened to our customers’ needs and our solution solved their problems.
Find the perfect balance of urgency and calmness
Bugs happen all the time. There will be dozens of Uber sales people trying to escalate their issues or feature requests and try to get us to prioritize their requests. In their defense, it’s their job to establish a good relationship with their clients and get any problems fixed as soon as possible.
It‘s hard to ignore my biases. My first reaction was to always try to resolve the situation immediately, listening to the loud voice or the request from a familiar person. I’ve found that challenging the request through a series of questions works best for me:
- Is this actionable in the next year? As a product team, we always have an opinion on how the product should work and we need to make sure that the request isn’t just noise.
- Does this need to happen now? There’s a high cost to pulling in engineers from their existing work. It’s always preferred to delay, deprioritize or delegate the request if possible.
- What is the exact ask? The more information, the better. Prioritizing a vague request will only lead to building something unused.
Nothing is free.
To work on something was to say that that was the most useful way to spend my time right now. So what if someone asks if we can tackle a new project? Saying yes to a new project meant stopping a current project. Saying no to a new project meant missing out on a new opportunity.
In other words, there’s opportunity cost behind every decision. I initially found that saying no to new requests was hard. I learned from peers that there are better ways to reframing new requests. For example:
Should we stop working on this existing thing and start working on this new thing? In other words, is this new thing more important than what we’re currently working on?
If the new request is less important, then there’s that should resolve the request. We live in a world where time is limited so we need to be intentional with how our team’s time is spent. Or in economic terms, the marginal benefit isn’t worth the marginal cost!
Having fun with product management!
Product management is as much an art as a science. Since it’s also an art, the many degrees of freedom enables ways to have fun on the job!
For me, that meant organizing team socials and celebrations, driving blue-sky brainstorming sessions, and designing conceptual mockups. For some weekly meetings that are at unpleasant hours like Monday morning, I liked to ask fun questions about people’s personal lives such as which shows they’ve been watching on Netflix or any movies that they watched. This was a fun way to get people engaged and warmed up for the meeting.
The end of my Uber ride
My time at Uber has been nothing short of incredible. The team at Uber was truly special and I couldn't have imagined a better team of folks to work with for my first job. It’s been incredible working with my managers and teammates to shape Uber’s products for millions of people.
As my Uber chapter closes, I’m embarking on a new adventure. I’ll be going back to being an engineer and joining a startup in the creator space. If you’re interested in joining along for my ride, come tag along here.
Thanks for reading!
