Reviewing the “Build-Test-Learn” Cycle from a Duplo Project
Be humble and observative in everyday life, you will learn quite a lot. This is one comment to my above post on LinkedIn.
This time it is about building a Duplo Railway. My 3-year-old boy started by observing how his 6-year-old brother build with Duplo. Having no burden at all in mind, he started his own “project”. He started to build, then he tested it very quickly to see if it is stable and finally he continued, of course, with some special learnings from each previous iteration he ran through.
“Build-Test-Learn” was performed so unconsciously by a 3-year-old boy, just like as if it is from the nature!
Wait, maybe it is really a born-with skill which is forgotten during our growth.
“Build-Test-Learn” cycle is the backbone of different agile methods:
Design Thinking: We build our point-of-view via synthesis from different perspectives/observation, turn our ideas into prototypes for testing in order to gain feedback in early development phases. Sometimes we might even skip some steps and instead of “Build-Test-Learn” we just “Build & Learn” or “Build & Test” or “Test & Learn”.
Lean Startup: With this approach we do not do heavy investment in the early development phases, instead we build low-fidelity to high-fidelity prototypes, MVPs to test our business ideas. Only when we find the correct product/service-market-fit we will start pumping money in the project to start quick implementations.
Growth Hacking: In most of the digital or data-driven (startup) projects we try changing different parameters to gain growth. Not every change will generate the expected growth. We have to do quick experiments. Figure out one single growth-parameter which could lead to critical growth, do a one-week experiment, analyse the data and decide, if it is worth of continuing. In a “black swan” case we should invest 10x of our resources to achieve a 1.000x growth within very short time.
Scrum: It is a framework for approved projects. Nevertheless we are still in the “Build-Test-Learn” cycle, in which we (try to) deliver shippable product (-increments) to gain customer/user-feedback from sprint to sprint.
Most of the time we forget one essential aspect about innovation management is the management of failure. I do not mean avoiding failures but how to make meaningful failures in order to learn and grow faster.
We are – among other thanks to our education system and our successful past – afraid of making failures and this becomes a heavy psychological burden for us to bear. And we lose our ability to be courageous enough to make failure. To avoid making failure we do not build, with no building we can not do meaningful test, and without meaningful test we can not learn.
Learn from our kids, or learn from our previous selves, be bold to “Build-Test-Learn”.
Add on 16th of September 2021:
- It is important to add “Hypothese” before “Build”; don’t fall in love with a certain idea to early, treat it as a kind of hypotheses, test it before building it correctly. I heard a real-life story about a previous project in which I was involved. There seems to be a dramatical U-turn in the project for missing testing a certain hypotheses which no one believed it.
- The purpose of doing all these steps is to LEARN. If you can build to sell, surely good, this could even validate your hypotheses if customers/users are willing to pay for your MVP. If not, see within the shortest time to learn from it. I recommend you read this post of David Bland.
