Case Statement

Product Kata

A friend told me that he would never build a new product from scratch again. It’s painful, annoying, and you never know what you missed until it hits you at 4am. Day. After. Day. Week. After. Week.

The whole process of releasing something is so full of complicated, little, nit picky details that I can’t help but feel like I’m spinning my wheels. This is really difficult because I’m also working a full time job. It feels like every hour I can spend on a side project needs to be productive.

Building Frustration

Two years ago, I had what I thought was a great idea. I talked to potential customers and there seemed to be consensus that there was a business there. Then I tried to build out my idea as a minimum viable product (mvp). I figured I could have something running in a month. Eighteen months later I had only spent maybe 80 hours on the project. It was something I thought about all the time, but it was incredibly difficult for me to work on it during evenings and weekends. I felt as though every time I touched the program I’d run into a problem or limitation, not with the concept, but with some third party service or library.

As I kept eating up my time reading documentation, digging through source code on github, weeding through stackoverflow, and fighting installation dependencies I started to doubt the fundamentals of my idea. What was my engine of growth? How could I attract initial customers if it wasn’t a problem people searched google to solve? Instead of being able to test any of this, I became more and more frustrated until I stopped working on it altogether.

People say that just releasing something is one of the biggest hurdles. I believe that releasing something is difficult because most coders only ever work on existing products. The foundation of a program is usually only ever built once, usually by a single person, and rarely documented.

There is very little novel code in an mvp; it’s all wiring and dependencies. This is almost (or should be) the exact opposite experience of working on existing products. At work, I’ve always coded on or around existing products, it’s fairly rare that I run into a situation that something completely new has to be built. There are libraries and tools and conventions you can fall back on when working around something someone else has built. I suspect this is likely a reason that many bootstrapped businesses come from the world of consulting and contracting, since they are more likely to be involved with projects during their inception.

Build Everything

So my new plan is to become adept at building. I want to take my simple, stupid ideas and dedicate a weekend or two to getting as far as I can to a released product as possible. Then I will leave it where it is and move on to the next idea before I get frustrated and never want to work on it again.

In the same way that there are code katas, I am practicing product katas.

Right now, I’m nowhere close to releasing something in a weekend, I’m not experienced enough in taking these raw libraries and services and building a customer ready application. But every time I build out a new idea I get much further and learn to solve new problems.

The first Rails app I created took days for me to really figure it all out, now I can prototype something in minutes. I ran into problems deploying to Heroku initially, now with a few apps, there’s no problem. It took me weeks to learn the different components of AWS, but if I want a new instance I can have it without thinking. I could name dozens of problems that I’ve run into with each idea I’ve tried to implement, but with practice I’m learning to solve them more generally and quickly.

Eric Reis talks about the build, measure, learn cycle. The faster you can loop through the stages, the more likely you’ll build something that people want. The more ideas that you can build, the more likely you will find one that succeeds.

They say practice makes perfect. I’m just trying to clear that first hurdle.