A few weeks ago, I wrote a post-mortem for ten products that I built and subsequently killed (actually nine, because the tenth is in progress and appears to be doing well so far). I got a lot of comments, both on my blog and Hacker News, and they led me to think a lot about what I learned. Some people questioned whether I had learned anything because I restarted so many times, and I had to ask myself whether that was true. Should I just throw in the towel and relegate myself to building things for other people, or have I learned what it takes to be successful this time around?
Then I started to think about my current product, and why things seem to be going pretty well. When I thought about it, I realized that we have done things in a fundamentally different way this time around. I'm convinced that this difference in approach is the main distinction between success and failure, and I'm going to attempt to describe it in the next few paragraphs. Essentially, you should be asking yourself the following question:
Is your goal to solve a problem, or just to build a product?
Problems vs Products
A lot of entrepreneurs (and especially wanna-be entrepreneurs) do things entirely the wrong way. And I've made this mistake many times, so I have the right to be critical. In essence, they think up a product, and then decide to build that product. So, this works sometimes, but it's not a fundamentally successful approach. And the reason is that, at the point where you think up the product, you have no idea whether or not someone actually needs it (sure, you can imagine in your head that someone else needs it, but who knows whether that matches reality). It just seems like a sort of interesting product that might be fun to build, and that someone might be willing to pay for. Maybe you even thinks it solves a problem that you have, but who knows whether it even truly solves your problem? When you use this approach, you care more about building the product than actually solving any real problems.
At this point, a lot of people go out there and attempt to get validation for their product. If you go to any startup weekend, you will see a lot of people doing exactly this sort of stuff. Which is better than just building the product right then and there (especially if you have to pay someone else to do it), but these folks are already starting off on the wrong foot. There are a few factors conspiring against their success, and the most important is confirmation bias.
If you already have a complete product concept in your head (possibly including screen shots that you mocked up in Balsamiq or Keynotopia), you already are somewhat attached to it. And you will be focused on trying to build up mental support for that product while simultaneously writing off anything that disagrees with your hypothesis. Any time someone tells you that they like your product idea, you are going to mark that off as a potential win, and any time someone tells you that they don't like it, you mark it off as someone who probably "didn't fit your target market." I've been through this with a lot of fledgling entrepreneurs, and I've seen it happen many times. They are trying to prove to themselves that their product is awesome, and by extension that they are awesome (you are already awesome, whether or not you build this stupid product). The problem is that building a successful company has very little to do with this sort of mental masturbation.
A slightly better question than "is this product awesome?" would be "does this product solve an important problem?" But even that isn't quite there, because even if the product does solve an important problem, you are still focused on that stupid product that you invented in your head before you ever talked to a single customer. You aren't focused on the problem, but on building that product. Even if you do build it, and it does sort of solve a problem, it is likely that you will be too focused on realizing your vision to pivot the product so that it solves the problem.
Some successful businesses are built in this way, because the company eventually figures out that the product does solve some major problem, finds a lead customer, and then throws out their preconceived notions in order to actually make that customer happy. The problem is that it's hard to get your head out of your butt long enough to realize this, and customers don't always tell you "I would LOVE your product if only you changed it to do something slightly different." Actually, people say this sort of stuff all the time, but many of us are pretty poor listeners. Once you've been around the block a few times, you actually start to pay attention to this sort of feedback, and when someone tells you something, you sort of start to get an intuition as to what they actually want (hint: customers don't always tell you what they want, because they often don't really know what they want).
So What's The Problem?
Now that I've spent a while talking about how not to do it, I can move onto the "correct" way to do things (at least in my opinion). So, instead of thinking about building any particular sort of product, you want to formulate a hypothesis which looks something like the following:
I think that (Problem X) is a significant problem for (Customer Y)
That's it. Now hopefully you will have some idea that it's actually possible to solve Problem X, but even if you don't, you may be able to figure this out later. Not knowing how to solve the problem is potentially even better than knowing the solution, because you won't lean towards any one solution before gathering enough evidence. Remember that if something is a large enough pain point, people will use pretty much any solution, even if that solution is only moderately less painful than the original problem. But it's now your job to validate that the problem exists. So your first task is to spend a few weeks (or maybe more if the problem is super-complicated) talking to everyone who might potentially have Problem X.
Don't hold back, and don't be secretive. Just talk to people who have that problem, and be totally open. Let everyone you know that you are trying to solve this problem, and ask them for intros to their connections who might have it. Here are some of the questions you might want to ask your potential customers.
- Is X a big problem for them?
- Is X their biggest problem? (if not, you may want to just ask whether you can solve their biggest problem instead)
- Are they willing to pay money to solve this problem?
- Are they willing to invest their time in solving this problem? (your lead customers will probably end up investing more time than money)
- Are they willing to pay for a beta product that solves even a marginal portion of this problem?
Once you start to do this, you will realize one of several things. The first could be that this problem isn't something that keeps people up at night. Maybe they would like to have it solved, but they won't really put any time and effort into solving it. Which bodes poorly for you, because they actually have to use your product, and unless your product provides enough benefits, they won't bother to adopt it. Now it's possible you will realize that your target market isn't the right initial target, but if that's the case, you want to start talking to people who do fit the new target market.
The second thing you will hear is that this is a big problem, but it isn't the blocking problem for most busineses. We recently had one customer whom we really wanted to land. After spending a while talking to them and even building custom features for them, we realized that they were more focused on solving a different problem, which was blocking their business progress. Since they were spending all of their engineering effort on solving that problem, they didn't really have time to work with us, even if we kept lowering the barriers to entry. We eventually realized that we should focus on solving that particular problem later, and change our energies to focus on a slightly different problem for other customers.
So, there's a third answer, and that's the one you want to hear. "I stay up all night thinking about that problem. We couldn't find a solution so we're even thinking about building one ourselves." When you hear that from a few people, you just might have hit on something.
Iterating Towards a Solution
So, what do you do now? You have a problem that people need a solution to, but you still don't want to jump immediately to the solution. It's likely, however, that you will need a product to get much further. So you want to define a fairly narrow and limited product that demonstrates some sort of solution to the problem. Most likely it won't solve the entire problem, but that's why you want to make it narrow and limited. Building a small product forces you to narrow your scope until you have something that's actually doable within a small amount of time (it's going to take a lot longer than you think). So you build the product, hopefully in less than month, and you go back to the customers with your prototype.
Now you are at the big moment of truth. Most of the time, that product won't be exactly what your early adopters want, but hopefully it will be close. At that point, they can make the small conceptual leap and tell you how to change the product so that it meets their needs. You do that, figure out how to productionize things, and you have the beginnings of a business.
And, if your customers hate it, you can go back to the drawing board. Maybe you need to solve a slightly different part of the problem, or maybe the problem as you understood it was different from the problem that they understood. It's likely that you will actually have to show your customers a few different concepts before you hit the nail on the head. You just want to make these iterations as small as possible so that you waste minimal time and effort (and also so that you can solve your customers' problems as quickly as possible).
Our Story (So Far)
So, as you probably guessed, most of my previous products were just that, products. And it turned out that the problems they solved weren't big enough (or, at the very least, we weren't focused on the solution, but rather the product and its features). This time around, we started out broad, so broad in fact that we didn't even have the initial problem in mind. We just said that we wanted to solve problems within a particular economy, and spent a while thinking about what the biggest problems were for that economy. Once we had some concepts, we started doing customer development. I think that we put in about a day of engineering effort into hacking together a demo to show to these initial customers. But it didn't really have any features - it was just an illustration of the broad problem we wanted to solve.
From the initial customer development we did, we were able to get enough information to build a rather ugly prototype, which took about a week. We were still focused on the problem - we just wanted to show some different approaches we could use to solve that problem. With this demo, we got some more customer feedback, which actually got us to the point where we thought we knew which approach to pursue first. We spent about a month building that product, and then went on a massive customer development trek to the bay area. We met with about 15 potential customers within the span of a week, but by the end of the second day, we realized that our customers wanted something different from what we had built (the features were pretty much correct, but the format was slightly wrong). The only plus was that several people told us they wanted this new product as soon as possible. We headed back to New York, and started building that new product. We hope to have our early adopters using it (and paying) by the end of the month. So that's our story so far; I will let you know how things turn out.