Back to resources

Coping Under Pressure

Managing Expectations
Product
Users

30 August, 2021

Punit Bhansali

Punit Bhansali

Senior Product Manager at Atlassian

Punit Bhansali, Senior Product Manager at Atlassian, shares how he tackled traffic conversion that was increasing immensely.

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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Scaling a Team in Two Parts: The Product and Manager

2 August

Viswa Mani Kiran Peddinti, Sr Engineering Manager at Instacart, walks through his experience scaling a team, product and his skills as a leader.

Managing Expectations
Product
Scaling Team
Leadership
Meetings
Viswa Mani Kiran Peddinti

Viswa Mani Kiran Peddinti

Sr Engineering Manager at Instacart

How to Organize, Manage, and Grow Your Team

12 July

Vineet Puranik, Senior Engineering Manager at DocuSign, discusses the impact of roadmaps, organization, and proper management for your teams to procure growth.

Managing Expectations
Delegate
Collaboration
Roadmap
Strategy
Vineet Puranik

Vineet Puranik

Senior Engineering Manager at DocuSign

How to Navigate Your Manager Role at a New Company

1 July

Saikrishna Desaraju, Engineering Manager at Marks & Spencer, draws from his personal experience to advise new managers on thriving in their roles.

Managing Up
Managing Expectations
Leadership
Collaboration
New Manager Of Manager
Changing Company
Saikrishna Desaraju

Saikrishna Desaraju

Engineering Manager at Marks and Spencer

How Product Management Chose Me

23 June

My accidental journey into product management

Product
Personal Growth
New PM
Career Path
Michael Castro

Michael Castro

Sr. Manager, Product Management at Capital One

How Product Marketing Can (and Should) Help Product Development

20 June

Pavel Safarik, Head of Product at ROI Hunter, discusses the frequently overlooked role of product marketing in getting high user adoption rates for your product.

Goal Setting
Product Team
Product
Different Skillsets
Cross-Functional Collaboration
Pavel Safarik

Pavel Safarik

Head of Product at ROI Hunter