Startup Sheep Vs. Non-Startup Goats (Or Transitioning From Coder to Founder)

11 Flares 11 Flares ×

There is some famous research, by Saeed Dehnadi and Richard Bornat, about “programming sheep and non-programming goats.” The gist is that educators find that there are two populations of students, those who can program, and those who can’t. Each population has it’s own independent bell curve. This “double hump” persists despite variations in programming language, application type, IDE, and student motivation.

So, there are natural born programmers. And there are natural born non-programmers.

Most natural born programmers notice this at some point (consciously or not), but often the conclusion they draw from it is overly general. Coders who can code may naively expect to found startups that, ermm, start. Or they may expect to be naturally good at other things that are only tangentially related to coding.

Lets take the example of a founder working on a software startup. Our founder is a programmer, at the top end of the programming bell curve. He is a really smart guy, he has done some reading on startups, but he hasn’t launched anything before, and he is entirely unaware that he has developed a severe case of shit’s easy syndrome regarding the non-programming tasks that need to get done before launch.

As programmers, we learn to be obsesively paranoid with our requirements analysis, timelines, and code otherwise the project will run off the rails. But we don’t apply that same rigor for business tasks, because well, that shit’s easy, right?

Turning a project into a product – that shit’s not easy

Packaging a programming project into a product that can be sold is a complex process. Assuming that the programming side is a beautiful finely-tuned instrument ticking along perfectly, there are still a behemothic number of things that need to be done to get it into the hands of paying customers, and each decision that needs to be made opens up into a fractally expanding rabbit hole leading to an infinite number of other decisions.

It starts off innocently enough: OK I need a website to sell this thing. How about a site with a free theme plus some marketing copy explaining the product tied into a simple shopping cart so customers can buy the product.

Which quickly turns into: How about a site with a free theme (which themes are optimized for SEO, which are optimized for conversions, how about some A/B testing, hey why is my site full of spam[1] …) plus some marketing copy explaining the product (what kind of copy sells, OK “benefits” are better than “features”, but now what are the product’s benefits…) tied into a simple shopping cart (secure digital delivery, payment processing, cart software, should I write some of this myself, will this stack work with an affiliate program…) so customers (who exactly are my customers, what “tribe” are they in, how do I find them, should I try advertising, where…) can buy the product. And spirals out of control from there.

It’s becoming obvious how “hello world hooked up to a random number generator” requires a super-smart, full-time guy doing the business tasks.[2]

Meanwhile, all of the startup guru expert guys are in my head screaming, “JUST LAUNCH! Iterate later,” but at this point I have lost all sense of what is absolutely necessary to prevent everything from blowing up in my face, what will just make me look stupid if it breaks, and what I can launch without and add later.

This launch paralysis is a problem for startups on down to micro-startups and coders that are just trying to make a bit of side money off of a weekend project. Programmers are probably more susceptible to launch paralysis because we are used to just naturally ‘getting it’ (remember, we have our own bell curve), and when confronted with mushy tasks like research or copywriting that don’t require the rigor of programming, we tend to fall into the shit’s easy trap.

A Tiny Example

My idea was to launch a weekend project, and use the experience to identify problems and iron out glitches in my workflow before tackling something bigger. I uncovered more than just glitches. Everything took drastically longer than expected, and some things I didn’t plan for at all.

Time to Launch: Planned vs. Actual

The graph above is data from a tiny project that makes some head-smackingly simple changes to Amazon links so that WordPress blogs earn worldwide commissions instead of just US commissions. I assumed it would be easy to sell since the purchase is so easy to justify – once a blog has a certain threshold of earnings from, the plugin is pretty much guaranteed to pay for itself. If you are interested, click here to see how the plugin increases earnings. Now defunct.

This wasn’t a startup. Calling it a micro-startup would be generous. It’s a WordPress plugin. We’re talking 700 lines of code, tops. But it still took 5 months to launch it. I was only working on it part time, but still, the number of hours spent getting ready to launch such a simple project is staggering.

Much of that time was spent researching different tools, not actually integrating them. Luckily, most of that knowledge will transfer to future projects. Now I have a standard toolchain that handles design, digital delivery, payment processing, A/B testing, etc. I will be able to put this type of site together much faster in the future.

So, it finally launched. Sheep or goat?

Sales so far have been lower than expected, and certainly less than spectacular. At times it feels a lot like a big goat failure. But there are still some sheep to be found. After stepping back for a bit of perspective, I remember that this little failure created some big wins. First, all of that research gave me a standard toolchain for launching mini software startups (see my toolchain here). Next time things will move much faster. Second, even though the plugin hasn’t earned much through sales, having it installed on my own sites has given a nice bump to passive income.

The launch isn’t really the end of the story. After launch comes a whole new rabbit hole of customer acquisition and iterating the product. It’s a bit too early to make a success or failure call. Everyone says that an overnight success takes years.

Edit: This project now defunct. I still use the plugin on my own sites where it has increased earnings a fair amount, but the support and website maintenance overhead associated with selling the plugin to others was not worth my time.

  1. Why you should never search for free WordPress themes []
  2. This is in reference to Patrick McKenzie‘s Bingo Card Creator software, which is technically pretty unsophisticated itself, but is supported by complex mechanisms for A/B testing, scalable content generation, conversion tracking, and various other types of optimization. []
11 Flares Twitter 11 Google+ 0 Facebook 0 11 Flares ×
# March 29, 2012 2 Comments