How NOT to Start a Startup
Three mistakes to avoid when starting a startup
Starting a Startup — A Real-Time Journal
There’s lots of great advice out there about how to start a startup. From Naval Ravikant’s recently-started podcast, to Peter Thiel’s Zero to One, to Eric Ries’s all-time classic The Lean Startup. However, all of these resources have one thing in common, they’re written in hindsight — after their creators have already launched massively successful businesses and made tons of money. As a result, the advice (while great) lacks the messiness of actually trying to apply these strategies in the real world before you or your company achieves success.
Since my business partner, Zach, and I are trying to do exactly that, I thought it would be helpful to document in real(ish) time our attempts to start a startup so others and our future (hopefully successful, wealthy) selves can see what it’s like to do it in the real world.
You can find all the journal entries here.
Signup here to get the next journal entry delivered to your inbox
Part One
On a crisp October, Saturday morning in 2017, Zach, two other friends, and I met at the brand new Austin Central Library to talk about starting a startup.
After throwing out a bunch of ideas, we stumbled on the fact that all of us took extensive Kindle highlights but didn’t really know what to do with them. I had an elaborate, labor-intensive process for exporting my highlights to Evernote and tagging and reviewing them so that seemed like it could easily be replaced by a streamlined app.
Working on the “scratch your own itch” theory of startups — ie if four guys share one problem there are at least 10,000 other people in the world who have the same problem — we decided to build the streamlined app.
And that’s when we made
MISTAKE ONE — unclear value-prop
We decided to build an app to solve the problem that “people take Kindle highlights and don’t know what to do with them”.
The problem with that problem is it’s not a problem.
It’s an interesting fact, sure. Perhaps there is an underlying problem and if we had dug deeper we would have discovered it.
But instead, we started building an app to “manage Kindle Highlights”, which is not a clear value-prop for the end-user.
A clear value-prop is one where it’s clear how a user will get more value out of the product then they put into it.
Examples
Google Photos — install this app on your phone and all your photos will automatically be uploaded safely to the cloud, where you can search for Christmas trees without any upfront tagging, share photos with friends and family, and see them across all your devices.
Superhuman Email Client — use this email client and get through your inbox twice as fast.
And (foreshadowing)
Readwise — automatically import your Kindle Highlights and get daily reviews sent right to your inbox.
Of course, these are all established products so their value-props are VERY clear. In fact, they may have multiple value-props at this point. But when trying to start a startup you need one, clear value-prop upfront so you can TEST it (and change it). A wishy-washy value-prop like ours is really untestable.
Which leads to
MISTAKE TWO — building before testing
This is right out of the Lean Startup. Coders and engineers (like us) love to “just build it” and believe “they [users] will come”
The problem with building an entire application on an unproven (or non-existent in our case) value-prop is that it’s a very expensive way to test it.
That’s why Ries recommends the now-famous, “minimally viable product” that lets you get one cycle of the “build-measure-learn” loop as quickly as possible.
As Ries says this really just applying the scientific method to business where the value-prop is the hypothesis and the minimally viable product and build-measure-learn loop are the test.
There are lots of ideas out there for creative MVPs, the landing-page test (which we half-heartedly tried), the concierge service test, the dropbox video test. But none of these can be generically applied to all ideas because scientific experiments can never be applied generically. Experimental design in science is hard and opportunistic and messy and very specifically tied to the theory that’s being tested.
That’s not to say you should just wing it (like we did). It’s just to say that when applying Ries’s advice to the real world prepare for it to be messy and hard. In fact, I would suggest that Ries’s is so right that it’s worth planning on waiting to build for a very long time as you think of ways to test your value-prop.
Our mistake was really just not being prepared to spend that kind of upfront time before building our app.
Now we did eventually build our way (after about eight months) into a clear value-prop, namely, that influencers want to share their Kindle Highlights with their followers.
But that resulted in
MISTAKE THREE — not having a distribution plan
So now it’s August of 2018, and we’ve finally got a value-prop and an app that delivers on it.
To this day I still really like the app. But from a startup/business perspective we’re missing one essential ingredient — customers.
After we built the app we realized we had no real distribution plan except posting to Facebook and hoping that it went viral.
It was at this moment that I finally realized that all four of us had spent almost all our time coding and none of our time on the other things (marketing, sales, support, etc) that are necessary for building a business.
So I made a commitment — I would NOT code anymore. I would spend 100% of my time trying to get influencers to use the app.
I think this is a really good heuristic for tech-types. Have one person on your team spend 100% of their time doing anything but coding (ideally working on distribution).
So I started reaching out to niche influencers I like — David Perrell, Alex Taussig, Len Edgerly. But these were kind of hail marys. I would expect about 1/100 to maybe start using the app and there weren’t enough of them for the strategy to work out.
So we found another niche to hit — Booktubers, people who review books on YouTube. There are thousands of them (the internet is a weird place). Finally, we had a large enough sample size to run a statistically significant experiment.
We decided that I’d reach out to 100 Booktubers and if 3 of them signed up for the app, that would be good evidence for the value-prop.
Reaching out to 100 Booktuber individually was laborious — it took about half an hour per Booktuber. But it was worth it. Why?
Zero responded.
In 50 hours of effort (not much compared to dev time) I finally had a solid piece of evidence that our value-prop — influencers want to share their highlights — was not valid. That’s worth a lot.
Conclusion
Things we tried:
👎 Scratch Your Own Itch Theory
👎 Landing Page Tests
👍 Designate One Person as Non-coder Heuristic
👍 Constructing Experiments to Test Theories (hard)
Takeaway
Don’t just build anything before you have a clear value-prop that you’ve at least tried hard to validate that includes a plan/theory for distribution.
Coda
While the other two dropped off at various points in 2018, Zach and I continued working on the app for a couple of weeks after the failed Booktuber experiment.
Then Tim Ferriss included Readwise in his Five Bullet Friday update and I realized it was the app I wanted to use to manage my Kindle Highlights.
It’s a great app. It automatically pulls in your highlights (not just from Kindle) and creates a daily review for you. It lets you tag highlights, add notes, all kinds of stuff that we added to our app.
It turns out that the guys who built Readwise are bootstrapping it just like Zach and I. In fact, they were just 6 months to a year ahead of us. But I don’t think the headstart they had is the reason they beat us to the punch.
I think they had a much clearer upfront value-prop — people want to review their highlights.
I don’t know what they did before they built the app, but based on their blog post they “must move more deliberately” which means they’re at the very least not “just fucking building it”.
Finally, they’ve spent a good deal of time on their blog and reaching out to users so they’ve at least thought seriously about their distribution strategy.
Now I’m a happy Readwise customer and Zach and I are working on other startup ideas. Ultimately, that’s not a bad outcome for a year’s worth of work.
Signup here to get the next journal entry delivered to your inbox
