99 App
Melhorando a experiência de "achados e perdidos" para usuários de ride-share que precisam recuperar um item esquecido no veículo.
Empresa
99 App
Data
Jan 2020
Período
10 dias
Aviso: não tenho relação com a 99. Esse é um desafio de caso que me foi apresentado como um exercício de Gerenciamento de Produto. Todas as decisões, opiniões e projetos são estritamente meus e não são afiliados à 99.
1. Introduction
The frustration of losing something
We’ve all experienced that moment of panic when we realize we’ve left something behind, whether it’s a restaurant, a friend’s house or a cab. In many cases, the lost item tends to be a valuable and/or important one, like a cell phone, wallet or house keys. It’s usually a stressful moment, considering the fear of having the item stolen or misplaced for good.
In 2018 alone, 99 reported* over 160.000 objects were left in their drivers vehicles, a considerable number. But thanks to technology we can develop efficient ways of reducing this number while increasing the rate of items recovered by users.
This document is about how I came up with a solution to help 99 achieve these goals.
2. The Problem
The biggest reason for contacting App 99 is “lost and found”, representing 20% of calls, with transactional NPS (Net Promoter Score) of -30, a very bad experience when compared to other contact reasons. The main forgotten items are cell phones, keys, and wallets.
Problem breakdown
The way I see it, the problem can be broken down into two parts:
-
It has come to our attention that 1/5th of the calls our support line receives is due to items that were forgotten inside a vehicle after a ride. It’s a very high percentage, and it’s consuming a lot of our resources (mostly our support staff’s time and energy).
-
The users are reporting very bad experiences when facing a situation where they forgot an item in a vehicle. Not only that, compared to other experiences they have with 99, it’s one of the worst-performing ones. Bad experiences tend to steer customers away from our product and they are more likely to chose one of our competitors in the future.
For each part I elaborated a statement and a hypothesis for a solution:
Defining jobs-to-be-done
For the purpose of this exercise, I used the Jobs-To-Be-Done framework, focusing on what the customer hopes to accomplish. Considering that other frameworks aim to tackle product development in a much broader sense, the JTBD framework helped me focus on a single task, guiding the development process into a much more focused solution.
3. Exploration & research
Inspecting current solution
As a frequent 99 user, the first thing I did was to put myself in the riders’ position and pretend I had just realized that I left something important in the vehicle after my last ride. At this point, I’m not 100% sure if I left it in the car (perhaps I dropped it or misplaced it somewhere else), but the first step would be to attempt to contact the driver and ask.
After quite a few attempts, I was unable to find a way to contact the driver directly, meaning that the logical next step would be to find a support line (either e-mail or phone) and see if 99 could help me get in touch with the driver.
Check the data
Reviewing analytics of how customers interact with the app and the support channels when trying to deal with the problem of retrieving a forgotten item is important to understand how they go about finding the information without subjective judgments. The objective is to look into the accounts with lost and found support tickets attached to them and find out how did riders behave and navigate through the app in search of information, as well as how long it took them to achieve the first contact with 99*.
*I understand that this type of data might not be available, but it’s important to try and find similar pathways to understanding user behavior in pure metrics format.
Customer comments
Customer Support would be an excellent way of understanding what problems users are facing when trying to retrieve items that were left behind. I’ve decided to check online and see some of the complaints left by users on public websites.
It becomes clear that most of the complainers have had trouble reaching the driver. Either 99’s customer support was ineffective in reaching the driver or the number provided for the customer to reach the driver was outdated. Below are some samples of comments found online:
During this phase, I would also consider conducting user interviews, as well as asking users to perform the given task and observe what decisions they would make with the app in hand.
Competitor analysis
Considering that our users have the choice of selecting between different service providers, it’s a good idea to compare the 99 App with its competitors regarding available features for retrieving lost items.
It’s important to remember that more features in a product do not necessarily mean a positive experience for the user. Just because a competitor’s product has more features, doesn’t mean that it’s intuitive, easy to use or easy to navigate through. Regardless, it’s always helpful to look into how other companies are trying to solve the same problem and learn how we can create an even better experience for our own customers. Having clutter or an unclear path to complete a task could lead to a confusing user journey and, thus, a bad experience. Creating a positive and intuitive experience depends on many other factors, which will be covered during the upcoming phases.
User pain points
Summarizing the research, I have developed the following considerations regarding the 99 App:
-
There is no dedicated option that specifically handles the issue of a lost item;
-
Getting in touch with the company is a valid option, but it’s unclear for the rider what’s the most convenient way to do so;
-
There is no guideline or FAQ on the app that instructs the rider on how to proceed in case of a lost item;
-
There is no web login feature in case the forgotten item is the smartphone that is linked with the account.
Needs & problems
To help guide this process, I established a list of user needs that we should fulfill, as well as problems we might encounter on the way of making that happen.
Goals & challenges
To keep eyes on the prize without losing track of difficulties, I’ve created a list of goals we need to achieve with our solution, as well as challenges that need to be overcome in the process.
4. Solution finding
Features brainstorming & prioritization
Knowing our issues, it was time to brainstorm solutions that would address our users’ needs.
Then, I’ve assigned scores to each one according to value to users vs. feasibility of implementation and created a prioritization matrix to help me establish which ones should be implemented first and which will go to the backlog.
Scores were assigned from a range between 1 and 5 in terms of value and feasibility.
Value: 1 = lower value and 5 = higher value
Effort: 1 = low feasibility and 5 = high feasibility
Total score: value x feasibility
Next release
Future release
Backlog
New process flow
The new process of retrieving a lost item should transfer most of the steps to the user’s hands, giving them more autonomy and independency while greatly reducing the load on 99’s support staff:
User task flow
With the list of features established for the next release, I laid down a simple user flow to accommodate the lost item features into the existing app, considering maximum usability with minimum interference:
5. MVP Execution
After gaining a better understanding of the product scope, I worked based on the user flow previously defined to create the basic structure of the feature screens. Since I was not redesigning the structure of the app, I jumped straight to medium-fidelity designs to gain time.
Wireframes
Working on lower fidelity versions of the screens is a great way to explore how the ideas can be executed and get quick feedback from stakeholders and users. We don’t wanna put too much design effort into something that hasn’t been validated.
Wireflow
Overlaying the wireframes with the task flow, we can have a clearer idea of the intended navigation steps of the feature:
A functional, web-based prototype can be found in the following link:
User notification
Before diving into the “lost and found” feature, Better than recovering a lost item is to not forget about it all! Besides is a simple representation of how riders and drivers can be notified at the end of a ride to remember to pick their stuff:
6. Validating & launching
User testing
Everything we build is for the user, so not testing with real users would be a waste of time. I would ask both riders and other employees to help us test the new features so we are able to identify potential problems or bugs in the release. Different data can be obtained from the tests, such as:
With the necessary data, we analyze it and use it to drive improvements to the next iteration
Stakeholder alignment
Marketing:
•Make sure everyone knows the audience and what we are trying to achieve
•Have a plan ready for distribution and content
•Knows when to act and what is the strategy
Business/Growth:
•Be aware of acquisition and retention strategies
•Maintain alignment with market strategies
•Keep close contact with potential partners
Operations & Support:
•A clear understanding of tutorials & processes to help customers
•Be familiar with questions & responses
•Understanding the internal processes and protocols to be followed
7. Keeping track
Tracking the feature's performance
Once the feature is ready, I would consider a soft launch to gather more data, making sure to request the following information:
Other comments
Process & stakeholders
Developing new products and features is not a solo job, it requires the involvement of a highly skilled team and executive leaders. For each of these steps, different stakeholders need to be involved:
The problem
Exploration & research
Exploration & research
MVP Execution
Validating & launching
Keeping track
Conclusion
This was an enjoyable exercise that gave me a chance to put my skills to practice while learning new things. Even without having access to actual user metrics from the 99 App there are still many assumptions that can be made for the sake of exercising process and decision-making based on facts.
Good products are never actually “finished” and constantly evolve with their customers, so the key to being a good Product Owner is being attentive to the changes and try to stay ahead of the curve, delivering relevant and valuable improvements proactively rather than reactively.
I am looking forward to hearing your feedback, feel free to reach out to me!