I joined Zomato with little intention of being a product manager (PM) in December 2016. I joined as a design researcher. But within a few weeks, I was asked to be a PM for Zomato for Business, a product for our restaurant owners. Knowing little to nothing about product management, I sat with the team and asked for help. Together, we’d build Zomato for Business over the next year.
If I were to highlight the key points of the PM journey, it would look like this.
In 2016, I learned what product managers do. And I tried it all. I learned how to write SQL queries, my first spec document, negotiated terms with our legal team, build web prototypes, published the app to the Store, and (tried to) manage stakeholders.
I want to share some lessons from that year. For me it was a period of struggle and growth because I had to become okay with discomfort. Every day, I learned and experimented with new skills.
Understanding
Users come with requests all the time. As per Pareto’s principle, where can we spend 20% of our effort to create 80% impact? Data helped us understand what holes had to be filled. I asked senior PMs to help me frame data questions and I learned how to extract data with SQL and Hive queries. Working with data was a new skill for me. Over time, I combined it with user research to create data stories.
Believing
To build a new feature, you have to believe in its cause. What problem is it solving for the user? Every time we started a new project with solid user research, data, and management support, we built something meaningful and shipped it. When we lacked any of these dimensions, our work was mediocre and results didn’t move the needle. For the team to give me their time and energy, I had to give them a reason to believe.
Following
When we design a feature, each detail adds a development cost. When developers look at mockups, they ask if it can be done an easier way. Deciding on an MVP with developers has been so important. It means shaving off the extra details. Following common design patterns, using iOS and Android guidelines, and using existing frameworks also save time and effort. At the end of the day, we need to ship to see what works and what doesn’t.
Planning
This was a lesson I learned after several repeated mistakes. Too often, we jumped into development before figuring out all use cases. Developers would start coding, realize that many failure cases weren’t met, and the design changed midway. The cost? Time, frustration, poor code architecture. With future projects, I spent more time on mockups and got feedback from developers and other PMs. We didn’t move to code till we felt 90% clarity at the design stage.
Listening
This role exposed me to the top management frequently. Our CEO would ask for a feature to be implemented and gave me a 5 min project brief. Early on, I would leave his office in a mad rush to implement the idea. After a few chaotic, unplanned, half-executed projects, I learned to avoid being hasty. Instead I just listened. I left the room calmly, planned the project, went back to him with questions and potential risks. Even if we started implementation a day later, listening and asking more questions dramatically increased success.
Reciprocating
Team dynamics are a huge part of the product manager role. It includes keeping the spirit of the team alive and inspiring team members to invest in themselves and each other. Our team changed several times over the year and we had to recalibrate our working dynamic each time. Nonetheless, I think a strong team is when everyone is working for the benefit of everyone. I made it a habit to ask how I can help, ensure new graduates had a mentor in the team, and experienced members took more responsibilities.
The product manager role in a tech team is very dynamic. Being in the role helped me observe other PMs in the company who were great at the job. I noticed that a strong product manager is someone who is learning, evolving, and going with the flow. Shit happens - features break, business requirements change, team members get shuffled. But these PMs stay cool, they know things can be solved over time. I think a good PM also absorbs the chaos around the team and shields them from it until needed. Everyone has a request, so it’s the PM’s job to listen, prioritize, say no to the chaos when required.