Learning Backlog: The

Lean Startup and the

Product Owner
Book summary of Eric Ries’ The Lean Startup

Scrum is done better when the product owner role acts as the Mini-CEO. The product owner is the
entrepreneur, she is the owner of the business, and she assumes full functional and budgetary responsibility
over the product. The Product Owner makes decisions on where the product is heading, whether to pivot or
persevere based from validated learning.
Learning Backlog: The Lean Startup and the
Product Owner Role
Posted on July 17, 2018 by agilepinoy

I was preparing for PSPO certification. Eric Ries’ Lean Startup is a recommended reading for the Product
Owner Role. I read the eBook and listened to the audiobook from Scribd. <– Using the link, you should be
able to get unlimited access for 2 months. This is enough to download, read, and listen to available resources
on your Product Owner journey (or on any topic for your reading pleasure).

Following the concept of “ScrumAnd”, which is greatly explained and illustrated in the Blog of Mr. Gunther
Verheyen (https://guntherverheyen.com/2013/12/19/illustrations-of-scrumand/),

Scrum is done better when the product owner role acts as the Mini-CEO. The product owner is the
entrepreneur, she is the owner of the business, and she assumes full functional and budgetary responsibility
over the product. The Product Owner makes decisions on where the product is heading, whether to pivot or
persevere based from validated learning.

Every Agile Team needs to know what their customers want. Without validated learning, Product Owners
are dealing with assumptions. It is likely that the team will give the market something it doesn’t want.
Product Owners must have the ability to listen to customers in order to identify wastage and eradicate it.

The Product Owner in the Lean Startup context needs to drive the business from extreme uncertainty.
Product Owners are not always handed with complete specifications and product backlog on a silver platter.
Oftentimes, Product Owners need to discover these conflicting needs and wants themselves. Even the
customers do not know what they want until they see the product in front of them.

In the book, a startup is defined as “a human institution designed to deliver a new product or service under
conditions of extreme uncertainty.”

In uncertain conditions, general management tools will not work that well. There is a need to frequently
change forecasts, yearly budgets, product milestones, detailed business plans as we adapt from the changes
to the business environment.
Similar to Scrum, Lean startup approach is empirical. It is about experimentation; testing predictions and
learning what works or doesn’t. The Product Owner should be ready to navigate the Scrum Team in these
uncertain conditions.

Here are the learning backlog items I was able to extract from reading the book:

1. As a Product Owner, I need to validate LEAP-OF-FAITH assumptions so that I can make PIVOT
or PERSEVERE decisions

Every business organization eventually faces an overriding challenge in developing a product: deciding
when to pivot and when to persevere. It is answering the tough question: are you making sufficient progress
to support strategic hypothesis, or do you need to make a major change? It is best that you are prompted
with these questions earlier on.

In the Lean Startup Community, Leap-of-Faith is the riskiest assumptions the business is making about the
product. There are two main of Leap-of-Faith assumptions:

• Value Creation Hypothesis: whether the product idea will in fact add value to the customers
• Growth Hypothesis: how new customers will discover the product/service, whether the churn rate is
lower and registration rate, Or whether the team can deliver what’s wanted at a price which will be
profitable and sustainable

The Lean Startup puts emphasis on Validated Learning as measure of success. To validate these assumptions,
there is a need to release the product as quickly as possible. There is a need to conduct experiments and
apply genchi genbutsu — go and see for yourself.

As an example, even with an unfinished form of Facebook, the amounts of time people spend on the site
were impressive thereby ratifying the value hypothesis. And because users were increasing, the growth
hypothesis was also validated.

2. As a Product Owner, I need to figure out what customers want and would pay for as quickly and as
cost effectively as possible so that I won’t end up executing plans that lead nowhere

Before building a product, the following questions should be answered:

a) Do customers recognize that they have the problem you are trying to solve?

b) If there was a solution, would they buy it?

c) Would they buy it from us?

d) Can we build a solution for that problem?

Rather than paying extensive market research, or spending too much time in developing business plans, the
Lean Startup approach is to learn what customers want (and don’t want) by carrying out experiments that
provide validated learning. Lean Startup encourages the team to deliver MVPs (Minimum Viable Product)
and sell it to early adopters. MVPs deliver faster by delivering less. This will mean story slicing to the
extreme. It may mean worrying about exception cases later and supporting single vendor at first and scale
later.

An MVP can be in a form of a video that you could share. The video can describe what your end product
will do. The video share can be used to solicit feedback or even book advance orders.
A concierge MVP on the other hand focuses on one customer to offer services to and solicit feedback from.
Once that customer’s problem is resolved, you then invest in automating that solution and scaling it up to the
broader customer base.

Most business and development team dramatically overestimate how many features are needed in an MVP.
When in doubt, the author suggests to simplify.

3. As a Product Owner, I need to present mistakes into learning events so that we can make learning a
major metric and not to repeat the mistakes

The recipe to success is to fail fast and fail often. In faster release cycles, you’ll get to see all your mistakes
as you figure out how best to deliver. As long as you have the tolerance for it, it will be able to get you a
better product sooner.

Building an MVP is not without risks. Getting an early prototype product out into the marketplace will
conflict with your goal to build a high-quality product. Although this may be true, remember that until you
really know what customers want and will value enough to pay for, you don’t yet know what quality is.

The Lean Startup Product Owner must be willing to set aside their traditional professional standards to start
the process of validated learning as soon as possible.

The Product Owner must be willing to empirically test predictions and learning what works or doesn’t. Fall
quickly and rise again. Most businesses are caught off guard by their later failures, not knowing how to
respond or even rise again. Validated learning and experimenting help avoid this.

The Framework of Lean Startup revolves around the Build-Measure-Learn Feedback Loop. The aim is to
minimize total time through this loop faster. (The images below are from
http://theleanstartup.com/principles)

4. As a Product Owner, I need my team to work on small batches so that we can minimize total time of
the Build-Measure-Learn Loop

One may argue that working on big batches will improve overall functional efficiency. Indeed working on
specific functional task will make one faster in that job but may not be true when the overall end-to-end flow
is taken into consideration. In the book, the author compared the performance of folding 100 letters and
stuffing them into envelops. The task consists of folding letters, addressing, stamping, putting letters in
envelops and sealing. Performing these tasks one letter at a time was faster overall compared to performing
them in large batches (fold all paper first, put address stickers to all envelops, etc.). Issues such as incorrect
paper size, non-sticking envelop or stamp, are discovered earlier and corrected faster. Compared to large
batch of folding, rework is not costly.

Kanban, scheduling/queuing system, can be employed to limit work in progress for each stages of
development. Working on smaller batches that will continuously test your assumptions will facilitate faster
learning. (Image of Kanban below is from: http://leanguru.pro/wip-limits-matter/)

5. As a Product Owner, I need to define 3A Metrics (actionable, accessible and auditable) so that we
know when we are moving towards our goal

Once the product is out in the market, there should be a systematic way to know whether you are making
progress or not. In this regard, the author introduces the concept of Innovation Accounting. Innovation
accounting is aligned with 3 learning milestones

A. Are the business assumptions correct?

B. What will be our key drivers of growth?
C. Is our business model sustainable?

Oftentimes, Product Owners choose to measure what the author calls Vanity Metrics, these are metrics that
may look nice on charts but does not actually mean anything. For example: number of registered users,
compared to number of profitable customers, growth in registered users may not directly indicate the three
learning milestones above.

Metrics should be:

A. Actionable – it demonstrates a clear cause-and-effect. Actions that led to the metrics can be replicated.
B. Accessible – it is available for everyone to see and is simple for everyone to understand. It can be used to
make decisions in the future.
C. Auditable – the data/information is traceable, it cannot be manipulated

Experiments should be measured against agreed 3A metrics to assess their impact on the learning milestones.
Working on small batches, building and measuring immediately enable this learning.

The author suggests running multiple experiments at the same time using A/B or split testing. Split test
results are traceable to which experiment resulted to which customer behavior. This enables the team to
deploy only the successful experiments to the mainstream.
6. As a Product Owner, I need to incrementally improve processes so that processes are suitable,
sustainable, and avoiding waste

Teams do not have the luxury of time and money to define fail-proof processes and training programs. The
aim of the Product Owner, with the help of the Scrum Master, is for teams to be adaptive. They should be
able to automatically adjust their processes and performance to meet the current conditions. The following
lean thinking approaches can be applied to build adaptive and sustainable processes:

Andon Cord – stop production so that production never has to stop. It refers to a system to notify
management, maintenance, and other workers of a quality or process problem. It forces everyone to stop and
fix the quality problem before it accumulates. Quality is not traded with time.

5 Whys (root cause analysis) – continuously asking why to a problem until the root cause is identified.
Cause-and-effect relationships underlying a particular problem can be traced. It effectively solves the
problem by eliminating the root causes. It prevents the problem and the immediate symptoms from
recurring. Common pitfall to 5 whys are the 5 blames. Instead of constructively and collaboratively
developing solutions, people may start pointing fingers on who to blame. To avoid this, everyone affected
by the problem should be present during the analysis.

Assigning Change Masters – the change masters are responsible for making sure root cause analysis is
performed and that the action to resolve the root causes are carried out. A change master is senior enough to
have authority to ensure actions are performed but not senior enough that he will not be available to oversee
the changes.

Suitable and sustainable processes are those defined by the team and are tailored to their specific condition.
These processes evolve to meet the needs of changing conditions.

7. As a Product Owner, I need to nurture innovation so that my product will grow to have new
customers to serve or new business models to explore

When companies become larger, they seem to lose capacity for innovation, creativity and growth as
processes and hand-offs keep on piling. So how would one nurture innovation within an existing team or
organization?
A. Create a platform for experimentation, a safe space for innovation called the innovation sandbox. The
sandbox should protect the parent organization from any failed experiments as it will focus on single or
small batch of product changes to selected customer segment.
B. Establish a cross functional team to incubate innovation. You may choose to get representatives from
existing Scrum teams.
C. The team should have complete autonomy to develop and test hypothesis without excessive management
approvals
D. The Product Owner should have personal stake on the result of the experiment and the team must be held
accountable for its results.

Successful innovations should be fed-back to the main product or may branch-off as a separate product.

All the Lean Startup ways presented in the book encourages companies to cultivate innovation and to avoid
waste in its operation.

Our current problems are caused by trying too hard at the wrong things. As Peter Drucker once wrote,
“There is surely nothing quite useless as doing with great efficiency what should not be done at all.” The
sooner we know that we are doing is not what our customer wants, the earlier we can pivot and build a
sustainable organization/business.

I end this summary by how Lean thinking defines value: value is providing benefit to the customer; anything
else is waste.
When taking a Product Owner role, remember the 7 Learning Backlogs above from the Lean Startup. Let’s
keep learning.

– Agile Pinoy

Support the Agile Pinoy Community by following the Blog:

https://agilepinoy.wordpress.com/