You are building too slowly

When I was a child I played with Lego. If I was at home, I had the leisure of playing with my own Lego, and I could take my time and build an elaborate creation. I would go to meticulous detail in building ships, castles or other buildings. I realized there was a certain serenity to playing my own sandbox at my own pace. When I went to kindergarten, I noticed they had a large box of Lego. When I went to play with it for the first time, I got upset that there were other kids taking blocks I wanted to use. I wasn’t afforded the luxury of taking my time, because if I did, I wouldn’t have the pieces needed to complete what I wanted to build. This is a simple parable but it made me realize that I was building too slowly, and not afforded infinite timelines.

I thought back to this during Democamp, where a company named VidYard built an impressive application in 16 weeks, got funded and are now on the upswing. This example made me realize that if you think you are building something quickly, you probably aren’t and will pay the price for it. The level of competition in the software/web application space has only gotten more intense. The ability of a focused and dedicated team to build something quickly is needed more than ever. What I have come to realize is that zealotry of innovation is powerful. People with a taste for both innovation and building something are hard to stop.

Last week, due to this epiphany, I decided to try to tackle something in one week that would normally take me multiple weeks. I refocused, got team buy-in and went to work. This didn’t come without bumps – the time I would normally take to think out every nuance was not there. I stayed up late and built and tweaked until it was ready. I would argue that a perfect plan with nothing built takes a backseat to something that works that perhaps isn’t perfect. It may sound cliché, but a good plan today is truly better than a great plan later. At the end of the week, I lost a lot of sleep and built out something cool. I didn’t quite hit my timeline, but when I looked back at the week, I saw that my team and I had built a lot and learned a few lessons.

So you want to build something quickly? How do you do it?

1. Set an unrealistic timeline. How better to start this project? Ask yourself how long it would normally take on this project and cut it in half. Setting an unrealistic timeline does two things: 1) it makes you scramble and 2) if you manage to pull it off you will get a huge amount of wind at your back and it will inspire you to do it again. Even if you miss your mark, you will accomplish a lot in that time because you are working your ass off. Think of Darth Vader in Return of the Jedi. He lands on the incomplete Death Star and basically says this thing will be operational or you have to deal with the emperor. Without some brash ambition and, frankly, a bit of fear, you won’t know how fast you can move.
2. You need to be 126% committed to building something quickly. What does that mean? It means while you are building it, you need to detach from the outside world. Cut out the distractions (Twitter, Facebook, casual web surfing). As much as we love these things, you need to cut them out. Get your team onside, lay out the parameters and just start building. Reconnect regularly with updates, but focus on moving forward. You need to be willing to sacrifice a little bit of sleep and fun, but you will be happy when you get the results. Distraction is the enemy. I can virtually guarantee that someone else has shared that same idea. It is question of whether you want it more than someone else.
3. When you’ve finished it, evolve it. Like any good lean agile project, as soon as you are done your project, evolve it. This can’t be a one off; you need to evolve. There are reasons that many agile methodologies use the concept of sprints. Those “sprints” can’t be leisurely strolls. After you are done your sprint take a quick break, re-evaluate what you have built. Determine what mistakes you made, fix them and try it again.

These are the caveats to taking this approach

1. Whatever you build needs to work – if you build, make it functional.
2. Whatever you are building needs to scale – If you Frankensteined something together with a sloppy code and approach, it is not going to work.

Going back to my original point, the luxury of building something slowly in this day and age is gone. You will get beaten to the market and beaten because those going to market faster will be able to iterate circles around you. It is time to ask yourself, am I willing to bust my ass to get this done quickly or do I perpetually want to come in second place?

[retweet] [facebook]