How would you design at ETA system for Lyft drivers?

Interesting! So I'm the PM on ETA for Lyft drivers - it already exists - and I want design a better version of it.

My proposed approach to this product design question is to start with the goals that we're trying to achieve. Second, I would like to better understand users and use cases. Then I'd like to prioritize use cases, focus on the top ones. Finally, brainstorm potential solutions and prioritize them.

In terms of goals, I would expect ETAs to be a significant driver of user satisfaction. Setting the ETA to earlier than the actual arrival time will mean the passenger will wait at the curb much earlier than needed, generating d-sat. Setting the ETA to later than the actual arrival also has the potential to generate d-sat on the driver side, who will have to wait for the passenger too long. ETAs are also probably a strong driver of usage of the product. If I open both Uber and Lyft apps and see a Lyft ETA significantly lower than Uber's, I'll probably use Lyft's rather than Uber's if I need the ride right away. That said, showing a lower ETA might convert a user on a ride, but if that ETA is wrong it will create user d-sat and the next time they might choose the competition. In summary, let's use improving user satisfaction as a goal, and the metrics can be around accuracy of the ETA vs actual. One example of that could be Mean Squared error of the difference between predicted time of arrival and actual time of arrival. Does that make sense?

Next, I would define the users and use cases. As mentioned earlier, I see drivers and passengers as the main types of users. Drivers see an ETA before they decide to deliver a ride, and should include both ETA to get to pickup location and ETA from pickup to drop-off location. Passengers see it before they book, and through out the ride delivery flow i.e. on the way to pickup, arriving notifications, on the way to dropoff, or to another pickup if it is a carpool ride, all the way to my dropoff. So there is a backend component of the experience that can be leveraged for frontend experiences for both driver and passenger.

I would think about the following use cases:

1. As a driver, I would like to see accurate ETAs so that I have correct expectations set before accepting a ride.
2. As a passenger, I would like to see accurate ETAs for pickup so that I can make an informed decision on which app to use.
3. As a passenger, I would like to know when to start walking to the curbside, so that I don't have to wait outside nor have the driver wait for me.
4. As a passenger, I would like to see accurate ETAs for dropoff so that I can make a decision on whether to inform someone else on my ETA or not (e.g. if I'm late for a meeting).

Next, let's prioritize the sue cases. Given that the goal is to improve user satisfaction, which we can measure immediately after a ride happens, I would consider the following criteria: reach, impact of inaccuracies, confidence, effort (RICE framework). Given the core work is making the accurate prediction, let's assume that the core of the cost to develop the solution is the similar across all options, let's focus on incremental cost with APIs and frontend to make the solution work:

I would focus on use case 3. Should we continue with brainstorming solutions?

Ok, so focusing on "As a passenger, I would like to know when to start walking to the curbside, so that I don't have to wait outside nor have the driver wait for me.", here are a few ideas:

1. As a passenger, I would like to be reminded, at the time of booking, about how long it will take me to get to the exact pickup location. For example, I would like to be notified that users in my location take on average X mins to get to the pickup location to take that into account.
2. As a passenger, I would like to receive an X min reminder before the driver arrives so that I start walking at a time when the driver will get to the pickup location. Given we don't know how long the user is going to take to get to curbside from where they are, let's assume 30 secs to 5 mins. If it's a large building with dozens of floors, and the need to walk to a specific pickup location it could take 5 mins. If it's a house it can take 30 secs. I would work with data sciences to come up with more accurate information.  The MVP could be a pre-defined threshold. V2 could be personalized based on the passenger's specific situation (may require getting user feedback at the time of booking).
3. As a passenger, I would like not to have to walk to curbside too early in extreme weather, so that I don't get wet/cold/sweaty.

Would you like to pick one of these? The first one? Sure!

In order to implement this feature, we would need to:

1. Gather data. We could leverage phone sensor information to:
   1. Determine when the user started walking to the pickup location.
   2. Infer drivers of time to get from where they are to pickup locaiton based on accelerometer, etc.
   3. When they got to the pickup location.
2. Build machine learning models to predict time from starting point to pickup location.
3. Serve models in production.
4. Display estimated time to walk to vehicle (by accessing prediction API)

I would work with Data Sciences, Engineering, and Design to flesh out the exact requirements for the product improvement. It's interesting that I started thinking about the vehicle ETA but ended up with features to improve the passenger and driver satisfaction/experiences!

Define the goal:  provides an estimated arrival time to the end users

Define the key consideration: accuracy; transparency or tracking

Define the key functions: 

A. Estimated the route

B. Estimated the speed

C. Estimated the local traffic

D. Estimated the extra time window as a buffer 

Data inputs:  Driver's GPS Locations and rider's GPS locations

Algorithm A: calculated the best route 

Algorithm B: based on the best route; calculate the speed 

Algorithm C: assess the traffic density and adjust the speed

Algorithm D: assess the individual driver's historical performance and estimate the buffer time

End User Interface: Provide the initial ETA and start tracking the car; update the ETA every 10 30 sec; real-time update the tracking 

Driver Interface: Provides the initial ETA and start tracking the car; update the ETA every 10 30 sec; real-time update the tracking; notify the driver when he does not follow the recommended route and lead to increase of the ETA; 

Driver's feedback: 

If the driver reached the customers within the ETA and follow the recommendation, provide rewards

If the driver reached the customers within the ETA without following the recommendation, ask the driver to manually overrides the recommendation

If the driver reached the customers beyond the ETA without following the recommendation, ask the driver to provide reasons

Nice to have:

Driver's feedback and algorithm D

Must have: all the other features are must have to enable the minimum function of ETA systems.