sean cassidy : The Practice Startup

You want to found a startup. You're not exceptionally well connected, you don't have the best idea in the world, your programming skills aren't world class. That's okay. You don't know how to build a product, market it, or how to sell it. That's okay, too. Because you're going to learn. You're going to learn the best way: by doing.

A few years ago, I, like many people, wanted to found my own startup. I had ideas – great ideas, so I thought – but I didn't know what to do with them. I knew how to program, and I naively thought that was enough. If only those venture capitalists would give me money I could finally have a chance! I read books about startups and businesses, read countless blog posts that focused on how to grow my startup, how to hire salespeople, how to run an email marketing campaign, and so on. But they didn't focus on improving me.

I started a company with a friend of mine. We built some software, called some people, and eventually realized it couldn't be a sustainable business. So we decided to solve a problem we had that we had run into while doing the previous startup: deploying software is hard, and we disliked Chef/Puppet/Ansible. So we made Squadron, actually managed to find customers willing to pay for support, and even got a YC interview. We failed for a few reasons I might write about later, but I learned more than I ever thought I would about products, about sales, and about marketing. That knowledge is still serving me well at Praesidio, where I joined as the first employee. It was invaluable practice that is still paying dividends.

Here's the deal: if you want to found a startup, if you want to build a great product, if you want your business to have a chance at surviving, you need to have the skills. You can and should read as many books and blog posts as you can. But there's no substitute for doing it yourself.

The Plan

You're going to practice.

For your practice startup, you'll need an idea. It's going to be a simple idea. You're going to build a minimally viable product (MVP) and start selling it. You'll build a marketing campaign for it, call potential customers on the phone, go to meetups and pitch your idea to people, and maybe even pitch it to investors. Nobody but you will know it's just practice.

You probably have a full time job now. Most people in the startup community will tell you to quit. I won't. You should keep your job while you do this. Yes, investors don't like that, but that doesn't matter right now. You're going to learn the skills it takes by doing. It's also helpful if you get a partner, but it's not essential yet. Don't listen to stupid advice like dump your significant other or move across the country. You can do this right now.

You'll need to pick your idea. Don't get too hung up on this stage. This doesn't have to be the best idea in the world, just something you think some people will pay money for. One easy way to do this is to pick a technology that you use, but don't love. Then, change it so that you love it. Tell your friends and family you're in the market for ideas. One thing to note: since you're purposefully doing this for practice, it's best not to pick an idea people or businesses would absolutely depend on. Make it clear to your potential customers that you're still in the research phase.

Once you have your idea, try to get a customer or two. That's right, before you build anything, try to sell it for actual money, or get people to use it if it's not a salable product. Don't ask if they would buy it or would use it, ask them if they will buy it or will use it. Pricing products is difficult even for more mature companies, so try out a few different prices. Listen to them and try to understand their problems and what they would want you to do. Your idea shouldn't be shoehorned into fix their problems, but you can modify your idea to better suite their needs. If you can't find anyone willing to pay actual money or actually start using it, start over. Remember: it's just practice.

Now that you have a customer or two ready to go, build your MVP. There are lots of blog posts and books written about MVPs, but I'll just say that I prefer working prototypes to screenshots. You should do whatever you think is best. If you're not a programmer, learn or find a partner who knows how. Don't pay thousands of dollars to a contracting firm yet. Avoid building mobile apps from the get-go unless you are particularly proficient at writing them. They take up a huge amount of time.

Once your have your MVP, find beta customers. Does your target customer typically have blog? Or tweets? Or uses Pinterest or LinkedIn or reddit? Contact them and send friendly, personalized messages to them. Keep it short and to the point. If you can't find their emails, find out where they go. Meetups, conferences, libraries, the climbing gym, schools, various Internet communities. Then start talking to them. You can't skip this step. Find at least a few more people or companies willing to pay actual money for, or at least, use what you've built (or said you were going to build). If you can't find any more customers, you should start over or modify your idea or MVP. It's just practice, so don't sweat it.

Armed with your customers, build your marketing website, complete with testimonials. Get a mailing list going. Solicit feedback. Build out some more features on your MVP.

Find local startup incubators and pitch to them, but don't get carried away with this step. You don't want to get too focused on finding funding, as that will warp your practice startup. Without even knowing it, you'll enlarge the idea to “attract” investors and start to talk about how your total addressable market is really everyone in the world. Instead, tell them the facts. If they don't fund you, it's no big deal, as this was just practice. It's like you're David Attenborough and you're going to make a documentary on the elusive venture capitalist in its natural habitat: you're learning about them and the process.

You might want to know at what point you should incorporate, buy an expensive domain name, or shell out a lot of money for a nice logo or t-shirts. These things give the illusion of traction and of having a product-market fit. I recommend you wait on all of them until the moment where it would be silly not to have them. Don't pay too much money for any of them.

What you've learned

Write down everything you learn as you go. Blog about it and email or tweet me the link, I'd love to read it. Share what you've learned and encourage people to practice, too. Write about the most surprising thing you learned about sales, or marketing, or product management, or building a prototype, or user testing.

It turns out that there's really no difference between doing the practice and doing the real thing. If you've done all of these steps, you may have actually built a fledgling startup. All you needed was permission. Keep going.

We as a community tend to get too focused on some details, like quit your job first, or how to select the perfect idea, or how to build the perfect MVP. Some people even think succeeding wildly on your first try is important. None of that matters in the same way that you being a good product person, a good marketer, a good salesperson does. Growing as a person is how you will best know how to grow your business.

Try it out. You have nothing to lose. It's just practice.

Articles

  1. Code as Risk
  2. Sherlock Holmes Debugging
  3. Plural gTLDs are evil
  4. Your Interface is what Matters
  5. Write in the Margins
  6. Meditations
  7. Better Java
  8. When names outlive their usefulness
  9. Diagnosis of the OpenSSL Heartbleed Bug
  10. The Intuition Trap
  11. Ambition
  12. The Story of the GnuTLS Bug
  13. Wrong Solutions
  14. Host an infodump session
  15. So, you want to crypto
  16. Hackers and Engineering School
  17. Strings are untyped
  18. Don't Pipe to your Shell
  19. How to Organize Your Brain with Bookmark Tags
  20. You are not a 10x Developer
  21. Windows ruins everything
  22. Don't Give Up and Die
  23. On Being Nice
  24. Bus Factors and Walk Score
  25. Wiggle the mouse to fix the test
  26. A Difficult Bug
  27. The Origins of the Diluvian Network
  28. Zipf your variable names
  29. H.264 and VP8, compared
  30. On Accepting Interview Question Answers
  31. Rate Limiting per User
  32. Write your own Data Structures