First of all, I’d like to start by defining what is Uber.
I’m assuming this time we are talking about Uber ride-hailing service and not other services such as Uber Eats. The interviewer says yes.

Then I’m going to define the Uber ecosystem. And assume the geography is India.
Uber is an on-demand ride-hailing service, where a rider can request a cab and that request is sent to all the available drivers nearby. This request is sent to the drivers based on some matching algorithm, driver can accept or reject the request. If the driver rejects the request then the request is diverted to the next driver based on the score from the matching algorithm.

Confirm with the interviewer if the understanding is correct. They agree to it and move on.

There are a few clarifying questions I’d like to ask following this. First is the waiting page, there are two scenarios

• The user has requested a cab and that request goes to the driver and then the driver accepts or rejects the request,

The user has been allotted a cab and on this screen, the user would see the driver’s location, along with the estimated time of arrival and waiting time

• The third scenario, unlikely, the booking was canceled due to a server issue which is at the backend

• What’s the average wait time of the user here after they are allotted a cab, the average wait time of the user has increased or decreased, what’s the trend?
• Cancellation on the waiting screen is user-triggered or driver-triggered? What’s the breakup and how has that trend been?
• If the majority of cancellations are triggered by the driver, what’s happening here, what is the behavior?
  • Is it across some drivers or all drivers?
  • Is it across geography or generic phenomena?
  • Which cab category sees the maximum number of driver cancellations?
  • What was the original time that was shown to the driver when they accepted the booking?
  • What was the time remaining when the cancellation was triggered?
  • Are maximum cancellations happening when the driver accepts the ride in the first few seconds or are they happening when a driver has started and then had to cancel or the driver reached the destination and is near (rider’s pickup point) and then cancellation is triggered?
• How is the retention for the riders whose rides were canceled, are they making another set of bookings or they are going away with the competition? This will help me understand the impact of the problem, basically how big is the problem.
• Are the cancellations happening in the peak hours or lean hours?

• Maximum driver cancellations happen in the first minute after accepting a booking
• For users who face cancellations, we observe low retention
• Driver cancellation is a more common phenomenon than customer cancellations and hence it makes sense to prioritize driver-related issues here.
• The cancellation is happening across peak hours mostly
• This is happening for all the drivers across all the geography

• The motivators need to be played around with, motivators are basically the user’s pickup point, net earnings from the ride, destination of the rider, and time to reach the pickup point. See what motivators work best here, can plan a few A/B tests around the same.
• The traffic conditions are not allowing drivers to reach a particular destination and hence they cancel the ride
• The driver is not willing to go to a particular destination and hence they are canceling
• The matching algorithm can incorporate a few signals or variables or introduce additional variables during peak time to optimize for cancellations. This can also be an A/B test scenario.
• One aspect could be penalize drivers after they have done x amount of cancellations
• Limit cancellation and give only x no. of cancellations to a driver per week
• Incentivize driver that don’t cancel beyond x no. of times

Clarification questions:

Is this occurrence affecting all user types, including new and returning users? YES

Are we observing the same issue on both Android and iOS platforms? YES

Problems:

-people are in a rush and need a car ASAP
-they found a car on another ride-sharing platform
-no driver would accept the ride
-they decide to get an offline taxi

Solutions:

1-To discourage customers from canceling due to long wait times, we can show them how long it will take for the next cab of the same type to arrive. A message such as “The next cab will arrive in 5 minutes” can help customers make informed decisions.

2-We can suggest a different type of cab that will arrive sooner. This will likely reduce the number of cancellations, but it may also lower the profits.

3- we can offer some games and activities to amuse customers waiting for a cab. This could help to reduce cancellations and improve the overall customer experience. we could also offer customers the ability to watch videos or listen to music while they wait for their cab. This could help to pass the time and make the wait more enjoyable.

Product description:
Uber is basically a service which allows people to commute & essentially, following the booking of a ride, there is a significant occurrence of cancellations on the Uber page, particularly when displaying the estimated waiting time on Maps
Clarification questions:

1. Is this occurrence affecting all user types, including new and returning users? Let’s assume it does, for our discussion’s sake. Both new & returning users could potentially experience this issue but I’ll choose to focus on returning users and it appears to be more prevalent among returning users & new users generally have a clearer understanding of the service, leading to more accurate suggestions & activation is done recently

Interviewer: Your call, you can pick any or both

2. Given that Uber has ample resources, can we assume that resource and financial constraints are not significant factors contributing to this problem?

Interviewer: Yes

3. Are we observing the same issue on both Android and iOS platforms? Assuming it is a widespread problem that occurs globally and regionally.

Interviewer: Yes
4. Assumption: Considering that cancellations are happening on the waiting page, can we assume  that these cancellations are initiated by riders most of the time rather than drivers?

Interviewer: Your call

Objective: 

Categorizing the user set based on AAAERRR (Awareness, Acquisition, Activation, etc.). In this case, it doesn’t seem to be primarily an issue related to Awareness, Acquisition, or Activation, especially since we are discussing returning users. For the current situation, I am focusing on improving user engagement as the primary objective, as addressing this aspect could potentially resolve the issue and, consequently, improve revenue in the long run.

Top User Groups:

Individuals

1. Individuals commuting to and from educational institutions (e.g., college or school).
2. Individuals commuting to and from their workplace or meetings.
3. Individuals needing transportation to healthcare facilities, classes, and similar destinations.
4. Individuals making bookings on behalf of others.

Corporates

1. Corporate users utilizing a company account for commuting to their office or attending meetings.

User Journey:

1. Launch the Uber App.
2. Enable GPS (if not already active).
3. Automatically detect the user’s current address.
4. Input the desired destination.
5. Confirm and book the ride.
6. Access the map screen displaying the estimated time of arrival for the driver.
7.  Monitor the distance of the driver from the user’s location, as some apps may provide this information while others may not.
8. Communicate with the driver to confirm their arrival status.
9. Check the real-time movement of the driver on the map if they have confirmed their intention to pick up the rider.
10. Consider canceling the ride in case the driver declines, the estimated arrival time is excessive, or the driver remains stationary.
Pain Points:

1. Extended wait times displayed on the map for the driver’s arrival.
2. Unintended driver inactivity (lack of movement).
3. Driver refusal to proceed with the pickup.
4. Customers discovering quicker ETA options from rival ride-sharing services.
5. Observing faster and more active movement of other types of cab types within the same app.
Solutions:

1. In instances where a customer contemplates canceling due to extended waiting times, we should display an estimated time for the next available cab of the same type. This would involve conveying a message to the user to discourage immediate cancellation, by engaging with this info

2. When a driver remains stationary, and a customer considers canceling, we could implement a feature that shows the driver’s pickup success rate as a percentage. For example, “This driver typically successfully picks up 95% of rides on the first attempt and is on time 95% of the time.” This information could help customers understand if the driver is likely facing traffic or technical issues, thereby encouraging them to delay cancellation by engaging with this information.

3. When a driver declines to pick up through chat or call, we can analyze the conversation and identify keywords such as “cancel.” We can then promptly assign a new driver while retaining the same Order ID. This backend process ensures a smoother transition to a new driver.

4. If none of the aforementioned reasons apply, and a customer is considering cancellation, we can inquire about the reason for cancellation. If the customer mentions finding a faster ride with a competitor, we can switch the cab to an alternative type of cab with the shortest estimated time of arrival. Although this approach may reduce cancellations, it may impact profit margins.

5. We can establish partnerships with grocery delivery apps, task management apps, and gaming apps to offer users alternative activities during extended wait times. For instance, if the waiting time exceeds 10-15 minutes, we can suggest adding groceries via Uber or engaging in in-app activities. This integration would require collaboration with these external apps such as Zepto, Swiggy, Online cricket, etc

Prioritisation:

Summarizing the features based on RICE prioritization:

| Feature | Reach | Impact | Effort | Priority |

|———|——-|——–|——–|———-|

| 1       | High  | High   | Medium | P0       |

| 2       | Medium| Medium | Medium | P1       |

| 3       | High  | High   | Medium | P0       |

| 4       | High  | High   | High   | P2       |

| 5       | High  | High   | High   | P2       |

Priority Legend:
P0: High Priority
P1: Medium Priority
P2: Low Priority

Please note that these priorities are based on the RICE framework, with the reach, impact, confidence and effort factors considered.

Metrics:
Success Metrics