How to build products for customers who are very different from us
Lessons from building a driver app for TaxiForSure, India’s second largest cab aggregator
Product managers working on consumer products have it easy. Whether we like it or not, we keep getting feedback from friends and family. We can use our products and be our own harshest critic. But how do we build products for customers who are very different from us? Those building B2B or other non-consumer products know the challenges of not fully understanding or empathising with the customer. At TaxiForSure, we had a variety of customers — B2C, B2B, cab operators, driver partners, call centre staff, operations team, and many more.
Below is the methodology we used when building the new version of the TaxiForSure driver app. The lessons below should be applicable to a wide range of customers, including B2B. These steps should take no longer than a few weeks, so this is absolutely something that can be done in fast-paced startups.
The steps we followed were:-
Start with the data
Talk to customers
Get in the customer’s shoes
Validate ideas
Win over the early adopters
Roll out widely
Monitor closely, lather, rinse, and repeat
1. Start with the data
Like any good engineer-turned-PM, we should start with the data. Data by no means is restricted to analytics tools like Localytics or Google Analytics. It is stored in various silos — logs, customer support queries, feedback, crash reports, and more. We need to have a constant reading of the data so we know where the pain points are. This will tell us the painkillers we have to create.
When we examined various data sources, we found that the common pain points were that the app was too slow, required too many taps, and caused unnecessary screen movements.
2. Talk to customers
After figuring out the painkillers, how do we find the vitamins we need to build? By talking to the customer, of course. Depending on who the customer is, we can use a variety of techniques to cull insights from them — surveys, emails, phone calls, in-person interviews, focus group discussions, ….
TaxiForSure’s driver partners had wide range of talkativeness and openness, so we used a combination of phone conversations and in-person meetings to figure out the painkillers and vitamins that they were looking for. We discovered that the app was confusing for new users and was missing few key pieces of information.
3. Get in the customer’s shoes
It might not be enough just talking to customers. They might respond in one way when a friendly Product Manager is asking their inputs and quite another way when they are using a product in their daily routine. To get the best insights, it is important to get into their shoes and get a feel for how the product actually gets used. This could either be by observing customers as they go about their daily schedule or by role-playing as the customer.
At TaxiForSure, we had sat behind numerous drivers during trips and observed their usage, delights, and frustrations. I wanted to get a deeper understanding and registered as a driver and drove around customers for a day. This experience helped us discover a few insights that would never have shown up in interviews.
4. Validate ideas
Create a few prototypes armed with the insights from data and customer interactions. Put the ideas through their paces by taking customers’ inputs. The best way to do this would be after the initial information architecture and wireframes are ready. If there are multiple approaches, this is a good time to see what customers think of each.
We printed out our initial wireframes on paper and shared them with drivers in a couple of cities. We observed their usage pattern and asked them detailed questions about the individual screens and flows.
5. Win over the early adopters
Hopefully, these steps should give the required inputs to build the product. The result should be something much more than an MVP. Still, a limited roll-out is recommended if the new product / version will be significantly different from the previous one. It is recommended to keep limit the initial user list to early adopters who will be patient with any gaps and share both good and bad feedback openly.
We did our pilot for 10–20 drivers in Bangalore, Chennai, and Delhi. This helped us get feedback from drivers of very different profiles.
6. Roll out widely
This step is the launch of the product to the entire customer base given the promising results of the pilot. Of course, if news from the pilot is not so good, we need to go back to the drawing board. A strong pilot does not suggest a successful run in a wider roll-out (Lost, anyone?).
Luckily for us, the wide roll-out was smooth and we continued to see good feedback from all our driver partners.
7. Monitor closely, lather, rinse, and repeat
The story is not over yet. For the first few days after the release, we should keep a close eye on key metrics and see how they trend. They should at least be better than the previous release. Once the new product is stable, it is time to start thinking of the next version. Ah, the life of a Product Manager!
Last updated
Was this helpful?