How to build products for customers who are very different from you

Product Managers working on consumer products have it easy -- whether you like it or not, you keep getting feedback from your friends and family. You can use your products and be your harshest critic. But how do you build products for customers who are very different from you? Those building B2B or other non-end-consumer products know the challenges of not entirely empathizing with your end customer.

At TaxiForSure, we have a variety of customers -- B2C customers, B2B customers, operators, drivers, call centre staff, operations team, and many more. Below is the methodology we used when building the new version of our driver app. The lessons below should be applicable to a wide range of customers, including B2B. For those who think that this process would be time-consuming and not something you can afford in a fast-paced startup, all of the steps below should take no longer than a few weeks.

Start with the data

Like any good engineer-turned-PM, make sure you 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. Make sure you have a constant reading of the data so you know where the pain points are. This will tell you the painkillers you have to create.

When we examined various data sources at TFS, we found that the common pain points were that the app was too slow, required too many taps, and caused unnecessary screen movements. On the right are screenshots of how the first version of our product looked.

Talk to the customer

Now that you have the painkillers sorted, how do you find out the vitamins you need to build? By talking to the customer, of course. Depending on who your customer is, you will have to use a variety of techniques to cull insights from them -- surveys, emails, phone calls, in-person interviews, focus group discussions, and many other tools are available at your disposal.

In our case, our driver partners come in a wide range of talkativeness and openness, so we had to use 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.

Get in the shoes of the customer

It might not be enough just talking to them; your customers might respond in one way when a friendly Product Manager is asking them for inputs and quite another way when they are using your product in their natural setting. To get the best insights, it is important to get into their shoes and get a feel for how your product actually gets used. This could either be by accompanying them as they go about their daily schedule or by role-playing as your customer.

For us, the best way was to be a driver for a day, use our driver app, and drive customers around. We discovered new insights that helped us understand our customer better and build a better product. You can read more about it on the official TFS blog.

Validate your ideas

Armed with the new insights, you and your designer will come up with a few prototypes. Time to put the ideas through their paces by taking your customers’ inputs. The best way to do this would be after the initial information architecture and wireframes are ready. If you have a couple of approaches that you are considering, this will be a good time to see what your customers think.

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. On the right are some early wireframes of our new product.

Get the early adopters on board

Hopefully, these steps should give you the required inputs to build your product. The result should be something much more than an MVP. Still, a limited roll-out is recommended if your new product / version will be significantly different from the previous one. Keep the initial user list limited to early adopters who will be patient with any gaps and will 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. On the right is what our final product looked like.

Roll out widely. Cross your fingers

Release your product to the entire customer base given the promising results of the pilot. Of course, if news from the pilot is not so good, you will be back to the drawing board. Do keep in mind that 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.

Monitor closely, lather, rinse, and repeat

The story is not over yet. For the first few days after the release, 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!

Satej Sirur heads TFS Labs, the Strategy team at TaxiForSure.Prior to this, he headed Product Management at TaxiForSure and worked in engineering roles at Microsoft and Amazon.

You can follow him on @satej_sirur