Our idea for Yipit was simple, aggregate all these daily deals being sold by different companies and put them in one email. Plus, you could specify categories so that your emails were personalized.
The only issue was that we were working on a different product. The idea of trying yet another concept was exhausting.
So, we compromised by giving ourselves 3 days to build it.
In the first two days, we quickly built an email capture, sign-up flow to collect preferences and a script that would send people an email with the deals that matched their preference.
But, how would we get the deals in our database and categorize them correctly as “restaurant” or “concert tickets”? We would have to build a crawler to parse the deals from HTML from various sites and write a classification algorithm. Not a daily task for us.
So, we took a shortcut. Instead of building a crawler, my co-founder and I would crawl out of bed at 3 am and manually enter the deals into our database. Plus, when you’re doing it yourself, classification was easy. We did it all manually.
Within 3 days, we released Yipit and it took off. We got press and became known as the leader in the industry. Three months later we raised $1.3 million and a year later another $6 million. Today, we’re 25 people, over a million people have signed-up and we’re on a path to profitability.
The funny thing is that within a few months of our launch, several competitors emerged and they all had crawlers. But, from our users’s perspective, we were more advanced since we had categorization which was definitely no easily automated task.
We didn’t actually build a real crawler for the first 9 months and just kept scaling manually by hiring more data entry professionals. Instead, we were able to focus our resources on improving the product and user acquisition.
It’s now clear to me that not building that crawling technology early on was one of the reasons our startup succeeded.
Taking this “manual-first” approach was our secret sauce.
Many Startups Take the “Manual-First” Startup Approach
We’re not alone in our “manual-first” approach:
- AngelList started with Nivi and Naval manually collecting startup applications and manually matching them up with potential investors. I know because Yipit was one of the first startups to use AngelList to raise funding
- ZeroCater, a Y Combinator company, started with just a big spreadsheet trying to connect companies with restaurants that would cater
- Groupon started with just a WordPress blog and manually sending PDFs with the first vouchers
- Grouper, another Y Combinator company, also started with just a spreadsheet trying to match groups of people on dates
Benefits of the “Manual-First” Startup Approach
There are many benefits to taking a “manual-first” approach to some of the trickier technology challenges including:
- Fastest way to get to the “moment of truth”. Having your potential customer evaluate your product and see if it addresses their need is the moment every founder is trying to get to and doing things manually allow you to quickly get there.
- Easy to change your solution if it doesn’t work. There’s no code to re-write, there’s no sunk cost. You just have to change how you’re manually doing something.
- Will really understand what to automate with tech when you’ve been manually doing it. When you’ve been manually providing the solution, you’ll know exactly where the pain points are that you should be automating.
- Can really wow your potential customers. When you do things manually, you can try different things that really wow the customer and see which ones are worth trying to scale.
- Customer doesn’t know how your product works behind the scenes. They won’t judge you for your manual approach because they don’t know that’s how you’re doing it. All they will care about it is that your product works.
- Your product will “just work”. Because you’re manually providing the solution, the product will just work. When trying to implement a solution with technology, it can be very hard to make sure that it just works.
- Helps you focus your time on the problem, not the solution. It’s very tempting to fall in love with the technology behind your solution only to painfully realize that the problem you set out to solve isn’t a real problem.
Next time you’re building a new product, I hope you’ll consider a manual-first approach to some of the trickier aspects of your solution.
Reid Hoffman, founder of LinkedIn, once said: “If you’re not embarrassed by your first release, you probably spent too much time on it.”
I also think it’s true that: “If people don’t laugh at how you first implemented your product, you probably spent too much time on it.”