Startup Validation for Hackers

I mentioned last week that I had an epiphany about my being-a-startup-founder strategy. I can sort-of capture the essence of it in one sentence: I've started using "personal newsletter subscribers" as my primary metric. (If you got here by clicking a link in an email, thanks for helping out).

This will be my main metric until I get my startup from the figuring-it-out stage to the growth stage. I've set a goal to grow the newsletter by 7% each week. My plan is to spend Monday mornings writing about the work I did or thoughts I had the previous week. So ideally I'm not shifting too much time away from working on the startup; I'm just taking advantage of that work to provide good content and grow my subscribers.

Why?

It comes down to startup validation. I first heard about the concept while reading Nail It Then Scale It 2.5 years ago, just before my last semester of college. Instead of going to town on your startup idea, first go talk to people. Make sure it's something people actually want before you spend a bunch of time on it. It seemed like good advice, and I wanted to be a diligent founder.

However... I discovered that my efforts at validating my idea were half-hearted. I wanted to create a music player with better algorithms. I had done undergrad research on music recommendation for a couple years, and I was confident I knew how to do a better job algorithmically than the competition. And especially, I deeply wanted this to exist for myself. But I had trouble finding other people who were as excited about my startup idea as I was. I remember trying to explain the idea on one occasion only to be told "This already exists; it's called Pandora." (Face palm).

So what do you do when you fail at validating your startup idea, but you still believe in it yourself?

As with all my hard startup questions, I asked myself: WWPGD? ("What would Paul Graham do?"). In short, I haven't seen PG write much about idea validation. I have seen him say, over and over, make something you want yourself. So I decided that my personal belief in the idea was more important than trying to get external validation.

I even came up with an explanation for why some people harp on idea validation so much (and criticize you if you ignore it—I call them the "Lean Police," cousins of the Agile/Scrum Police). It's because there are different kinds of startups. There are plenty of founders for whom idea validation is their form of hacking. For them, the whole point of doing a startup is to find an inefficiency in the market and fix it. That's a great thing. It's just a different thing from working on something because you want it badly for yourself, and it would be a mistake to say that either method is the One True Way to start a startup.

To expand on that, the whole point of idea validation is to reduce risk. But that's not always a good thing—it means you may overlook good ideas that seem bad. So putting effort into validation simply has a different risk/reward profile vs. scratching your own itch (not to mention effects on motivation). I think idea validation is good advice; it just doesn't apply to everyone in every situation.

However.

Morale is a fragile thing. The joy of working on something you love can be sometimes crowded out by fears of having to get a job if it doesn't work. Or even worse; the fear of spending years going down a dead end when you could've instead failed fast and switched to something good sooner. How do I work on things I love while being smart about the risk?

I've adopted this strategy:

1. Pick an idea I love.

2. Decide how far I would need to go in order to satiate my desire to work on it. In other words, which features do I need to scratch my own itch? (You might call this the MVP, but the goal isn't necessarily to have something that other people will pay for).

3. Code code code. Get there as fast as possible, ideally within a few months. Don't focus too much on trying to get users. Also don't worry about how to charge for it.

4. In the mean time, write every week. Write about my work, write about anything; just try to build a personal following. While I'm not trying to get people to use the product per se, I am preparing to do idea validation later.

5. Once I'm at a state of closure—where the project is completed enough that I would feel OK moving on to something else if needed—launch it. Ideally the newsletter is decently large at this point, but there are also channels like Show HN and Product Hunt etc.

6. Now that I've given birth, step away from coding so much and focus on promotion. The goal is to rationally decide if the baby will continue as a business or as a side project. This decision doesn't have to happen right away. I could fork off a background process to do promotion while I work on another project, do some consulting, or even write full-time. But I should be past the point of thinking "once I add feature X, then it'll be good enough to get users."

If the project does end up as a business, I'll be stoked. If it's a side project, then at least I've been building a personal newsletter, not a newsletter for the startup. I can move on to the next thing and keep the same subscriber base. In fact, the more I've been thinking about it, the more I wish I had started a newsletter 10 years ago. No matter what I do with my career—startups, consulting, or even getting a job—I can take the subscribers with me.

I worked on my music recommendation idea from last June until November, at which point I decided to pivot. (Details here if you're interested). Had I used this strategy, I think I would have more to show for it with less time spent.

Discuss on: Twitter