Kernel of Truth in Ambiguity

Find what really matters amid competing signals, inputs, and good ideas

Brian Tolkin
Lessons from scaling Uber and Opendoor

Kernel of Truth in Ambiguity

"Product is finding the kernel of truth in a sea of ambiguity and signals... The core job is to understand what really matters, right? What is noise? What is a good idea, what is a suggestion and what is... really going to move the customer forward?" - Brian Tolkin

What It Is

Kernel of Truth in Ambiguity is a framework for the core product management skill of distinguishing what truly matters from the overwhelming flood of inputs, suggestions, and good ideas that constantly arrive from all directions.

Good ideas come from everywhere: customer support teams, direct customers, YouTube videos, executive feedback, field visits, competitor analysis, data dashboards, and more. Each input may seem compelling in isolation. The job of product management is to synthesize all of this into what will actually move customers forward.

This requires intellectual discipline—the willingness to say no to things that sound like good ideas because they're not the kernel of what matters. It connects directly to jobs-to-be-done thinking: amid all the noise, what is the actual job the customer is trying to do?

How It Works

Recognize the Input Sources:

  • Customer support / CX teams
  • Direct customer conversations
  • Executive suggestions
  • Competitor moves
  • Data and analytics
  • Field visits
  • Team ideas
  • Industry trends
  • Partner requests

Understand the Nature of Each Input:

  • Noise: Interesting but irrelevant to core progress
  • Suggestion: Worth considering but not definitive
  • Good idea: Valuable but potentially distracting
  • Kernel of truth: What will actually move customers forward

Apply Jobs-to-Be-Done Thinking:

  • What is the actual job the customer is trying to do?
  • Which inputs relate to that job?
  • Which inputs are tangential to the real job?

Make the Hard Calls:

  • Say no to good ideas that aren't the kernel
  • Disappoint stakeholders who contributed suggestions
  • Accept that you can't do everything
  • Focus relentlessly on what actually matters

How to Apply It

  1. Write everything down - Capture all inputs in one place:

    • Validates that people were heard
    • Creates a reference for pattern-matching
    • Enables revisiting ideas later
    • Helps onboard new team members
    • Use whatever system works: backlog, Google sheet, Jira
  2. Pattern match across inputs - Look for:

    • Multiple sources pointing to the same issue
    • Inputs that align with core jobs-to-be-done
    • Signals that challenge your assumptions
  3. Apply the "kernel" test - For each input ask:

    • Is this noise, suggestion, good idea, or kernel?
    • Does this relate to the core job customers hire us for?
    • If we did this perfectly, how much would it matter?
  4. Communicate your reasoning - When saying no:

    • Acknowledge the input was heard
    • Explain why it's not the kernel right now
    • Show where it lives in your system
    • Revisit if patterns change
  5. Revisit regularly - The kernel can shift:

    • Market changes
    • Customer needs evolve
    • Competition moves
    • What was noise may become signal

When to Use It

  • Roadmap prioritization
  • Feature request evaluation
  • Stakeholder management
  • Strategic planning
  • Saying no to executives
  • Filtering customer feedback

Examples

Uber Early Days:

  • Kernel: Matching riders and drivers efficiently
  • Good ideas: Better support tools, analytics dashboards
  • Decision: Focus engineering on dispatching and pricing
  • Result: World-class core experience, acceptable everything else

Opendoor:

  • Kernel: Accurate pricing and transaction certainty
  • Good ideas: Many operational improvements
  • Decision: Build deep vertical integration in core competencies
  • Result: Defensible position that Zillow couldn't replicate

Anti-Patterns

Treating all inputs equally:

  • Every customer request becomes a feature
  • No filtering mechanism
  • Product becomes a mess

Ignoring inputs entirely:

  • "We know best" attitude
  • Missing real customer pain
  • Building in isolation

Analysis paralysis:

  • Never reaching conviction
  • Endless research
  • Shipping nothing

Source

  • Guest: Brian Tolkin
  • Episode: "Lessons from scaling Uber and Opendoor"
  • Key Discussion: (00:56:33) - Finding the kernel of truth in a sea of signals
  • YouTube: Watch on YouTube

Related Frameworks