Problem-First AI Adoption
Start from the customer problem and ask where AI helps — never from 'what do we do with AI?'
- Difficulty
- Easy
- Time to result
- ~weeks to results
- Steps
- 4
- Confidence
- 93%
Most companies adopting AI start with the technology and hunt for a use case, which produces bolted-on features nobody uses. Inbal Shani inverts the sequence: name the customer's actual friction, decompose the workflow into tasks, then ask which of those tasks a model can absorb. GitHub Copilot itself came from this order — the problem was that developers spend under 25% of their time coding, not that OpenAI models existed and needed a home.
Origin
Shani's application of Amazon's 'working backwards' method (she was a GM at AWS and an engineer on Amazon Robotics before joining GitHub), carried into GitHub's AI product decisions. She explicitly names it as 'working backwards from the customer problem.'
Core principles
- 01The question is 'what problem are we solving?' not 'what do we do with AI?'
- 02AI is a tool in the toolbox, not the strategy
- 03Find the workflow with heavy manual work or configuration — that is where AI pays
- 04Hype creates a false obligation to ship something AI-shaped; resist it
- 05A tool nobody adopts solved no problem, however impressive the model
How to run it
- 1
State the customer problem without the word AI in it
Write the problem as your customer would say it. GitHub's was: developers have so many tasks piled on them (meetings, builds, legacy code, collaborating with 21 people a week) that they spend under 25% of their time actually writing code.
Pro tip If you cannot write the problem statement without naming a model or a vendor, you do not have a problem statement yet.
- 2
Decompose the workflow into its component tasks
Break the user's day into discrete tasks and mark the ones that are manual, repetitive, or configuration-heavy. Those are the AI-addressable surface.
Pro tip Look specifically for 'I have this workflow and it requires a lot of manual work or a lot of configuration' — Shani's own tell for an AI candidate.
- 3
Ask what would give the user time back, then pick tools
Only now select the technology. GitHub asked how to give developers even half an hour a day back, and that led to incorporating OpenAI models into an in-editor assistant — not the other way round.
Watch out Skipping to tool selection produces 'plastering AI on a lot of things' — Shani's phrase for the failure mode she sees in customer conversations.
- 4
Run a real change-management program, not a tool announcement
Adoption is a change process, not a distribution event. Budget time for enabling, explaining, and supporting the rollout across teams, because the same tool lands differently in different companies.
Watch out 'Companies expect a change to happen magically — here's a tool, go use it.' That expectation is the number one adoption mistake Shani sees.
In the wild
GitHub started not with 'we have GPT access, what should we build' but with survey evidence that developers had too many competing tasks and too little coding time. They asked which coding elements could be automated to hand time back, and only then wired in OpenAI models to build an assistant that sat inside the editor.
→ By the time of the interview: 37,000+ organizations and 1.5M+ developers on Copilot, with surveyed users reporting code written 55% faster and 88% feeling less frustrated.
Enterprise customers repeatedly came to Shani asking what they should do with AI and how to adopt it. Instead of prescribing, she walked them through GitHub's own sequence — problem, task decomposition, then tooling.
→ She describes seeing 'light bulbs' go on: customers realize they had been trying to plaster AI onto things rather than pointing it at a manual, configuration-heavy workflow they already knew was broken.
Common mistakes
Treating AI as an obligation rather than an instrument
Because AI is hyped, teams feel that not shipping something AI-branded means they are doing something wrong. That fear produces feature-shaped noise instead of solved problems.
Assuming adoption is automatic once the tool is licensed
Handing out seats is not deployment. Without a change-management process the tool sits unused, and the efficiency case never materializes.
Reading efficiency gains as a headcount cut
Shani is blunt that you cannot cut your people — the time returned should be spent on collaboration, creative thinking, and recovery, which is what generates the next innovation.
Is it for you?
Best for
Product and engineering leaders under board pressure to 'have an AI strategy' who need a defensible way to choose where AI actually goes in their product
Not ideal for
Pure research teams whose mandate is to explore model capability itself, where technology-first exploration is the point
From the transcript
“what is that problem that we're trying to solve and how can we leverage AI better to help solve the problem versus what do we…”
“the first one is companies expect a change to happen magically here's a tool go use it and it's not always flying the same way…”
“we wanted to plaster AI on a lot of things versus I have this workflow and it requires a lot of manual work or it…”
From the episode
The future of AI in software development
Inbal Shani (CPO of GitHub)