💡

InsightHunt

Hunt the Insights

I

Inbal Shani

Episode #124

Chief Product Officer

GitHub

📈Growth & Metrics🎯Product Strategy

📝Full Transcript

9,625 words
Inbal Shani (00:00): The user of the AI tools to develop software needs to form a different thinking. You need to start figuring out how are you using these AI tools to help you be successful. And it's no longer just the actual code writing, it's really evolving your thinking to the big picture, to the connected experience, to connected systems, which today we just find it more in the world of more senior developers and less and less in the junior developers. (00:24): The junior developers, when they start, usually we expect them to be able to write simple code. But if now there is an AI system that is helping them writing code, they can spend more time from the get-go understanding the system, understanding the environment that they're building, or understanding that product that they're building, which today they don't have time because they're still learning how to code. Lenny (00:46): Today, my guest is Inbal Shani. Inal is Chief Product Officer at GitHub, formerly a general manager at AWS and at Microsoft, and also a senior software developer on Amazon Robotics. (00:58): In our conversation, we explore the end state of Copilot and AI-based tooling for software engineers, what the future of software development looks like with AI, what's underhyped and overhyped in AI and software development, what metrics the teams look at to understand if Copilot is doing its job, what mistakes teams and companies make jumping into AI, the design philosophy of Copilot, plus what's helped Inbal most become the leader she is today, and also where GitHub is heading as a product and an organization. (01:27): With that, I bring you Inbal Shani after a short word from our sponsors. You fell in love with building products for a reason, but sometimes the day-to-day reality is a little different than you imagined. Instead of dreaming of big ideas, talking to customers, and crafting a strategy, you're drowning in spreadsheets and roadmap updates, and you're spending your days basica...

💡 Key Takeaways

  • 1AI is a 'Copilot', not a pilot; human oversight remains essential for innovation and complex architecture.
  • 2The definition of developer productivity is shifting from 'time saved' to 'Time to Value' and 'Developer Happiness'.
  • 3Testing (unit, integration, security) is the most underhyped opportunity for AI in the software lifecycle.
  • 4Junior developers must evolve from writing simple code to understanding systems and architecture earlier in their careers.
  • 5Product teams should act as 'Customer Zero'—GitHub uses GitHub for everything, including Finance and HR, to validate utility.
  • 6Don't start with 'What do we do with AI?'; start with the friction points in the workflow and apply AI to solve them.
  • 7Future AI architectures will likely be hybrid: General LLMs for broad tasks + Niche Models for specific constraints (e.g., embedded systems).

📚Methodologies (3)

📈 Growth & Metrics

Instead of measuring raw speed, product leaders should measure how quickly a developer realizes value (ships a feature/fixes a bug) and correlate it with qualitative happiness metrics. Efficiency without happiness leads to burnout; speed without quality leads to technical debt.

Core Principles

  • 1.Shift from 'Time Saved' to 'Time to Value': How fast does the task impact the business?
  • 2.Prioritize Developer Happiness: Measure reduction in frustration and cognitive load (e.g., less time digging through legacy code).
  • 3.Quality as a Metric: Incorporate security scans and code retention rates (e.g., 88% of suggested code retained) to ensure speed doesn't degrade quality.
  • +1 more...

"Time is not quantifiable as a success metrics because you can write really bad code really fast."

#"time-to-value#happiness"#metric
View Deep Dive →
🎯 Product Strategy

A rigid dogfooding strategy where the product team serves as the first, most critical customer. At GitHub, this extends beyond engineering to non-technical departments (Legal, HR) using the platform to ensure versatility and usability.

Core Principles

  • 1.Internal Ubiquity: Everyone in the org uses the tool (e.g., Finance communicating via Pull Requests).
  • 2.Extended "Cooking" Time: Nothing ships until it has been used internally for months.
  • 3.Feedback Synergy: Direct lines between internal users and the platform engineering team to iterate rapidly.
  • +1 more...

"If we cannot use them, our customers cannot use them for sure. So nothing is shipped before it spends enough months cooking inside GitHub."

#"customer#zero"#innovation
View Deep Dive →
🎯 Product Strategy

Separating product execution from pure research (GitHub Next) while maintaining tight synergy. This allows exploring 'Horizon 3' ideas (3-5 years out) like Copilot Workspace, while product teams focus on 'Horizon 1' execution.

Core Principles

  • 1.Dedicated Research Bandwidth: Create a specific team (GitHub Next) for 3-5 year thinking, free from quarterly roadmap pressures.
  • 2.Make it Real: Research cannot just write papers; they must build POCs intended for eventual production.
  • 3.Fail Forward: Accept that not every experiment works, but learning is mandatory.
  • +2 more...

"If you try to structure innovation, you're losing that organic spark... GitHub Next's job is to invent the future."

#hybrid#ai-horizon#strategy
View Deep Dive →