To The Point

To the point
a recipe for creating lean products
Paulo Caroli
This book is for sale at http://leanpub.com/tothepoint
This version was published on 2015-10-21
This is a Leanpub book. Leanpub empowers authors and

publishers with the Lean Publishing process. Lean Publishing is
the act of publishing an in-progress ebook using lightweight tools
and many iterations to get reader feedback, pivot until you have
the right book and build traction once you do.
©2014 - 2015 Paulo Caroli

Contents
Minimum Viable Product . . . . . . . . . . . . . . . . . . . 1

Origin . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
MVP enhancement . . . . . . . . . . . . . . . . . . . . 2
Small hypothesis, great businesses . . . . . . . . . . . . 3
A sample MVP evolution plan . . . . . . . . . . . . . . 7
Lean Inception . . . . . . . . . . . . . . . . . . . . . . . . . 9
The Lean Inception workshop . . . . . . . . . . . . . . 9
To The Point, uncovering the technique . . . . . . . . . 10
Collaboration . . . . . . . . . . . . . . . . . . . . . . . 10
Have fun with Icebreakers . . . . . . . . . . . . . . . . 11
Placing . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
The war room . . . . . . . . . . . . . . . . . . . . . . . 13
Colored post-its . . . . . . . . . . . . . . . . . . . . . . 14
The Burn-up Agenda . . . . . . . . . . . . . . . . . . . 15
The fixed time slots and the burn-up agenda . . . . . . 16
Parking Lot . . . . . . . . . . . . . . . . . . . . . . . . 18
The Inception planning checklist . . . . . . . . . . . . . 19
Product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Writing the Product Vision . . . . . . . . . . . . . . . . 20
The product Is – Is not – Does – Does not . . . . . . . . 23
Clearing the objective . . . . . . . . . . . . . . . . . . . 25
Understanding trade-offs . . . . . . . . . . . . . . . . . 27
Personas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
CONTENTS
Quadrants to identify types of personas . . . . . . . . . 30

Creating Empathy Maps . . . . . . . . . . . . . . . . . 32
Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Discovering features . . . . . . . . . . . . . . . . . . . . 36
Technical Certainty and Business Agreement . . . . . . 40
Effort and Business Value . . . . . . . . . . . . . . . . . 46
Better understanding of Features . . . . . . . . . . . . . 53
User Journey . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Describing journeys . . . . . . . . . . . . . . . . . . . . 58
Features in the Journeys . . . . . . . . . . . . . . . . . . 63
MVP blueprint . . . . . . . . . . . . . . . . . . . . . . . . . 70
The MVP canvas . . . . . . . . . . . . . . . . . . . . . . 71
The MVP canvas waves . . . . . . . . . . . . . . . . . . 71
The rules for each wave . . . . . . . . . . . . . . . . . . 72
Converging rules and journeys . . . . . . . . . . . . . . 73
Identifying MVPs in the Canvas . . . . . . . . . . . . . 76
Calculating effort, time and cost . . . . . . . . . . . . . . . 79

Detailing sample waves into tasks . . . . . . . . . . . . 79
Comparative Estimate . . . . . . . . . . . . . . . . . . . 83
Defining sizes . . . . . . . . . . . . . . . . . . . . . . . 84
Understanding cost and time . . . . . . . . . . . . . . . 85
Calculating the average . . . . . . . . . . . . . . . . . . 87
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Product Vision . . . . . . . . . . . . . . . . . . . . . . . 91
Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Personas . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
User Journey . . . . . . . . . . . . . . . . . . . . . . . . 93
MVP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Facilitator competence levels . . . . . . . . . . . . . . . . 94

CONTENTS
The Burn-up Agenda . . . . . . . . . . . . . . . . . . . . . 96

The axis . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Agenda topics . . . . . . . . . . . . . . . . . . . . . . . 99
Agenda time marks . . . . . . . . . . . . . . . . . . . . 99
The target and the meeting pace . . . . . . . . . . . . . 100
Scope line . . . . . . . . . . . . . . . . . . . . . . . . . 100
Checking progress . . . . . . . . . . . . . . . . . . . . . 101
Making choices . . . . . . . . . . . . . . . . . . . . . . 102
Icebreakers . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Punctual Paulo . . . . . . . . . . . . . . . . . . . . . . . 103
Geographic Location . . . . . . . . . . . . . . . . . . . 104
Visual phone . . . . . . . . . . . . . . . . . . . . . . . . 105
One Two Ping Four Pong . . . . . . . . . . . . . . . . . 107
Forming Triangles . . . . . . . . . . . . . . . . . . . . . 108
Zip Zap Zoom . . . . . . . . . . . . . . . . . . . . . . . 110
Untangle Yourselves . . . . . . . . . . . . . . . . . . . . 111
Minimum Viable Product
Minimum Viable Product (MVP) is the simpler version of a product
that can be available to validate a small set of assumptions on the
business.
Basically, you don’t want to waste time, money and effort building
a product that won’t attend your expectations. For that reason, you
need to understand and validate the hypothesis about the business.
MVP helps to validate and learn the fastest way.
Different from products created using the traditional way, usually
taking too much time and effort on prototyping, analysis and
elaboration, the goal of MVP is only to validate the first step, the
minimum product, far less elaborated than the final version. MVP
focuses on the minimum but viable product to verify if the direction
is correct. The initial set of functionality needed for hypothesis
validation and for learning more about the business.
Origin
The idea of MVP is originally connected to the ideas that became

popular with the Toyota´s lean manufacture style ¹ ² ³. Steve Blank,
an entrepreneur from Silicon Valley, created a methodology ⁴ based
on client development. That was the beginning of the Lean Startup
movement, which hit its apex with Eric Ries and his book ⁵ named
¹Womack, James P.; Daniel T. Jones, and Daniel Roos. (1990) The Machine That Changed
the World.
²Ohno, Taiichi. (1988) Toyota Production System. Productivity Press
³Womack, James P.; Daniel T. Jones. (2003) Lean Thinking. Free Press.
⁴Blank, Steve G. (2006) The four steps to the epiphany: successful strategies for products
that win.
⁵Ries, Eric. (2011) The Lean Startup: How Today’s Entrepreneurs Use Continuous
Innovation to Create Radically Successful Businesses. Crown Publishing.
Minimum Viable Product 2
after the movement.

While Eric Ries turned MVP popular since the publication of his
book “Lean StartUp”, the expression was in use for many years
before the movement came to life, especially amongst startups
with their entrepreneurs and stakeholders from Silicon Valley. The
expression minimum viable product came up for the first time in
2000 in a Willian Junk’s ⁶ article, “The Dynamic Balance Between
Cost, Schedule, Features, and Quality in Software Development
Projects, Computer Science”.
MVP enhancement
MVP does not mean that the product won’t evolve and enhance
its features. On the contrary, the idea behind MVP is the product
enhancement guided by proven hypothesis validation.
Course correction or confirmation is what is going to guide the
following enhancements. These enhancements are MVP: new min-
imum products added to the minimum products already validated.
Once more, minimum products but viable to make decisions about
the product evolution. The product now is elaborated, maybe with
a bigger user database, allowing the validation of hypothesis even
more elaborated.
It is very important to comprehend that the MPV promotes an
evolutionary creation. Ergo, the architecture as well as the building
tools of the product must allow this continuous and progressive
evolutionary feature.
In 2010, Jez Humble and David Farley published the book Con-
tinuous Delivery ⁷. In this book the authors discuss a fast and
⁶Willian, S. Junk. (2000) The Dynamic Balance Between Cost, Schedule, Features, and
Quality in Software Development Projects, Computer Science Dept., University of Idaho,
SEPM-001.
⁷Jez Humble and David Farley. (2010) Continuous Delivery, Addison-Wesley.
low-cost delivery process, allowing the incremental creation of

software products. They define Continuous Delivery as a discipline
of software development that promotes quicker and more frequent
deliveries.
In spite Continuous Delivery goes on details about software prod-
ucts and the workflow for its creation, the essential idea of con-
tinuous delivery is the same that Eric Ries recommends on Lean
Startup: fast cycles to validate hypothesis.
Fast and frequent cycles, allowing very short liberation periods and
low costs of experimentation. But it’s not easy to implement this
kind of approach. And the creators of MVP products are going to
need different structures and practices from those used traditionally
in products with a slow cycle.
This book focuses on analysis and effective planning activities based
on MVP. Continuous Delivery is the bible if you want to understand
the necessary tools to software products creation and evolution.
But even more, the techniques and the learnings shared by the
authors of Continuous Delivery are being applied for other kinds
of products, not only software products. The same apply for this
book.
Small hypothesis, great businesses
The product is built incrementally, with recently created MVPs

being added to the existent solid product. With MVP enhancements,
the continuous and incremental delivery provides the increase of
value of the product through time, while the creation process for
traditional products does not provide any value up to the end, when
the product is ready in its whole.
Do you need to get taller? Would you step up for that?
Do you need to get taller? Would you step up once more for that?
Do you need to get taller? Would you step up once more for that?
Do you need to get taller? Can you wait for an elevator to be built?
Final result: to go up, use the stairs or the elevator.
This picture sequence shows how MVP offers small validations in

the long run, while the more traditional style to product creation
only offer validation of the whole in the end. But please do not get
caught in this example, because real products are not as simple as
one step to another relatively similar.
The following image offers another example of MVP: the MVP for
crossing a river. A simple solution to crossing a small stream is to
lay a wooden beam across it. And it makes a great MVP. Besides
allowing a small stream of a river to be crossed, it is a simple way
to validate the location for building the bridge. Perhaps lay more
than one wooden beam on different locations, and validate which
one will have more usage.
A very simple bridge
MVP promotes an incremental approach in which only a small part

of the general hypothesis are treated at the same time. Each one of
these hypotheses is designed, created, and prepared to be added to
the product, in order to generate useful data to its own decision-
making, learning and validation.
In essence, an idea (or great business hypotheses) is sequenced
in a series of small, simpler and, ergo, easier to understand hy-
potheses. The outcome is: the simpler hypotheses are more quickly
elaborated, and get available in the product for the final user. For
instance: if there was a bridge in this place, how many pedestrians
would use it in a week?
In this case, the final user (or who validates the MVP) provides data
for validating the enhancement of the product. This validation is
essential for two reasons: (1) corrections and changes can be made
in an initial stage of the product, instead of only appearing in the
end of conception, reducing the product’s risk; (2) the analysis’
complexity of the hypotheses is reduced. The product’s creators and
final users have early access to something functional and viable.
Thus, the decision of the next steps and increments of the product
are based on the product itself, instead of being hypotheses about
other hypotheses. And this work pattern in small enhancements of
the products and its hypothesis allows building products much more
elaborated, with small steps but very well-founded.
A sample MVP evolution plan
The product is built incrementally, with newly created MVPs being

added to consolidated existing product. The last released MVP has
a positive result. Then the team follows the MVP evolution plan
creating the next set of features for the next MVP release.
MVPs for grass grooming
This figure shows how MVP offers small validations over time,
while more traditional product creation only validates the final
product. Traditional product would focus on the final version, for
example, the nice lawn mower (MVP 8) on the button right of the
figure.
The shears is the first MVP. Is there any grass to cut? Is there anyone
to handle a simple grass cutting apparatus? The validation of these
hypotheses drives the evolution of the product to the next MVP.
Perhaps, something more convenient: a grass cutting apparatus
with a cable. How about adding wheels to it? And so forth evolving
the product from MVP to MVP.
The most important and valuable feedback is a negative answer. Is

there any grass to cut? No. In such case, the shears will not be used.
By the way, a nice and expensive lawn mower wouldn’t be used
as well. Your hypothesis is false, so a fully evolved product would
have been a big waste of time, and money!
This example illustrates how MVP promotes an incremental ap-
proach in which only a small part of a more comprehensive idea
is treated at the same time. Each of these MVPs are designed,
created and prepared to be added to the product, adding more
(validated) functionality to it. In essence, an idea of product is
sequenced in a series of smaller validations, and therefore easier to
understand, create and account for. And it is worth remembering
that fortunately software products is not manufacturing. In the
software world, a lawn mower can be created by adding wheels,
engine and a cable to a simple shears.
Lean Inception
Agile projects place emphasis on early and continuous delivery
of valuable software, according to the business objectives and the
needs of the primary users. Lean product creation promotes incre-
mental release of the product–MVP, the minimum viable product,
or the simpler version of a product that can be made available to
the business.
But how to understand the MVP and start an agile project as quickly
as possible? How to ensure the team starts the product creation with
a shared understanding and an effective plan?
The Lean Inception workshop
In a single week of collaborative work, the team will understand the

product objectives, the main users, and the high-level functional
scope such that the project duration can be estimated and an
incremental release strategy of MVPs can be identified.
collaboration during an inception

Lean Inception 10
To The Point, uncovering the technique
To The Point is a technique to understand and plan for the in-

cremental delivery of MVPs. The technique organizes ideas and
features in a model that seeks to understand the main purpose of
the product, considering the journeys of the users and incremental
valuable delivery. Like a recipe cookbook, with rapid and effective
sequenced activities, the technique will enable the team to:
• Describe the product vision

• Prioritize the business goal
• Describe the main users, their profiles and their needs
• Understand the main functionalities
• Detail perceptions of risk, effort and business value by func-
tionality
• Describe the most important user journeys
• Create an incremental product enhancement plan, driven by
MVP
• Estimate effort by sampling
• Calculate costs and specify dates and delivery schedule
The chapters to follow explore each of these points’ concept and

activity.
Collaboration
Collaborating is the act of working together to perform a task

and reach common goals. The success of an inception is directly
connected to the capacity of the group of collaborating effectively
in each activity described in this book.
The inception proposes a collaborative process of discovering and
elucidating in which people involved work together in a sequence
Lean Inception 11
of activities to understand the options and elaborate MVPs. The

activities presented in the following chapters represent structured
collaboration methods, seeking for a creative environment, while
sharing knowledge, learning, and building consensus. The activities
aim to build up the team success, as they get involved in elucidating
and resolving each step towards MVP.
Have fun with Icebreakers
Never underestimate the power of having fun. By having fun and

laughing, your stress levels decrease significantly and you are much
more open to working with other people. When you’re happy and
relaxed, you’re much more open to trying new things and thereby
increasing your participation on this highly interactive workshop:
the lean inception.
To the extent you want to be a part of engaging people deeply and
fully with fun and effective activities, you will yourself be invited
into a journey of highly participative sessions. Keeping this in mind,
you need eto break the ice and get the participants into the right
state of mind. Icebreakers help to create a friendly environment and
make people more comfortable to participate in the activities that
will follow.
Icebreakers are quick and fun activities that can be run to warm
up the team and promote group interaction. It is a good meeting
starter for any team meeting. It is extra valuable for early stages
of team building, which it typically the case for the lean inception
workshop.
You should select an icebreaker activity to match the needs of
your inception moment. On the first days, I recommend activities
that focus on sharing information, such as names and hobbies.
After the lunch time, you should select some Icebreaker to wake
everyone up. And finally, get to know the Icebreakers with simple
Lean Inception 12
message, such as “complex systems are hard to handle”, or “written

documentation in not enough”. Besides being fun and energetic,
they deliver important messages.
Below is a sample Icebreaker great for sharing names. Appendix A
– Icebreakers have more Icebreaker activities and ideas.
Punctual Paulo
This is a quick activity to help team members remember each

other’s names.
Running the activity
1. Ask the participants to think about an adjective that begins

with the same letter as their name.
2. Form a circle and ask each participant to say his/her name
with the adjective, in turns (“Hi, I’m Punctual Paulo!”).
3. After all the participants speak, ask them to go clockwise
telling the name and adjective for the person at their side.
4. After a few turns, ask the participants to repeat step 3 going
counterclockwise.
Besides sharing some laughs and breaking the ice, this activity will
also help the team to associate people’s names with some adjective,
making it easier to remember them.
Placing
Don’t underestimate the value of face-to-face interaction. Inno-

vative technologies, such as videoconferencing and online shared
documents facilitate remote work between people. However, face-
to-face interaction during inception allows the hard work in ac-
tivities, guaranteeing that everybody will be present and actively
participating.
Lean Inception 13
When everyone is in the same room, the level of participation

increases. You cannot simply sit down in a corner and turn your
back to the meeting, doing some other thing. Face-to-face meetings
tend to be shorter and more efficient than remote meetings.
Understandings and misunderstandings are better comprehended.
Facial and body expressions add up to the written and verbal
communication. In general, face-to-face meetings help the team to
get to the point, straight to the point!
The sequence of activities to reach MVP is long. Collaboration and
results are positively surprising when everyone is physically in the
same room. Do everything you can to get everyone involved in the
same environment, interacting face-to-face during inception.
The war room
Maintain the same room allocated to the team during the intense
period of inception. This is commonly called war room.
example of a war room during an inception

Lean Inception 14
The room must accommodate the team comfortably. There must be

a table and a clear wall. The room also must hold flipcharts, index
cards and colored post-its, paper and pen for everyone.
a war room set for an inception
The war room sets the environment to collaborative activities. It

also avoids any waste of time when people move from one room to
another. All information is created and remains in the same place.
It is important to keep information in the same room, avoiding its
transportation and premature document. Everyone can and must
hand-write annotate (index cards, post-its, flipcharts etc.) and put
them on the wall and tables, in the way that the information stay
visible for everybody.
Colored post-its
Make notes on colored post-its or index cards. Write and put them
on the table or on the wall. Gather people around them. Talk
about them. Write a little more. Group them. Separate them. Tear
them down and write again. Use colors. Reorganize them. The
collaboration born from such simple display cannot be reached by
any digital mean.
There’s no substitute to writing, re-writing, grouping or tearing
Lean Inception 15
colored post-its. It promotes interaction amongst people and helps

the creative experimental process, in which the path is being built
without the fear of trying, mistaking or re-doing. As soon as
the information goes to the computer, it does not return to the
paper. That reduces the interaction amongst people because there’s
nothing on the table or on the walls, visible to everyone, and that
can be easily torn down, re-grouped or re-written.
The Burn-up Agenda
The burn-up agenda (detailed in the appendix) helps tracking the

progress of a Lean Inception workshop. Having the agenda visible
to everyone builds up the group confidante and awareness towards
the management of time and the progress of activities as a whole.
It is a simple and effective tool to plan and facilitate the workshop,
and to get to the point.
Lean Inception 16
a burn-up agenda example
The vertical axis has topics or activities to be performed (from

the bottom to the top) during the whole inception workshop. The
horizontal axis represents time, usually measured in half-days.
The fixed time slots and the burn-up

agenda
The burn-up agenda provides a good framework for sequencing

opened brainstorming sessions and activities while tracking the
overall progress and the time. However, some people, especially
those who won’t be dedicated to the Inception workshop, need
to have an overall view of the week. For that reason I share the
planned inception agenda template (available at LeanPub as a book
attachment).
Lean Inception 17
sample agenda with fixed time slots
The model of planned agenda with fixed timeslots presents two

types of sessions (in orange and blue), that correspond to the levels
of participation: stakeholders or active members.
• Stakeholder is anyone impacted by the project. These are

people very much interested in the direction and result of the
inception, but don’t have time to attend in all sessions. These
ones can include: sponsors, final users, legal department, sales
department and marketing department.
• Active member is anyone directly involved by the prod-
uct’s comprehension and implementation. These are the peo-
ple who should participate actively in every session of the
workshop. They can be: product owners, developers, testers,
project manager and user experience.
Notice that in the planned agenda the kick-off activities and the
workshop showcase are marked in orange, respectively in the
beginning and in the end of the week. In an ideal world, everyone
Lean Inception 18
would be present in the war room during the week. However,

we rarely have free schedule from stakeholders. The minimum
necessary is that the stakeholders attend the kick-off and showcase
sessions, in which are presented the business expectations for the
inception workshop, as well as the results obtained by the team in
the workshop. The other days are taken by a sequence of intense
activities, followed by consolidation periods.
Parking Lot
The Parking Lot helps to track any items, ideas and issues that
are raised during an activity, but may not be useful to discuss at
that specific time in the inception. It is an essential toolkit for the
facilitator as it provides a polite way to say “yes, I heard you. But it
is not important at this moment.”
The facilitator should introduce the concept of parking either on the
beginning of the Lean Inception, or whenever the first conversation
goes off track. Write Parking Lot on a flip chart and place it on a
wall on the war room. If not already on a post it, the item under
discussion should be written on a post it and placed on the parking
lot. Make sure to briefly explain the concept of parking lot, and get
back to the current activity.
It is important to send the strong message to the participants on the
Lean Inception:
The conversation was getting off track, and it was

not in the current activity scope. But, it is equally
important to listen to and respect people thoughts
and feelings. Therefore, the parking lot must be used
with a pure intention:
This is parked for now; but we will get back to it later.

Lean Inception 19
Indeed, at the end of each inception day, you should take 10 minutes
to review the items in the Parking Lot. Then one of these two actions
is taken for each item: (1) The item is removed from the parking lot
(the topic was already covered or no longer needs to be addressed),
or (2) the item remains in the parking lot for the next review.
The last parking lot review should happen towards the end of the
inception. At that last review it is very important to clarify any
remaining items and share with everyone what will happen to it.
The Inception planning checklist
The following checklist is designed to aid the Inception planning

process. Please make sure to have all items scheduled before starting
an inception.
• Participants selected and invited (stakeholders and active

members)
• Experienced facilitator (view the Appendix - Facilitator)
• Room reservation (keep the same room allocated for the
inception period)
• Flip chart, index-cards, colored Post -its, A4 paper and pens
for everyone.
• Coffee break
Product
With a good understanding of the product vision, you can set which
and how the first pieces of your business puzzle are going to gather
up. You must decide on over which product feature the initial path
is going to be traced, and which is going to be your strategy.
understanding the business puzzle
Writing the Product Vision
Somewhere between the idea and the launching, the vision of the
product helps to trace the initial path. It defines the essence of your
business value and must reflect a clear and convincing message to
its clients. This activity will help you to define collaboratively the
vision of the product.
Product 21
For [final client],

whose [problem that needs to be solved],
the [name of the product]
is a [product category]
that [key-benefits, reason to buy it].
Different from [competition alternative],
our product [key-difference]. 
Template “The vision of the product”, describe in the book Crossing the
Chasm: Marketing and Selling High-Tech Products to Mainstream Customers,
by Geoffrey A. Moore (1999).
Activity’ step by step
1. Write the template vision of the product in a white board or

flipchart in a visible way for the whole team.
2. Divide the team in smaller groups and ask to each one to fill a
blank separately (or more, depending on the size of the team).
3. Gather the result of each group, forming a unique sentence.
Product 22
vision of the product – example 1
vision of the product – example 2
In this activity it is very common that the result is a senseless

sentence. Ergo, after executing the third step, it is important that
Product 23
the team works together to form a homogeneous sentence, using

and altering the previous results, if necessary.
The product Is – Is not – Does – Does not
The activity * Is – Is not – Does – Does not * helps to define

a product. Sometimes, it’s easier to describe something by telling
what this thing is not or does not. This activity seeks for explaining
this way, asking specifically each positive and negative aspect about
the product and what it is or what it does.
Activity’ step by step:
1. Divide a white canvas or flipchart in four areas (Is / Is not /

Does / Does not).
2. Write the name of the product above the quadrants.
3. Ask to each participant to describe the product, on post-its
and putting them on the correspondent areas.
4. Read and group the similar notes.
The product is…

The product is not…
The product does…
The product does not…
.
Product 24
an example of result
Product 25
another example of result
This activity helps to explain the product. Typically, after such

activity the participants will have a more consensual view regarding
what the product does as well as what the product doesn’t do.
Strategic decisions can be clarified, such as this thing the product
will never do, while that other one it still wouldn’t do.
Clearing the objective
Each team member must share what is his/her understanding of

an objective for those who use the product, and the several points
of view must be discussed in order to reach a consensus on what
is really important. This activity helps raising and clearing these
objectives.
Product 26
1. Ask each team member to write, individually, three answers

to the following question: “If you had to define this product
with three goals for its users, which would they be?”
2. Ask the participants to share what they wrote in a common
canvas, grouping them by similarity.
3. Ask the team to re-write the goal, now collectively. By this
time, it will be clear that some of the goals listed do not
really represent the objectives of the product, and must be
discarded. This way it will be clear to the team what is the
focus of the product.
Hereafter, a sequence of two pictures of steps 2 and 3. In the first

picture, the goals are grouped by similarity. In the second one, the
goals are re-written (in pink post-its). Notice that some goals were
discarded (in the upper right corner).
grouped objective
Product 27
re-written objective
Understanding trade-offs
Trade-off is a trade in which you let go something in order to get

another one you want more. A lean product reflects decisions of the
team regarding trade-offs.
The activity Understanding trade-offs helps building and recording
a common understanding about trade-offs of the lean product.
Many decisions and conversations are based on individual vi-
sions and premises between choices. Some examples: what is most
valuable: security or usability? And what about performance and
security? And usability and performance? This activity promotes
an open and collaborative conversation on trade-offs. Clearer trade-
offs avoid misunderstandings and help to make decisions quickly.
Product 28
result example – trade-offs of lean product
1. Describe all categories that are relevant to the product in

post-its (for instance: security, usability, scalability).
2. Put the categories in the white board or in the flipchart as
line titles. Next, draw an horizontal line to each category.
3. Draw vertical lines (the same number of horizontal lines).
Write “more” (important) above the leftmost line and “less”
above the rightmost line.
4. Ask participants to mark their initials in several post-its and
put one post-it on each line. The restriction: each column
must contain a post-it with your initials (for example: only
one of the categories will be marked as more important).
5. Equalize the trade-offs. With a post-it with different color
(green post-its in the photo), set the marks to each category,
from less to more important. This mark should be relatively
easy since it considers the post-its with the votes of everyone.
Product 29
another example of outcome – trade-offs of the lean product

Personas
To effectively identify the functionalities of a system it is important
to have in mind users and their goals. The usual way taken to
represent these users is through personas ⁸.
A persona represents a user in the system, describing not only his
role but also his specific needs, creating a realistic representation of
users, helping the team to describe functionalities from the point of
view of those who will interact with the final product.
Quadrants to identify types of personas
The following activity is used to describe types of personas. Such

activity is simple, illustrative, fun and quick.
1. Ask the team to divide in pairs or triplets and handle the

following template of personas to each group.
2. Ask to each group to create a persona, using the template as
reference.
3. Ask to participants to present their personas for the whole
team.
4. Ask the team to change groups and repeat steps 1 to 3.
⁸Pragmatic Personas, by Jeff Patton, article in StickyMinds, 2010.
http://www.stickyminds.com/article/pragmatic-personas
Personas 31
template para identificar personas (em folha de papel A4)
By the end of the activity, a set of personas must have been

created and the different types of system users must have been
described. The stakeholders who know the goals of the project must
participate actively, helping the team when creating the personas
and suggesting changes in their descriptions, as required.
Example of personas – activity outcome

Personas 32
Another example of personas – activity outcome
The template presented was created by Natalia Arsand, an excellent

User eXperience designer and work colleague at ThoughtWorks
Brasil.
Creating Empathy Maps
The Empathy Map is a visual template to identify and visualize a

persona. It was originally created to analyze consumer segments,
but Empathy Map is an excellent tool to classify, explore and
understand different types of persona.
The Empathy Map was originally described by Dave Gray as one
of the methods of XPLANE ⁹ to comprehend users, clients and the
other participants in the business. It got more well known since it
was presented in the book Business Model Generation as a tool to
discover insights on clients ¹⁰.
⁹XPLANE, a visual thinking company, founded in 1993 by Dave Gray.
http://xplane.com/
¹⁰Osterwalder, A., Pigneur, Y., Business Model Generation, A Handbook for Visionaries,
Game Changers, and Challengers (Amsterdam: OSF, 2009)
Personas 33
The map contains four main areas, which fulfill the sentence: What
I ________?
• what I ____ (see / think / hear / say)?
Aside these four main areas, the original version presents two more
fields: pain and gain, for such persona.
Empathy map - template
Every time I’ve applied the Empathy Map for persona identification,
I’ve used its four main areas: see, hear, think and say. Sometimes, I
use the pain and gain areas, as described originally; but sometimes
I change these other areas, for instance: what I do, what I don’t do,
my friends and my enemies, my hobbies.
1. Choose a persona to be analyzed.

Personas 34
2. Draw a template of the map, putting the persona in its center.

3. Describe the areas for such persona.
4. Repeat steps 2 and 3 for the next personas.
Below you’ll see some examples of empathy maps.
empathy map – example 1

Personas 35
mapa de empatia – exemplo 2

Feature
Feature is the description of an action or interaction of a user with
the product. For example : print invoice , see detailed statement ,
and invite facebook friends.
The description of a feature should be as simple as possible. The
user is trying to do something. The product should have a feature
for that. What is the feature?
Since you already described the personas and the main objectives of
the product, the following question helps uncovering the features:
“What there must be in the product so that this persona reaches this
goal?”
Discovering features
The following activity is used for discovering features. Note that

this activity depends on the list of goals and personas, which must
be artifacts acquired in previous activities:
1. Ask the team to put the goals in a common canvas, in order

of priority, from the left to the right, as column titles.
2. Ask the team to put the goals in a common canvas, in order
of priority, from top to bottom, as line titles.
3. Promote a features’ brainstorm. The discussion must be
guided in order to find out which features are necessary to
reach the goals and personas. A question that helps in this
process is:
Feature 37
• “What there must be in the product so that this persona

reaches this goal?”
The team must guide itself on the canvas, repeating the above
question for every combination of persona and goal, starting with
the highest prioritized ones. Thereby, the features with the biggest
priority will come first.
The time tracking is essential for all activities, but this one requires
special attention. In case a great number of goals and personas
are selected (on steps 1 and 2), then innumerous features might be
raised by the team. This will be counterproductive and might take
the team in a direction of spending too much time talking about
features which will not be on the first MVPs.
For avoiding such scenario, it is strongly recommended that the
number of goals and personas are shortened to very few (such as
the top three or four goals and personals).
• ”if we were on a very short budget and could work on only

one goal, which one would that be?”
The above question helps the group prioritizing goals and personas.
Repeat the question a few tomes for goals, then to personas. This
should help with prioritization and focused discussions towards a
product MVP.
Feature 38
Example of result: features, goals and personas, respectively in blue, orange

and green
Feature 39
Example of result: features, goals and personas, respectively in blue and pink
post-its, and white paper sheet
Feature 40
Example of result: features, goals and personas, respectively in light yellow

and dark yellow post-its, and white paper sheet
Although the canvas is similar to a matrix, it won’t have necessarily

a feature for each intersection. It can have multiple features for one
persona to reach one specific goal, as well as it is possible to have
personas who don’t need a feature for a certain goal.
In case you identify goals and features that do not attend the needs
of any persona, those must be discarded or re-thought, because their
value is not clearly associated to a user.
Technical Certainty and Business

Agreement
This activity aims to discuss how the team feels according to the
technical certainty and the business agreement for each feature.
From this activity, new notes are captured and disagreements and
Feature 41
doubts get more apparent.

template for the activity
1. Create a common canvas, a graphic, in which the axis X

Feature 42
represents the technical certainty (how to do) and the axis Y

represents the business agreement to the requirement (what
to do).
2. Ask for a member of the team to read a feature out loud and
put it on the graphic according to his/her understanding of it
(technical certainty and business agreement).
3. Question if everyone in the team share the same opinion. Of
somebody disagrees, the team must discuss the requirements
and the technology involved in a way that an agreement is
reached about the feature. Everything that is mentioned and
that helps to achieve a better understanding must be noted
and attached to the feature.
4. Note, in the feature, the level of understanding. For instance,
the picture below shows features in post-its that were glued
in green, yellow or pink index cards, indicating low, medium
or high uncertainty levels, respectively.
5. For each feature captured previously, repeat steps 2 to 4.
In the axis X, the goal is to verify the understanding of the team

according to the technical challenges, to the liabilities, and the
requirements of infrastructure. In the axis Y, the proposal is to verify
the clearness of the goal of the feature, the benefit for the business
and what should be done.
By the end of this activity, all features are categorized according
to the technical certainty level and the business agreement. Each
feature post-it is placed on a colored index card – green, yellow
or pink, respectively representing high, medium and low levels of
understanding.
Feature 43
example 1
Feature 44
example 2
Feature 45
example 3
Feature 46
example 4
Features marked with a pink index card with an X represent higher

risks for the project. Typically, the team will either (1) discard these,
or (2) divide them in smaller and less risky pieces of work.
Effort and Business Value
This activity aims to discuss how the team understands the effort
to do it, as well as the business value related to each feature. From
this activity, new marks are added to each feature.
Feature 47
template for the activity
1. Create a common canvas, a graphic, in which the axis X

represents the effort (the level of the work that needs to be
done) and the axis Y represents the understanding on the
business value (what is the return or saving that it will bring).
Feature 48
2. Ask for a member of the team to read a feature out loud and
put it on the graphic according to his/her understanding of it
(effort and value of the business).
3. Question if everyone in the team share the same opinion. If
somebody disagrees, the team must discuss the requirements
and the technology involved in a way that an agreement is
reached about the feature. Everything that is mentioned and
that helps to achieve a better understanding must be noted
and attached to the feature.
4. Note, in the feature, the level of effort and the business
value. For instance, the picture below shows features in index
cards that were added the marks $, $$ and SSS, respectively,
indicating high, really high or super high business value, as
well as E, EE and EEE, indicating low, medium and high level
of effort, respectively.
5. For each feature captured previously, repeat steps 2 to 4.
In the axis X, the goal is to verify the understanding of the team

according the difficulty and the work that is going to be necessary
to complete such feature. In the axis Y, the proposal is to verify the
value, the ROI (Return On Investment) of the feature, a measure-
ment of the business on how much is worth such feature.
Feature 49
example of features with marks of effort and business value
Some examples of features categorized according to the level of

effort and business value. Note that the color of the index car
represent the levels of understanding, according to the activity
Technical Certainty x Business Agreement.
Feature 50
example 1
Feature 51
example 2
Feature 52
example 3
By the end of the activity features will be marked with the un-
derstanding related to the effort and value of the business. Such
marking must help the team in activities such as: prioritizing,
estimate, and planning.
The business value scale

The marks $, $$ and SSS, respectively, indicate high value,
really high value or super high value of business value. When
I started using this graph these marks were used for indicating
high, medium or low business value. But hardly a business
person would grade a feature as low value. The change on the
scale made it a little easier for grading and comparing business
value.
.
Feature 53
Better understanding of Features
The activities Technical Certainty and Business Agreement and

Effort and Business Value can and should be held together. That
is, each feature must pass through the graph shown in one ac-
tivity (Technical Certainty and Business Agreement), and, shortly
thereafter, must pass through the graph shown in the other activity
(Effort and Business Value).
Graphs side by side
In the first activity the feature gets a color; on the second activity,
the feature gets two marks. The color represents the feature´s uncer-
tainty level: red for a high level of uncertainty, yellow for a medium
level of uncertainty, and green for a low level of uncertainty. The
marks are about effort and business value, and vary on a scale of
one, two or three times in comparison to each other; for example E,
Feature 54
EE, and EEE. Such color and marks will help the team in subsequent
activities to prioritize, estimate and plan.
Below are two examples of features before and after passing by both
activities.
Example 1: Features before the activities

Feature 55
Example 1: Features after the activities

Feature 56
Example 2: Features before the activities

Feature 57
Example 2: Features after the activities

User Journey
The User Journey describes the path of a user in a sequence of steps
in order to reach a goal. Some of these steps represent different
points of contact with a product, featuring the interaction of a user
with him.
Following a simple and effective approach, the description of the
path begins by identifying a user and a goal. Actions described in
post-its represent the small steps in the path to reach the goal. The
journey becomes clear when the post-its are aligned in a logical and
chronological order, representing the user’s behavior and the flow
of interactions with the product.
Questions, agreements and disagreements will lead the talk on
building the journey. Maybe, more than one option of journey
will rise. For instance, the optimist journey, the realistic one, the
pessimist, the master, the exceptional one depending on this and
that. The options will force the prioritization and clear definition of
the goal and, as a result, the focus will be clearer in some journeys.
The prioritized journeys will complement and help searching the
MVP.
The level of detailing of a journey shouldn’t be too high, or too low.
While a journey shows a step-by-step guide of the interaction of the
user, it is also a synthesis, a higher and simplified level of the flow
without the redundant information and the deep details.
Describing journeys
The photo below shows a lot of user’s journeys in the same table.
Note the personas and goals identified with a blue post-it are at the
left side, and their journeys that go from the left to the right. In
User Journey 59
these journeys, orange post-its identify actions that don’t involve

the system, while pink post-its identify actions that involve it. Small
arrows were marked connecting a step to the next one.
various journeys
The description of a journey is based on a persona. Identify a

scenario for this persona and describe step by step the path to reach
a goal.
Simple questions help the beginning of the description of the
journeys. Some examples:
• Which goal this persona wants to reach?

• How he starts his day?
• What he does before this?
• What he does after this?
A talk, a post-it, and a pen. This is what you need to describe the
journey of a user. I suggest write and re-write. But start, don’t stand
User Journey 60
still waiting for an insight that won’t come. After having written
some stuff, you change it. If it makes sense, connect some detailed
steps into one. Or break up a very little detailed step into smaller
ones. There is no magic in it. The important is that the journeys are
described.
example of a journey of the user 1

User Journey 61
example of a journey of the user 2

User Journey 62
a team looking at several journeys

User Journey 63
another team looking at several journeys
Features in the Journeys
The journeys clear up how it will be the interaction with the

product. If you’ve followed the order described in this book, the
journeys must be described (like a sequence of steps on a table or
a canvas), and the features, available (in single index cards). This
activity describes how to reunite them, revalidating and verifying
the entire analysis up to this moment.
User Journey 64
journey and features, side by side
1. Put the main journeys and the visible features, if possible,

side by side, as showed in the picture below.
2. Following the journey, search for the necessary features for
each step. The sequence below shows an example of how the
features are mapped in the journey.
User Journey 65
mapping features for a journey - stage 1

User Journey 66
mapping features for a journey - stage 2

User Journey 67
mapping features for a journey - stage
Below, another example in which features are added to the jour-

neys of the users. In this sequence, the first picture shows lots of
journeys in the same table. Note that in this picture the personas
are identified with blue post-its in the left side, and their journeys
go from the left to the right. In these journeys, orange post-its
identify actions that don’t involve the system, while the pink post-
its identify actions that involve the system.
User Journey 68
Picture 1 of 2: the journeys
In a second moment, the participants put in the journeys the

features previously identified. Note the journeys in the photo below,
now with the features in colored cards and marks identifying effort
and value (see chapter Features).
User Journey 69
Picture 2 of 2: the journeys with the features
By the end of this activity, two things might occur: (1) missing
features are identified for some journeys, and (2) some features
were not mapped to any journeys. For (1) you must create the
feature cards as per the colors and marks identifying understanding,
effort and value (see chapter Features). (2) is an indication that
some features are not mapped to the users´ journeys. These features
should be cleared up (and documented) but the team does not need
to carry it forward, keeping the focus on priority items, as per the
journeys.
MVP blueprint
“Is this feature important?”
I’ve always had the same answer when asking such question. That
is why I don’t ask it anymore. The most relevant question that is
going to help you to plan the order of the features to be created is:
“Which one of these two is the priority?”
Thus, the features are prioritized according to one another. This

question is very useful and must be used, but from another starting
point.
Previously, you pointed the most important user, as well as the most
priority journey. This is for sure the best starting point: the first
feature of this journey.
Maybe more than one feature will be in the journey, or in journeys
that can be created at the same time. Then, in such scenario, you
must ask which of the two features has the most priority.
Fortunately, in the previous stages some parameters have already
been added up to the features. They are: business value ($, $$ or $$$),
effort (E, EE or EEE) and uncertainty level (green, yellow or red
card, identifying high, medium or low uncertainty, respectively).
These parameters will help you with planning features and their
relative priorities. So, which is the minimum combination of fea-
tures that can be available to validate a small set of assumptions
on the business? Now is the time to visualize and conceptualize the
first MVP and its following increments.
MVP blueprint 71
The MVP canvas
The MVP Canvas helps you organize and visualize the features and
its relation to the MVPs. The canvas organizes and plans the product
releases beyond the first MVP. Typically, teams using the MVP
canvas will dazzle the product evolution via a clear understanding
on the features contained by each MVP, and the MVPs release order.
sample MVP Canvas result
The MVP canvas waves
You must plan a sequence of waves for grouping features in order

to help you organize the production order, something easy to
understand. A wave after another, in sequence. Draw in a flipchart
or white board, a template with the waves, the MVP Canvas.
MVP blueprint 72
template with the waves: the MVP Canvas
The rules for each wave
Features will be added to each wave. Hereafter, the five rules for
adding features to the waves. Such rules were defined after applying
this type of planning and prioritizing innumerous times.
• Rule 1: A wave can contain 3 features max.

• Rule 2: A wave cannot contain more than one feature in pink
card.
• Rule 3: A wave cannot contain 3 features in either yellow or
pink card.
MVP blueprint 73
• Rule 4: The sum of effort of the features cannot surpass 5 Es.

• Rule 5: The sum of value of the features cannon be less than
4 $s.
• Rule 6: A wave must contain 2 features minimum.
The rule 1 limits the number of features being worked on at the

same time. It avoids features clogging up on a partially done state,
by increasing the focus to the few prioritized features. The rules 2,
3 and 4 prevent an unbalanced work period with either too much
uncertainty, or too much effort. The rules 5 and 6 guarantee the
constant focus on delivering high business value.
Converging rules and journeys
Simple rules are added to the MVP canvas template. Now, it’s just
a matter of seeking the first features of the first journey. Then you
must seek the next one. Respecting the rules, you will decide if such
feature gets in the wave ‘n’ or ‘n+1’.
If in doubt between two features that are in compliance to the rules,
just answer the question “Which one has the most priority?”
Below, you see a sequence with two pictures. The first one shows
a hand searching for a feature on the table where journeys and
features are mapped. In the second picture, the same hand puts the
feature in a wave of the template, respecting the rules.
MVP blueprint 74
seeking features
putting features in the MVP Canvas

MVP blueprint 75
Duplicate or use the same post-it or card?

A feature with its marks is positioned in a canvas (for example,
a journey canvas). You are about to take the card and put
it in another canvas: the MVP canvas. In addition to the
information described in the card, its position on the canvas
brings more information. This is the case of the feature with
the journey and on the MVP canvas. By this time you ask:
do I duplicate or use the same card? My suggestion: take a
picture before anything else. Then consider replicating the
card, as long as it doesn’t make the activity slower and
the environment more confuse (with the innumerous colored
papers).
Below is a typical picture of a team using the MVP Canvas. Note the
involvement of the team, and how everyone is positioned in front
of the canvas. At this stage everyone is well aligned in relation to
the main user journeys and their features (with its uncertainty level
and marks for business value and effort).
MVP blueprint 76
team using the MVP Canvas
Identifying MVPs in the Canvas
Now it’s the time to understand the increments and the evolutional
creation of your product. The activities so far have cleared up and
prioritized each aspect of your product.
The small blocks of the product, the features, are now arranged
logically in the MVP canvas. In addition, you understand them and
visualize them for the users´ journeys. By browsing on the flipchart
of the MVP canvas with its waves and features, you will elucidate
the MVP increments.
By the end of each wave check if such composition of features
reaches a simple version of the product that can become available.
If so, give a name to this composition and write it down on a post-it,
putting it on the line that delimitates such wave. Do this for all the
waves in the MVP canvas.
Below, there are some examples after the stage of identifying MVPs
(in orange post-its) in the canvas.
MVP blueprint 77
one example of MVP in the MVP canvas
another example of MVP in the MVP canvas
The waves won’t necessary relate one-to-one with the MVPs. Note
that this was the case on examples of MVP in the MVP canvas
presented previously. The intention is to practice planning and
sequencing features in waves in order to deliver value as fast as
possible, although respecting the dependencies between features
and the rules of MVP canvas.
Below is a illustrative example for a MVP Canvas. In it you can
find two MVPs and thirteen features. The MVP 1 is composed of
MVP blueprint 78
the features F1, F2, F3, F4, F5 and F6. The MVP 2 is composed of
features F7, F8, F9, F10, F11 ,F12 and F13.
a illustrative example of the MVP canvas

Calculating effort, time and
cost
The MVP increments and the MVP canvas waves make visible and
tangible the deliveries of the product. Even thou, we still need to
understand effort, time and costs related to each wave.
The sequence of activities until this moment as well as the rules of
the MVP canvas generate waves similar in size. This simplifies the
estimation of the product with its MVPs, as it provides the means
to work with an average wave size based on a smaller sampling.
Instead of detailing every wave with its features according to effort,
time and cost, you will select only a few waves. Then you will detail
its features, sum up the numbers and calculate the average for a
wave.
Detailing sample waves into tasks
The size of the waves is alike. Ergo, choose three waves and
use them to generate detailed information on effort, time and
cost. Three waves are sufficient to give you a good view of such
parameters and generate an effective average.
1. Choose three sample waves to be detailed.

2. Select a feature of one of the three sample waves.
3. Describe, in other cards, the smaller tasks for the selected
feature.
4. Go back to step 2 and select another feature until you have
detailed all features of the three sample waves.
Calculating effort, time and cost 80
When selecting the sample waves (on step 1), remember that in
this moment you are interested in the estimate of the whole and
the average size of a wave, and not in the detailing of work itself.
Therefore, the waves to be chosen must provide good combination
of the risk level (marked by the colors of the cards), as well as a
good variation in the sum of effort levels (marked with “E” on the
features).
The first waves are good candidate, because such details will
be useful not only to estimate the whole, but also helps in the
description of smaller pieces to build the initial features of the MVP.
The smaller piece (on step 3) must be something that makes sense
for each team. Software development teams that follow the scrum
methodology [ˆKen] typically utilize user stories ¹¹ as those smaller
pieces. Other teams prefer to call the smaller pieces tasks and
describe them with no predefined format. In the context of this
book, I will call tasks the smaller pieces of a feature.
[ˆKen] Schwaber, Ken and Beedle, Mike (2001) Agile Software
Development with Scrum; Prentice Hall
During step 3, make identification marks on both, the card feature
and its tasks cards. For instance, mark F1 for all tasks of feature 1,
F2 for the tasks of feature 2, and so on.
In the following activities, the cards will move and such marking
will be used to re-group features to their smaller pieces.
The pictures below present some examples of features that were
detailed in smaller pieces.
¹¹Cohn, Mike (2004) User Stories Applied: For Agile Software Development; Addison-
Wesley Professional
example of features and tasks 1


By the end of this activity, the features selected as samples will be

detailed with their several tasks.
Comparative Estimate
The following activity is used for understanding the relative effort

of tasks.
1. In a common canvas (typically a desk or on the floor) identify

a corner as + (more) and the other one as – (less).
2. Select two tasks and ask the following question: How this task
compares (in effort) to this other one? More, less, alike?
3. Put both tasks on the canvas, with their relative positions
indication how they compare in relation to the effort level.
Put one next to the other, if both required the same effort
level; or put one under the other, indicating if one requires
more effort than the other.
4. While there is still tasks to be compared, put it on the canvas
next to another task and repeat the steps 2 and 3.
By the end of this activity, all tasks will be on the canvas, where
they can be understood according to the effort level and how they
compare to each other.
Defining sizes
This activity is very simple but essential for is effective with time
and generates numbers for calculation.
1. Write in post-it’s the following t-shirt sizes: small, medium,

large and extra-large.
2. Put the size marks on the canvas, being the small next to
the less effort corner, and the extra-large next to more effort
corner.
3. Define the limits between sizes and reposition tasks to let
their sizes clear.
example of result
By the end of this activity, each task will be associated to a t-shirt

size: small, medium, large or extra-large.
Understanding cost and time
This activity is essential to generate numbers for calculate cost and

time for each wave as well as for the whole MVP Canvas.
1. Choose a small task, and ask how long a person can take to
complete it.
2. Choose two or three more tasks of the same size and ask
again.
3. Calculate the time average and take note.
4. Repeat the previous steps to tasks of different sizes.
example of result
By the end of this activity, all tasks will have an estimate of time and
cost. For instance, the following result was obtained in a request of
this activity: half day for small tasks, two days for medium tasks,
four days for large tasks and eight days for extra-large tasks.
The time answers will influence the final outcome. Therefore, be
emphatic regarding the question. If possible, ask for comparisons
with past jobs, and try to understand the motivation and the ability
of people answering such question.
Developers do not like to answer this question:
How long does it take to complete such a task?
Therefore it is very important that everyone feels very comfortable

with the task description. If there is any discomfort in relation to a
task, rewrite it, and consider breaking it into smaller pieces.
Another way to ask such a question is put it in the plural:
Consider a pair of developers. One knows more about

the business, the other one knows less. One is more
senior, the other one is younger. One is savvier on the
specific technology, the other one is a beginner. How
long does it take for the pair of developers to complete
such a task?
In my experience, everyone is more comfortable giving such an an-

swer considering pairs of developers working together to complete
a task.
Calculating the average
From the understanding of the effort of the previous activity, we add

the estimated time for each task of each feature. Then, we sum the
estimated time per feature of each line of the MVP canvas. Thereby,
we reach an average of effort for each line, defined per person per
time unit.
The two following pictures show how the calculus was made
for a team. The pictures show respectively the waves chosen per
sampling and the calculation made in order to reach the average of

the estimated time per wave.
waves for sampling
Note in the previous picture that the waves 2, 3 and 4 were selected
for sampling. Therewith, the features detailed in the tasks were: F4,
F5 (wave 2), F5, F6, F7 (wave 3), and F9, F10 and F11 (wave 4).
calculating the wave average time
The previous picture shows the calculation made to get the average
time estimated per wave. Each task was estimated in days for a
pair of developers. In the picture, each line shows the sum of time
estimated per task of a feature. The measure of time estimated for
each task was: ¼ of a day, ½ day , 2 days or 5 days. Making the sum
per feature and then per wave, the team has reached the values of
11 day, 11 ½ days and 9 days, respectively, for the wavez 2, 3 and 4.
The average used for such team as 10 days for a pair of developers
per wave.
Below you can see another example of outcome to another team.
example of result
In this picture the resulting average was 20 units. Note the calcula-
tion on the pink post-it at the left, with three waves of sample.
In this team, the unit used was a pair of developers a day. With this
information in hands, it became easy to calculate effort, time and
cost of each wave.
We can choose to work with a pair of developers, and

deliver a wave of features in almost a month (or 20
workdays). Another option would be to double the
monthly cost having two pairs of developers delivering
approximately two waves per month.
Glossary
A short list of terms is used in this book. Each one of the concepts
is explored in details in the main chapters. However, I believe it’s
necessary an definition, even for the high level, for these terms from
the beginning.
This list of terms must be visible during the Inception Workshop.
I suggest printing this glossary and put it on the wall at the war
room.
Product Vision
A product vision is a brief statement of where you want to take your

product idea.
Goals
A goal is a desired result envisioned for the product. Understanding

the product goals serve as an effective tool for establishing agree-
ment of what the product must have to fulfill the product vision.
Personas
A persona represents a user of the system, describing not only his

role, but also his specific needs. This creates a realistic representa-
tion of users, helping the team to describe features from the point
of view of those who will interact with the final product.
Glossary 92
Feature
A feature is a grouping of related functionalities. Such grouping
helps to understand the product as a whole, as well its smaller and
complementary parts. The understanding of a feature will change
from team to team. The important thing is that such groupings
makes sense to your team, and are aligned with the product goals.
Feature Technical Certainty
The feature understanding according to the technical challenges,

to the liabilities, and the requirements of infrastructure. Have you
done this before? Do you know how to do it? Strong yes indicates
high level of certainty.
Feature Business Agreement
The clearness of the goal of the feature, the benefit for the business
and what should be done. What to do? Direct and clear answer
indicates high level of agreement.
Feature Uncertainty Level
A Feature Uncertainty Level refers to the degree to which the

feature is uncertain, from the point of view of business agreement
and technical certainty. This is indicated by the feature index card
color which are green, yellow or pink, indicating low, medium or
high uncertainty levels, respectively.
Feature Effort
The level of the work that needs to be done for a feature. The
understanding of the team according the difficulty and the work
that is going to be necessary to complete such feature.
Glossary 93
Feature Business Value
The value, the ROI (Return On Investment) of the feature, a mea-

surement of the business on how much is worth such feature. What
is the return or saving that a feature will bring?
User Journey
The Usr Journey describes the path of a user through a sequence of

steps given to reach a target. Some of these steps represent different
points of contact with the product, featuring the interaction of the
user with it.
MVP
The Minimum Viable Product (MVP) is the simpler version of a

product that may be available for business. The MVP defines which
are the essential features for the minimal functional product that
may add value to the business (minimal product) and that can be
actually used and validated by the final user (viable product).
Facilitator competence
levels
This book provides you with a recipe, a sequence of activities to
be followed for reaching out the understanding and planning for a
product MVP. Just like a cookbook, this one depends on the mastery
of a chef. In other words, the execution of such recipe is in the hands
of our chef, the Inception workshop facilitator.
The figure below identifies six levels of competence for the Incep-
tion Workshop facilitator. This rating serves to align expectations
and to show the importance of the facilitatorâ€™s ability to apply
the techniques described in this book, as well as to identify the level
of the facilitator allocated for an Inception.
facilitator competenc levels
1 Beginner Facilitator People who are attending the Inception

Facilitator competence levels 95
Workshop for the first time.

2 Intermediate Facilitator People who have already attended but
didnâ€™t facilitate any activity during an Inception Workshop.
3 Apprentice Facilitator People who have already attended and fa-
cilitated one or more activities performed in Inception Workshops.
4 Facilitator People who have already facilitated an Inception
Workshop and feel able to do so.
5 Advanced Facilitator People who have already facilitated at
least five Inception Workshops and feel able to coach apprentice
facilitators.
6 Evangelist Facilitator People who have already facilitated more
than ten Inception Workshops and nowadays are sharing the tech-
niques with people interested in Inception Workshops.
The Burn-up Agenda
The burn-up agenda tracks progress towards the planned topics for
a workshop. It can be used for any meeting, but is especially useful
for time-boxed workshops with a list of topics to be covered.
Burn-up agendas emerged from intensive brainstorming work-
shops, such as inceptions and ideations. Even though such work-
shops invite broad discussion, typically they have a time box and
must cover a few topics, achieving the desired outcome.
The sequence of photos shows a burn-up agenda on different times.
Starting at 8 am, when the agenda was created, then snapshots at
9:20 am, 10:50 am and noon when the workshop ended.
burn-up agenda at 8:00 am

The Burn-up Agenda 97

burn-up at noon
The axis
The vertical axis is the amount of topics to be covered, and itÃ¢â‚¬â„¢s

measured up in units customized to your own plan. The horizontal
axis is time, usually measured up in hours or days.
the burn-up agenda axis

Agenda topics
The topics to be covered must be grouped in a way that the

topic discussion duration is somewhat similar. For instance, if your
agenda has five topics, and you expect that topics 1 and 2 take half
hour each, topics 3 and 4 take one hour each, and topic 5 takes two
hours, then you should consider having the topics grouped in the
following way:
• Topic 1&2
• Topic 3
• Topic 4
• Topic 5.1
• Topic 5.2
This way, each topic grouping has similar expectation on the

duration of the discussion allocated to it. Please, note that despite
of the actual timing (it should take 10 minutes, half hour or two
hours), the most important thing is that a topic grouping has similar
expectations on the amount of time taken. Another important
aspect is for the topics to follow a chronological order. Just like a
clear meeting agenda: first we will cover this, second we will cover
that, and so forth. The sequence of the topics must be clear.
Agenda time marks
The time marks on the horizontal axis must identify equal interval
of times, starting on the beginning of the workshop, and finishing
on the expected end of the workshop. The burn-up agenda example
show time marks as half-hours. The time parks units (such as
minutes, hours, days) should be related to the excepted duration
for the topics. Consider you are building an agenda for a 5-day
workshop with 10 topics. Perhaps an hourly-based time marks
would be too fine grained; a daily or half-day time marks feels more
appropriate.
The target and the meeting pace
The advantage of the burn-up agenda is the clear understanding of

the target, the point in which the scope line meets the end time line.
The target is shown in the next picture.
the pace for the workshop
By drawing a diagonal line from the start point (the point where
the axes meet) to the target point, you do have a clear indication of
the pace for the meeting or workshop. On the figure, it is depicted
as the planned line.
Scope line
Another important measure is the scope line, the horizontal line

above the last planned topic. Such line clearly tracks if and when
new topics have been added or removed to the meeting. It also
allows you to visualize the intersection of this horizontal line to
the vertical line representing the end of the workshop. Everything
under discussion should be a topic. If new topics emerge, they

should be added to the topic list and the scope line must be adjusted.
This way, the scope line allows you to easily spot when topics are
being added, which will affect the completion time. Whether this
topic is essential to the discussions, it is an important signal that the
completion time may need to be moved in response. The scope line
also tracks where topics are being removed to meet a fixed deadline.
Again, this is important to know as it may impact the other topics
on the agenda, and is something that needs to be clearly discussed
with everyone.
Checking progress
From time to time you should look at the amount of topics covered
and the total amount of planned topics. The distance between the
horizontal lines marking the current topic and the last one to be
covered is thus an indication of the amount of topics remaining.
two lines
When the two lines meet, the planned agenda will be complete. This
is a powerful measure of how close you are to complete the planned
agenda.
Regularly checking progress is an important part of time manage-
ment. There are two basic movements on the agenda, and they are
both horizontal movements: (1) time has changed; the post-it with
a big arrow representing the current time moves to the right, and
(2) an agenda topic discussion has ended; the respective topic post-
it moves to the right to the current time. This tracking mechanism
allows you to instantly identify certain types of problems, such as
a deviation from the excepted duration for the first topics. These
problems can then be discussed and corrective action can be taken
at an early stage, rather than when it is too late.
Making choices
Consider the snapshot represented on the next picture. It is 10:00

am, the middle of the workshop, and only four out of ten topics
have been covered. The burn-up agenda makes this visible.
planned versus actual pace
Draw a line from the start time to the last topic covered, and then
extend it to the end line. This is the actual line. With it, the target is
questioned. What to do? Accept the current pace, and reduce scope
(remove topics from the agenda)? or move faster on the remaining
topics?
Icebreakers
Icebreakers are activities to warm up the team and promote group
interaction. It is a good starter for any team meeting. It is extra
valuable for early stages of team building, and intensive workshops
such as Lean Inceptions. An activity called Punctual Paulo has
already been demonstrated in the Chapter Lean Inception.
This appendix brings even more icebreaker ideas for your Lean
Inception. Such activities have been cordially shared from the
website and book Fun Retrospectives ¹².
Punctual Paulo
This is a quick activity to help team members remember each

other’s names.
1. Ask the participants to think about an adjective that begins

with the same letter as their name.
2. Form a circle and ask each participant to say his/her name
with the adjective, in turns (“Hi, I’m Punctual Paulo!”).
3. After all the participants speak, ask them to go clockwise
telling the name and adjective for the person at their side.
4. After a few turns, ask the participants to repeat step 3 going
counterclockwise.
¹²CAROLI, Paulo e CAETANO, Tainã; Fun Retrospectives, Activities and ideas for
making agile retrospectives more engaging, LeanPub, www.FunRetrospectives.com, 2014.
Icebreakers 104
Punctual Paulo Activity
Besides sharing some laughs and breaking the ice, this activity will
also help the team to associate people’s names with some adjective,
making it easier to remember them.
Geographic Location
This activity is a good ice-breaker and also helps team members to

learn a little bit about each other.
1. Explain to the participants that each one will be a geographic

location (for example: their country, city or neighborhood).
2. Show where is north and south in the room.
3. Ask each participant to move where he thinks he belongs to
make a map as close to scale as possible.
4. After everyone moves to their spot, ask one volunteer to draw
a map representing the room.
Icebreakers 105
Geographic Location Result Map
Visual phone
Visual phone is a great energizer to get everyone engaged while fos-

tering a conversation about communication and its interpretations.
1. Break the large group into ones/sets of three people (one or

two groups can have four people).
2. Place three post-its and a pen in front of each person.
3. Ask everyone to write a sentence (on the post-it), then place
a blank post-it on top of it (at this time, only the author of the
sentence knows it).
4. Everyone passes the post-it clockwise.
Icebreakers 106
5. Each person reads the sentence from the post-it in front of

him/her, and then creates a representative drawing for the
sentence (on the blank post-it).
6. Everyone passes the post-its clockwise.
7. On a new post-it, each person writes a sentence for the
drawing in front of him/her, and place it on top of the post-it
set (now the set has three post-its: the original sentence, the
drawing, and the new sentence).
8. Everyone passes the post-it set clockwise (for the groups of
three people, the set should end up in front of the original
sentence writer).
9. Open the post-it set so everyone can see the sentences and
their respective drawings.
Participants drawing
Icebreakers 107
Sample result
Typically the participants will laugh and have a great time compar-
ing drawings and sentences.
This is a great energizer with a sublime message about communi-
cation (visual and written), context and interpretations.
This is an adaptation from an activity we have learned on a UX
(User eXperience) workshop by my dear UX friends Natalia Arsand,
Glauber Ramos, Juliana Dorneles and Gabriel Albo. They have
learned it from the Human Centered Design workshop by IDEO.
One Two Ping Four Pong
This is a short activity to start up a meeting in a good mood and get

participants engaged.
1. Ask the participants to form a circle.

2. The participants must decide upon a direction to follow
(clockwise or counterclockwise).
3. Someone starts by saying any positive number that is not a
multiple of 3 or 5.
4. The next person, following the decided direction, mentally
increments the number by one. Then:
Icebreakers 108
If the number is not a multiple of 3 or 5: Says the number

If the number is a multiple of 3: Says ping and clap
If the number is a multiple of 5: Says pong and jump
For large groups, it is recommended to remove a person from the

circle for making a mistake or erroneously accusing someone. Soon,
everyone will be laughing and cheering for the remaining ones.
Forming Triangles
This activity is a great energizer with a valuable message, being

very useful for starting a conversation about self-organizing teams.
This activity is divided in two parts.
First part
1. Ask the members of the group to walk individually in a

random direction.
2. After some time, say the magic word “triangle”: each group
member will have to find other 2 people and form an equi-
lateral triangle (each person is a triangle vertex, and should
point each arm towards the other two people representing
the other triangle vertices; each person is a triangle vertex on
one triangle only).
3. Track the time of how long it took the group to form the
triangles.
Icebreakers 109
Forming Triangles
Second part
1. Select one person to be the fugleman of the group triangle.

2. Ask the members of the group to walk in a random direction.
3. After some time, say the magic word “triangle”: the group
triangle fugleman has to form equilateral triangles with all
group members (including himself in one of the triangles).
4. Track the time of how long it took the group to form the
triangles.
The first part shows a self-organizing group; the second run shows
a group guided by one organizer (the group triangle fugleman).
Typically, the self-organizing triangle formation runs faster than its
counterpart, and the team feels more engaged on the activity.
This activity was engaged from Heitor Roriz¹³, a friend and scrum
coach and trainer. Kudos to him for applying a fun activity for
fostering the conversation about an essential concept of successful
agile teams: self-organization.
¹³https://twitter.com/hroriz
Icebreakers 110
Zip Zap Zoom
This is a good meeting starter, especially for new teams. It brings

energy to the room and the activity dynamics helps the participants
to remember each other’s names.
1. Ask the team to form a circle, and each participant to close

his/her hands while pointing index fingers.
2. Explain the verbal comands.
3. Ask a participant to make the first movement, saying one
of the verbal commands and choosing the initial direction
(clockwise or counterclockwise).
The verbal comands Each participant should, in his/her turn, make

a verbal command, pointing to a receiver. The verbal command
should be one of the following:
• Zip: Point to the person exactly at your side, keeping the

previous direction.
• Zap: Point to the person exactly at your side, changing the
previous direction.
• Zoom: Point to anyone in the circle, saying his/her name. The
receiver should decide the direction for the next movement
in his/her turn.
When a participant executes a wrong command (either a command

that doesn’t exist, or pointing to the wrong direction in a zip/zap
command), he/she should be removed from the circle.
Icebreakers 111
Zip Zap Zoom
This activity is not only a good energizer but also pushes the
participants to focus, and helps them to remember each other’s
names.
Untangle Yourselves
Untangle Yourselves is a great energizer to get people moving. It

has a very interesting message on finding your way out of a tangled
situation.
1. Ask the group to form a circle.

2. Ask everyone put his/her hands up.
3. Give the tangling instructions.
“With your right hand, grab someone’s left hand.
With your left hand, grab someone’s right hand.
You cannot grab the hands of people next to you.”
4. Ask the group to untangle themselves without letting the
hands go, and trying to form a circle.
Icebreakers 112
each group forms a circle
holding hands (and getting tangled)

Icebreakers 113
untangling
The group will jump hands, switch around and find a way out,
either forming one or more circles. Sometimes, it is not possible
to untangle. At such scenario, ask the group to select one person to
be removed. Hands that become free should reconnect to the person
remaining on the tangled group.
Group size: larger than 6 people, up to any number. For very large
groups, break into smaller groups of approximately 12 people.

To The Point

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

To The Point

Uploaded by

Copyright:

Available Formats

To the point

a recipe for creating lean products

This version was published on 2015-10-21

This is a Leanpub book. Leanpub empowers authors and

©2014 - 2015 Paulo Caroli

Minimum Viable Product . . . . . . . . . . . . . . . . . . . 1

Quadrants to identify types of personas . . . . . . . . . 30

Calculating effort, time and cost . . . . . . . . . . . . . . . 79

Facilitator competence levels . . . . . . . . . . . . . . . . 94

The Burn-up Agenda . . . . . . . . . . . . . . . . . . . . . 96

The idea of MVP is originally connected to the ideas that became

after the movement.

low-cost delivery process, allowing the incremental creation of

Small hypothesis, great businesses

The product is built incrementally, with recently created MVPs

Do you need to get taller? Would you step up for that?

Final result: to go up, use the stairs or the elevator.

This picture sequence shows how MVP offers small validations in

A very simple bridge

MVP promotes an incremental approach in which only a small part

A sample MVP evolution plan

The product is built incrementally, with newly created MVPs being

MVPs for grass grooming

The most important and valuable feedback is a negative answer. Is

The Lean Inception workshop

In a single week of collaborative work, the team will understand the

collaboration during an inception

To The Point, uncovering the technique

To The Point is a technique to understand and plan for the in-

• Describe the product vision

The chapters to follow explore each of these points’ concept and

Collaborating is the act of working together to perform a task

of activities to understand the options and elaborate MVPs. The

Have fun with Icebreakers

Never underestimate the power of having fun. By having fun and

message, such as “complex systems are hard to handle”, or “written

This is a quick activity to help team members remember each

1. Ask the participants to think about an adjective that begins

Don’t underestimate the value of face-to-face interaction. Inno-

When everyone is in the same room, the level of participation

The war room

example of a war room during an inception

The room must accommodate the team comfortably. There must be

a war room set for an inception

The war room sets the environment to collaborative activities. It

colored post-its. It promotes interaction amongst people and helps

The Burn-up Agenda

The burn-up agenda (detailed in the appendix) helps tracking the

a burn-up agenda example

The vertical axis has topics or activities to be performed (from

The fixed time slots and the burn-up

The burn-up agenda provides a good framework for sequencing

sample agenda with fixed time slots

The model of planned agenda with fixed timeslots presents two

• Stakeholder is anyone impacted by the project. These are

would be present in the war room during the week. However,

The conversation was getting off track, and it was

This is parked for now; but we will get back to it later.

The Inception planning checklist

The following checklist is designed to aid the Inception planning

• Participants selected and invited (stakeholders and active

understanding the business puzzle

Writing the Product Vision