In late October I spent a week in San Francisco with Byte, a Finnish program that takes young builders to the Bay. Every conversation started with the same question: what are you building?
A lot of people there didn't have an answer yet. Nobody saw that as a problem. In SF, being pre-idea is just a stage and the advice for getting out of it was always the same: go find a problem.
Founders, not ideas
At a16z we were told they invest in founders, not ideas. The team is what matters and the idea barely does. At YC the advice was to skip the big company and start right away.
Almost everyone we met said some version of this. Back the right person and they'll find the problem. Finding it is the easy part.
I agree with the first half. Most startups that matter, matter because of who started them. The second half I think is backwards. Finding a real problem is the hard part, and I don't think you can do it by going out and looking.
Hunting for problems
The clearest version of the advice came from a small fund in SoMa. Read Hacker News and TechCrunch. Look at what Sequoia is funding. Find the space where the money is going, and build something there.
That isn't finding a problem. It's picking a market and working backwards to a problem that fits it. And when finding a problem is your job, you'll always find one. Whether it's real is a different question.
Problems I didn't have to find
The best things I've worked on started the other way around. The problem was just there.
Every Finnish man gets called up for military service, and everyone wants to know when their call-ups are. I built milloinkutsunnat.fi in a day to answer that one question. Three years later it's still running, and it ranks above the Finnish military for its own question.
Most of what pulls me in looks like that. At Ericsson, a database migration that was supposed to be a one-off turned into a full-time role, because people kept calling me with database questions. This summer at Palantir I worked on production infrastructure.
I think I'm a 1 to 100 person. I like taking something that clearly works and making it hold up for real: scaling it, debugging it, figuring out how it actually behaves. I want the problem to be obvious first. That's why "go find a problem" never landed with me. I'd rather work on a good problem than work on finding one.
The case against me
I'm honestly not sure I'm right about any of this.
The best problems might not look obvious at the start. If they did, someone would already be working on them. Founders are the people who commit before it's clear, and a lot of what looks obvious now only looks that way in hindsight. If I wait for obvious, I might only ever get problems someone else already took.
There's also a less flattering reading. "I'd rather join something real" is a comfortable thing to say. Someone else takes the risk and I get the part I enjoy. And I know I'm reactive. I tend to take the closest route instead of planning years ahead. "Wait until the problem is too obvious to ignore" is exactly what a reactive person would say.
And maybe the investors are simply right. If the person matters that much, a good founder finds a real problem eventually, and the first idea was only ever a place to start.
Let me know what you think: [email protected]