How to building something people don’t want

When I left my job late last year, a friend and I were throwing around some startup ideas. My buddy had one idea he was super excited about — it was a piece of technology that he used internally at the last company he worked for. A lot of developers hardcode various configuration variables in their applications, and we realized that a lot of companies eventually build a homegrown solution to enable these to change on the fly. If only we could make something better than those solutions, they could just pay us to do it for them.

My friend was getting some good feedback (or so he thought), so we decided to just build it. In all honesty, I was mostly just looking to code something, and it was a good opportunity to brush up my React skills. After 2 years as a PM, I was feeling kind of rusty, so I agreed. We spent a few weeks hacking together a basic app and some client libraries, and quickly ended up with something we were ready to launch on Hacker News (you can tell where this one is going).

The day of our launch came and went. We got our product on the front page of HN, and had a few signups for our mailing list, but no one actually integrated our product into a real application. Then we got an email from a user, and he was interested enough that he offered to pay. We added a bunch of “enterprise features,” and told him it was ready. And then he was “too busy” to use it.

Over the next couple of months, we spent a lot of time reaching out to various user segments (mostly development shops and product marketers), with the idea that we could find a strong use case for our product. This was the classic “solution in search of a problem” that you hear about. We got pretty good at mining contacts from LinkedIn searches (thanks Gem), and as we built up our cold email game, we had a bunch of interesting conversations. Along the way, we read The Mom Test, and started to put some of the early feedback into context. We learned a lot, but alas, no one seemed to want our product. Some people straight out said told us that it wasn’t useful, while others were very polite but just didn’t have enough time to integrate.

Additionally, we learned that Google already has a free version of our product in their analytics suite, and we couldn’t figure out any compelling differentiators. We even talked to one of the founders of that product, and he asked us that straight out before suggesting that we work on something different. “At least you have only put 5 months into this so far,” he said. “It took us 3 years to build something people wanted.”

So in the end, we realized we had built something that no one wanted. If we are being completely honest, we hardcoded a bunch of things into our app, and didn’t even use our own product. So it was time to pivot, but what were we going to pivot to. I remembered some advice Paul Graham gave me back in 2009, l when I was in the process of killing my first startup.

“You spent a lot of effort deciding to kill this idea. Take your time figuring out the next thing to work on, and don’t jump for the first idea that comes along.”

Of course I promptly ignored his advice at the time, and ended up going down a bunch of stupid rabbit holes before giving up on startups for the next ten years. But this time around, we are determined to do it the right way. We are taking it slowly, talking to potential users and really considering our options before building anything. We want to make sure there is actual market demand, and that we aren’t just solving an imaginary problem.

I’m not really sure where this will lead, but at least I’m having fun…