The Duke's Discoverage

Flow is described as “mental state of operation in which a person in an activity is fully immersed in a feeling of energized focus, full involvement, and success in the process of the activity”, and said to require 1) clear goals, 2) skills matching the challenge and 3) clear and immediate feedback. Last weekend, at least about 100 people experienced that state at the Aalto Venture Garage.

Garage48 is a 48 hour event where a number of web apps are created from scratch to launch by teams assembled based on people’s preferences on 90 second pitches. As an event lasting a single weekend, it is the greatest way for creating value in a startup ecosystem, for multiple reasons.

Agile startup destruction

First of all, every time such an event is held, many potentially great startups are born and launched. Most, of course are scrapped because the founders already have other things to do, but the best ones might actually become something. 

If you think about it, it is an extremely effective way of testing out a startup idea: if it creates actual value after just 48 hours of coding, it actually might have a future. And even if it doesn’t work, the founders have learned many lessons about team, working habits and so on. I ended up getting a bit of both.

Bookstrapp — flow, case in point

Our Bookstrapp team was some sort of a miracle: we originally had ten people which had been filtered in by being required to operate in a PHP-based environment, but that was the only common denominator. In addition to me and Tuomo, we had two guys who we had previously worked with, but both bailed on Friday evening.

So basically, it was just me and Tuomo and six people we had never worked with. I don’t know what initiated the process, but the team ‘clicked’ very quickly and went straight to flow mode. This post attempts to dissect what happened.

Focus, focus, focus

I think the greatest contributor to our state of flow was the fact that ten minutes from team formation, we had shut out every possible distraction. No cell phones were answered, the door was shut and everyone was wired into their own computer. The only speech was discussion of certain design aspect.

Actually, the funny thing was we discussed very little on how the product should be, because we seemed to share a strong vision from the very beginning. It might sound that it was boring, but really everyone was just so determined to do their part and the atmosphere was positive throughout the weekend, even when everything seemed to be failing and the time running out.

Skillset overlap, parallel task division

Another thing contributing to the flow was that we didn’t have collisions in work division: we had overlap in skillsets, but one PHP programmer was doing one feature and one the other. Also, because all PHP programmers could do both front end and back end, we didn’t need to wait around for the outputs of other people. 

I think this is a huge thing contributing in the speed and success of a project. If you try to do a feature with one back end developer and a front end designer, chances are that the front end designer has to wait for the back end designer to finish. 

Independent developer is a fast developer

Much better is that the front end designer has enough back end knowledge to be able to develop the front end alone and when he gets stuck into some more difficult issue, he can ask the back end guy for help.

I think this was the most important lesson I learned during the weekend and we will apply it directly in the development of Dealmachine.

Launch every day

The final lesson that can be learned, which is of course quite obvious, is the fact that launching early forces the team to focus on a narrow problem and solve it well. In this sense, I totally agree with the 37signals philosophy of “Half, not half-assed” (Evan Williams agrees).

When you have too much resources, you try to do exhaustive feature sets and end up finding out that your original plan didn’t take into account certain emerging problems which end up delaying you and destroying the quality of your product.

When you force yourself and your team to launch as often as possible, you can be certain what you can achieve in a given timeframe and drop features that aren’t critical.

So, there you have it. 24 hours later, I am very tired but satisfied. Our product also kicks ass. Check it out: http://bookstrapp.com

Thanks for everyone attending!

-t