As APM programs start opening their applications, I thought I’d share my advice for how to approach Uber’s APM homework process. During September of 2022, I completed the homework interview round for Uber’s Associate Product Management program. At this point, I had only passed the resume screening so I had no interviews nor previous homeworks done.
The spec I wrote allowed me to go onto the interviewing rounds, so I wanted to share how I tackled the problem. If you’d like to review my spec before reading this article, you can click the button below:
The Question
Uber provided the following prompt for the homework assignment:
You are a Product Manager tasked with improving the experience for couriers delivering to apartments via Uber Eats.
Please propose a product feature or improvement to an existing feature. Think deeply about this problem from the perspective of couriers, eaters, merchants, and Uber. Product Managers are expected to analyze a problem space, ideate, and prioritize solutions.
Take us through the entire product cycle for your proposal - a feature(s) that you feel will improve both the experiences of users of Uber’s products as well as Uber’s business.
My answer would be evaluated on:
Understanding of the problem and the solution space
Intuition of the product(s)
Problem solving and analytical skills
Ability to think through and analyze business scenarios and execution strategies
Ability to communicate complex concepts in a concise and effective manner
My solution was limited to either a 10-slide max presentation or a 3-page max document.
Along with this prompt were documents that linked to Lenny Rachitsky’s Newsletter with two types of spec formats:
I was fortunate enough to have another spec template on hand (courtesy of a friend) and used that instead.
Framework
I took a six step approach (based partially on Lewis Lin’s CIRCLES framework):
Explore the Market Environment: Figure out what the company does and what it’s dealing with in the market
Define the Stakeholders and Their Goals: Define who the key stakeholders are and what their goals are
Prioritize the Key Stakeholder's Problems: Dive into the stakeholder of focus and prioritize problems based on their impact on the key stakeholder and the broader set of stakeholders
Ideate Solutions and How to Test Them: Develop solutions with hypotheses to test and understand what you’d need to know to ensure they work
Expand On the Best Solution: Focus on one and create a rough mockup along with hypotheses, risks, and metrics to assess the features success as it’s rolled out
Define Success: Describe what success looks like for the feature and what metrics will be used to track the level of success, as well as assess the feature’s impact on the broader product
I’ll now speak on how I used this framework.
Market Environment
The first step is incredibly helpful for understanding what the company has been dealing with along with what options customers have available. It was enlightening for me as I found I knew much less about UberEats (UE from this point on) and food delivery as a whole than I had thought.
To find out more about Uber, I delved into company documentation (i.e. 10ks, investor presentations, etc.), market research (i.e. McKinsey reports), courier web forums (i.e. r/UberEats, r/DoorDash), and (most importantly) using the UE application from both a courier and eater perspective to get a better idea of what the company wanted, what the industry looked like, and what problems each party faced. I also tried to do a user interview with an UE courier after I ordered food but unfortunately that didn’t work out.
Next time, I’d ask folks on the forums to do an interview as it would be easier to schedule a call and have a more full conversation. I’d also use competitor apps as well to get a more full picture of how the courier experience differs for each app.
In my market research, three things stuck out to me:
Many food delivery apps (including UE) experienced massive growth during COVID-19.
The market was saturated with a few large players (ie UE, Doordash, Grubhub, etc.) looking to gain lead market share in different cities while also ensuring they didn’t bleed money.
Urban centers were the key markets for these delivery apps. Couriers in these markets tended to use multiple different delivery apps.
Stakeholders and Their Goals
The following graphic lays out the relationships between eaters (those ordering the order), couriers (those delivering the order), and restaurants (those making the food for the order; labeled as merchants in the spec) and how the UE platform (or any other platform for that matter) facilitates their interactions. The white-highlighted interaction is the one my spec focused on.
Once I understood the market and user experience, I used the documents mentioned above to dive deeper into what each stakeholder wanted. Uber was relatively easy to learn about (based on the corporate documents mentioned above) and I assumed many of the other food delivery platforms were aiming to achieve similar goals.
As for the users, along with Uber’s documentation, the messaging board proved to be most helpful. I read through posts to understand how couriers thought about the platforms, the players they interacted with, and the strategies they employed. I followed similar approaches for eaters and restaurants but in less depth. The following chart lays out the the different goals each stakeholder has in relation to the food delivery experience provided by UE:
Prioritizing Key Stakeholder’s Problems
Now that I had an understanding of the market and the different players, I needed to do a deeper dive into the courier experience.
I also wanted to have a clear question for my approach. To more effectively define the situation I decided to specify my problem to the following:
How can Uber improve couriers’ ability to increase courier profits by delivering food to apartment buildings more efficiently and ensure that more users utilize UE as their main delivery app?
Using the messaging forums for the earlier steps, I asked questions about the worst part of urban delivery on different forums to understand how couriers felt about the platform they used when delivering in urban environments. You can see an example below.
Understanding not just the problems couriers had with UE but with competing products as well was key to finding areas where UE could create a competitive advantage for itself. I then summarized the problems I discovered from each forum and used them as the basis for coming up with key problem areas that couriers on all platforms face.
In defining these problem areas, I made clear the benefits of researching the area of interest in relation to courier's goals (i.e. “Addressing this problem allows couriers to better understand the tradeoffs of taking an order”), the potential limitations of solving the problem, and the issues that may occur if this problem is solved (i.e. developing features for easier entry for couriers may become a security risk and lead to potential legal problems for Uber).
In my case, the three areas were difficulty with building navigation, uncertainty around in-building delivery time, and difficulty finding parking. As I broke down each of the problems, the third issue showed up the least so I put that as the lowest priority. Focusing on the first two problems, I realized that although derisking delivery time within apartments may help couriers be selective, couriers may self-select to choose shorter delivery times and harm the experience for a variety of eaters. This left the issues with building navigation to be the best area to focus on due to its lower risks to Uber as well as its high ease of solvability for certain edge cases.
Ideating Solutions and Tests
After assessing the problems, I developed solutions that addressed the key problem mentioned above. I wrote up a brief description of the solutions, a series of hypotheses to test each solution's effectiveness (along with what metrics should be used to test them), and the risks of implementing these solutions. I felt keeping things simple would be better than going for an incredibly complex feature as the spec had relatively strict page limitations and most early stage PMs handle very small parts of a product (i.e. a button, a window, etc.).
Of the three solutions I came up with, I mainly delved into the two that would have the biggest impact on the problem area I had defined. They were:
A text box that would allow users to input their building entry code if they lived in an apartment building with a code (referred to as text box).
A library of PDFs of floor layouts in which the proper layout would be given to a courier based on the building they were delivering to (referred to as PDF library).
Although both definitely addressed the problem, the greater security risk, uncomfortableness to eaters, and general technical requirements of the PDF library made the text box a much more feasible solution to pursue. Furthermore, the text box feature had fewer unknowns than the PDF Library and would’ve built onto an existing feature. It also addressed more use cases than just direct delivery to apartments (i.e. gated communities).
Defining the Best Solution
After my evaluation, I wrote an overview of the text box feature and described how it provided value to couriers and other stakeholders. In particular, it would allow couriers to increase their efficiency and get more orders per hour in. For eaters, the feature provided them with a clear and easy spot to provide entry code information to couriers to get their food faster.
I then defined the long term vision for the feature, or the ultimate form of this feature. If this feature was perfect, what would it do for the stakeholders?
I defined it as such:
Wherever a courier goes, they’ll be given the necessary information and permission to frictionlessly enter into a building to drop off an order.
I then briefly described my design and created a mockup of the feature by editing screenshots from the UE app with Figma, a tool for planning out the UI for applications and websites.
A mockup with a brief description of how the feature would work is shown below:
Next, I reiterated the rationale for choosing the text box feature and I finally closed with a series of proposed hypotheses and tests to understand usage of the new feature. My hypotheses and tests were oriented around testing user expectations related to data entry, time-related issues to entering buildings, and the impact of providing couriers with building entry codes in relation to the buildings eaters reside in.
Execution
Finally, I focused on the execution of the feature. I answered questions like where to launch the feature, how to introduce users to the feature, and what success would look like for this feature for each of the different relevant stakeholders. I then included metrics specific to the feature that would measure the goals related to the feature (primary metrics), metrics that track the health of the feature (secondary metrics), and metrics that check if progress is being made in opposition of the goals of the feature (guard rail metrics). The main goal of the feature was seeing an increase in deliveries per hour for couriers. This would mean the feature had led to a decrease in delivery time and couriers would be able to deliver more per hour.
For my primary metrics, fill out rate of the text box and delivery time specific to entry code required buildings along with the number of deliveries completed per hour at entry code required buildings would reveal how the feature impacted delivery time and effectiveness for entry code required buildings.
For secondary metrics, checking satisfaction and delivery completion rate would validate if the feature harmed courier or eater experiences and if it decreased service to entry code required buildings.
My guard rail metric would show if users were even filling out the entry code text box or instead using the traditional notes section. If users were using the traditional notes section, clearly the feature was not being used in the intended way and it would be useful to see if a different educational approach would get users to adapt to the feature or if another feature/approach would be better.
Big Takeaways
As many PMs like to say, specs are living documents. Although my process gave me results that were good enough to move onto the next round of the Uber APM interview, I wanted to highlight the practices I would keep and what practices I would change if given another opportunity to work on this spec.
Don’t be afraid to ask for feedback and advice: When I was working on my spec, I was confused on where to even start. Seeking advice from someone I knew that had succeeded in the interview (my friend mentioned above is a current member of Uber’s APM program) helped me understand what to do. I also wanted trusted, more experienced colleagues to look over my work as well. I reached out to my former manager and mentor with a quick text, and they were more than happy to review my spec. Having people who support you and provide you with honest feedback can be incredibly helpful in defining and scoping problems as well as providing feedback on the directions you’re taking with your specs. Even if it seems scary to ask for help, ask yourself, “What’s the worst thing that happens if I reach out?” In my experience, the worst outcome is that they forget to respond or ignore your message. If that’s the scariest thing that can happen, I promise you the benefits of asking greatly outweigh the fear. So reach out; the people providing you with help and advice usually want to see you succeed.
Use your product AND approach it like you’re a user: Due to not having a car and being a busy student, I didn’t have time to go through the full courier experience. Instead, I watched videos to give me a sense of what that experience would be like. Although it’s a good workaround, you don’t really “get” a product until you use it like your users do. Going to deliver a food item to a high rise building (which was the major scenario I focused on in my spec) would’ve provided me with a better understanding of what that process would look like. Trying your competitors' applications is also helpful as it provides you with other ideas that you can improve on. I wish I had used DoorDash and other food delivery apps to get a more full perspective. If you can’t do any of these though, finding the next closest experience can still help a lot.
Be specific and always define your terms: On review of my spec over a year later, something I noticed was how vague I had been in defining what an urban area was. Did I mean a city like New York, with towering skyscrapers and a bike oriented delivery economy? Or a city like Houston, with car oriented traffic and a huge urban sprawl? Fortunately I provided greater specificity in my solution, which focused on high rises which you’re more likely to see in NYC or Philadelphia, but being clear helps not just you but all readers of your spec understand what exactly you’re trying to build. I could’ve also been more specific about the solutions I’d built and better segmented out the different types of stakeholders (i.e. bikers, drivers, walkers, etc etc.) but given the time and space constraints, I think skipping this was ok for this spec.
Thank you so much for reading! If you found this article helpful, I post about the projects I work on in product management, technology, energy, the environment, and more here.
Press the button below to keep hearing my “frank thoughts” and improving with me every week!
All the best,
Frank Lapinski