Leader Spotlight: Empowering teams to be independent, with Indranil Chakraborty

---

Indranil Chakraborty is Product Lead at Abbott’s Lingo biowearables group. He previously served as Head of Product at Turing.com, a data science-driven deep jobs platform. He has extensive experience in the technology industry and worked in product management at Google for 14 years, with his last two as Head of Product for the Payments Checkout platform. In 2022, Indranil transitioned from Google to Even and Turing before joining the product organization at Abbott’s Lingo biowearables group.

In our conversation, Indranil explains how the best product managers are the ones who can dig into the trenches when there is a need. He discusses the importance of obsessing over the details and shares examples from his time at Google when these details were instrumental to building successful products. Indranil also talks about his advocacy for having independent teams, i.e., those who learn to do things themselves so as to not become dependent on other parts of the organization.

---

Digging into the trenches

When we spoke earlier, you mentioned that product is often not as well-defined as other functions in an organization, such as frontend development or UX. Could you say more about that?

If you think about the different roles involved in any product development, engineers are actually building in the sense that they’re writing code and building the product. They have a very clear role in terms of what they need to do. Researchers are talking to users and trying to understand them, and designers are designing. If you ask any of them what they do on a day-to-day basis, they’ll have a definitive answer.

If you ask a product manager what their day-to-day role is, they may struggle to answer. It’s not very specific or well-defined. There are days where, as a PM, you are working closely with engineers and designers, in sprints, or you’re trying to figure out what needs to be built.

Or, you’re sitting back and thinking through how we crystallize it into a very clear strategy.

Product is meant for a person who can come in and work with different folks, even starting with customers, to understand the requirements and bring clear insights. They have to distill that into a very clear set of product requirements, which can then be taken by the different teams in building and shaping the products.

Do you find that balancing all these responsibilities is what makes the best product managers?

The best product managers that I’ve seen are the ones who can dig into the trenches when there is a need. They sit with engineering and can speak their language to help them solve the problem. At the same time, take a step back and have a 360-degree view of what the market is like and the high-level product strategy. The ones who can switch back and forth, they’re the ones who are really effective.

Do you feel like there are some companies, maybe based on size or stage, where the product function isn’t that well-defined? Have you seen that in your experience?

I had the good fortune of working at Google for a very long time, more than half my career. There are companies like Google that are very product-driven and their product role is much better defined. There’s a clear definition of the role, and for every level, there’s an expectation of the product manager across multiple dimensions, from strategy to communication to leadership.

I haven’t experienced this personally, but I’ve heard that, at some companies, the product manager just becomes a glue function. They’re sitting in between, say, the business team and the engineering team, and they’re essentially taking business inputs, translating them into requirements documents and PRDs, and then passing them to engineering to be built.

Advocating for teams to be independent

You’ve managed products used by millions, such as the GPay checkout system and the Even mobile app. Could talk a bit about your strategies for scaling without compromising the high quality that people are expecting?

I’ve had the opportunity to build products from the ground up, like when we built up the Cloud IoT product, as well as take a well-established product and then figure out how to scale it. I would say there are three key things.

First, for a product to scale well, it’s super important the metrics are well-defined and that the data foundation — the underlying instrumentation to measure those metrics — is really built. You need a clear set of metrics and the right instrumentation to be able to track those metrics at scale.

Second, once you reach a certain inflection point and you’re scaling up, the temptation is to add more features, but you need to really focus on and obsess over the details. As I was looking at the GPay checkout rollout, we launched financing in a Buy Now Pay Later in Japan. And there’s a difference in customer expectations between Japanese and US customers. We had to tweak the user experience in ways that attuned to the expectations of these Japanese users. You have to really understand what the customer needs are as you scale.

Finally, even when you scale, focus on a few things, but do them really well and iterate fast. It’s important that as you’re scaling, you don’t lose track of the core principles. For example, in GPay, we had three core principles: simple, safe, and fast. Even as we users scaled and we scaled into multiple markets, with every feature we would add, we would tie it to the core principles.

What methods or tools did you use to measure the customer experience as you were scaling? Google had a lot of resources, I’m sure.

Google has the luxury of using a lot of products that are built internally. It was eye-opening for me once I left Google after 14 years and went to startups and smaller other companies. There’s a plethora of third-party tools which you can use. Teams benefit from the underlying infrastructure that Google invested in during the early days.

In some of the companies I joined afterward, I’ve seen product managers say, “I need this data, but I can’t do it myself. I need to wait for the data analyst and ask them instead.” I said, “What do you mean? You should be able to run your own queries on the table.” One thing I found really amazing was that every product manager at Google was empowered to be able to run analysis and not be dependent on other folks to pull the data. Everybody can write SQL, write queries, and pull the data as long as they’re pulling it from the real source of truth. I advocate for that in every team that I work with.

Machine learning and pivoting the roadmap

At Google Cloud, you spearheaded the integration of machine learning and cloud technology. What challenges did you experience integrating machine learning into existing product ecosystems?

Challenges with integration with ML are threefold:

1. The data itself — Do you have the right data? Is it labeled and do you have quality data? Oftentimes in Cloud, we used to have the same issue where customers would come and say, “We have all these telemetry of all the buses that we run. Can we just use that to improve or reduce maintenance for the buses?” And the telemetry data may not be well-structured. So data availability and quality are the first thing
2. Explainability — The challenge with ML is it can make a prediction or a recommendation, but it becomes a black box. You don’t know why that model has recommended one processor versus another. Explaining the rationale behind decisions becomes difficult when you’re using machine learning as a prediction method
3. Cost — Oftentimes, training and running machine learning models are expensive. Is there a real ROI and have you done the cost-benefit analysis?

Is there an example that you could share that illustrates a time when you had to pivot the product roadmap due to changing market conditions?

We had to pivot when I was building up our Cloud IoT platform. Our initial hypothesis was that there’s a huge opportunity in the manufacturing industry because a lot of factories have internet connectivity but use manual processes. We wanted to target that segment and offer a solution to connect their factory equipment to the cloud via our Cloud IoT platform.

When we spoke to a few customers, there was a clear value proposition. They were excited about it. We started down that path and began building the product. Six months into the process, there were a lot of headwinds. There were challenges with data co-location. A lot of these companies don’t want to push all the data into the Cloud, and we were building it as a cloud-native product.

We started thinking about what we should do. Around that time, the car parking industry started investing in connecting parking spots online so that when somebody looks for parking, they can see where spots are available. The scooter and bike ride-sharing industry was taking off. So we pivoted. We said, “Manufacturing is a big market, but there’s a clear need here, and the overall value proposition is much stronger.” Within a few months, we added the functionality to help these parking and ride-sharing companies use our product. Sure enough, we had a bunch of ride-sharing companies adopting our product fast.

‘Repetition doesn’t spoil the prayer’

Earlier, you mentioned that you advocate for your teams to not be dependent on others for things like SQL or data analysis. Are there other traits you look for in candidates when hiring for your team?

When I look for a product person, I look at a few things. One is, is the product person curious? Are they willing to learn? I’ve had product people on my team who were not engineers or PMs before. They’ve transitioned from, let’s say, sales or operations, but they have that willingness to learn fast.

It starts with expectations. If the expectations or attitude of the person is, “I’m just going to talk to customers, write requirements, shove it over the fence, and the rest of the team will pull the data for me,” that product person is not set up for success. They’re dependent. When there’s a need, when you really need to analyze the data and figure out what’s going on with your product, you can’t scale if you’re constantly dependent on somebody else.

Within your team, what’s your approach to keeping everyone motivated and on track?

This ties back to clear ownership. I think a few things are super important. One is that every product person in my team feels very clear ownership of certain metrics that they have to move.

This helps them be more cross-functional. They’re required to think holistically across the entire stack in terms of the user experience. It also motivates the person to go above and beyond.

Second, I focus more on outcome than output. There’s a process that is established. You’re writing requirement documents and PRDs, you’re attending meetings, or you’re convening meetings. All that is good, but what is more important is the outcome that your actions drove.

Lastly, if you’re in a fast-paced environment, there’s a lot of ambiguity. Even the product roadmap is not set in stone. Things are changing constantly. There’s a lot of fluidity. What’s important is that every product person is actually over-communicating to make sure that the team is all on the same page and they’re all moving in the same direction. At Google, one of our product SVPs would say that repetition doesn’t spoil the prayer. If you keep repeating either your product vision or product roadmap and the product status, let’s err more toward over-communication than under-communication.

Finally, do you have techniques that you lean on for mentoring more junior members of the product organization?

I’ve managed product people new to the profession and fresh graduates starting as associate PMs. And the philosophy I usually use is, when you’re starting as a PM in any organization, it’s important that you build credibility with the team. And, similarly to my point earlier about digging into the trenches, the way to build credibility is by digging right in.

Whenever I hire a product person, I have that person go to relevant meetings and sit and take notes and share the notes. This forces them to think about the product and some of the underlying issues and the different areas, and it also immediately adds value to the team. Find an area where you think that there’s either no ownership, the ball’s getting dropped, or there’s a lack of bandwidth. It could be a simple fix or a bug, but dive in. That gets you more assimilated into the team.

Also, work to understand your customer — how they’re using the product, the challenges they’re trying to face, their pain points, etc. If it’s a consumer product, sit in the focus group, talk to consumers, and be involved. That’s where you really can pick up some of those key insights that probably the rest of the team doesn’t have.

The goal of a product person is not to come up with each idea on their own. It’s to collate all these different ideas from different sources and really crystallize them into a few big rocks, as I call them. A few big rocks that can move the needle for the product.