10.10.10 & the “Problem-First” Model

When I began to talk about 10.10.10, in 2012, the core was there, but the program had a slightly different starting point. I first described the program as 10 entrepreneurs, 10 days and 10 ideas. If you’ve been following the growth of 10.10.10 you know that our program no longer starts with 10 ideas. We focus, instead, on problems. And more particularly, we focus on wicked problems.

10.10.10 has since become widely known as a way to challenge entrepreneurs to create market-based solutions for the world’s wicked problems — “10 impact entrepreneurs, 10 days, and 10 wicked problems.” How did and why did this shift from ideas to problems take shape? Chalk it up to a mentoring relationship. During a meeting in 2013 with friend and entrepreneur, Joel Wishovsky, Joel made simple a comment that forced me to stop and think: “You should do 10 problems, not 10 ideas.”

At first, I resisted. But the more I thought about it, the more Joel’s counsel made sense. (You’d be surprised how often mentors learn from those they mentor.)

What’s the difference between starting with ideas and starting with problems?

Everything.

People, organizations and corporations tend to feel a sense of ownership about their ideas. This is “mine.” When we feel we own something, we tend to care more about what happens to it. Often this means we nourish it. Feed it. Build it.

We tend to want to protect “our” ideas. We shield them from public view. We lock them up — literally and figuratively — to ensure our ownership is honored and that we receive the value to which we feel we’re entitled. And here our “ownership” can have negative consequences, particularly if it seriously constrains our willingness to share something with the larger network that might otherwise provide valuable input and perspective.

I often hear investors and more experienced entrepreneurs say “ideas are worthless; it’s all about execution.” (This is useful hyperbole, but it isn’t true: so-so execution of a great idea beats extraordinary execution of a bad idea — every time. So good ideas do matter. Still, “your idea is worthless,” is an important corrective in at least two ways. It keeps you from hiding your idea under a bushel. And it keeps you from believing — mistakenly — that your idea by itself (independent of any execution) generates meaningful value.

All of this, taken together, helps explain why 10.10.10 has decided to take a very different approach. It turns out, people, organizations and corporations don’t have the same sense of “ownership” about problems. They are often far less protective and far more willing to share. This means that 10.10.10 has been able to ask people, organizations, corporations and institutions for problems. This makes the problem a far better starting point for collaboration and engagement than the idea.

Still, the notion of an “idea” as the starting point for a new venture has been with us for ages. This isn’t a bad thing. But the idea as venture starting point confuses and conflates two things that should really be considered separately. When you’re starting a new venture, consider beginning with a problem (vs. an idea.) Most startup pitches or presentations have a common format, a structure that goes something like this:

  • problem
  • solution
  • market
  • team
  • unfair advantage
  • etc.

Ideas tend to conflate problem and solution, rolling the whole thing up into a neat package. That’s handy and sometimes quite powerful — e.g., Uber’s origin story — “wouldn’t it be cool if I could call a black car right now from my phone?” But by combining problem and solution, startup founders often rush forward, skipping an important step. They don’t take enough time to think about the problem itself. And when they fail to understand the problem, they nearly always fail to create a valuable solution. From that point forward the company they had hoped to create begins to suffer — or, worse, is DOA.

As a founder, what does this “problem-first” approach require of you, and what benefits does it provide? Starting with a problem requires that a company’s founders ask a series of important questions.

  • Is this problem big enough or important enough to care about?
  • Does anyone else — an individual, organization or institution — really understand this problem?
  • Who has the problem, and do they have common characteristics — geography, age, habits, perspectives?
  • What pain does the problem create for those who have this problem?
  • What do they do now to address that pain?
  • Is this a problem that can be solved by an entrepreneur and/or a startup?
  • Is the problem too big — does it require more time, talent or “magic” than the startup team has (or has access to)?
  • Can you address the problem without also addressing an even bigger problem (i.e., is there a meta problem you haven’t considered)?
  • Is there a sub-problem (that is big or important enough) that can be solved more readily?
  • If you solve this problem, could the solution also be applied to similar or adjacent problems?

If you can’t answer these questions — worse, if you haven’t even thought about them — your solution (or your hypothesis about a solution) is almost certainly a waste of your time and money (and everyone else’s). On the other hand, if you can answer these questions, you can craft a solution that is purpose-built for the market.

One word of caution. A friend of mine warns against “admiring the problem.” He’s right to be impatient with this. Problem admiration occurs with some regularity in academic and research environments, but it can also occur in the business world. The antidote? — after addressing key problem questions, moving swiftly to develop and test a market-based solution (i.e., a product or service that can be deployed). Solutions developed with a rich understanding of the problem have a much better chance to become the foundation for fundable companies.

In a later post, I’ll say a few things about another step along our path: our transition away from ordinary or “tame problems” to “wicked problems” and why that matters. Today, though, I want to conclude by thanking Joel for his contribution to 10.10.10. Thanks, Joel!