Thursday, March 25, 2010

Over at Harvard Business Review, I've been building up a series designed to introduce the Lean Startup methodology to a business-focused audience. This is the first post that moves into making specific process recommendations for product development. Here's an excerpt:

Every startup that achieves success eventually faces a critical moment — whether to speed up or slow down. It usually looks like this: the can-do attitude and high-bandwidth communication that characterized the first few iterations have produced magic. Everyone was in the flow; the team was hyper-productive. In many cases, they did the impossible, building a new product faster, cheaper, and better than anyone could have predicted. In the early days, chaos stayed under control. Duplicating efforts and stepping on toes was quickly resolved by short all-hands meetings. Firefighting was part of the fun of living on the edge. Defective prototype code was as often thrown out (because customers didn't want it) as it was fixed (when customers did). Hence, cutting corners often paid huge dividends. And with success came growth: in resources, staff and attention. And a certain amount of chaos reigned too.

But as the team gets bigger, early mistakes become more costly. Pretty soon, a soul-searching meeting ensues. 'Are we going too fast?' 'Will the addition of process kill our innovative culture?' 'Well-functioning teams just don't make these kinds of mistakes, right?'

Over at Harvard Business Review, I've been building up a series designed to introduce the Lean Startup methodology to a business-focused audience. This is the first post that moves into making specific process recommendations for product development. Here's an excerpt:

Every startup that achieves success eventually faces a critical moment — whether to speed up or slow down. It usually looks like this: the can-do attitude and high-bandwidth communication that characterized the first few iterations have produced magic. Everyone was in the flow; the team was hyper-productive. In many cases, they did the impossible, building a new product faster, cheaper, and better than anyone could have predicted. In the early days, chaos stayed under control. Duplicating efforts and stepping on toes was quickly resolved by short all-hands meetings. Firefighting was part of the fun of living on the edge. Defective prototype code was as often thrown out (because customers didn't want it) as it was fixed (when customers did). Hence, cutting corners often paid huge dividends. And with success came growth: in resources, staff and attention. And a certain amount of chaos reigned too.

But as the team gets bigger, early mistakes become more costly. Pretty soon, a soul-searching meeting ensues. 'Are we going too fast?' 'Will the addition of process kill our innovative culture?' 'Well-functioning teams just don't make these kinds of mistakes, right?'