Moving from Prototype to Production

Why do projects rarely turn into products?

Living at VeloCity for the past term, and being involved with a few side projects myself (for the record, inflo is not a side project, it’s a startup), I’ve noticed a general trend: lots of stuff gets built, very little is ever used.

Projects often remain just that – projects – built for the joy and satisfaction of building something. Which is fine – I can say with confidence, at least in my experience, that the most effective way to learn something is often to dive in and immerse yourself – to get in way under your head, and then crawl your way back to the surface with the support of others. If learning is the objective, it’s a great approach. If building something useful is the objective, it’s backwards.

The mentality is multi-fold:

  • To build something useful requires you ┬áto solve a problem people actually care about. It’s fairly unlikely that this is the case if you never consulted your target audience in designing the prototype, as hypothesis of what people want are almost never entirely correct. Projects are often spawned out of people wanting to build stuff for their own use.
  • Turning prototype code into production code is hard and boring. Sure, building something that works is one thing. Building something that’s secure, bug-free, looks nice, and will scale well is entirely something else, and ┬ájust isn’t glamorous. Features and flashy are much more exciting.
  • “Patience is a virtue, posses it if you can. Seldom found in women, and never found in man.” Rome wasn’t built in a day, and neither was Facebook or Google. Just because something doesn’t gain traction in a few days doesn’t mean it’s time to move onto the next thing. Sure, iteration is key, but give the thing a chance at life by at least spending as much time buzz-generating and blogging as building.

I am most interested in building things to solve real world problems – to bring something valuable to others. To do so requires a 180 degree shift in the way we typically approach building things: it starts with the customer.