"Uber" case study
This approach should help us analyze Benefits, Risks, and Issues for the potential stakeholders to create a new mobility experience on the market. This is a great case to show how BRIDGeS is applied for complex contexts with multiple stakeholders, who have different needs and risks along with those in common.
We start describing the problem by mentioning Subjects and their Descriptors (Benefits, Issues, Risks, Domain Knowledge, Goals). Our team members should have a deep understanding of the context to have a productive session and generate quality content for the right solution.
This is how the Problem Space should look after the problem description is done:
First, we define all Subjects, which represent stakeholders involved in the context — those who will benefit from the future Solution. The main stakeholders and users of the Uber service are the Passengers and Drivers. Our key stakeholder is the Uber company, which has the intention to identify the problem and resolve it.
We can diversify Subjects and go as deep into segmenting as a particular case requires - by geography, specific features, interests, etc. In this showcase, we will stick to three Subjects: Passengers, Drivers, and Uber Company.
Each Subject is analyzed through Descriptors. We focus on the needs and current experience of the Passengers and Drivers. However, the main goals originate from the business, so we should also add some input about the company itself.
Here we mention the existing problems that result in a bad experience for the passengers:
- Clunky ordering experience: raising one’s hand in the street or waiting on the line with a call center is far from being a great experience;
- Price prediction: some taxis have counters, but you still struggle to guess the total price at the moment of your departure;
- Price negotiation: you never know what the end price is;
- Call center communications: staying on the line sometimes seems to last forever;
- Rush hour busyness: in the rush hour, the prices go up, and a car is hard to find;
- Precise meeting point: knowing the exact address can be rather challenging and still does not guarantee that a driver finds you.
Here we look for the potential needs of the passengers. What value can they get from the future Solution?
- Predict time to destination point: a passenger does not know the route a driver will take or the traffic situation;
- Predict the time of taxi arrival: operator can tell the approximate time of arrival, but one cannot predict it for sure;
- Simple tip experience: difficulty finding cash for the tip; weird and outdated card readers;
- Simple cancelation process: operator is hard to contact; slow operators;
- Driver-Passenger communication: sometimes the call is not the best option;
- Fair price, prices may be too high or variable based on distance and trip time;
- Flawless payment process: need to prevent delays at the destination point.
Potential issues that passengers may experience in the future are:
- Personal safety: passengers don't know the driver controlling the car, and drivers never know the passenger getting in the car;
- Cash payments: neither drivers nor passengers know how much the fare will cost until the trip is done, so passengers might not be carrying the right amount of cash and drivers might not have appropriate change.
- Getting a taxi licence: not all drivers have appropriate licences, especially if being an Uber driver is not their primary job. It takes time and effort to obtain the licence;
- Not enough rides while on duty: drivers never know how successful a day will be and how much money they'll earn in a shift.
- Easy to join the service: drivers can register with minimal paperwork;
- Quick money: some people consider ride-sharing as a temporary source of income while searching for a permanent job;
- Car provided by a company: if drivers don't own a car, they can still drive a taxi;
- Additional income source: drivers can earn extra money in addition to their primary job by working evenings or weekends.
Now that we have mentioned all Subjects and Descriptors, it’s time to set the proper focus for our further steps. We should prioritize all Risks, Issues, and Benefits in the Problem Space and set aside non-essential tasks. Applying MoSCoW prioritization technique, we simply go through each Benefit, Risk, and Issue and tag them with the relevant markers, defining what Must, Should, Could, or Won’t be done.
The descriptor type doesn’t influence the priority - a Benefit, for example, can still be of higher importance than an Issue or Risk. What does the “time prediction” feature matter to passengers? Considering the main reason passengers call a taxi is to get to their destination on time, having a feature to predict the length of their trip is a Must. Price negotiation is something that needs to be improved, but it’s less critical since it does not influence the choice to get a taxi. We mark the Price negotiation as Could.
The same way we mark each Benefit, Risk, and Issue for other Subjects in our Problem Space.
Now that everything is beautifully set up in the Problem Space, we are ready to head to our Solution Space and start brainstorming potential high-level solutions to address all prioritized Benefits, Risks, and Issues.
An app might be a solution to the issues, considering the needs of the passengers, drivers, and the business itself. Since these are different platforms, and audiences with different needs and goals, we can make separate mobile applications for passengers and drivers, a universal mobile app for both, or a web app.
We place the cards with our high-level Solutions on the board in the Solution Space. According to the BRIDGeS color-coding, these are big blue cards.
This is where the magic happens. Now that we have several high-level solutions, we split them into smaller semantical blocks, classified as epics and nested tasks.
We go through the Benefits, Risks, and Issues for the passengers and drivers in the Problem Space and cover each with "epics" or "tasks" in the Solution Space.
Considering all mentioned descriptors, we define the following epics: “Ride”, “Payment”, “Communications", “Security” and “Account”. Now color coding is different - each epic and its tasks should have its own color.
Then we depict our epics through the small tasks referring to the features an app should have. E.g.: “clunky ordering experience” - “ride request”, “precise meeting point - “map” etc.
Next, we go through each descriptor and make sure it is covered with a relevant task. A single task can cover several benefits, issues, and risks at a time, and vice versa — one descriptor can be addressed with multiple tasks.
Here is how it looks on the board:
It is possible that more Issues, Benefits, and Risks come to mind during the solution ideation process, and we end up adding more cards to the Problem Space. BRIDGeS framework gives flexibility, which allows being more creative.
After all of the epics and tasks are mapped on each and every descriptor, we prioritize them using MoSCoW framework. Often the priority level of the tasks is inherited from the descriptors they cover. However, we might have a situation where one task needs to be completed before the team can tackle another, even if the business value of the first task isn’t high. In that case, the priority goes up.
Now that we have a bunch of ideas, we need to decide where to begin. Our high-level solution, beautifully organized into epics and tasks, is just the beginning of the magic.
Now, we transform the epic stack into a roadmap view. We take epic cards for a colored legend and sequence tasks by priority, all while considering other factors like time of execution, resource availability, etc. With this, our team will be ready for product development in no time.
It looks just as simple as this:
This showcase is designed to show you how the BRIDGeS framework helps create a product. Now you should have a better understanding of its main components and the overall process.