In an engineering organization there is normally not a lack of ideas. What if we make the button yellow instead of orange? Why can’t we use drag and drop between the mail application and the calendar? And wouldn’t it be nice to have our logo in gold on the new top of the line product?
Ideas are normally not the problem, however incorporating everything that could be “nice to have” is normally not done in new products. Maybe it has a cost associated to it, and maybe it will complicate production, and maybe users will not use the new feature. So why not build and test it?
In software development just as in organization development, changes do not have a large initial cost. No machines need to be modified and no equipment needs to be purchased and ordered. However there are large costs for having features you do not use. They must be maintained and further complicates the use for all users who do not want them. They also might lead to unpredictable behavior and complications when future changes are incorporated.
It is quite simple, what is the easiest way to test our idea? Is it by developing a new product for 3 years, and then ship it to the global market and wait? Or is it to find a
potential user with a problem, and see if we can test our idea on them? To be effective in our “scientific approach” to test all of our ideas we need to design the experiment small enough, but still representative enough to be tested. The principles to find a good balance was: Test it in a real industrial setting: A workshop or a game is fine, but it is first when people use it for real when we can see that it works. Test an absolute minimum “thin slice” of the product: value is often generated by a small portion of the product, lets focus on that. Continue to use the product forever: if the test is successful, continue to build on it and document your learning’s.
Read More in the first “Whitepaper” from Project Visit.