Building a worldwide driver platform (Uber)
Date: 13 April
Matthew Zehnder & Jonathan Pepin
This was one of my favorite meetups so far. It was extremely actionable and tactical. Takes a lot of the aura/black box out of product management and felt doable! The only feedback I had for the product manager is to s.l.o.w. down when talking — he was super fast throughout, and I’m sure I missed some of his points. There were two speakers from the driver platform internationalization team - the product manager presented for the majority of the talk, and the engineer had a smaller section and chimed in throughout.
Introduction
- How did Uber international driver app start? Began with beta app + guerrilla marketing tactics to get people (riders & drivers) to use it
- First day on the job: “This is how it works? Oh my god!”
- First priority: translation
Driver Onboarding
- In the US: Had to upload documents, background check
- In Paris: Have to get expensive training
- In Manila: Had to hire a lawyer to become a driver
- So many unique problems per geo! Impossible to have just one driver app.
- Solutions: how does a product manager go about solving these problems?
- Listen: talk, in person, to drivers. You cannot just talk to Support.
- Drive clarity: make sense of the feedback. Be sure you are focused on the right problem.
**My favorite line of the night**
There are certain people that can read a long email thread & say: THIS is what is the most important point in this thread, and THIS is the next step we should take. Product manager’s job is to drive clarity for the team!
- Used data scientist to determine what features will result in the largest return
- You need to know- how long will it take your engineers to build something? All of your executives will ask constantly so you should be technical enough and knowledgeable about your team’s abilities to estimate this
- The engineer chimed in: Trust your engineers! If they say it will take 3 days instead of 1, trust them.
Engineer perspective
- It’s amazing how difficult things are when you talk about them vs you start to actually implement- so many details and questions come up
- Make sure that engineers & everyone are up to date. But do not disrupt your engineers! Tell them at standups, lunch, etc.
- Everytime something changes, you have to spend hours or days to rebuild it. You will find yourself saying: “It’s all garbage!”
- Be aware of what problems are actually critical. If it’s not critical, put it into v2, v6, etc.
“If I’m trying to be a good PM…”
- I know what my team likes to do & is good at- I structure my roadmap based on this, to give engineers things that they like to build
- Focused on finding rider 1. Convince Mayor or sports star to take one ride, then get PR to cover it.
Q&A
- What do they think about Lyft/Competition: Our strategic advantage is for drivers to be busy & earning money at all times (more rider demand). Generally, this PM thought Uber provides a similar experience to competition. A little difference between ETA
- How to do testing: segment by cities before randomly dividing users in 2 groups.
- He works on routing team within Maps. They support a bunch of teams & have to balance their requests.
How does Uber make progress fast?
- (Note: Don’t read drama into this sentence, it was described casually) We are in constant fights. Engineering wants to build code that’s scalable and can be posted on Github [which might take a long time]. So-
- We build a spec for MVP. Ship that as fast as possible. Then give the engineers a week to start over.
