Enabling Rural Coverage

Problem

It might sound strange, but I was unaware that I was in product management during my first ever gig about 11 years ago. To begin with, it was a very casual responsibility assigned to me by my management as a project. Years later, when product management became more popular in India, I started comprehending more. To paint the little picture, I joined my new job and met my senior management. They handed me the project and gave me a timeline of around 3 months. What was expected of me was to make the product a huge success.

The project was a one-liner description that mentioned what the product was to do. The product was a mobile application for the salesforce of the multinational company I was working with. The goal was to push the sales of their consumer goods to rural retail. I was given a remote rural town of about 60,000 people, where they reached during that time. However, the way the business used to function was very manual and oversight-based. The sales supervisors would have to visit the site and oversee the sales in person manually.

That was how it started, and it took me on an incredible journey because I was clueless — I did not know where to get started, nor did I have any formal product training or experience. I was armed with my logic and a good sense of judgment with which I set forth. The mobile phone used was not a smartphone but instead a Nokia palm phone with a smaller screen. We had to figure out what sold the most out of the 1600 products. It was a complicated problem from both a technical and logical standpoint. On top of that, I was working independently, without forming a team in the beginning.

Actions taken

Since I was working with the business side of the people to discuss the logistics of rolling out the devices, I started building the mock designs by myself. We were funding 50 percent of the cost of the mobile phones for the pilot project, which was about 120 phones on the ground. There was no structure to the problem or the solutions, nor the team.

I started producing long, descriptive documents about how the product would function with low-key UI designs. Furthermore, I started discussing my ideas with other teams to be taken into good shape. After that, the development started, and we anticipated some of the results that would happen on the ground once the rollouts began to occur. I was always looking for ways, identifying the steps to take when something would go wrong. Were there any tools at the disposal to solve any on-call problems, or was I on the right track?

Luckily, I anticipated some of the consequences and put some of the toolings in place. Although it was slightly rudimentary, the good news was that it worked. I still remember my train journey from Delhi to Saharanpur; the memories gleam about me solving emergency app problems. I was helping the grounds people to work on specific functions while I was logged into the company server, making some changes to make everything work.

Long story short, I worked on the analytics, tracking, monitoring, and tooling for enabling long-distance monitoring of the project. This helped me to publish the matrix and GPA. More importantly, I created the product spec, product mockups and worked with the developers all by myself to finally roll it out. Once the rollout started, I worked with the operations team to create the training material. In the end, I delivered the objectives in front of the operations team to keep insight into what was happening inside.

I broke down all the barriers to organizational communication etiquette. I gave the operations team my mobile phone number to contact me at the slightest inconvenience caused by the app. Besides, I gave the senior management visibility on the day-to-day progress of the project.

During the early phases, I experienced immense stress for the project as I did not work on the stakeholder alignment. For that reason, I had a conception of what we needed to do, while the senior management did not. By the time we formally scheduled our updates, we realized that there were many discrepancies for which the senior management had to step in. We had to organize 8-hour long workshops to answer the unanswered questions.

We cultivated a team and envisaged its structure. Throughout the team, we delegated effectively, which resulted in a very supervised and organized rollout. Sometimes, it became an 18-hour workday for me for about 6 weeks. I would lie if I say that it felt great to work such long hours, but it was worth it. I set the ball rolling, and then after 6 months, I left the project while the teams instituted to carry it daily.

That was my first ever product gig, which was almost like a startup. Practically, there were no people or teams designated for different responsibilities, but I stepped in. I knew the way to get things done and how to approach it more smartly. And, in cases where the puzzles did not match, I figured out how to do it, and then I paved my way. In all honesty, it was a lot about my observation and sense of analyzing and recalling my surroundings.

Lessons learned

• Make sure that your job description aligns with the company goals. It allows one to make informed decisions that clearly outline what they are supposed to do. I was empowered to take over a number of responsibilities, but due to me not knowing about it, I could not assign a job code number in hindsight.
• To be a great leader, you need to learn how to delegate and whom to do so. As an independent worker you might start communicating and train more people.
• Pay attention to how the senior management perceives the work that you are doing. Always try to be as transparent as you can with your communication etiquettes as it would help them ensure that employer expectations are fulfilled.