The Best-Teams Adoption Heuristic
Adopt a practice only if several of the best teams already use it — then strip the culture from the technique
- Difficulty
- Easy
- Time to result
- ~weeks to results
- Steps
- 4
- Confidence
- 88%
Cagan's filter for what practices are worth adopting: nothing in INSPIRED or EMPOWERED was invented by SVPG — it is all observed from the best teams. If several of the best companies use a technique, it is worth trialling and, if it works, advocating. If none of them use it, it is snake oil or unproven. The second half of the heuristic is the hard part: separating a company's culture (Amazon's, Netflix's, Stripe's, Google's — all different) from the transferable technique underneath it.
Origin
Marty Cagan / SVPG's stated method for how INSPIRED and EMPOWERED were produced. He points to Working Backwards (Amazon), No Rules Rules (Netflix), and Build (Apple) as the same techniques described in each company's own vocabulary.
Core principles
- 01Don't invent practices; observe them where they demonstrably work.
- 02Several of the best teams doing it is the evidence bar for a trial.
- 03Zero adoption among the best teams means snake oil or unproven — not innovative.
- 04Cultures are idiosyncratic and non-transferable; techniques are transferable. Untangle them before copying.
How to run it
- 1
Define your reference set of best teams
Name the product companies whose results you would want. Cagan's list includes Amazon, Netflix, Google, Stripe, Apple, Shopify, Slack, Spotify — plus countless small companies nobody has heard of yet.
Pro tip The reference set should be judged on product outcomes, not on marketing or headcount.
- 2
Apply the adoption filter
For any proposed process, tool, or framework, ask: do several of the best teams use it? If yes, trial it and see how it works in your context. If none of them use it, reject it — it is either snake oil or not yet proven.
Pro tip Cagan's blunt version: 'if none of those companies are using it, i'm like, don't bother me.'
Watch out Vendor-marketed frameworks are the main thing this filter catches — 'they call themselves agile but it has nothing to do with agile'.
- 3
Untangle the culture from the technique
Each great company wraps its techniques in its own cultural language. Read the primary sources — Working Backwards (Amazon), No Rules Rules (Netflix), Build (Apple) — and look for the common threads across them rather than importing one company's vocabulary wholesale.
Pro tip If a practice only makes sense in the originating company's cultural idiom, you have not yet extracted the technique.
Watch out You have to work harder to see the common threads — this step is where most copycat adoptions fail.
- 4
Trial, then advocate only if it works
Run the technique in your context. Only if it works well do you promote it internally as a recommended practice.
In the wild
Cagan opens every engagement by saying nothing in his books was invented by SVPG — they share the practices they see used in the best teams. A practice used by several of the best teams gets trialled; if it works, they advocate it.
→ The books are an evidence-filtered digest of observed practice rather than a proprietary methodology, which is why Cagan can point to Amazon, Netflix, and Apple's own books as describing the same things.
Cagan applies the filter to heavyweight scaling frameworks: none of the best product companies use them; they are, in his words, repackaged waterfall sold to executives who don't understand software, marketed under the agile label.
→ The filter rejects the framework on evidence rather than taste, and points the company toward scaling with leaders instead.
Common mistakes
Copying a company's culture instead of its technique
Amazon, Google, Netflix and Stripe all have great but very different cultures. Importing the cultural wrapper (rituals, vocabulary, artifacts) without extracting the underlying technique produces cargo-cult adoption.
Treating novelty as evidence
A tool or process nobody excellent uses is not ahead of its time by default — Cagan's default read is snake oil or unproven. Novelty is a reason for scepticism, not for adoption.
Is it for you?
Best for
Product and engineering leaders deciding which methodology, framework, or tool to bring into the company
Not ideal for
Genuinely frontier problems where no established company has a proven practice yet, and you must invent and test your own
From the transcript
“all we do is share the practices we see being used in the best teams so the heuristic is pretty easy if it's used by…”
“if none of those companies are using it i'm like don't bother me”
“we try to untangle the company's culture from the technique”
“you can read books like working backwards from amazon describes what i talk about all the time but it's using amazon terms you can read…”
“so they call themselves agile but has nothing to do with agile sort of the antithesis of agile”
From the episode
The nature of product
Marty Cagan, Silicon Valley Product Group