Strategy and Framework

The feature change product question has a similar framework to the measuring success product question.

1. Clarify and ask questions
2. Understand feature change and set goals
3. Analyze data and provide recommendations

Clarify and ask questions

Let’s clarify any misunderstandings around Uber. Uber is an app that allows riders to request cars to get to different places. When we use the app, we input our destination and get an estimated car arrival time.

Let’s assume this feature can be brought up in a couple of cases:

• When the user requests a ride, a modal could pop up asking if the user would want a reduction in price by X% if they have to wait Y more minutes.
• When the user is about to request a ride, a button appears and gives the user to opt for a cheaper price.
• The app could offer a setting option to always default the user to cheaper rides for a longer wait time.

Given these three options, we should ask the interviewer which option would be best for the proposed feature. Notice how we have demonstrated a wider breadth of clarifying the potential product features instead of having a narrow vision of what kind of product the question is posing.

Lastly, let’s assume this scenario is not for an Uber pool or any kind of rideshare.

Understanding the feature change

We need to understand the feature change and why someone would propose the feature in the first place. This is similar to measuring success, except that while the goals are the same, the analysis uses the existing data before the feature or product is launched to analyze why we might have the idea to go through with it in the very beginning.

For example, Uber’s business goals are to:

• Grow their rider marketplace
• Increase their completed ride volume
• Increase rider and driver retention

Uber’s goals for this feature change could be to:

• Acquire more price-sensitive riders.
• Increase rider usage where riders are price-sensitive or driver supply is low.

Now, how do we know that utilizing this feature change will improve Uber’s goals in the long run? We have to make a connection between the goals of the feature change and Uber’s goals. We can assume that an increase in price-sensitive riders will increase the overall market share of Uber while also helping them increase customer satisfaction when wait times are long.

Data analysis

Now that we’ve defined the context of the problem and how the feature might work, we now have to dig into the data to understand what pieces of data and information we can brainstorm that could prove our hypothesis that this feature is needed and necessary.

The framework would be to go through each feature goal and analyze:

• What data and metrics could we look at that would help us figure out if the goals are aligned with the feature?
• What considerations do we have to make when introducing the feature to our goals?

Acquire more price-sensitive riders

How do we know whether launching this feature will lead to acquiring more price-sensitive riders? One thing we could immediately measure would be the number of riders that open the app, type in a location, and then don’t request the ride due to the price or the estimated wait time. We can define price sensitivity by looking at each user’s average ride request rate completion, given different price thresholds.

Since this metric is dependent on wait times as well, we would probably need to segment wait times into this analysis as well. Let’s assume we keep distance and other geographic metrics constant.

Price	Wait Time	Request Completion Rate
<$10	<2 minutes	90%
$10-20	<2 minutes	80%
$20+	<2 minutes	50%
<$10	2-5 minutes	88%
$10-20	2-5 minutes	78%
…	…	…

Given this analysis, we can then understand how big the portion of price-sensitive users is in our marketplace. We know what proportion of our users we could potentially increase ridership on if we decreased pricing and increased wait times.

If we run this analysis and see that increasing wait times by an average of 10% decreases the request rate by 5%, but a decrease in price by 10% increases the request rate by 15%, then the tradeoff would be worth implementing in terms of a feature change.

Wait times → +10%

Request Rate → -5%

Decrease price → -10%

Request Rate → +15%

We could do this for multiple different prices and wait time thresholds.

Increase rider usage

When riders are price-sensitive or driver supply is low, we can run this same analysis for price sensitivity but change the target metric to accurately reflect this particular goal. In this case, we want to increase rider usage where riders are price-sensitive. This boils down to increasing the number of rides per price-sensitive user, increasing the frequency that users use Uber, and generally increasing the lifetime value of our price-sensitive users as well.

Let’s look at the price-sensitive users that we defined in our previous example. We can imagine that for certain users, there exists a drop-off point from which they don’t use Uber anymore when dealt an extremely high price or an extremely high wait time after making a request.

In either scenario, we want to understand what the retention curves look like for each user in order to launch a feature that can communicate both the decrease in price and an increase in estimated wait time.