 Hey everyone, this is Carlos and the founder and CEO at Product School and today I'm here with Inval Shani who is the Chief Product Officer at GitHub. Welcome Inval. Thank you, Carlos. My pleasure. I'm glad to have you on the show. I know that GitHub is one of those OG companies used by millions of people and also got acquired by Microsoft. We definitely talk more about that journey for the company and for yourself. But before I want to talk about you, even before GitHub, how did you get into product? Oh, well, you go straight in. I have a weird and interesting story. So I actually have my bachelor's degree in aerospace engineering and my master's degree is in mechanical engineering. And when I went through my bachelor's degree, I was really much focusing on their control systems because they said if I'm in the business of building airplanes or other avionics system, I want to build the brain of those systems. So I did my specialization in navigation systems and control systems. And then I spent 12 years in the aerospace industry, started as an applied scientist. You know, my first role was around building and tuning common filters. Even before they were called AI, it was the first algorithms that you needed to tune and get the right weights to really filter the signal and get the actual solution that you wanted. So I was 12 years in the aerospace industry, grew up from being an applied scientist to team lead to a manager, and then started taking more multidisciplinary roles. So I was leading one of the projects to replace avionics systems and really focusing on navigation for helicopters. And I started managing software engineers and hardware engineers and product management. So started playing more of a GM role on end to end. And then I've done that for 12 years. And I got an opportunity to move from the aerospace industry to the automotive industry. I'm originally from Israel, and we have needed to relocate to the Netherlands. So took my husband, three kids, went on a plane and moved to live in Holland. I had a chance to work for TomTom and lead groups that were responsible on location based services and part of guidance. And then Amazon came knocking on my door, because at that time they had these magical project that was called the Firephone. And they wanted me to join Amazon and build Amazon capabilities around location based services and guidance, navigation, everything that comes on the phone is a foundation for mapping. So I joined Amazon, and again, led a multidisciplinary team. And a month after into my job, that project got canceled. So there was an aerospace engineer with expertise in control system navigation system, leading multidisciplinary team playing GM role, with basically nothing to do. And I needed to reinvent myself. So I started looking for different roles in Amazon that were close enough to my domain expertise, but also something that will stretch me. So I stayed in the device organization, and I started doing different roles in kind of device responsible on different devices, and then had a chance to launch Alexa. So that was going back to my roots in AI. And then my last role in Amazon was building an autonomous robot, autonomous delivery robot, I was tapped on the shoulder to go do that. That was a lot of fun. Again, if you're looking throughout my career, my career was always around multidisciplinary roles of both engineering and product. I think the uniqueness that I had was my system thinking coming from being an aerospace engineer. And then I went back to AWS. And this time, I took a role in the cloud. And I was the GM of AWS Elastic Container. So if you think about all the containers, world compute words that are not Kubernetes that AWS has built was there. And then I started talking to GitHub. And if you ask me, okay, so how did you find yourself as a CPO in GitHub and why GitHub? You've heard my story. I've been all over the stack from embedded real time with NLP devices, robots, cloud. And the one common theme that was there is that developers tools are just not good enough. They're not really appealing to all developers. Each one of the developers has a very different need. And someone who built that understanding, I wanted to jump in and help shape that future of developer tools. So let me stop you there because I am fascinated by that moment of like, okay, you're building systems for helicopters, among other things. Then you go into building systems for GPS navigator systems. Then you do the same thing for phones. Yes. The Gorgon is smaller. Helicopter, navigators, phones. Smaller and smaller. So you definitely come from a hardware background. There's been an intersection there between software and hardware. Right. What was that for you? Like, what are the angles for someone who has a strong background in hardware to be able to apply some of that into software? Yeah. So when you think about hardware, then if you think about the device, okay, the device has different layers. There is the hardware layer for sure. And then there is a big stack of software that sits on top of that hardware. And my focus was more on the big stack of software that was sitting on top of the hardware. But really connecting the dots and understanding that the design of the hardware is influencing a lot how software is written. But it's also software is written influencing a lot of the hardware design. So being able to close that loop, that helps you develop that end to end system thinking. So you have to imagine yourself, what will be at the end of the cycle? How do we want to have that product look like, feel like, use like at the end of the cycle? So you can work backwards from that. I want to put a phone at the end of the customer. What are all the things that needs to happen? And that that's the system engineering that I'm talking about. That's like the basic strongest tool that I have in my toolbox as a product leader, because I can see what needs to be at the end of the development cycle. So I can work backwards from what the customer needs right now or in the future to be able to scope that into software requirements, hardware requirements, and so on and so forth. And how would you able to translate some of that system thinking approach in a hardware world where cycles I assume are longer to a software world where those cycles are shorter? The easy parts in the software world is that cheap to learn, like your ability to ship something and iterate much faster, is a faster moving cycle than when you're developing a device or a car or you're developing an avionic system for helicopter. Because their experimentation has to be done a lot before you're shipping something. While when you're moving more towards kind of software as a service, your iteration cycles are much faster, because you can ship a lot of the things and you can iterate much quicker, which is something I was looking for. I was looking to move away from the longer development cycle to something that can deliver impact immediately. And that's what I love about GitHub. But that mentality of the we're quick to innovate, we're quick to ship to learn, we're able to do that experimentation, learn from them and kind of revert. That was an interesting journey for me. And I think it's very interesting for other people thinking about how to get to that sea level suite as a product executive, because there's not just one silver bullet with your story is fascinating, you come from a hardware world systems engineering. But that's not the only path. So in your case, kind of leveraging what you have, would you say that help you now be a CTO and do things that are probably more related to managing people than managing systems? Yeah, I think the ability to learn fast and learn from every role that I've done and add these tools and skills to my toolbox. If you think about system that takes long time to deliver and develop, you have to be very strong on your product opinion, like you need to have a strong working backwards from a customer, you need to know what the end results need to be. And then you set a high bar for the deliverables you want to get because you don't have a lot of these iteration. On the other hand, you have to think a lot about how the system is connecting itself, how the product is connecting itself. So that's that's an interesting tool that I had in my toolbox. And then going to cloud and seeing how basically we're scaling our compute today through the cloud talking to customers, figuring out how digital transformation and the migration from on-prem to the cloud and their needs is important. So I think if I'm summarizing that the ability to have a quick learning and keep an open mind and be I like the Amazon principle to learn and be curious, that's something that is super critical. And I think the second thing is that if you continue being curious, if you continue doing different roles across different places of the stacks or different products, then basically you are continuing to growth your your breadth of I would say technical guts. And you're developing very strong instinct, no matter what the product is, to know if it's going in the right direction or not, what should be the new direction, what should be the vision. And then talking to different customers build that skill set. Obviously, I can imagine you can think of a team or as a system, but obviously when you are talking about humans, they are more complex, right? They have emotions. And that's something I come from an engineering background. And unfortunately, I wasn't trained on on that, those soft skills or some people will call it power skills. Right. I'm curious to know in your experience, how were you able to develop that emotional intelligence and that flexibility to make sure that you are bringing people alone, alone, and they can fully understand that, hey, if something doesn't go according to expectations, you have some wiggle room to to keep them engaged. Yeah, I think that the biggest advice I was ever given when I started being a leader, and that I carry today is the ability to listen. And you always have to listen to people and understand what they're going through, understand what are the challenges they're going through. Because if you want to be able to influence and drive a change, you need to know what makes someone else move. So that's that's the one element. The second, I call it radical candor, right, which is mean you have to be honest, you have to be transparent as a leader, you need to tell your team and focus a lot of the why. It's not, you know, a leadership is not a command and control. It doesn't work like that. Everyone want to feel that they contribute, everyone want to feel they have a voice. So your way to the to take people with you through the journey is generate that clarity. This is where we're going. This is why we're doing here's what I heard from the team. Here's what we've heard from the customers. And here's where we're finding that golden path that basically everyone is marching to the same direction. So keeping being honest, keeping being very clear in the sense of direction while listening to people. So you make sure that they're coming with you on that journey. We had the author of the book radical candor on the podcast. We spend good time talking about difficult conversations and deliver feedback curious in your own experience, especially also coming from Amazon love that leadership leadership principles. How were you able to create your own principles or create an environment, not just for you to have that radical candor with your leaders, but for those leaders to also create and spread that type of culture and candor with the rest of the organization. So I think it's a lot about I believe in a leadership that is show don't tell. So it's a lot about leading by example, and expanding that circle. So it's not just how my leaders see me, but also how the rest of the organization, how the rest of the company see me operate, see me behave, see me in if it's in meetings or in conversations with customers, really creating that here's who I am. Here's how I lead. Here are all the skill set that I have in my toolbox. Here are some of my experience. Here's what I want to learn from you and how are we creating that. So it's a lot about creating these opportunities to showcase your leadership style and then seeing the reaction from people how they're reacting to that and saying, Oh, it's okay to sit in a meeting and give a feedback. It's okay to sit in a meeting and and have a conversation that may be slightly different. It's okay to challenge the station and really again focusing on the show don't tell. I think that's the big one to drive a change. I agree. And then I think creating the right incentives to reward those type of behaviors, type of behaviors along the way. I've seen people being rewarded for actually speaking up or actually pushing back because it's easy to say, okay, do it. Can't talk to me if you have any questions. But sometimes leading by example and saying, Hey, you like, I noticed this, are there any specific questions you have for me? Exactly. Create that momentum sometimes. And I can tell you that my Slack channel is full with people all across GitHub that are sending me feedback or they're sending me a recommendation or they're saying, Hey, we heard you. I'm talking a lot about the flywheel in the company and how you generate the momentum and figure out what is the GitHub flywheel. And I got a lot of recommendation people were actually sitting down and writing a paper that says here is how we think about the GitHub flywheel and they will send it to me and I will respond back and we'll have a conversation. But that enables that change management that's kind of how we're doing things in a more open environment and that you have that ability to to converse with everyone in the company. I see that you join GitHub a year ago, right? Yeah. This is post Microsoft acquisition. Yes. I see here in the news that Microsoft acquired GitHub for 7.5 billion in stock. It's an incredible platform, the largest community for developers. I've already believed in that. What was the status of the product organization when you joined and where it is today? I think that the product organization is a relatively new function to GitHub as a product organization that was always product leaders in GitHub. But as kind of a well founded function, it started in the Microsoft acquisition. Microsoft has a strong culture for product led growth. And after Microsoft acquired GitHub, that culture started penetrating GitHub. So overall, our product team has started more or less I would say four and something years ago. I think GitHub is really a strong advocate of a product led growth mindset. And we see that with the investment that we're doing with product, with growing our product organization, with growing our product marketing, our investment across the board in design and how we're thinking about really working backwards from the customers. That's something that GitHub is now in the journey to. So overall, I think that product continues to grow. We are continue to enhancing our product capabilities. So I want to double down on that because one of the things that I'm also passionate about product led growth and how we can leverage product as a huge growth channel for existing as well as for new users. Microsoft sometimes has been criticized for saying, well, they have a platform, right? So in a way, you put something there and it's pre-installed so people get to use it. Microsoft Teams was the latest one. There was a rumor, a graph where people were talking about looks like it's the example of product led growth and Microsoft Teams is much bigger. And it's also an example of just being there and sometimes kind of pushing from the top. I actually believe that Microsoft has a lot of product growth as well because in a way, this is a collaborative platform and you need to invite other people to do good work. But still Slack is to give you an example. They didn't have that platform, right? They didn't have hardware with this software being installed. So how are you thinking about some of those TLG motions created by GitHub and how can they influence all their products within their broader Microsoft ecosystem? So the way I like to think about product led growth is really focusing on working backwards from the customer. For me, product led growth is the ability to build products that sell themselves. They're so great. They're so easy to use. They're solving exactly what you need from them. And then basically these products are having the ability to grow themselves. You don't need a lot of marketing. You don't need a lot of that because basically these products are doing that. And if I'm talking about a recent GitHub example, Copilot is an amazing example of a product led growth type of a solution because when we launched Copilot, it was the first ever type of that code complete. We started with the individual and then we've upgraded to the business ability to manage Copilot. But if you're looking on Copilot, Copilot is the rocket. It's growing so fast and the developers love it because there is a clear value. There is a clear ease of use. And you see product led growth in its best because it was developed from anticipating the future needs of the customers. So that's how GitHub is operating. It's really focusing on what is the need of the developers. We are a developer company that is built for developers and our goal is to make all developers productive. Now, we are part of a bigger ecosystem because the developer is not a developer, it's part of an organization. He's part of an enterprise. He's part of a business. He's part of a startup. And in order for that to succeed, it's much more than GitHub. So we're doing a lot of better together stories when we're working with Microsoft to influence that developer thinking. So how are we bringing more of that developer thinking to Microsoft? We have a lot of joint venture we are doing with Microsoft. Our security products that we're partnering, if it's the Copilot and Visual Studio, Visual Code that we're doing with them. So there's, you'll see, you'll start seeing more influencing of kind of the developer mindset on Microsoft and how it is operating. And I actually believe that when we talk about product growth, not an either or decision, there can be other motions that are supporting the growth for a product. Having a broader platform is a good thing. That doesn't mean that there can't be a PhD motion just because the product is installed in a platform. Ultimately, users need to love the product. You cannot make an excellent customer experience. And I believe that in this case, GitHub, but also as well as the Microsoft platform, they have the additional advantage to have the reach and having that reach give you an opportunity to eventually create adoption at least at the very beginning. Then you have to earn that trust by the user. One of the moves that I noticed by GitHub was that they eventually decided to make their product, their private repository is free. That is a power move that startups they can do. And I think I'm curious to know from your own experience, are you thinking about pricing as a lever to increase adoption? I see product, I believe in input goals and output goals. I see pricing more of an as an output goal that helped drive the revenue numbers we have in mind that we want to achieve. It's more about when I'm looking into pricing is the value. What is the value that you're getting out of our product? I'll go back to co-pilot, but we can talk also about our security products. Like co-pilot is going to help developers be more productive. And if you think about where developers spend their time today, there is a research show that they spend maybe 25% of their time writing code. All the rest is going to meetings, waiting on hardware, waiting on build, collaboration, whatever. So 25% of their time is only spent on writing code. When we brought co-pilot to the market was, okay, how can we make that 25% of their time much more productive? So we can save, let's say 35% of your time writing code using co-pilot. And we have stats that shows that 35% of the newly written code historically when we launched co-pilot was written by it, but now it's 60%. So we can make developers more productive. Eventually, that has a price because we're making the existing pool of developers more productive. This means that we're helping companies get their shortened time to value shorter time to market. So we're thinking about pricing through that is what is the value that we're helping and then how are we pricing it in a way to make sense of what are we are helping the companies to achieve. So that's how we're thinking about pricing. That's the lever. It's more I want you to pay fairly for that capability that we're offering you against that value that you're getting out of it. And then I understand that developers are the main or the core user for GitHub and always need to collaborate closely with PMs. So how can PMs also leverage GitHub in order to increase collaboration within your own product? Well, I think we're the best example for that because GitHub uses GitHub. Our product team is using GitHub to develop GitHub. We're using PRs. We're using issues. We're using discussions. We're using projects. We're also using Microsoft tools like Power BI to develop our product. So basically we eat our own dog food. We believe that if we're unable to use our products to run our business then how can we offer it to customers? So that's one element. The second thing is we need to remember that we talked about developers have only 25% of their time writing code and all the rest of their time is going somewhere else. So if we can offer a solution where a developer has a one tool that they can spend most of their time on and they don't need to leave that tool and we can bring all the rest of the personas that are responsible on software development lifecycle into that tool and they can collaborate using that, then basically we made our developers even more effective. And that's why we're investing in things like projects. This is why we're doing all the new AI capabilities that are spread across the platform to attract more than just the developer persona to use GitHub. I heard you talk about AI multiple times and the co-pilot product is not a secret anymore. Everybody's talking about it. But I also heard you talk about how AI is not really that new. Back in the day, I remember when I was a student in computer science I had a class on AI and actually people didn't want to take it. We're in a whole different world right now. So interested in finding practical use cases for people to start seeing value right here right now. Can you share a little bit more about how can someone start using that co-pilot or other AI use cases and kind of get into the motion without having to learn a lot about AI or become super technical? Yeah, I think you mentioned that AI has been here for a very long time. But AI historically was an issue. It was for a specific group of people that knew how to build these algorithms. They knew how to take advantage of AI. You needed to have an advanced degree. You need to be specializing in developing AI. What we're seeing right now is the era of democratizing AI. I sometimes call it the industrial revolution of AI because basically you're making AI something that is much more accessible to everyone. And what does that mean? That means that not everyone needs to know how to build AI capabilities, but basically you're getting the ability to build on top of that. You mentioned Microsoft building platforms. We can think about AI, the LLM model, the open AI model, even co-pilot as that new platform that is AI driven. So now you can start building your application. You can start using AI without the need to know what's going on inside. You don't need to develop the models anymore. They're not widely available for you. So you're starting seeing all these startups that are taking advantage of CHAP capabilities that are fine-tuning it to their needs. Or we see a lot of the companies, for example, using co-pilot to help advance their technology. Or we're seeing a need to help developers handling languages that are kind of disappearing from the world, see developers or cobalt developer, embedded developers that are really struggling, the industry is struggling to find them because that's kind of a very small part of the generation of developers that still exist. So you can take advantage by implying AI on top of that and the code complete, for example, to help achieve these goals for productivity. Let's say for the non-technical user who's being exposed to co-pilot for the first time, what would be some specific examples for that person to start seeing value? I think that CHAP capability is likely the easiest one to start using because you can use CHAP to really ask questions around the code of what has been writing or summarizing a PR or help me explain what is written in this function. I think CHAP is a big one from the aspect of co-pilot but in general in the industry we see CHAP is becoming basically a new language for people to use search. So instead of going to like just a browser and search something you can go to CHAP and you have an interactive kind of a conversation with an entity that enables you to source and get information the way you used to do when we just launched search engines. Yeah and how do you see the relationship of let's say that the PM and a CHAP interface when it's asking about summary for a PRD or a summary for a roadmap. At what point does the PM trust enough to move forward and what are the fine-tuning parts or the tweaks that a PM is expected to do in order to bring that point home? I think what when a PM is using that and is getting a summary the expectation is that they have enough of an instinct to know what from that summary matters and don't matter because you get a summary. Now how do you know that that PR is really representing exactly what you wanted to do so you still need to apply your instincts and your product thinking to be able to look into that summary and highlight what are these areas that as a PM I need to go and double click maybe with my engineering partner I need to ask a question okay you chose that architecture and you've implemented that and that was these reflected is that the right design decision why have you done that or how is that implementation really translating into that use case that I ask you to build so still being able to question the summary you're just going to save you a lot of time into you know debugging code or reading code because you are getting basically the summary of what was implemented and now you can have more dedicated questions on the areas that you care more about. I agree and the other point you made around the AI platform like that layer that is going to allow users to turbo charge their own productivity. I believe we are the early days yes we're all talking about it now but in reality they what they 300 they 600 out of an entire journey ahead of us and the same way I've seen I've seen a similar pattern in cloud when suddenly companies like Microsoft and Amazon and others try to become that default infrastructure for the for the developer for the builder I'm curious to see how AI evolves and when what's going to be the the platform play to empower a whole new generation of builders to build on top without having to worry about all the different technical details. Yeah I agree I think what when we're thinking about AI and GitHub you know the first thing that we have put out there is really focusing on making developers more productive in when they're developing software but we're thinking about AI today as an intrinsic part of our entire platform the entire software development lifecycle from like PR that is summarizing itself to searching a documentation and really showcasing that or how we automate actions in in GitHub advanced security can we automate using AI and detecting all secrets or even auto fixing. So we're thinking about using AI into its full intent across the software development lifecycle and then we also see our partners that are integrating with GitHub taking a similar approach and kind of scaling AI to their different solutions so if we're thinking about like observability tools can you alert on on something that is happening not just expect the developer to look into a dashboard or can we find something that is broken in the tool or broken the test and showcasing you how you should fix that so it's really taking AI to its full intent and its full scope and the ability to take it through the entire software development lifecycle. But I can imagine that your calendar is packed. No so very curious to know what you're curious what you want to learn these days and how you find time for it. That's a good question. Learn how to learn. I think that that will be my my biggest area that I'm spending more time. We talked about how fast the industry is moving how fast the world is changing and in order to continue growing in order to continue growing my skills I have to become a faster and faster learner and figure out what are the areas that I need to continue digging into what are these areas that I need to continue enhancing. What are the new skills that a product manager or product leader will need so it's really for me right now is investing in in terms of learn how to learn and learn how to learn fast. What are some of those areas for you right now? Well AI is for sure number one because I've grown through the AI industry and I've had the chance to play with AI when it was a niche and now in the democratizing of AI I keep on asking myself what's next so what is after LLM you know that's that's an area that I'm very curious about you see there's a lot of trends there is a lot of discussions on the day after I feel we're going through a cycle you know we started with AI being a niche and now AI is democratized and I think that AI democratize will eventually come to how much you can create a general purpose platform and then we're going back we will go back to more combination of niche and democratize it will never go just to a niche but I do expect that there will be more niche implementation so that's one the second thing that I'm really curious about learning is more about the developer experience especially in the in the day after their AI era we are seeing that developers are changing and the skillsets that they need to have are going to be different than if you go today to do a computer science degree then you learn Java you learn Python you learn that and then you learn a little bit of system thinking a little bit about system design but the majority is the languages in the world after AI how much is language is still going to be the thing versus more the system design system architecture optimization of code so that's an area that I'm looking into is like what can we do what can I do as a product leader for GitHub to think about that day after and how can we shake the the new curriculum for developers so these are two areas and then you know in my in my spare time I like to paint and draw so I try to find time to also tune into my artistic side because I'm no longer an engineer and then build love it but thank you so much for your time in math it's been a pleasure to learn from you same here thank you so much for having me