Kernel-of-Truth Signal Triage
Product is finding the one thing that really matters in a sea of inputs — capture everything, then ruthlessly filter
- Difficulty
- Moderate
- Time to result
- ~ongoing to results
- Steps
- 4
- Confidence
- 85%
A discipline for prioritization under signal overload. Good ideas come from everywhere (CS, customers, executives, field visits, a YouTube video); the core job is to sort noise from signal and identify the single kernel that really matters — for early tech-and-ops companies, that's usually where technology can uniquely create leverage. You capture every input so people feel heard, then filter hard to what advances the customer.
Origin
Brian Tolkin's framing that 'product is finding the kernel of truth in a sea of ambiguity and signals.'
Core principles
- 01Good ideas come from everywhere — but most inputs are noise, suggestions, or nice-to-haves
- 02The core job is deciding what really matters: what will actually move the customer forward
- 03In early tech/ops companies the kernel is 'where's the tech leverage that uniquely solves what really matters'
- 04You must be comfortable letting other fires burn while you focus on the kernel
- 05Write every idea down — both to reference later and so contributors feel heard and respected
How to run it
- 1
Capture every input in a durable backlog
Write down all ideas and feedback wherever you keep a backlog (a Google Sheet, Jira, whatever) so context is captured and contributors know their idea was considered.
Pro tip Writing it down serves two ends: you can reference it, and the people who raised it feel heard and respected.
- 2
Classify each input: noise, suggestion, or real signal
Sort the inputs — what is noise, what is merely a suggestion, and what will genuinely move the customer forward (tie back to the job to be done).
Watch out This means saying no to things that sound like good ideas — that's the hard part of the discipline.
- 3
Find the kernel where leverage is highest
Identify the one thing that really matters — for early tech/ops companies, where technology can uniquely solve the core transaction — and go do that.
Pro tip In early Uber the kernel was: connect rider and driver, price the transaction, issue receipts, collect payment — everything else (support-ticket efficiency, centralized growth) was immaterial at the time.
- 4
Let other fires burn
Be comfortable that non-kernel problems go unaddressed for now; deliberately accept that other things are on fire while you nail what matters.
Watch out What's immaterial early (e.g. support-ticket efficiency, CAC) can become super-critical later — the kernel shifts as the business scales.
In the wild
Uber deliberately didn't build sophisticated tooling, a centralized growth team, or optimize support-ticket efficiency early on. The kernel was the simplest network: connect a rider and driver, price the transaction, collect payment, issue receipts. Everything else was treated as noise until that core worked really well.
→ Concentrated scarce engineering on the dispatching and pricing systems — where the leverage actually was.
Common mistakes
Chasing every good-sounding idea instead of the kernel
Inputs flood in from everywhere; failing to filter to what really matters spreads scarce resources thin and starves the one thing that would move the customer.
Not writing ideas down
Uncaptured ideas can't be referenced later, and contributors who don't see their input considered feel unheard and disengage.
Is it for you?
Best for
Product leaders drowning in inputs who must concentrate scarce engineering on the highest-leverage core, especially at early tech-plus-ops companies
Not ideal for
Mature products where the core is solved and the work is broad optimization across many surfaces rather than finding a single kernel
From the transcript
“product is finding the kernel of Truth in a sea of ambiguity and signals”
“the the core job is to understand what really matters right like what is noise what is a good idea what is a suggestion”
“where's the kernel of what really matters that Tech can uniquely solve and let's go do that and be comfortable with other fires may be…”
“make sure it's written down for a number of reasons one you can then go reference it but two part of the the the job…”
From the episode
Lessons from scaling Uber and Opendoor
Brian Tolkin (Head of Product at Opendoor, ex-Uber)