Coping Under Pressure

Problem

Beginning my product management journey at a women’s e-commerce fashion portal was interesting. To start with, I was voted for multiple departments that have worked with operations. Hence, automatically I found myself working with designer stylists, marketing teams and various other departments. Moving forward, I figured out that it would be a great idea to proceed things from the product side of the area. In that case, we would need to develop the whole website from scratch.

That was when I took everything in my hands — I moved into building up a mobile landscape. Generally, the mobility is in the limited image of the desktop website, which was already existent in our platform. Later, to my understanding, I found that the mobile website did not function in the same way as the desktop one. As soon as we started working on it, we understood that we needed to make the website on a different scale on the server’s side.

In India, we were faced with a number of technical issues. The internet speed was not as fast, so we could not build anything that took a lot of bandwidth. Therefore, we were not able to pull off most of the features, while plenty of users were coming on mobile websites. Also, the users were not signed-in users either. On top of that, we did not have any personalization history, which restricted us from creating something suitable for an app or the website.

This is how we made it through, quick and smart, while overcoming the challenges:

Actions taken

We went through the A/B testing and concluded that testing wholly broke the experience on various browsers. This could not stop us; we built a minor feature for Google Chrome that covered up almost for all of it. However, there are plenty of browsers today, and not everyone is not using Google Chrome. Furthermore, the JavaScript was also not working. Subsequently, we missed our deadline, and the big thing was that the mobile website did not work online — a huge loss in revenue and marketing.

At the same time, we did not want to launch something that gave us a secondary experience. We tried to throw a complete package of robust expertise on all the platforms. As we were creating it for the first time, we tested it with a mirror version of the desktop website. We figured it out, examined it, and gave it to a lot of people for prototyping. We wanted to treat this working experience as an office environment. When people went to their homes and started using it with the mobile network, we realized that it was working but at a prolonged speed.

I was trying to commute the chat, but the signal was not great. It was not loading; it was taking too much time. Our primary user was in tier two and tier three cities. We did not want to go ahead with the mirror image, and we wanted to build something that users can adapt quickly. The earlier version was only functional, so we needed to launch something good.

I used to monitor the traffic and see where it came from. As of the sources, 80% of the traffic was coming from Chrome. To make it suitable for Chrome, I looked at all the metrics, and I figured out the conversion of the traffic. Although it was 80%, after the conversion it was 1% or 2%. When I looked at the other traffic coming from the other devices, it was around 12%, but the conversion for those servers was about 5%.

It was five times more than was coming from chrome. When I looked at it from the business perspective or user perspective, I found out that the users were much more engaging in these platforms. In chrome, there were many paid users coming, and we were looking to fund the products. These were the products found on our website, and these were the organic users, and they had a high intent to purchase that way.

Lessons learned

• When you build up a PRD or a requirement doc, keep in mind the assumptions and validate all those assumptions. For example, what our beliefs were and whether it was valid or not etc. It requires a lot of attention, then things we thought as a user for ourselves will work for us. You will never know what can work for the user, how the user perceives it, how they look at it, and their behaviour and experience. Never make a lot of assumptions. If you do it, validate it with the user. Do not give it to any specific kind of sample because only developers are working on it, and give it to a diverse population, and they will come out with their problems. Putting it up where suitable, the Internet would work on everyone, and everyone will have a 4G connection. These are the assumptions we took earlier, but it backfired. Thereafter we learned how you would like it to be a good product manager.
• Put yourself as the actual user of the product. The existing user of the product is someone, which is out there all the time, and whatever happens, it will take you to prototype it and then test it with the population there. If you have any decision, always try to validate it using B testing. There are tools that you can do a B testing or build a prototype, and you can bring in people and focus group discussions or the 1:1 interviews or things like that with an always engaged user at every stage. When you have fulfilled the requirements, validate them with the users. Once you have a minimal skeleton and MVP validated with the user, you must completely legalize it.
• We figured out there were a lot of assumptions. The way we worked, it did not work out that way. We needed to go full proof and plan with different variables and environments and then only move forward. It was gratifying to work on big projects, but at the same time, there were many challenges which you learn and move ahead.