Learning Objectives
Today you will:
• Understand a new approach to requirements and benefits realisation
• Understand what Lean Startup is
• Understand how Lean Startup, Lean and Agile interrelate
The Agile Revolution Podcast http://www.theagilerevolution.com 2
Agile Forest Blog http://www.agileforest.com
What Is A Requirement?
re-quire-ment [ri-kwahyuh-r-muhnt]
Noun
1. That which is required; a thing demanded or obligatory
2. An act or instance of requiring
3. A need or necessity
The Agile Revolution Podcast http://www.theagilerevolution.com 3
Agile Forest Blog http://www.agileforest.com
The Requirements Dilemma
A standard Agile team setup
The Agile Revolution Podcast http://www.theagilerevolution.com 4
Agile Forest Blog http://www.agileforest.com
The Standard Agile Approach
Release Backlog
The Agile Revolution Podcast http://www.theagilerevolution.com 5
Agile Forest Blog http://www.agileforest.com 5
Who Is The Real Voice Of The Customer?
In a “Lean startup”, who the customer is and what the customer might find
valuable are unknown.
Customers don’t care about how much time something takes to build. They
care only if it serves their needs.
The Agile Revolution Podcast http://www.theagilerevolution.com 6
Agile Forest Blog http://www.agileforest.com
What is success?
What if we found ourselves building something that nobody wanted? In that
case what did it matter if we did it on time and on budget?
The BIGGEST waste in the delivery of products is
in delivering a product no one wants.
The Agile Revolution Podcast http://www.theagilerevolution.com 7
Agile Forest Blog http://www.agileforest.com
A True Measure of Success
Is all of these AND:
• Customer growth
• Customer value
• Business Revenue
The Agile Revolution Podcast http://www.theagilerevolution.com 8
Agile Forest Blog http://www.agileforest.com
A Lean Startup Measure of Success
100%
90%
80%
70%
60% Registered but didn’t log in
Logged In
50%
Used Functionality "x" once
40% Used Functionality "x" 5 times
Paid
30%
20%
10%
0%
Jan-05 Feb-05 Mar-05 Apr-05 May-05 Jun-05 Jul-05 Aug-05
Success is knowing that whether the requirements
(hypotheses) we have implemented have resulted in
customer growth, customer value or business revenue
The Agile Revolution Podcast http://www.theagilerevolution.com 9
Agile Forest Blog http://www.agileforest.com
Types Of Hypotheses
Value
The value hypothesis tests whether a product or service really delivers value to
customers once they are using it.
Growth
The growth hypothesis tests how new customers will discover the product or
service. Additionally you have to ensure new customers incoming > existing
customers leaving.
Revenue
The revenue hypothesis tests whether the customer’s usage of a product or
service results in the revenue return of investment against expectations.
The Agile Revolution Podcast http://www.theagilerevolution.com 10
Agile Forest Blog http://www.agileforest.com
What Is Lean Startup?
An environment designed to create or enhance products and services under
conditions of uncertainty.
Ideas
Learn Build
Data Product
Measure
The Agile Revolution Podcast http://www.theagilerevolution.com 11
Agile Forest Blog http://www.agileforest.com
Minimum Viable Products
Build
MVP
Learn Measure
The Agile Revolution Podcast http://www.theagilerevolution.com 12
Agile Forest Blog http://www.agileforest.com
Cohort Analysis
Build
Learn Measure
We want to measure customers as they familiarise themselves with the
product for the first time.
Each grouping of these customers is called a cohort.
The Agile Revolution Podcast http://www.theagilerevolution.com 13
Agile Forest Blog http://www.agileforest.com
Split-tests
Cohorts are split evenly into two sub-groups – those that see the change and
those that do not.
Old Product New Product
50% 50%
Homepage
The Agile Revolution Podcast http://www.theagilerevolution.com
Agile Forest Blog http://www.agileforest.com
14
A Normal Agile Story Wall
The Agile Revolution Podcast http://www.theagilerevolution.com 15
Agile Forest Blog http://www.agileforest.com
A Lean Startup Story Wall
The Agile Revolution Podcast http://www.theagilerevolution.com 16
Agile Forest Blog http://www.agileforest.com
Pivot/Persevere
Pivot
A structured course correction designed to test a new fundamental hypothesis
about the product, strategy, and engine of growth.
Persevere
A data driven confidence that we are making sufficient progress to believe that
our original strategic hypothesis is correct.
The Agile Revolution Podcast http://www.theagilerevolution.com 17
Agile Forest Blog http://www.agileforest.com
Agile Principles
• Collaboration
• Motivated individuals
• Value
• Customer satisfaction
• Adaptation
• Deliver frequently
• Sustainable pace
• Simplicity
• Self-organising teams
• Reflective improvement
The Agile Revolution Podcast http://www.theagilerevolution.com 18
Agile Forest Blog http://www.agileforest.com
The Lean 7 Deadly Wastes
The Agile Revolution Podcast http://www.theagilerevolution.com 19
Agile Forest Blog http://www.agileforest.com
Why Lean Startup? Why Change?
• We want to validate our benefits realisation hypotheses not just
deliver efficiently
• We want real customer data and feedback from new customers
• We want be able to adjust our plan quickly based upon real
customer data
• We don’t want to waste unnecessary time delivering functionality
that customers won’t use
The Agile Revolution Podcast http://www.theagilerevolution.com 20
Agile Forest Blog http://www.agileforest.com
Inflight example
Site Performance (daily) Learnings:
120 1. Uptake of Feature A is not to
expectations
2. We need to be able to test
100 multiple hypotheses at once
80
Hypotheses:
1. Providing links to Feature A
inside of content will improve
60
uptake of MVP A
2. Moving button to be first for
Feature A on the landing page
40
will improve the uptake of
Feature A
3. Adding a indication of flow/status
20
bar to the key links on the
landing page will improve the
uptake of Feature A
0
11-Apr 12-Apr 13-Apr 14-Apr 15-Apr 16-Apr 17-Apr 18-Apr 19-Apr 20-Apr 21-Apr 22-Apr 23-Apr 24-Apr 25-Apr 26-Apr 27-Apr 28-Apr 29-Apr 30-Apr
Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun Mon
Total Visits Campaign Visits Feature A Start Feature A End Feature B Usage Feature C Usage
The Agile Revolution Podcast http://www.theagilerevolution.com 21
Agile Forest Blog http://www.agileforest.com
Where can I find out more?
http://theleanstartup.com/
The Agile Revolution Podcast http://www.theagilerevolution.com 22
Agile Forest Blog http://www.agileforest.com
Editor's Notes
Start with: “Here is the common definition”Emphasise: Point 3 “When we talk about system or product requirements it is usually the third point – a need or necessity that we are talking about”; Pause. “But whose need is it?”
This is an example of a team setup that we normally have for projects.See the Business Subject Matter Expert inside of the team? This person is the one that normally gives the “requirements” to the team. They are the “voice of the customer”, the “voice of real end users” and what end users want or need. Sometimes this role is performed by a Business Analyst. Often the Business Analyst is two steps away from real customers. They often talk to multiple business experts to elicit needs. These business experts may be in contact with real customers. Are you starting to see a problem?
Where are most of the requirements conceived in this approach?When do we get feedback from users on the product? We shouldbe getting feedback each iteration if it is deployed to production. But commonly each iteration is not deployed to production (the internet). Sometimes a subset of users are brought in for iteration feedback.
The real voice of the customer is not a Business SME. The real voice is not a handful of customers. The real voice is all of the customers.
First: If we truly understand that the only real voice of the customer is the customer this means that it is only the Customer that can tell us if a requirement is valuable or worthwhile. We might have spent months building something that nobody wants. In this case, it doesn’t matter if we did it on time and on budget. Second click group: Each time we have an idea or a requirement they should be considered hypotheses – because we do not know until we deliver that requirement if it really was a need or not.
A true measure of success on a product project development is NOT just delivering to agreed thresholds of cost, quality, time and scope – it is ensuring that:The customer is getting valueThe customer base is growing – both in new customers and retention of customersThe revenue model is affirmed
So lets take a look at an example of a product and it’s actual usage by customers. The x-axis represents time. The y-axis represents the depth of the customer’s usage of the system.If we look at January 05 we can see about 35% of users registered but didn’t progress further into the system. Then we have about 35% of users registering and logging in. After that about 22% of users registered, logged in and used a portion of the functionality in the system (a core feature that was expected to be of value). 5% of users additionally have used that functionality a lot (ie arguably found the functionality of enough value to use it multiple times). Only 1% of users found the product so valuable that they then became a paying customer. So what does this graph tell us about the success of this product? {Pause and prompt for response}We can’t see here what the growth rates are (that would normally be a different graph showing the number of new customers landing on the product). But what can we determine about value? Of those customers that are finding the product, the number that have found the site valuable enough for them to register hasn’t really changed over time. Over time those that registered did improve at logging in. There was a good improvement in customers in having higher usage of the core functionality but what about the bottom line?How did the return of investment improve? It didn’t. Paid customers never improved. But we want them to. What we have become successful at, at the very least, is in learning that we haven not achieved our desired result.Success for a Lean Startup Project is all about how quickly we can learn about whether our hypotheses have been proven or not. This is called Validated Learning.Validated learning is the process of demonstrating empirically that a team has discovered valuable truths.
So if we no longer consider the ideas and needs at the start of the project as “requirements” and now understand that they are really “hypotheses” what types of hypotheses are there?Now generally you need to prove value hypotheses before growth hypotheses (you want to know that customers will use your system before spending costly money on growth options such as television advertising). Once these two are done then you can focus on revenue.
*Every slide up to this point has been leading to the solidification of Lean Startup’s foundations*Every new product or product enhancement begins with an idea that is ultimately a hypothesis to add customer value or growth. These get built and deployed. Importantly they get built with the knowledge and structure to support how the hypothesis will be measured. The data is then gathered and analysed to determine whether the product is on the right track or whether a fundamental shift in the product is required.
The Minimum Viable Product (MVP) is that version of the product that enables a full turn of the Build-Measure-Learn loop with a minimum amount of effort and the least amount of development time.We need to focus our energies on minimizing the total time through this feedback loop.
So how do we measure?
Split-testing of a cohort ensures that results are statistically validated.
{Explain the flow at a very high level}At the end of the iteration the product should normally be deployed to production.
Note:There are no iterations. This isn’t to say that you cannot have iterations, but that the length to implement or even to measure a hypothesis might vary from hypothesis to hypothesis so you may not want to constrain yourself to a strict timebox.The backlog is now a list of hypotheses. These can be ideas, requirements or learnings from the Build > Measure > Learn feedback loop. The key change is what happens after being deployed. Hypotheses are not automatically considered ‘done’ once deployed. They continue to stay in the flow that the team focusses on until they have been fully measured. Once enough data has been gathered then a decision can be made. This decision is either to Pivot of Persevere.
The decision to pivot or persevere is something that should be done regularly – no shorter than every two weeks and no longer then once a month. Formalising this decision step is important. NEED TO GIVE AN EXAMPLE using the graph previously
Lean Startups do closely align with the Agile Principles. Just look at the first principle – we want to ensure that what we deliver is valuable – to the real customer. We Build-Measure-Learn so that we ensure what we deliver is valuable or not. We want to do this Build-Measure-Learn loop as fast as possible which is where Speed comes in.We want to adapt what we deliver based upon real customer feedback – this is where flexibility comes in.We want to do the most simplest solution to be able to determine if our hypothesis is valid or not….. NEED TO PROVIDE EXAMPLE HERE
The worst waste is over-production. Lean Startup is specifically designed to target this waste – ensuring that what we are producing is used and considered valuable by the customer.
MVP A = EngineMVP B = Progressing with suppliers for productsMVP C = Content access (youtube)