Knowing How to Know

Knowing the problem, not the solution

The pattern reframes founder competence as a meta-skill. The job is to know what the problem is, why it matters, and how to get the right people to solve it, rather than to personally know how each thing gets done. Several founders describe versions of this, and their accounts differ enough to mark it as a real difference in emphasis rather than a single slogan.

Ryan Petersen is the clearest case of arriving at it from ignorance. He says he could not have told anyone how to do freight forwarding or customs brokerage, having experienced the problem only as a customer, and that he failed the customs-broker exam by one question.¹ His stated method was to move deliberately slowly, spending four years as the only employee, and, from the start, to hire smart people and set direction: tell them what the problem is, why it matters, and how it fits the vision, then let them solve it. His sharpest example is the inverse. Marketing, the area he considered himself good at, became on his own account Flexport's least developed function precisely because he meddled. The lesson he draws is that letting go can produce a better outcome even where the founder is strong. This connects to the practice of going to where the work happens, described in Gemba Walk, and to the hiring bar in the A-Player Framework.

Verifying you have the right experts

Brad Jacobs states the same principle with the ego work made explicit. He says he deliberately hires people smarter than himself in their domains, describing his CHRO, M&A lead, CFO, and technology lead as "inch wide, mile deep" specialists whose depth exceeds his own. His stated want goes past staffing: "I want people who uplift me, who teach me."² Where Petersen explains why a founder must trust experts, Jacobs supplies a test for whether the right experts are actually in the seats, treating the question of who is irreplaceable as one to keep asking rather than settle.

Never stopping at the first answer

Michael Dell gives the most mechanical version, which he calls "peel the onion": every answer reveals the next question. He describes taking a PC apart as a teenager, identifying every chip, calling the distributor to ask the hundred-unit price, and mapping the result against IBM's retail price. He describes reading competitors' chip date codes to calculate the age of their inventory, noting that "the numbers are just sitting there. They're talking to you."³ His observation is that most people stop at the first answer not because the next question is unavailable but because they feel no compulsion to ask it. He also names the limit: this is an individual competence, and at scale the challenge becomes building systems and culture so the same instinct propagates.

Choosing which problem to know about

Peter Thiel reframes the target of the knowing. Where the others ask what the problem is, who the expert is, or what lies beneath the surface, his notion of a secret asks which unsolved problem is worth pursuing at all: a problem that can be solved but has not been, or an idea at the boundary of consensus. He treats the further question of why others miss it as itself a form of knowing, since it tells a founder how durable the insight is before competitors recognize the same thing.⁴ In this telling the secret sits upstream of all the extraction methods, selecting the problem the others then work to solve.

The open tension the founders themselves surface is how far the humility extends. Petersen concedes he "still kind of doesn't" fully know what the company should do, which raises the question of when productive deference to experts shades into an absence of direction. The principle sets the disposition but does not draw that line.