Thomas Pendergast Vladeck home


What follows is the central lesson I learned from two years of working on a startup and making a ton of mistakes. A few caveats: I’ve never had a successful startup, and this resonates with my experiences and view of the world.

It’s commonly said and written, at least in the Bay Area: “build something people want” (BSPW). Yet, for my startup (Building Hero), this was the central, original reason we did not succeed. We built things, but they were not things that enough people wanted badly enough.

Why can it be hard to BSPW? It's really two problems that reinforce each other:

  1. Building a product (BS) produces tangible results whereas validating a problem (the PW part) does not

  2. It’s less clear how to validate a problem then it is to build a product

So the BS part is both more tangible and more fun. You can show it to your friends and feel good about the progress you’ve made. Not only that, if you’re an entrepreneur, it’s probably because you’re excited about technology and because you have fun building things. It’s also easier for you, probably, because you’re excited about it and it’s closer to what you normally do (i.e., writing code or designing mockups). And once you have a working product, it’s very easy to get excited about its capabilities. If you’re smart, you can probably convince yourself that it’s awesome.

The PW part is much less tangible. The result of validating a problem is a clear idea of what opportunity exists, an empathic connection with your potential market, and the beginnings of an understanding of how you might solve the problem. It’s a lot harder to show people; it’s harder to get excited about; by itself it’s unfulfilling both personally and socially.

Finally, because BS is so tangible, there is significantly less cognitive overhead in figuring out how to build the product then in validating the problem. It doesn’t take too long to put together a roadmap for how you’ll build something. PW is much less tangible; it’s not clear how to begin or even what you want to end up with.

So, when faced with the choice of finishing up a webapp, which you can show your friends and pitch to investors, or individually emailing 100 people in your target market (much tougher to show your friends), it’s easy to see why many would choose the former and not the latter.

Building Something Arbitrary

If you don’t PW before you BS, it’s likely that what you’re building is arbitrary. Through a commercial lens, it doesn’t have a reason for existence. It’s just one of the infinite things that could exist. Not one of the subset of things that needs to, or should, exist.

Sometimes entrepreneurs may get lucky and build something and find out that people want it too. Or some entrepreneurs may have such a strong creative vision that they can “see the future” and build into it. I guess I’m just not that way, so I need a more defined approach.

The other issue is that starting with BS before PW is that it doesn’t equip you to evaluate how well you are doing. Really validating a problem should leave with you with an understanding of the assumptions that must be met before a product will succeed to the level you desire. Without this work below the tip of the iceberg, you’ll lack critical navigational ability: knowing what assumptions are being proven right and wrong.

In our case, we got fooled by “vanity metrics” - the number of projects we were doing and the amount of revenue we were bringing in. We didn’t have defined assumptions at the outset that we could prove right or wrong. So we made decisions based on the wrong things.

Find out what people want, then build it