In this installment of our Expert Series, Software Development 2.0, we sat down with Udit Gupta, entrepreneur and former Head of Product at Zomato. Udit shares his insights and experiences from building and scaling product teams at Zomato, and there’s tons of lessons. Check out our interview below.
Yes, I had interned at Zomato when I was still in college, and after college I joined them full-time as an iOS engineer. There were about 15 people in the tech team. In 2012, we launched our first in-house iOS app and it was really exciting to be an integral part from inception to the go-to-market.
I had an interesting journey in that I went from leading the app engineering team from the technical perspective, and then moved into a product lead role. At first it was a very steep learning curve for me because, as an engineer, I hadn’t been a part of managing business stakeholders. There was jargon and other concepts I didn't understand all the time, so it was a real baptism by fire for me. That was an especially exciting time for us as a company, because we kicked off the food ordering business around 2015, and I led the product initiative for that.
Given the stage we were at, it was a constant evolution. Also, I was coming in as an engineer and there was no framework for how product management should be - the team was small and we were very much in execution mode and wore many hats. We were working in very fast product iterations, launching big features every two weeks, ensuring that we were continuously delivering value to our hungry customers.
For example, we realized that it was important for the customers that their orders get accepted within seconds by the restaurant. As it is with many food delivery companies, restaurants are traditionally not very tech savvy - at the end of the day, their bread and butter is cooking. To get them used to accepting orders online, we quickly set up an IVR call which would ring every time they received an order. We also made sure that the call was in their native language so that they don't ignore it.
So in true product fashion, we were bobbing and weaving, constantly iterating to see what works, and what doesn’t.
For me, I had to learn more about the people management aspect of product management, given that I hadn’t done that before. I was also dropped into managing business stakeholders, which brought a lot of pressure that I didn’t necessarily feel as an engineer.
At first, I would say yes to all new requests, and quickly realized that there was a prioritization process that needed to be put in place. I would have to work with other departments, such as the customer delight team or the restaurant operations team. Since we had limited resources at the time, I was forced to really make sure we were building the most value we could for our customers and restaurants.
It was quite the balance, and I would regularly meet with the stakeholders to update them on how the engineering team was progressing, and what we were going to do next. From there, I would be the interface for the engineering team to make sure we were all on the same page.
For example, we had a fortnightly meeting with our Founder, so every two weeks were essentially planning the roadmap. After that, every Monday I would do a long planning session with the engineering team. It was vital to give them context on the larger picture, and put the customer first in our discussions. Being a former engineer myself, having that in the context of building was important to understand why we were doing the things we did. I was able to speak that language to the rest of the engineering team.
There were times when it may have been frustrating for the engineering especially when requirements were changing often, and pressures from new features were coming into the mix. In addition, when we didn’t have all the data at our fingertips, and it was sometimes hard to make a call. Plus, sometimes even when we did have some data, it didn’t necessarily pan out the way we expected. As with any form of product management, it’s all part of the gig.
First and foremost, our main company goal was to bring in more orders and market share. India and the surrounding regions were very competitive from a food ordering standpoint, and we were trying to keep our growth up.
As a team, we were trying new initiatives each week, that would help support that growth goal. From there, we could look at the data and be able to capture what was working and what wasn’t. In the midst of the crazy growth, it was vital for us to keep the engineering team excited as we embarked on our mission to bring better food to the people. We were on a rocket ship and were learning at a very fast pace.
Later on, as the product matured and we found product/market fit, we started setting up OKRs for ourselves. The larger goal was still to provide a wonderful user experience and get more orders. Setting up OKRs helped in two ways; First, they made our objectives more actionable and efforts were much more focused. Second, they helped in setting the right context with everyone as the team was expanding very quickly. So it was important for everyone to know why we were doing what we were doing.
The best thing about the app was that we were able to dog food internally - order the food, explore the restaurants in person and understand what it was like to be a Zomato customer. We also had a group of 20 to 25 people who were given a monthly stipend to place orders, send us feedback and give us input on the new features we were working on. Both of those things combined made it easy and fast for us to get feedback on what we were building.
One example of getting customer feedback has been our post order experience. We were dealing with the pain of helping customers understand when their food would arrive, and ultimately it turned into live tracking, but it took us time to build on top of the feedback that was coming in. We were putting the building blocks in place to make that happen, and without understanding what the hangry customers were going through, it would have been difficult to make that happen.
At the time, we wanted to get deeper into the dine-out journey of users, so we initially came up with a “deals” product. But even before it launched, we realized that the deals experience was completely broken with all the terms and conditions built into it. Such a product wouldn't fly. So we did some constraint free thinking and visualized what a 10x experience of a customer at a restaurant would look like. That's how Zomato Gold was born.
The initial traction was crazy - we had something like 25,000 memberships sold in the first 10 hours, which we weren’t expecting. I remember we had to shut down people from getting memberships because the demand was so high, and it was trending on Twitter. In the end, we figured out the user behavior and then doubled down on that.
For me it was really exciting, again coming from an engineering background to now seeing what it’s like to lead a product team through an exciting time of growth (in this case, it was for a completely new product initiative).
When we were bringing in new people, the first line of criteria was are they a lover of Zomato - have they used it, are they fans, can they bring something new to the table. From there, we were looking for people who had the right set of principles, and who could grow into a great product manager.
Because that’s what I had done, coming from an engineering background into a role that led the team from a product/business perspective. We wanted people who were interested and invested in the Zomato mission, and could help us get there. And it often came from places where people didn’t have the product credentials (whether a sales or marketing background), and we believed could fit the mold of what we were looking for in a product leader.
I think product managers are mini-leaders in an organization, so I would like to leave the readers with a quote from Sir Alex Ferguson, the legendary manager of the Manchester United Football Club:
"I slowly came to understand that my job was different. It was to set very high standards. It was to help everyone else believe they could do things that they didn’t think they were capable of. It was to chart a course that had not been pursued before. It was to make everyone understand that the impossible was possible. That's the difference between leadership & management."
In Software Development 2.0, experts in the field of software development share their insights and best practices with the community.
Interested in sharing your experiences? Give us a shout.