The Product Development Triathlon
facebook.com
facebook.com
> You could say that Google makes its living by finding problems that have this kind of shape [0]
Kent Beck says,
> I hope I’ve convinced you that this really is an awesome awesome stick.
No, not without an example.
Of course that's only for running the company. Developing code in startup are more like running a kitchen. You need to get a group of random people to produce a good product under intense pressure. Everyone is responsible for their own area and need to produce good quality in sync with everyone else, but management is ultimately responsible for the quality of the product.
But as I said, I'm not sure how useful this is. If people just realize that running a startup or developing a product is mostly like organizing any successful project and not some special thing that you learn solely from blog posts and venture capitalists.
PS. Things like the waterfall model is often useful if you're optimizing for getting a specific product out. Startups often struggle to get anything out or establishing themselves in the market, which is why it's useful to do things differently. That doesn't mean startup style projects are suited for every industry which seems to have become a widespread misconception.
> Part of the key is letting go of the idea of experiments "failing". An experiment only fails if you fail to learn from it. Experiments should turn out the way you expect half the time, if you want to maximize learning.
i guess the principle being propounded is that of 'fail early and fail fast' or be wrong as fast as you can. because, to be wrong as fast as you can implies that you sign up for aggressive and rapid learning. more importantly, failure is a manifestation of learning and exploration. if you are not experiencing failure then you are making a far worse mistake...
as in science, experiments should be considered fact-finding missions that over a period of time inch towards greater understanding. which implies, that _any_ outcome is a good outcome, because it yields new information. if your experiment proved that your initial hypothesis was wrong, better know it sooner than later.
unfortunately, this is easier in a lab, than in business :(
This is an interesting article IMO. I don't think many of the organizations I've worked in are mature enough to shift their process as they cycle through these phases, though.