This article is a lightly-edited summary of the conversation between Inbal Shani and Rahul Abhyankar . This conversation was recorded in May 2024 when Inbal was Chief Product Officer of GitHub. She is currently Chief Product Officer of Twilio.
Having led engineering and product teams at Amazon and Microsoft and served as a General Manager for most of her career, Inbal specializes in crafting solutions that maximize customers’ outcomes. Inbal was among the pioneering technologists who applied AI in the lab during her Master's in mechanical engineering. In this conversation, Inbal shares her thoughts on the impact of AI on software development, the mindset of building 0 to 1 products, how to become comfortable moving from an individual contributor to management role, and much more.
You've been at the forefront of lot of waves, early stage with GPS and navigation, then robotics at Amazon. How did you get into these early stage domains and contribute to them?
Inbal: I think it's part of my character. I'm very good in the 0 to 1 as a builder. I like to be in areas that have a lot of ambiguity, that you need to figure out what is it that we're trying to solve and how to think about it. A lot of that comes from my history as an aerospace engineer, and that systems engineering thinking, which is the ability to look into a problem and dissect it, connect the dots and then use that to predict what will be needed, what will the customer need in the future, how this product will look at the end of its development cycle and working backwards from that. So that's where my passion is. All that together keeps on pushing me forward to dive into these new ventures, new world of innovation.
Were there some defining moments that built your philosophy around 0 to 1 and just building that ability to look around corners?
Inbal: I think it's the engineering instincts that I have developed throughout my career, and it comes from the fact that I was never afraid to try something new.
I spent the first five years of my careers as an applied scientist in the aerospace industry and then started taking additional responsibilities, also managing software and managing hardware, and then taking on the systems engineering, which is basically product management in aerospace.
So I continued stretching myself, putting more tools, more skills in my toolbox, and then doing the same, going to the automotive industry, then going to Amazon and then Microsoft. Someone asked me what is the weirdest role that you ever played in your career? And I said I worked for customer service and I developed solutions that helped customers self-serve.
And people looking into my history and my experience were like why did you do that? Like what pushed you there? Because I said that's a tool that I didn't have in my toolbox. That's a skill that I was still missing as a product leader, as an engineering leader. If I never had a chance to work so close to the customer and really understand the experience that they have, then I'm missing that customer obsession.
So building that customer obsession by taking a role in customer service and figuring out how to help customers, that puts another tool in your toolbox. The idea of getting used to feeling uncomfortable and when you feel too comfortable, look for something else, because that means you already know what you're doing and you stop stretching yourself. That was a guiding principle, along with the ability to go all over the stack, solving different problems, thinking about different products, different customers, different markets, that enables me today to be much better in anticipating these corners, figuring out what are the next problems that will show up, when no one else sees that.
This detour with customer service, is that something you sought out actively?
Inbal: Someone asked me, did you plan your career? I say I didn't plan my career, but it didn't just happen. I took deliberate decisions throughout my career. I didn't think that I'll be the CPO of GitHub, but the decisions that I took throughout my career, identifying what are the skills that I want to add to my toolbox, what are the things that I want to learn more, that I want to be better at that. These are the criteria that I use in order to take decisions on the roles that I've played. Did I think that I will be forever in customer service? I didn't know at that time. Every role that I'm doing, I'm assuming that I'm going to do it until I don't feel that I add any more value at that point and I need to go and find a different adventure. That was my philosophy when I built my career.
You were doing software development in robotics at Amazon. Then you went to Microsoft and came back to Amazon as a General Manager. So that was a jump. How did that jump happen and what enabled it?
Inbal: The title of General Manager in AWS represents a multidisciplinary function that is managing both engineering and product and has P&L responsibility. Looking throughout my career, more or less since my first management role, I've been doing these multidisciplinary roles. When I was in the aerospace industry, I built navigation systems and I was responsible for the software, hardware, sensors, design of the systems, product management. So I played a General Manager role throughout my career and AWS was the first time that I had the formal title that represents that multidisciplinary function.
The big jump for me in going to AWS was enhancing my understanding in cloud and cloud development and really figuring out how to scale compute in the cloud and figure out what it means to enable businesses to run on the cloud or going through a cloud transformation at that scale.
A different thinking and a different skill in my toolbox is asking "what does that mean?" My time in AWS enabled me to be now the CPO for GitHub, because I've had a chance to work with so many developers throughout my career. I understand the variety of the developers that are using GitHub as a platform which makes me think about "what does that mean" as developer experience, and how we build these platforms for all these developers that have very different needs.
I've heard you talk about the metrics that GitHub enhances. One of those metrics that you've mentioned is developer fulfillment. How do you measure that? How do you measure fulfillment?
Inbal: That's an excellent question. It's really hard to measure developer fulfillment. There are input goals and output goals. Developer fulfillment is an output goal. We've done developer experience research recently. Developers said they feel fulfilled when they have effective collaboration, when they feel that they're more productive, when they're getting recognition from their leadership on the work that they have done and they get acknowledgement for the decisions that they are taking.
When we look into how do we measure fulfillment is what are these set of metrics that we can measure as an input that will eventually result in a developer happiness? So we're focusing on making developers much more productive, if it's with Copilot or if it's with projects and issues, with actions, everything that we can across the software development lifecycle making developers more productive.
GitHub today is the largest platform in the world to lead collaboration between developers. We have more than 100 million users, on the one platform that is GitHub. And then the third one is because you're running everything on GitHub, you can measure the developer productivity, you can see the collaboration, you can see the decisions, you can see the thought process. So a developer will get much more appreciation from their leadership on the thought process because it's all in one system and when you aggregate all these metrics together you're getting that eventual developer fulfillment and their enjoyment and a lot of that.
Developers want to figure out that they focus on the things that matter. So if we're enabling to focus on the things that matter to them, the things that drive impact, and less on the infrastructure that they run their code, or less on writing code maybe that is repetitive then automatically we're making them more productive, hence we're making them more happy.
Is there a corresponding way to think about product manager fulfillment, and is that how you're looking at the PM organization that you lead?
Inbal: PMs want to solve impactful problems. They want to make sure that they're delivering impact. When they're thinking about a product, when they're thinking about a solution for customers, they want to make sure that they have captured that entire space of the existing problem, but also the future problem. That's where product management magic happens. They are venturing into these unknown areas. They're trying to figure out what is the next thing. They need to go and innovate on behalf of the customer.
So, product managers wear so many hats. They need to think like a developer. They need to think like a customer. They need to think like a project manager. They need to think like a CTO that is taking a decision. They need to think like a CIO that is maybe taking a buying decision, or like a CISO that is looking into a platform for security.
So that's the uniqueness about a product leader. They have to represent all the segments of customers that the problem they're trying to solve exists. And then they need to have that creative mindset and the ability to look around corners and ask what is the end result that they're trying to achieve? The biggest satisfaction for a product manager is when they are able to capture that space, when they're able to make something that eventually will lead to a product and that product will deliver value to the customers and they'll see the customer adoption. They will hear the customer reviews. They will see they are meeting the goals that they have set up for themselves and sometimes exceeding. That's the biggest fulfillment for a product leader.
I've heard you say that you wanted to be your own worst customer. What do you mean by that?
Inbal: I always try to think what is the customer that will struggle the most using our product and where will they struggle. I am trying to predict that when I'm thinking about a product, when my team is thinking about a product, is always having that customer chair in the room when we're having a product discussion or product design, what will that customer that maybe don't understand anything in AI and we put in front of them a code completion or a Copilot how will they feel? Will they know how to use it? Will they know to understand the value that is coming from that? What are the set of questions that a customer will ask us? Will that customer will be willing to pay for that solution?
If they were in the room with us taking a decision when we're doing a feature, when we're doing a capability, when we're thinking about a new product, will that customer our worst customer will they sit in the room and say, yeah, I understand the value of what you guys are doing. I see how I can use it, I see where is the documentation that I need to find in order to onboard to your product. So to me that's the worst customer. Is that the customer that we need to figure out how to position the value in a way that they really understand it, and maybe the customer that will struggle the most to use our product and see how do we make our product usable for that customer.
Inbal shares more insights in the full conversation:
- What customer obsession really means and how you build it
- Putting the Amazon leadership principle of Customer Obsession into practice
- Becoming comfortable with moving into people management roles
- Putting yourself in situations that stretch you
- Defining the mission for the organization
You can watch it below on YouTube and also listen on Apple Podcasts and Spotify.
