The Core Technical Insight Test
Before funding a product, force a one-sentence answer: what's the genuine technical breakthrough underneath it?
- Difficulty
- Easy
- Time to result
- ~days to results
- Steps
- 5
- Confidence
- 80%
This is Eric Schmidt's screening question for new product proposals inside Google: before funding anything, ask 'what is the core technical insight that makes this possible?' If a team can't articulate a genuine breakthrough — something novel enough to stand on its own as a research paper or first-of-its-kind mechanism — the project doesn't get resourced. Acquired's hosts trace this pattern across Google's biggest wins (PageRank, Ajax-powered Gmail, real-time collaborative Docs, YouTube's encoding stack) and contrast it with failures like Google+ and Google Wave, which were built as product ideas without an underlying technical unlock. The test acts as a fast filter to separate 'nice idea, weak moat' proposals from genuinely defensible innovations before committing engineering resources.
Origin
Extracted from Acquired
Core principles
- 01The best products let the technology breakthrough BE the user experience, not a feature bolted onto a business idea.
- 02If you can't state the core insight in one sentence, you probably don't have a defensible product yet.
- 03A copycat feature set without a technical edge rarely beats a focused incumbent.
How to run it
- 1
State the insight in one sentence
Before funding, require the team to articulate the specific technical insight that makes the product possible.
- 2
Test for genuine novelty
Check whether the insight is truly new — could it be published as a research paper or is it a first-of-its-kind technical mechanism?
- 3
Verify the tech IS the experience
Confirm the breakthrough directly translates into what the user feels, rather than being invisible plumbing behind an ordinary feature.
Pro tip If you have to explain the tech to make the product seem impressive, it probably isn't the core insight.
- 4
Decline or downscale weak proposals
If no clear insight exists, don't fully fund it — run it as a small experiment or don't fund it at all.
Watch out Saying no here is politically hard when there's competitive pressure to 'have an answer' to a rival's product.
- 5
Sanity-check against known failures
Compare the proposal against past products that lacked a technical insight and failed, to calibrate the bar.
In the wild
Paul Buchheit discovered the XMLHttpRequest feature in JavaScript, enabling a web page to fetch data without reloading — the technical insight behind Gmail and the wider Ajax/web-app era.
→ Gmail launched as a category-defining product built directly on this single technical unlock, growing to 2 billion+ users.
Google+ was commissioned top-down to compete with Facebook, built around product ideas like 'Circles' rather than any novel technical mechanism.
→ Despite massive company-wide resourcing and forced integrations, Google+ never found product-market fit and was shut down in 2019.
Common mistakes
Copying a competitor without a technical edge
Google+ tried to out-build Facebook feature-for-feature without a unique underlying mechanism, resulting in a mandated product nobody organically wanted.
Confusing design polish with a technical insight
A well-designed UI is not the same as a defensible breakthrough; competitors can copy UI far more easily than a genuine technical unlock.
Skipping the test under competitive panic
When leadership panics about a rival category, it's tempting to greenlight lookalike products without asking what makes your version structurally different.
Is it for you?
Not ideal for
Purely design- or brand-driven product categories where the winning factor is taste or distribution rather than technology.
From the transcript
“Some people can make an Instagram and those people are not Google.”
From the episode
Google Part II: Alphabet