Whole Problem
(No text container on this page. It is an embed/table/form; see assets manifest. May require the browser pass.)
🎙 Hear how Michael taught it the lecture, cleaned & woven in
▶ Watch the original lecture
Before you lock a problem definition, make sure you’ve understood the whole problem, and in particular the root cause, rather than a symptom.
A student raised exactly the right worry: how do you know you’re not just hypothesizing that something is unworkable? She gave the example of oral cancer. You might assume the problem is lack of awareness and start raising awareness, when the real problem is lack of access to care. If you build around the wrong root cause, you’ll be solving the wrong problem. She essentially answered her own question: keep drilling on the question (“is it this, or is it that?”) until you find the true root cause. Many startups fail precisely because they don’t do that.
And who do you go to in order to drill down? It’s on the board: your customers. Go ask the user, “Tell me what the real problem is here. Is it lack of awareness, lack of availability, or my inability to use the product?” Ninety percent of the time the answer comes straight back to asking the user and taking their viewpoint of where the pain really sits. The more you do that, the better-defined your value proposition becomes, because you’ll be addressing the whole problem, at its root, rather than a convenient symptom.
There’s also a strategic honesty point here. One team realized during the exercise that their problem might be better solved by a new government policy than by a startup at all. That’s a big “aha,” and I gave them a round of applause for it. Don’t be afraid to recognize that what you’re trying to do may not be a good thing to build as a business. This is your life; you don’t want to spend it on something that isn’t a real, solvable problem for a startup. Sometimes the right move is to go work in government and lobby internally, not to found a company.