3 lessons from a web idea that didn’t go anywhere

In my last post, I talked about the second bad website I had started. I learned a lot of lessons (some of them very obvious and amateurish) in trying to explore the idea, and here are some of them:

Focus on the core problems, not on “acting” like a business
To a complete startup newbie, there’s a lot of pressure to create legitimacy when you’re a total nobody. This can manifest itself in many forms, and the more corporate/traditional/Microsoft you are, the more likely you are to cave into these pressures. So what are some things that people expect “real” companies to have?

  • Business cards
  • Office space
  • “Experts”
  • A really big, complex idea
  • A big team
  • Lots of money
  • etc…

Ultimately, this insecurity about what a startup is about can really gnaw away at new entrepreneurs, and they focus on the wrong things. In fact, whenever I see a new startup with 4 MBAs, I imagine them running around making financial models, getting office space, and trying to decide on the “brand” behind their business cards when they should probably be trying to prototype their product and verifying consumer/market assumptions.

From the venture capitalist’s standpoint, they are betting on the team to execute against a bunch of unknowns, and that involves collecting fundamental data right away. So that should be 90% of your time with 10% being dedicated to whatever minimal things are necessary to support the central tasks.

For us, of course, Jake and I spent a bunch of time creating business cards, trying to convince our friends to join us, architecting for “massive scale,” as well as forecasting and re-forecasting financial models. Luckily we didn’t waste a huge amount of time and money doing this.

Nerds love to jump right to the code, but you should probably start elsewhere
If you get a bunch of engineers together and you have a great idea, there’s an instant desire to jump to the code right away, and start developing the product. Let me argue that while this is a great way to get some intuition about the idea, it’s probably not the right thing to do at first. (Although you want to get there quick!)

At the end of the day, investing in the development process is a hugely expensive thing to do, by time or money. Once you build out a wonderful dating site, it’s hard to turn that into a photo-sharing site. Yet at the same time, these days the development process is not the highest risk thing. Instead, the highest risk thing will be consumer behavior risk, or market risk, or some other issue. Put those two together and you can safely say that it’s probably more important to identify the key risks, test for those, and move on.

The key assumption in our business idea was that there was enough value to be collected from these books that it would make it worthwhile. While there are several ways to test that assumption, we jumped into the code very quickly. We later realized that the right approach was to call up a bunch of these charities and used bookstores, and ask them how many books they had. We also figured out that we should actually figure out how many of these books had value, versus being scrap. We ended up creating a pilot program with one of the Goodwill charities to collect data on this, using little more than a barcode scanner and Notepad. Even then, we probably invested too much in our technology system to price things in real-time, post eBay listings in real-time, etc.

Iterate quickly and cheaply (rather than slowly and expensively)
Some folks that are reading this might think that going to the code is the cheapest thing to do. Let me beg to differ. For almost any consumer site out there, the risk on consumer behavior is really the biggest. How do you know that people will like your site? How will you know what audience will love it the most? What features will appeal to them? These questions are impossible to answer.

So I think ultimately, you have to go down the IDEO approach where you pick a general target market, interview a bunch of people, and build a persona for the person you’re trying to target. That way you can have constructive conversations about Artsy Anna and how she reacts to new feature X on your photo-sharing site. But after then, you have to be prepared to build 20 different concepts, iterating on each one, until you catch the perfect customer experience.

The key thing that eventually caused us to stop working on the books idea was that Jake had the great thought to grab a dozen books and auction them all off on eBay. Theoretically, a bunch of what we were doing was contingent on eBay being a “perfect” marketplace for books. If Amazon priced a used book at $20, then the eBay closing price would hopefully match that.

Of course, we found that $20 books went unsold, while $0.05 books sold for $10. At the end of the day, our model was broken because there wasn’t a good way to figure out what books were monetizable and which ones weren’t. While we could have pushed it further by trying to pattern match and creating our own eBay pricing predictions algorithm, instead we laid down our cards – Jake was going to NYU Law School in a month or two anyway, so our little hobby was over.

In retrospect, of course, we should have just done that first. When we came up with the idea, we should have iterated on it by just auctioning off 10 books right away. And if that worked, we could have gone to verify our other assumptions, but we chose to start nerding out right away. Although this could have worked if we were lucky, I think 9 times out of 10 it doesn’t end well.

So if you are working on a new website and 10 months into it, there’s no traction and you don’t know why, you probably could have stepped into it more experimentally. Take the approach as “finding a company” rather than “executing on a plan” and you’ll get more mileage from the situation.

Exit mobile version