Posts Tagged ‘experiments’

A lean template for Product managing

July 26, 2016

Having recently read the Lean Startup and Start with Why I wanted to bring the two together, as I feel they can work well together, and expand upon templates I have seen online related to the Lean Startup (with the best being here).

For those that are not aware, basically the learn startup is about taking a belief, idea, problem, and turning it into small and simple experiments to try and prove or deny the belief, idea, problem as a product before you bet the farm on it and risk losing everything or spending N months to discover your idea does not work (i.e. fail fast and iterate).

With regards to the Start with Why this asks you to look at your idea, problem, and think about it from the angle of why you want to solve this rather than how you are going to solve it. Detailing the Why around a belief, idea, problem is very powerful and hence I feel that the two should work together and would like to suggest a template based around the two. To quote the “mantra” from the book; “People don’t buy what you do; they buy why you do it

Below I define my thoughts on a template (headings in bold, and then the description) and then try and give an example for you. Very interested to get your thoughts.


 

The WHY:

The believe / vision behind the idea, the why that people buy into to share your believe.

This would typically be at least a paragraph explaining what you believe, why you are looking to do it, and ultimately pitching your idea.

The problem:

Now that you have outlined your vision, you know that there are many problems to over-come. Here we summarise each problem. You are writing the problem here, not the solution, this is something that you will use with the team to start expanding out to design experiments. All of the problem roll up to the The WHY, the vision.

Experiments:

You will have numerous experiments for each problem. The purpose behind each of these experiments is to literally test a solution for a problem by detailing the hypothesis. This hypothesis will test that the problem exists, even test your WHY. These should be cheap and simple, clearly defined, with KPIs that can determine the success or failure. These are so important as this is the feedback mechanism for your over-arching WHY and is giving you clear feedback.

A list of experiments with measurements / KPIs that can determine the success of each experiment, the format for outlining an experiment is:


Experiment Name:  – A name for the experiment which you can reference.

Hypothesis:  – This is what you plan to test, a hypothesis must be clear enough that we can prove or deny the hypothesis. Your tests do not always have to be successful, you will learn just as much (if not more) when you experiments are “failures”.

Learning goal:  – This forces us to clearly define the goal of the experiment, which saves any confusion further down the line, especially when you are presenting your results, and it keeps everyone aligned.

Metric(s):  – These are the KPIs that will help you to determine the success / results of the experiment. These are typically quantitative measures which you can measure on a frequent basis, even in real time if you so desire (although that may cost too much)

Fail condition:  – If you define this you can call the experiment failed without having to wait for the time box to expire. It is the metric that convinces you, beyond any doubt, that the hypothesis is invalid.

Timebox:  – This is the amount of time you want the experiment to run for, this should not be a long amount of time – it should be in the space weeks, not months. Experiments should move fast.

Results:  – As with any experiment you need to write up your results 🙂 Plus you want a nice table detailing your result so in 6 weeks time when you are asked about it you can provide that detail.

Next Steps:  – Here we can detail what we either plan, or decide, to do next. Typically it would be the next experiment to run


So, with this in mind, I am going to put out one of my ideas….. It is not earth shattering, but I am trying it as an exercise for myself and trying provide an example of this layout.


The WHY:

We believe that air pollution is getting worst and affecting children’s and adult’s health, as well as the planet. We believe people are not aware of how bad the pollution is and we would like to democratise air quality, so that everyone can find out about the air quality local to them. Ultimately we believe that by achieving this goal we can effect local and national policy and empower people with knowledge about the quality of air around them


Right, so this is quite a big vision. Below I have tried to extract a few problems (there are many) and in turn then the experiment definitions. These are all examples.


The problem(s):

We need to know if people do care and want this

We need a tool to collect air quality data, which is cheap and simple and the data should be posted to a repository that others can access.

Experiments:


Experiment Name:

Air quality early adopters

Hypothesis:

I believe that there are people who care about the levels of air pollution

Will be interested in having a tool to collect data and/or investigate the collected data

Because people care about the environment and want to better understand the air pollution levels locally with the aim of being empowered to pressurise / question local authorities / government, care about the health of tomorrows generation, and want data which is local to them

Learning goal:

To understand that people are interested in the why.

Metric(s):

At least 10% of people show an interest out of a sample of 100

Fail condition:

<5% show any interest

Timebox:

2 weeks

Results / conclusion:

TBD

Next Steps:

On a positive outcome we would move to the next experiment, Air Quality Collector, if the experiment fails we should revisit the Why and review this with the aim to devise more experiments to prove the Why or re-define Why.


Experiment Name:

Air Quality collector

Hypothesis:

I believe that we can build a solution solution that

will collect air quality data

Because early adopters are willing to accept a prototype

Learning goal:

To understand that we can build a cheap tool and people can use it

Metric(s):

The projected cost for the tool cannot be more than £10 each

The tool will reliably collect air quality data

Fail condition:

The tool is too expensive

The data collected is sparse

Timebox:

2 weeks to test the two with early adopters

Results / conclusion:

TBD

Next Steps:

Build out the tool based on our findings, look to expand functionality and move from prototype to production quality solution


The list goes on.

As you can see the second experiment is very deep, I could imagine this could take an engineering team a while to build something. I would want to break this into smaller pieces, but without a engineering team to discuss this with I am leaving it as is. The first experiment is really a market research exercise, you could also split this into many experiments, e.g. for each marketing medium – imagine you try and pitch the idea via Facebook, maybe a blog post with Google keywords driving the traffic, etc.

With each effort you would monitor them as separate experiments over short amounts of time as the mindset is to keep things small, simple and fast.

Your thoughts are most welcome, this blog post is almost an experiment in it’s self; so any feedback is most welcome.

Advertisements