Get ready to learn fast and fail forward

By The App Business under Insights, Agile 25 February 2016

At our recent Breakfast of Champions event, I manned one of our topic hubs, which looked at the value of lean experimentation in helping product teams learn fast, and fail forward. In this post, I plan to unpack that topic in a bit more detail.

Getting over the F-Word

To get us started, we need to confront the F-Word - failure. The sound of the word alone is enough to make us despondent. Failure is, however, a great unifier: it is something that all of us have, and will, encounter - without exception. Failure is also an effective teacher: it’s just that sometimes, we learn the wrong lessons from it.

In many companies, for example, failure is the thing that Must Be Avoided At All Costs, and that is understandable. Failures can be damning, detrimentally impacting upon time, resource and budgets. Unfortunately, however, this desire to avoid failure also leads to okay decisions, safe choices and less-than-exciting opportunities. In short, mediocrity - which in turn stifles the very thing so many companies are striving for in the face of disruption: rapid innovation.

At TAB, we believe failure doesn’t have to be a negative thing if you plan for it, and know how to manage failure effectively. We don’t set out to welcome failure with open arms (TAB is a company of perfectionists) but, if set up correctly, we know failure can teach us a lot and help us to continuously improve. The difference, therefore, is not to be afraid of failure.

There are, after all, countless success stories of products that were initially designed to do a particular job, but that didn't quite work out as intended. So, their creators pivoted the product or adapted the offering - famous examples being Pinterest and Instagram. These companies used what they learned from failure to rethink their product and create something else. In those cases, failure was used as a stepping stone to a better product.

The key is to minimise the failure where you can so that it is easy to learn and move on from. It’s a bad idea, for example, to put all of your eggs into one basket, all at once. Put a single egg in, and see if the basket holds before you add another one. This way, if the basket breaks, you will lose only one egg - and not the whole dozen.

Enter lean experimentation

Lean experimentation is an invaluable way to minimise the risk of failure. In its principles, lean experimentation is similar to those that underpin the method of creating an MVP. For both, you distill what you need to do down to its very core, just enough so that it is lightweight, but not too much so that it loses all value. Then you build something you can test, and improve it incrementally.

Lean experimentation, however, can be employed before building your MVP. Where an MVP allows you to test a live product with a prioritised, defined feature set - however ‘lean’ that list of features may be - lean experimentation affords the opportunity to test and validate your thinking, or your ideas, before you launch into building a product.

Your awesome idea, which might subsequently become either a new product or a new feature, needs to be explored and ‘beaten up’ (as we would say at TAB) before you commit further resource and time to it. That is because, once you begin to test and validate it, you might equally realise the idea isn’t quite right, or needs to pivot.

User testing and research in the innovation lab or back at the office can be a great way to gauge this, but it is not always accurate. This is especially true if your potential concept for a product or service is breaking new ground, or is rare within your marketplace. Research participants can find it hard to put themselves in the scenario you are asking them to and give ‘real’ answers.

This very topic will be the theme of an upcoming post from fellow Product Owner, José Carbajo, who ran a neighbouring hub at our Breakfast of Champions on the value of user testing in the wild. For the purpose of this post, let’s just add that while we are big advocates of putting products in user hands fast, it is not always smart to build something you are unsure about: there needs to be a balance between effort, and learnings.

First, define the problem

First of all, forget about your product idea. Forget about how amazing it is. That might well be true, but you can’t prove it yet. Focus instead about the problem your product is trying to solve. What is the job it is actually trying to do? With the egg and basket example above, the basket is the product, and the problem is that there is no good way to transport eggs.

Here at TAB, we are big advocates of stripping requirements right back to the outcome you want to achieve. This allows you to focus on the problem and think about multiple ways of solving it, as opposed to honing in on one solution too early. If you do that, and subsequently discover it is the wrong solution, the failure you encounter will be far more costly.

So remember that what you are validating is not the solution: you are exploring the problem, or the need, itself. By focusing on the job that needs to be done - transporting eggs, for example - you can better think of a way to get to this goal simply and effectively. This becomes the basis of your experiment: the hypothesis you are testing against to determine which way is the quickest, easiest path to solving the problem or achieving the user outcome.

Next, create the experiment

So you have identified the problem or the outcome. Now you need a way to test your idea against it. First, define the data you need and what your success criteria looks like. When your experiment is complete, it is this data and a clear picture of whether your experiment worked that gives you the go/no go filter for deciding whether your idea should progress further. You also need to set a clear timeframe, so that your experiment reaches a conclusion, and you don’t end up endlessly iterating. Remember, however, that you can always adapt the timeframe depending on what you discover during the experiment.

There could be multiple boxes you need to tick, and you need to be precise about how you are going to measure them. Think about everything you want to learn from this first iteration, and define the data you will need to capture in order to do this. What events and triggers do you want to track? What are the paths that users take? All of this will serve to measure success, but also provide essential insight into how your users are actually interacting with your product in order to achieve their outcome.

Without collating the data, clearly defining success and setting an agreed timeframe, you will be flying blind with decisions made on gut instinct. That isn’t great if your gut told you to go in a different direction to what your users needed. In addition, without those components, your experiment will struggle to reach a concise, valuable conclusion and clarity on a way forward.

So, in summary, lean experimentation will not guarantee success, but it will enable you to learn quickly, uncover what success looks like and help you gauge whether your great idea should carry forward into the next stage of its development. Here are six top tips to get started:

1. Do not be afraid of failure: it is an opportunity to learn and continuously improve;

2. Forget about the solution, and focus on the problem you are trying to solve;

3. Think about the most lightweight, but robust solutions to the problem;

4. Set out specific targets and measurements so that you can test and inspect;

5. Give the experiment a clear timeframe;

6. Review results against your targets and success criteria to determine next steps.


If you are interested in lean experimentation and would like to learn more, drop us a line.