Some time ago I had a very fruitful retrospective session with a team which I support. It was about approach to prototyping. We created a “prototyping contract” – a set of general rules that we would like to follow while prototyping and testing product development ideas. I realized that these few points are very universal, so I would like to share them with you to help you properly experiment and implement empirical approach in your team.
MVP != prototype. MVP stands here for Minimum Viable Product, so a version of product with just enough features to satisfy early customers and provide feedback for future development. Prototype is something a bit different than MVP – it is just a sample of functionality which can be used to gather customers feedback but is not satisfying their needs. Here we would like to define rules for prototyping, not for MVP creation.
Prototype only things which you are not sure of. There is no need to prototype everything only because you can. Prototyping costs. It helps you to save money if your initial assumption was wrong, but if you already know that you will implement feature and release on live no matter what, there is no reason to invest effort into prototyping.
When you want to prototype, you should always define hypothesis which you want to test and metrics based on which you assess whether hypothesis was achieved or not. Having hypothesis and metrics allow to better define what needs to be part of the prototype and what does not. You need also to be ready to give up further development if after the assessment results are different (worse) than you expected.
Never ever you should have prototype existing on production in long term. There needs to be an agreement, that whenever you prototype something (prototype, not even temporary solution), this is only for the purpose of checking something. After checking is done and hypothesis verified, prototype is removed and decision about developing or not developing the feature needs to be made.
To properly prototype and develop you should check development direction before investing into process automation. Oftentimes, the development direction is defined based on nothing – no information or data, which could prove that decision makes sense. To prototype and test something you need the data driven approach.
For prototyping you need to deeply think how to go fast (taking shortcuts, using ropes whenever you can), trying to identify critical path. Only critical path needs to be developed, the rest can be hardcoded or covered even by “protein interface” (aka human being).
First you should consider the possibility to verify hypothesis even without investing in any development. It is possible way more often than you think.
That’s all – a cornerstone of our prototyping approach. What kind of rules do you follow with your team? What is your “prototyping contract”? Please share it in comments.