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.
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.
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.
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.
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.
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.
Challenges with integration with ML are threefold:
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.
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.
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.
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.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Sanjay Modi discusses his role in leading a website security product portfolio through drastically changing customer needs.
The acronym SDK stands for software development kit. It contains platform-specific tools to run and develop software.
If you think about some of the businesses that market familiarity as a selling point, you actually don’t get negative vibes from them at all.