From Robots to AI at Amazon: Sahil Gupta
We speak with Sahil about his journey at Amazon (from robots to Alexa to AI), and the nuances of managing PM teams
Sahil (LinkedIn) has had a stellar career across consulting, investing and product. Here’s what we talked about
(1) Sahil's career path over the past 17 years - roles in consulting, investing, Amazon and moving back to India.
(2) Discussion around product manager roles and the skills or spikes needed, including whether analytics is essential or can be supplemented by strong partners.
(3) Three distinct levels of seniority on the product manager ladder based on scope and responsibilities.
Takeaways
The importance of choosing large and growing trends when picking a career direction. Sahil saw the impact tech was going to have on the world and made a deliberate choice to work in that space.
Amazon is an organisation that gives someone in product a large canvas to work on across multiple types of roles - from core consumer facing product, to robots, AI, and even chips. Sahil’s experience at Amazon spans robotics, Alexa, and AI product.
Sahil stresses the importance of calibrating problem statements to PM skills and setting expectations clearly. This is a key part of a PM leader’s job, and PMs should sometimes take initiative to drive these expectation setting conversations.
A framework to thinking about career growth as a PM.
The How and Why of Moving from Consulting to Tech
Vibhav: Hey Sahil, thanks for taking the time! Let’s start with an introduction? Our readers would love to know how a long career at Amazon looks like.
Sahil: I’m Sahil Gupta, been working for, well, more than 15 years now—I'm trying to do the math—it's a little early in the morning. About 17 years since I graduated from Kharagpur. I spent about nine or ten of those years in the US, and seven of them here in India. I started life in consulting, worked at McKinsey for a couple of years, got an opportunity to be an investor at Blackstone, bought a bunch of companies, deployed a lot of capital. Went to business school on the East Coast, did a lot of introspection on what I wanted to do and what are the things that are important to me, who's was the person I really wanted to become. Because I'd seen a lot of great role models, both at McKinsey and Blackstone and in lives before. I had done my internship at Unilever, H&L. My frequencies seemed to resonate most with folks who were running large organizations. Because those are the skills that I admired and those are the people that I aspired to be. I also got an impression that technology was about to change all of our lives. This was around 2011-2012. The iPhone was about two, three years old, Amazon was quite big, a $100 billion company. And I could see how almost every part of what we were going to do was going to be changed by consumer technology. So, I wanted to join a company that was in that space that promised to teach me how to be a general manager and run large organizations.
Sahil's first product management role focused on improving customer experience and reducing defects at Amazon scale.
So I joined Amazon, that was almost the only job I applied to when I was at Harvard Business School. I applied for them in the summer. Then we decided we wanted to come back to India, so I declined that offer, and I came back and worked for a startup. But then my wife decided that she was going to study as well, so I was free to take it up full-time. We moved to Seattle, I joined as a product manager in the retail team. It was 75% business, 25% engineering focused. At the time, I was deciding policies and helping define products that made the shopping experience better for customers. We focused on how we avoid sending customers the wrong product or misleading a product that was not meeting their needs or was broken on the way. There were a bunch of reasons why customers would return stuff, or they would call up and complain. We were building closed-loop mechanisms to take all of that feedback and improve the customer experience, preventing defects from arriving at the customer's door. At Amazon scale, it all mattered. Even at that time, we were tens of billions of dollars in revenue. Now we have hundreds of billions of dollars in revenue. So those products we built then have all scaled. They've become core to some of the things that we take for granted. If you order something on Amazon, it shows up on time, it's correct, it's what you expect.
Working with Amazon Robotics and scaling from 2000 to 100,000 robots
We had to move to Boston, after a couple of years, my wife was keen on doing her studies. So I worked with Amazon Robotics, it was a company called Kiva that they had acquired - they make fulfillment robots. Pioneering at the time was IoT, right at the beginning, before it became a thing, industrial IoT. It was an inexpensive robot controlled by software, it moved around and eliminated a lot of repetitive human effort and saved money in our fulfillment centers. This was a complex system, which was never truly understood at the time that I joined. So I first led their product analytics team, three or five BIEs, data scientists, who were doing all manners of things. They were doing business analysis and data science, writing white papers on how the system should work, building simulations that would predict what would happen if XYZ happened. I didn't have the technical skills to do some of their modeling work, but I think my business perspective and problem-solving chops allowed me to add value to the team. Then I moved on to run the Solutions team. It was a product configuration or product customization type of organization - we worked out how do you adapt the robots to a fulfillment center. This was overall a 15-20 person team.
When I joined Amazon, we had 2,000 robots in the field. By the time I left Amazon Robotics, we had 100,000 robots. We went from being a fraction of Amazon's fulfillment network to well over 50%. And now, I believe the latest number is somewhere between 300,000 to 400,000 robots. Those systems have scaled tremendously, and every year, the technology has gotten a bit more complex. We built on some of the scaling problems just as we built on some of the initial technology that the founders had developed, which eventually got sold to Amazon.
I got a stint as a chief of staff to a VP, the one who led Amazon Robotics and fulfillment technology—essentially all of the software inside the fulfillment center. It was a product strategy role where I was developing a three-year robotics roadmap, doing strategic planning, thinking through what platforms we should invest in, and evaluating acquisitions. It was a bit of a catch-all for whatever was top of mind for the VP.
From robots to consumers - Growing Alexa Music
After spending about five years building internal facing technologies, I figured I had enough and wanted to dive into something consumer-facing. So I transitioned to working with Alexa, which at the time was going through an inflection point. I led their music customer experience, which encompassed engineering, product, and program management. We built all the features to make it easy for customers to listen to music in any way they wanted, enhancing the service. When I joined, we were in a couple of countries; we grew it to dozens. Initially, we had one or two service providers, like Amazon Music and Spotify, but then we expanded to include others like Apple and Saavn in India. We had to build features and expand our offering so that it was intuitive for people to use, managing multiple products and services.
Orchestrating these different services to deliver a better customer experience was a significant focus. For instance, if a customer said, "Play Bruce Springsteen," we had to determine which service had the right content and which one the person was entitled to use. Often, people wouldn't specify whether they wanted it on Amazon Music or Spotify. But you could be smart about it—if the first request was for Spotify, you would play it on Spotify. If they wanted their favorite station on Pandora, it would play on Pandora. This orchestration played a big role in improving the music experience, significantly enhancing retention and daily active use by making the system more friction-free.
Short stint setting up a US team at OYO, then moving back to India with Amazon.
This stint lasted two to three years. I then had an opportunity to work at OYO. I was invited by Abhinav, OYO’s global COO/CPO, to help set up the US team. This was a short stint; I was there for about eight months before the pandemic hit, and the business took a hit. I decided to take a sabbatical. OYO was fun; it was a combination of product management, revenue management and data science. We built some automated pricing systems, understood the market, came up with a strategy, hired a data science team, and built out a roadmap. But then it was time to move on.
About three and a half years ago, at the end of my sabbatical, we decided we wanted to move back to India. I received offers from Seattle, San Francisco, Singapore, and India. It became clear that this was what we wanted to do. And now at Amazon, I had a new role.
Building data services for foundational models at Amazon
There’s this company called Scale.ai, which is a big service provider to a lot of these foundation model teams, like OpenAI which build foundation models. My current team is like Scale.ai for Amazon, providing human-labeled data at scale. I manage a B2B business where scientists come to me saying, 'I need X thousand people who will do this work.' This data you guys label and send me, I will use to train my models to make them more accurate, less harmful, more informative. When I joined, we were still focused on Alexa, but over the last year and a half, we have pivoted to providing more and more labeled data for foundation models. It's a lot of discovery with customers, understanding their needs. It almost feels like the business changes every six months. It's been a good experience. It started off as a product role with three to five product managers here in India, but over the last three years, it's grown to a couple of hundred people globally, including twenty to twenty-five product managers, among other functions. It's become a GM role. I've just put in my papers to go work for a startup. I'm going to see if what I've learned at Amazon is at all valuable outside. We'll find out, I guess.
Product Managers Need to have a spike in several areas
Vibhav: I think there are a lot of themes we want to touch upon, such as moving back to India, running a large team, managing people, and promotions. A lot of PMs ask, "Should I pivot to become an AI PM? What is an AI PM? What roles are out there? How will this affect the craft?"
Sahil: My experience over four years as an analyst at McKinsey and Blackstone shows that the fundamentals haven't really changed. Yes, the technology has evolved—people are using more models instead of just Excel—but you're essentially using data to tell a story. If you're good with data, you'll have a much better grasp of the business nuances.
Product managers need to have a spike in several areas: analytics, user understanding, design, strategy, engineering, and marketing. You don’t need to master all, but having strengths in a few while being competent in others makes you effective. If you're strong in analytics, it takes the pressure off other disciplines. For example, if you're not as deep on engineering but great with numbers, you balance your team accordingly. For example, I've always found strong engineering partners who could bring my customer experience visions to life without me needing to delve into the technical details.
Mithun: That's an interesting point. In my experience, particularly in India, product managers are expected to have much deeper knowledge across the board compared to in the US. For instance, when I was working on recommender systems at ShareChat, I was expected to know the details of the models, parameters, and backend processes.
Sahil: Yes, the depth required can vary by location. In the US, communication tends to be clearer, and there's better narrative building. In India, technical teams might push back harder, which can overwhelm the less technical PMs. This requires PMs to have more "spikes" or deeper expertise across more areas.
Mithun: Exactly. And sometimes, the technical founders are the ones who can really push back because they have the depth. In our discussions with Shreesh and Sudhanva, we noted that they built their team to scale from day one with engineers who could truly partner in the process.
Sahil: Right. Another important concept for PMs is to pick roles where your "spike" or superpower—something you do exceptionally well, differentiates you compared to your peers. It's not about trying to gain superpowers in areas that don’t come naturally; it's about aligning your role with your strengths. For example, if you excel in user design and empathy, forcing you into a heavily data-centric role won't play to your strengths and will likely make you miserable.
Managing PM Teams: Setting Expectations
Vibhav: How do you manage those who are great at earning trust but may not deliver tangible results?
Sahil: You need to meet certain thresholds. Delivering results is crucial. During the hiring process, we ensure the candidate can demonstrate this ability. If after six months, the results aren't there, it might not be the right fit. Delivering results is also an outcome. Chances are if someone isn’t delivering results, they are not doing enough on some of the inputs. Not diving deep or not taking ownership.
Mithun: Given your experience managing large organizations, how do you approach promotions within a PM org?
Sahil: It's about calibrating the size of the problems given to a PM. It's very visible; success or failure is apparent to all. Giving a PM a problem beyond their capability sets them up for failure. As they flail, they lose stakeholder confidence, which is crucial for influence. Promotion and role assignments should match the PM's capability level, allowing them to grow and succeed without overwhelming them. This careful management helps maintain the balance and ensures the PM can handle progressively larger and more complex problems effectively.
Vibhav: What about setting up PMs for success? How do you calibrate the difficulty of assignments?
Sahil: As leaders, we must set our PMs up for success by assigning problems that match their capabilities. If a PM is given a challenge they can't handle, and they struggle early on, intervention becomes necessary. On the other hand, if you give them a problem that's too easy, they won't grow. Finding that balance is key to helping them build credibility and eventually take on bigger risks confidently. Some vectors that tend to matter when matching PMs with tasks are complexity of stakeholder relationships, seniority of stakeholders, ambiguity, type of problem solving required, their level of interests.
Vibhav: And how should PMs approach promotions?
Sahil: Promotions are about demonstrating capability and potential. PMs should work closely with their managers to set clear expectations for their roles and understand what is required to move to the next level. They should not just expect promotions to happen but actively engage in discussions about their career progression and seek feedback regularly.
Mithun: How do you handle the calibration and setting of expectations?
Sahil: You have to be honest with PMs about their readiness for the next level. Just because they're doing well at their current level doesn't mean they're ready to advance. My encouragement as a manager might be taken differently from my calibration of their overall performance. I might say a piece of work was well done, which it was, but that doesn't necessarily mean they're a top-performing product manager. There’s no substitute for having hard conversations and giving clear, frequent feedback about performance.
A framework to think about PM career growth: Inputs, consistency, and expectation setting
There are three levels of product management that I see. The first one is about solving well-defined features within a clear scope, typically lasting three to six months. This level is all about executing on the defined plan, gathering data, and iterating based on feedback. It's an entry-level, post-MBA kind of role.
Moving up, the next level involves handling broader problem statements without predefined solutions. Here, you are expected to craft roadmaps and achieve business outcomes independently. This involves managing stakeholder communications effectively, tracking progress meticulously, and integrating feedback mechanisms into your process.
At the highest level, which is the Principal Product Manager and above, you're dealing with initiatives that are core to the organization's mission. These could span across multiple products and require thinking years into the future. These roles come with high visibility and significant ambiguity. The problems may not be well-defined, the customer segments might be unclear, and the boundaries are often fuzzy. Your job is to craft a vision from an anecdote or a mere idea, iterate on that vision, and execute a plan that may involve delegating to others as you scale the solution.
Vibhav: How important is luck in a product manager's career? Can a tailwind from a successful product mask deficiencies in a PM's performance, or do people generally recognize the difference between market forces and individual contributions?
Sahil: It's a mix of luck, instinct, and having supportive leadership. In most cases, it's challenging to pin down whether a successful outcome was due to the product manager's skill, another function's excellence, or the simplicity of the problem. However, the quality of work—like document clarity, meeting management, and solid analysis—is noticeable. If you're lacking in these areas, it becomes obvious. Over time, a consistent track record of success helps differentiate a good PM from a great one.
Mithun: What should PMs focus on early to mid-career to ensure they're positioned well for advancement?
Sahil: Early and mid-career PMs should focus on finding the right balance in the challenges they take on—not too easy, but not beyond their capability. They need to consistently deliver high-quality work, manage stakeholder relationships effectively, and communicate well. It’s also crucial for them to align their efforts with organisational expectations and demonstrate the impact through well-defined projects.
Mithun: Finally, how can managers handle situations where a PM might be struggling?
Sahil: The key is early identification. If a staffing mistake is made, it's better to correct it sooner rather than later. If the issue isn't with staffing but perhaps with oversight or stakeholder management, then more frequent check-ins and clearer communication may resolve the issue. Ensuring that PMs are set up for success from the beginning and supporting them through the initial stages of their projects is crucial. Once they start hitting milestones, confidence builds, and the risk decreases significantly.
Often, the failure mode is that PMs don't have a clear understanding of the expectations for the next level. They might deliver a feature well—or even poorly with a lot of support—and then assume they're ready to own a whole product. That's not necessarily true and not necessarily good for them. If given too much responsibility too soon, they might crash and burn, which is worse off. The leveling guide is very useful here. It clearly states the expectations from one level to the next and helps set the criteria for promotion, like demonstrating certain competencies, gaining support from specific people, and producing certain artifacts.
Mithun: It seems there's a gap in proactivity among PMs in India?
Sahil: Yes, many expect promotions and success to happen automatically because that's been their experience during a company's growth phase. But suddenly, when growth slows, you find VPs of Product who can't write a strategy document. They've risen quickly without developing the necessary skills. Product management isn't just about the glamorous parts; it involves a lot of gritty, detailed work that some aren't prepared for.
Vibhav: How do you plan to address these challenges in your new role?
Sahil: I'll be building teams from scratch, including hiring first-time PMs and helping them climb the ladder. Understanding what product management really involves and aligning it with the local context will be crucial. The structure I'm used to at Amazon and the complexity of what I’m planning next will be a significant challenge. It’s about setting the right expectations and providing the necessary structure and support to develop competent PMs.
Mithun: You've already had a taste of the challenges in product management in India?
Sahil: Yes, during a brief experience where I was the customer and not in the product management role, I saw firsthand the discrepancy in standards. Simple questions would cause proposed plans to fall apart, which indicated a fundamental lack of robustness in the product thinking and execution. There's a steep learning curve, and I'm preparing to address these challenges head-on. It’s going to be an interesting journey, adapting my approach to fit the local nuances and elevating the product management practices here.
Mithun: Thanks for time Sahil, and all the best for your new role!
Sahil: Thank you!
Sahil has recently joined murf.ai to lead their product organisation and is hiring PMs with 3-5 years of experience to build the next generation of AI Voice products. Please reach out to him on LinkedIn if you’re interested!
More to Read
Setting expectations - The Product Roadmap with Vickram Saigal