Clarifying question
1. What do we mean by scooty sharing business and who is gonna rent their scooty? Users who own a scooter,

Companies willing to rent out a scooter

2. Are we talking about India or any other geography? Assuming India.
3. Who are we? Assuming we are a marketplace connecting supply with demand and charging commission per transaction.
4. Is the app gonna be used across the whole country or any specific region? Across All.
5. Do I need to build app for customer side or scooty owner side? Focus on Customer side
6. By consumer we mean an installable application for either android or IOS right? Yes, Ignore  webapps.

Customer Segmentation
I will now look at customer side.

Need to rent a scooty is generally faced by a traveller in a tourist place,
Other major demand can be in Big cities where commute distance is high. Generally natives own a scooty/bike in an area.

I wanna prioritize Travellers in a tourist place because that market seem to be large enough and their is relatively less competition than metro cities where there are multiple options available for commute like metro/local train/Ride hailing services/buses.

Prioritised User Segment- Tourists.

Tourists can be further segmented- Who have used public transport to reach the destination + who have used their own cars/buses to reach.

Going ahead with tourists who do not have their own vehicle at the tourist spot.

Major goal of a tourist is to enjoy the place and have as great experience as possible by visiting all famous places, enjoying the scenic beauty(if there is).

Customer Journey of a tourist in an offline world will look like

Major Pain Points

1. Discovery of rental services
2. Offline document submission- chances of forgetting
3. Have to pick up from owners location, thus needs to travel to pick it up.
4. Have to drop off and collect documents and money.

Solution:

1. Curate list of all scooty rentals and individual scooty renters along with pricing, vehicle details and time availability.

2. Connect digilocker with the app/ give option to send documents by uploading on the app.

3. Give option of vehicle drop off/pick up from the customers location.
4. Give digital payments option.

Low Fidelity Wireframe

Step 1: Ask clarifying questions to narrow down the scope of the product/question

-Is it going to be a desktop based or mobile based app? (Mobile based)

-Android or IOS(both)

-To begin with will the app be available only at a particular region? (Yes, it’ll be only available for users in NY)

-What kind of scooters are these? (Normal 2 rider-scooters, nothing special)

-Are the scooters new or old? (Both works)

-Any restrictions on the kind of travel the scooter can do? (Only for short distance ride and travel)

-Standalone product or part of an already existing application? (Standalone)

Assumption:

Here we have assumed that the owners of the scooter will also be the driver of the scooter and they will be using this app as a way to earn an extra source of income while travelling.

Individual owners we will be assumed for the scope of this question

Step 2: List down the user groups

Now this kind of application (follows a marketplace type model) and will have both a supply side and demand side

Supply side:

Owners/Drivers

Demand Side:

-Individual tourists: Travelling to explore and checkout new places

– One time travelers/commuters: Travelling either for leisure or business

-Regular commuters: People who have to travel across the city on a daily basis

Step 3: Select/Choose user group and give your reasoning for the same.

For the scope of this question we will go with Individual owners/drivers  on the supply side and tourists on the demand side as our main user groups.

Tourists are generally people who are new to the city and are always looking for cheap means of transport to reach from one place to another, also tourists will be using the app the most and benefiting the most from this app. Hence for this reason we are going with these 2 user groups.

Step 4: List down the user pain-points

Supply Side: Owners/Drivers

1) Don’t know the people who might need a ride and might think it’s not safe

2) Don’t exactly know how to find people/or who are the people who might be interested in a ride

3) Might want to talk to the riders before accepting or declining the request

4) Finding the riders address might be very diffiult

5) Don’t want to go all the way to the rider’s address only to find that the rider was a no-show

6) Wants to know how much they might get for the ride

Demand side: Tourists

1) Want to know who are the drivers that are available close to them?

2)Want to know about the condition and details of the bike before getting on the ride?

3) Want to know whether its safe or not

4) Payment options available and whether payment gateway is safe or not

5) Clarify any doubts or queries before getting on ride

Step 5: Prioritise the user pain-points based on criterias like: Impact to end user, Impact to business value

Supply Side

Demand Side

Firstly, we have to better understnd the problem.

C: What is meant by scooter? Is it a bike-scooter or gas-scooter?

I: Lets assume it is a bike scooter (non gas).

C: Okay, What type of app we want? Native/Hybrid or Web app?

I: We are looking at a Hybrid app.

C: Okay.

Following main user groups come to the mind for a bike sharing app business:

 Demand Side:

1. Tourists
2. Students
3. Working professionals

Supply Side:

1. Users who own a scooter
2. Companies willing to rent out a scooter

I will focus on the students from the demand side and both users from the supply side. My solution can be scaled to other user groups as well with slight modifications.

Now, let evaluate the User Needs.

On the demand side, i will prioritise User Needs numbered 1-4, 7. Needs numbered 5,6,8,9 can be taken up for later releases as they are not necessary in the MVP from a usability perspective.

On the suppply side, i will prioritise User Needs numbered 1-4. Needs numbered 5,6 are not necessary for the MVP.

So, the solutions above tell the basic flow of the App.

One important part is pricing of the ride. This can be done on a demand and supply basis like Uber with occasional surge or it can be that sellers bid for the same.

As the ticket size is small, sellers probably won’t devote time in bidding, hence Uber like pricing model works best.

Metrics that we are going to evaluate

My take on this Google product design PM interview question:

I would like to know
1. which scooter are we talking about (Ans – a)
a. 2 person scooter so that the owner/driver can offer the vacant seat to a rider
b. 1 person electric scooter that can be shared/rented to people by the owner.
2. Do we need a mobile or desktop application ? (Ans – Mobile)

Confirming that the business model is that the app connects owner/driver with riders so that they can scooter-pool together. For the initial design, I am assuming that the driver of the scooter is the owner as this would reduce complexity in design. Also, I believe we are not focusing on monetization for the business as of now. However, I will address the payment issues between driver and rider (Ans – yes to all)

Having understood the business, I will come up with personas, find their needs, build user stories, create solutions and evaluate them to create an MVP.
There are 3 Personas for our application
1. Driver
2. Rider
3. Customer Support who can remotely access application to help user resolve any issue

I will focus on Driver because other 2 do not matter if we cannot get Driver on-board first. This is the same reason why uber first on-boarded drivers and then opened it to riders.

Driver would generally be a person between 18-35 years of age who needs extra cash and can adjust with a stranger on a scooter for a ride to increase his/her income. I believe people 35 years are more likely to earn decent in comparison to the extra money they get by sharing their scooter. Of course, there can be people outside this range but I believe majority of drivers will be in this range. Few of the needs of drivers would be
1. Finding and confirming riders
2. Deciding a pickup point
3. Estimated fare
4. Payment and ride completion confirmation
5. Security
6. Hygiene

Since we are focusing on MVP, I will build the most needed features which are 1, 3, and 4. So my user stories are
1. As an owner, I want to find riders and send them a confirmation so that I can start my ride
2. As an owner, I want to know the fare I will get so that I can decide whether it is meaningful for me or not
3. As an owner, I want a way to tell the system that I completed the ride and will be paid so that I can drive without any hesitation

Usually I will pick one of these user stories and create solutions to them but since MVP will not be complete without all these 3 user stories, I will create options of solutions for each and select one solution for each user story to build an MVP.

Solution to User Story 1 (US1):
1. Display list of all riders near owner’s location who are interested in going the destination selected by owner. This can have additional details on age, interest etc.
2. Let the owner find a rider by riders’ username
3. Blind Match from nearby riders going to owner’s destination

Solution to US2:
1. Owner decides and sends the fare to rider
2. We estimate the far using a) distance and fuel cost b) data from other rider with same start and end destination
3. Rider decided and sends the far to owner

Solution to US3:
1. Rider send the ride completion confirmation
2. Auto tracking using GPS co-ordinates of both driver and owner
3. For assurance, we can have a) credit card b) create a wallet where rider prepays if ride completes c) insure the payment to driver

I will evaluate solutions in each story on customer impact and ease of implementation (skipping this, fairly simple). After the evaluation, I selected 1 in US1, 2 in US2, 1 and 3a) in US3 for the MVP.