Subscribe to blog updates via email »
“Will it scale?” is a less important question than “will it ever matter?”
The rise of automation and computing power has lifted vast segments of the population out of manual labor, thus freeing up their minds to pursue more existential concerns (such as making apps that make it so you can say “yo” to your friends with a tap of the finger).
But just because you can avoid “manual” labor, doesn’t mean that you always should. Having a system that does something quickly and easily is only worth it if you’re doing it often enough to merit building that system.
If you aren’t a big company, especially if you’re a single-person company like mine is, you need to find out if it matters whether something scales or not before you go through all of the trouble of making it scale.
WANT TO WRITE A BOOK?
Download your FREE copy of How to Write a Book »
(for a limited time)
As you read this, at some hackathon somewhere in the world, wantrepreneurs are rubbing their chins and pensively asking “will it scale?”
The question they should be asking is “will it ever matter?”
(Thanks to commenter Ken Doman for pointing out this perfect XKCD cartoon.)
Wantrepreneuritis made me ask “will it scale?”
When I did my first product launch, as I struggled with my own wantrepreneuritis I tried to make everything “scalable.”
I had a customer login area for…well, just because I probably felt like I should.
I had to do a bunch of hacking so that my payment processor would integrate with my member portal, which would then integrate with MailChimp, so customer data would be consistent across all of the systems.
This stuff took me months to figure out! I researched dozens of different configurations, then finally built it.
I was waaaay too concerned with whether it would all “scale” or not – way too concerned with avoiding doing “manual” labor (and doing way more labor than if I had just done that “manual” labor in the first place.)
When I finally launched my product, it just did “okay.” It didn’t matter that I built systems that could scale. (In retrospect, even if it had been explosively successful, the systems still weren’t necessary).
I cured my wantrepreneuritis by asking “will it ever matter?”
Last week, when I launched the Design for Hackers Video Course, I did things differently. I didn’t worry about making every last thing “scale.” I even scrapped the system that I had already built! It was too much of a hassle, and would ultimately slow things down.
Here is a list of some of the things that didn’t “scale” from my launch. Some of them could be considered downright “ghetto.”
- The product is just HTML pages with Wistia videos embedded. There isn’t a secure login. Gumroad (my payment processor) sends digital files, so this was the most straightforward way to deliver the product. A “customer portal” wouldn’t have added much value for the customer.
- The sales page was static HTML. I didn’t want to deal with integrating it into some kind of a WordPress theme. To get “smart quotes,” (hey, perfect typography is still important), I copy-pasted HTML from a draft page I created in WordPress.
- I didn’t have version control for the sales page. “Pushing changes” consisted of uploading the HTML file (and CSS, if changes) via FTP. I don’t do development on a regular basis, so I’m rusty with version control.
- I manually replaced the landing page with the “course closed” page when the sales deadline passed at midnight on Friday night. I could have figured out how to do this programmatically, but it would have taken me more energy than it was worth.
- I manually updated people’s MailChimp files. I could have updated their files using Zapier, but that would have overwritten all of their existing group settings. So, I did a copy-paste import.
- I manually reconciled email addresses across systems. Even though I auto-populated the “email” field in Gumroad’s checkout using a URL variable, some of the email addresses for customers were different from the email addresses on their MailChimp files. So, I had to manually contact those email addresses to find out what email address they had subscribed to my list, so I could update their MailChimp files. (I only marketed the course to existing list members.)
- The community is just a private Facebook group. I might have been tempted to build my own community using WordPress, but that’s too complicated, and people already use Facebook much of their day. Why reinvent the wheel? I manually added people to this Facebook group.
- I fielded all support requests and questions myself. I’m still learning about my customers, so I consider it R&D.
- I used Zapier to send confirmation emails to people who had bought certain products. This is some slick automation, but the emails were sent through Gmail, which has a 500-messages-per-day limit. This wouldn’t scale if I had more than 500 customers in a day (at which point, I could afford to have a more elegant solution built).
I knew that my launch would be relatively small (fewer than 200 customers), so these manual tasks didn’t worry me. Since I did a “windowed launch” (with a start and stop date), I don’t have to worry about being distracted by these tasks while I service my new customers, and collect feedback for the next iteration.
Still, the launch went much better than my previous one had. I made over $17k in revenues over the course of the 4-day launch.
Manual labor != poor product!
This is not to be mistaken for delivering poor product. I (and my customers so far) believe the product is excellent, and in any case, there’s a money-back guarantee. This is about cutting out those things that don’t provide value for the customer, and not being afraid of a little “manual labor” if it helps you get your product out faster.
What do you do that doesn’t scale? Better yet, what are you going to start doing that doesn’t scale? Share it in the comments below.
[New Post] "Will it scale?" is a less important question than "will it ever matter?" http://t.co/xf4KnbSiPy
— ? David Kadavy (@kadavy) July 30, 2014
Related: Do the things that don’t scale by YCombinator’s Paul Graham is full of practical ways to re-think what needs to be scaled in an early-stage startup.
