“One must learn by doing the thing, for though you think you know it-you have no certainty, until you try.” – Sophocles
I always thought this was an interesting quote. You cannot gain any certainty without trying … something. And even at that, you may actually fail. But if you are truly learning, you adapt and adjust and give the next experiment a fair shake of success.
From software to science, using experiential learning as a way to define an experiment, to conduct and observe the outcome to potentially learn and adapt the experiment as needed has created amazing products and scientific breakthroughs. It works. I think we can all agree on this.
So, why do you think we don’t apply it to something like organizations?
Fear of Failure
Thomas Edison is quoted to have said “I have not failed, I have just found 100,000 ways it will not work” in relation to his research into the first lightbulb. This is a very healthy way to look at progress but very contrary to a lot of business thought. Why do you think that is? My speculation, which could be very wrong, is that for Edison there was the possibility of the realization of a dream forged from that creative spark with future potential of a product. For many businesses, the future capital earnings heavily outweigh the creation of “the thing”. Many of the successes in the world have been born from the want to capture an idea and then only become monetized later therefore reducing the fear that capital is burnt without return.
Often times, creators of these eureka products (Google and Facebook as a couple of examples) are often shaken by the idea of monetization as the creation was the core driving factor, not the end profit result.
I honestly feel that the initial introduction of the drive to capital gain often induces this fear and it creates a trickle down effect from the very top all the way to the source of creation of the product. The pressure to get to market first and capitalize of the highest money stream may cause people to become less innovative, take less risks and instill a fear of product failure even before it hits the waters.
But I contend that keeping the horizon for learning at a “just enough” level not only helps you determine a better product but it can save money from building out full features that are often unused (see the pareto principle as applied to software features) or poorly received.
Minimal Viable Product
Eric Ries of the Lean Startup approach introduced this concept (I think it had rolled around for sometime but he is connected with the idea) as producing the smallest amount of the idea to learn from. Basically a seed of a product to gauge a posture to “pivot or persevere”.
One of the most noted examples of this approach is Dropbox. The initial MVP for this product was a marketing video explaining the product and how it would work. This was launched and an accompanying form was created so that potential customers could sign-up for future information about the product or provide feedback.
This allowed them to gauge interest to know if their investment into the product in which they saw high potential value showed a reaction by their potential market. This was actually one of the most brilliant approaches I had ever seen. They were actively working on the product and seeded their base features before completion to test the market space. Had they gotten a less than exciting response, they could have targeted marketing research and determined why or pivoted their approach in some way (either the campaign or the product work).
How did this help them in proceeding this way? It allowed them to learn about the interest of their potential market and gauge feedback from customers before launch so they could consider the feedback and potentially pivot with the market. If the feedback was a “lame duck” they could have abandoned the product altogether and pivoted towards a new direction. This allowed them the potential of failure much earlier. The potential magic of all product management after this stage is having that gut feel for how long you can ride this curiosity until the product must get to market. This is why really good product owners stand out.
Minimal Marketable (or Lovable) product
This is another concept introduced that we see extremely frequently in the market space of software and software services. Determining only those core level services or features that get buy-in to a product for more. This means that product vision has to be solid to get these to market and feedback and seeding of new features is sought to be cadenced regularly.
The initial iPhone release is a prime example of this approach. When initially released, the iPhone lacked many features that were present in many of the competition in the marketspace (MMS messaging, apps and the ability to copy and paste). But when released it became one of the fastest selling phones in the cell phone market (competing more closely with mass volume sales of game stations like the Play Station 3). Which it did seed was a phone level OS with an SDK for developers to build upon (even though there was no store in place yet for deployment or sales mechanism). These “missing features” allowed them to gauge the market reaction as they had faith in their initial MMP to ensure the importance of future features and to allow them space to ensure that they released the best quality updates with these features sought by customers.
They released a product that seeded a way for it to grow (the iOS Phone SDK), made it available to the developer community and focused on those features of differentiation that allowed them to not only contend with the market but even under strong criticism and scrutiny release the features not initially there in a thoughtful way consistent to their brand and end goals. They essentially “hooked their customers” through thoughtful and innovative design and a stellar responsive interface (far better than competitors) which allowed them to build the features that would build a community around the product. By making the Phone OS available, they even made it possible to “jailbreak” the phone and create some of the missing features which could allow them to gauge what potential customers seemed to be drawn to use. This allowed them to strive to introduce the right features at the right time and draw from the community at large to create a learning opportunity and pivot as needed.
The Design Sprint
Another recent approach to the idea of validated product learning is the Google Ventures Design Sprint . This idea distills the idea of rapid learning through a functioning (and often simulated) prototype to gauge immediate and rapid feedback from real potential customers for a idea over a short span of time. O’Relly Media has also written an excellent book on this approach which can be found here. The idea itself has been around for sometime and often attributed to be initially used at IDEO Design as early as 2009.
The idea divides the approach optimally into a 5 day approach which breaks down to one day focused on the following events:
- Understand – Define and unpack the problem to solve (though interviews and research)
- Diverge – Generation of ideas to solve the outlined problem (more is better, no wrong answers)
- Converge – Determine which ideas or pieces of ideas will be pursued for testing
- Prototype – Build a prototype of the solution that end users can actually play with and develop testing criteria to observe
- Testing – Validate your assumptions through observation of user interaction with prototype and providing feedback
Here are a couple of real world examples of how this has been performed
This approach may not work for every scenario but as a tool in your toolbox for learning, this can be a rapid way to learn what resonates with your potential market and generate immediate feedback from real-world interaction.
So, where does that leave us?
In the vein of this blog being focused towards being about agile leadership, I wanted to explore this topic to hopefully inspire those leaders to truly see the value of a targeted small experiment from which you can gain quick knowledge about your potential product from which you can pivot, persevere or abandon. The key being that failure should always be an option but seen as a mechanism for learning and focus as opposed to use as something to vilify a bad approach.
I hope this will guide you to finding tools to help you target your search for knowledge or even better be inspired to create the next approach of which I blog about.
Fail fast and stay agile!