Improvement21 Handouts V1.3

V1.
3 – November 2015
Improvement21
Course Handout
Habit-‐building improvement prac4ces

Welcome to your
improvement
journey!
About this guide
The purpose of this guide is to serve as inspira4on for all the things you
can do to improve your company and the environment that you are
working in, star4ng today.
We designed it to be short, prac4cal and easy to start on any page. Just
browse through it or go straight to your selected topic of interest.
Let us know how you get on – we would love to hear your stories of
changing, improving your team and company one step at a 4me! Don’t
forget to sign up to our newsleMer and social channels and we hope to
see you on one of our improvement21 events!
improvement21.com ·∙ We help people and companies create con4nuous improvement habits.
About us
We started Improvement21 because we believe that improvement is
everyone’s daily job. For companies to strive, everyone on the team
needs to have the tools and means to influence where they are going and
how things are geRng done.
We are doing this because we believe that people should be happy at
work. Happy people can change the world and create amazing solu4ons!
We are Happy Melly Funders – check us out at www.happymelly.com!
Angel Medinilla and Andrea Darabos,

Improvement21 Founders
Culture
Improvement and
Change
Management
Assess your culture
• Purpose: show them a noble cause, a global purpose beyond profits, company growth, and
stakeholder wealth. Be open to change for the sake of a greater purpose.
• Learning and Long-‐term vision: people must be conscious of the effects of investment over 4me and
the expected beMer state. Learning must be a real priority. Short-‐term urgencies must not seriously
impact strategic goals.
• Whole system approach: Show them the whole picture and avoid the tempta4on of sub-‐
op4miza4on. Be able to see root causes of the problems, not just their symptoms.
• Constant communica@on and sustained effort: in all ways, not just from managers to employees.
Communica4on is part of our work, not just addi4onal work. Con4nuous improvement must be
sustained on a con4nuous base, not just on occasional events.
• Quality first: technical debt will cost more in the future than the cost of building quality into the
product up front.
• Courage and the absence of fear: Everyone should be able to point at what they consider to be an
impediment, a defect, or an improvement opportunity.
• Transparency: people should be able to ques4on everything. Every trace of a ‘blame game’ culture
must be eradicated. Internal poli4cs and personal agendas shouldn’t drive company decisions.
• Empowerment and ownership: improving the system is everybody’s job. Ownership also means
responsibility and accountability. Have enough resources to improve.
• Teamwork and self-‐organiza@on: empowered individuals should ac4vely seek to collaborate with
each other. Teams should be able to plan and execute for improvement.
• Respect and Recogni@on: use construc4ve feedback and, especially, give recogni4on for individual
and team contribu4ons to company improvement.

How to use cultural assessment:

• Ask your people to rate your company / group / area / team from 1(low) to 5(high) against these
Kaizen cultural enablers.
• Address different opinions. Open conversaEons and gather stories on when are we enhancing /
impeding these enablers. How are these enablers affecEng us on our daily tasks? How do they reflect on
the long term? How do they affect customer value?
• Define symptoms and root causes. Design acEons and experiments to improve these enablers.
Kaizen Roles and Making Change Happen
• Change Evangelist : Who is telling us about the need of change? Who is bringing ideas from other
companies? Who is bringing up the uncomfortable issues? Who is making everyone aware of the
ini4a4ve? Who is dealing with skep4cs and resistance to change? Who is gathering and suppor4ng the
early adopters? Who is fostering Kaizen communi4es? Who is radia4ng informa4on? Who is fostering
dialogue and par4cipa4on?
• Change Agent: who is actually making change happen? Who is pushing change? Who is defining
change strategies? Who is execu4ng improvement plans? Who is training people so they are able to
change?
• Change Leader: who is a role model? Who is succeeding? Who can give us example? Who is making
change desirable? Who is linking change to the group’s purpose, values, goals, behaviors, and needs?
• Change Champion: who is a relevant senior stakeholder that can support change? Who is providing
resources? Who is addressing top management and rule makers? Who is authorizing change? Who is
empowering the teams? Who is incen4vizing change? Who is elimina4ng impediments and barriers to
change?
How to use Kaizen Roles:

• Use the different quesEons to see new things you could be doing in order to push improvement and
change
• Develop more leaders: your job is not to improve the company or make it change yourself, but to make
*everyone* change and improve the company
• IdenEfy your early-‐adopter community
• Spot the Chasm
• IdenEfy SkepEcs and Laggards
Impact Mapping Value Stories
• Why
• Who
• What
• How
How to use Impact Mapping Value Stories:

• Stories
• Impact Map
People and Team
Improvement
Problem Solving Team Checklist
• Small: 5 to 9 people typically. Smaller teams lack capacity, crea4vity, synergy, robustness… Bigger
teams collapse with internal communica4on, bureaucracy...
• Self-‐organizing: no “boss” telling people what to do and how to do it. Team gets assigned goal and
decides how to beMer perform it, how to divide work, who works on what...
• Cross-‐func@onal: team has all the different profiles and skills as needed to perform an increment of
work for the customer, ideally concept-‐to-‐cash. Analysis, sales, development, tes4ng and deployment
are managed by the team.
• Feature oriented: ideally, any team could develop any product feature. Teams are not specialized on
technologies or components (this might be complex on big-‐huge products -‐ consider “as close as
possible” to feature oriented)
• Stable: team members are not added -‐ removed regularly. Same people are able to collaborate for
several months before any small changes are made to team composi4on.
• Collabora@ng: Team has a common, customer-‐defined goal. Team defines a working agreement / Way
of Working. Team members engage same tasks and stories together on a regular basis.
How to use Problem-‐Solving Team Checklist

• Draw a radar chart with the six dimensions. Ask your teams to rate themselves as a team using the
chart.
• For each dimension, run SoluEon Focused RetrospecEve / Root Cause Analysis to spot opportuniEes for
improvement and plan next steps
Mo@va@on Radar
• Security: the need for stable and fear-‐free environments. Earning a decent salary, working in an
environment were your basic needs are met. Being respected.
• Purpose: knowing that you are contribu4ng to something great, that what you are doing is not “jut a
job” or “earning a salary”. Making a difference, being proud of what you do. A sense of achievement.
• Self-‐organiza@on: being autonomous on how to approach your assignments. Having enough power to
decide on certain aspects of your work. Feeling that you are more free and empowered over 4me.
• Learning: growing your knowledge and skills while also engaging challenges that trigger your
curiosity. Improving and advancing in your career.
• Social contact: feeling that you belong to a group and you are accepted by your peers. Having
opportuni4es to exchange opinions and socialize with others.

How to use MoEvaEon Radar

• Ask your team members to rate their own level of saEsfacEon against these five axis, from 0 (not
happy) to 5 (super happy). Engage in conversaEons on why they feel that way. Try to know more about
what moEvates them.
• Is there anything missing from the list? Are they moEvated by travel, exercise, food, family, fun…?
• What would they need in order to have a “5”? use the SoluEon Focused RetrospecEve as a guide to
develop acEon plans to improve each person’s moEvaEon. Develop a common plan and help them
achieve their moEvaEon goals.
Team Facilitator Checklist
• Proper communica4on and respect amongst team members.

• Knowledge-‐sharing strategies and prac4ces.
• Construc4ve and efficient decision-‐making processes.
• Team iden4ty and culture – care for team purpose, respect for team values, and development of team
cultural ar4facts.
• Team learning and improvement.
• Whole team par4cipa4on.
• Observance of ground rules and team agreements.
• Team performance.
• Understanding the team goals and stakeholders’ expecta4ons.
• Individual improvement and ‘career paths’.
• Individual and team mo4va4on, momentum, and engagement.
• Providing feedback and recogni4on on behavior and improvement.
• Showing the team their own results and outcomes to encourage further improvement.

How to use Team FacilitaEon Checklist

• Use this list as a checklist with your Agile Coach / ScrumMaster / Team facilitator, to agree on their
role and their goals
• Use it as an assessment tool to see if the team is receiving enough help – ask them to rate the help
they receive in these dimensions, or how valuable they feel they are, from 1 (not enough) to 5 (great).
Discuss with them ways to increase the facilitaEon support.
Jurgen Appelo’s Delega@on Boards
1. Tell: just communicate your decision

2. Sell: explain your decision
3. Consult: ask people their opinion before taking your decision
4. Agree: agree your decision with the group
5. Advice: give advice to the group before they take their decision
6. Inquire: ask the group to inform about their decisions amer they’ve taken them
7. Full delega4on: don’t even ask about decision

How to use DelegaEon Levels

• Start by idenEfying key decision areas in your environment.
• Define the current decision / delegaEon level of each area. Different decision areas can be delegated
at different levels. For instance, a team can be empowered to make their esEmates on “Inquire” level,
but just “consulted” about new hires
• If there is something at “tell” level, address it as an emergency. On a Kaizen environment,
transparency is a big enabler
• For each key decision area, evaluate what’s needed in order to build enough trust to move the
delegaEon level one step forward. Teams should grow in trust, responsibility and accountability over
Eme! Again, on a Kaizen environment, progressive delegaEon, empowerment and growth both of
individuals and teams is a necessary enabler
• Find more at www.manegement30.com
• Consider the possibility to create a DelegaEon Board, like the one in this example:
Lyssa Adkins’ Conflict Levels
1. Problem to Solve: fun, engaging ques4on that the team approaches as a whole
2. Disagreement: different people have different opinions on how to solve the problem
3. Personal Conflict: the language turns personal; people start to protect themselves and the ques4on
of blame gains importance. New problems will be risen to divert aMen4on and spread blame amongst
others. People will be visibly uncomfortable and the facts being studied or the solu4ons start to fade in
favor of personal argument.
4. Crusade: language turns poli4cal, “them against us”. Anything coming from “them” is immediately
rejected, no maMer if it’s a good idea.
5. Total War: people stop communica4ng, will refuse to collaborate and will try to destroy each other.

How to use Conflict Levels

• Try to maintain your discussions on a construcEve level (problem to solve)
• If disagreement starts to block the team, explore the opEons. Try to negoEate. Use Conflict ResoluEon
list of quesEons (next page)
• Stop any afempt to bring it to personal issues: watch for the use of “you, me, them” (“you always…”,
“I’ve tried, but…”, “they are the ones who…”). Ask people to state and focus on the facts without finger-‐
poinEng. IdenEfy and address the emoEons that turned people defensive or aggressive. Acknowledge
the others: try to argue their proposal. Empathize with the other.
• On a crusade, ask people to stop discussing poliEcs or group issues and focus on the problem to be
solved. Establish common goals and show how these goals will affect all the parts.
• If people have stopped talking to each other, try acEng as a diplomat between them unEl it comes to a
point where you can sit with them together to discuss without hurEng each other.
Conflict Resolu@on – Reaching Consensus
• What’s the conflict we are trying to solve?

• What are the op4ons? Which is the currently decided op4on?
• What’s the part of this op4on that you can’t live with?
• Is it an emo4onal issue or is it a fact-‐based argument?
• How is this op4on personally affec4ng you?
• Why do you think other people might prefer this op4on?
• Is there any way we could modify this op4on so you could live with it, even if you don’t fully agree
with or like it?
• What other op4ons can you provide? How are they different from this one?
• Can you support a 4me-‐boxed test of this op4on?
How to use Conflict ResoluEon

• If emoEons are addressed correctly, this Conflict ResoluEon script can be a good way to focus on
agreement and negoEaEon instead of just each person defending their point of view.
• Try to explore each quesEon beyond the evident, immediate answer. Use open quesEons like “and
what else?” or “how else?”.
• “Why” / “How” (Root Cause Analysis) is also a powerful way to deep-‐dive into quesEons and find
hidden issues
Labs
• Coding standards / Clean code prac4ces / good coding prac4ces / Design paMerns
• Pair Programming / code reviews / coding katas
• Frameworks and tools (code metrics, test automa4on, con4nuous build-‐deploy…)
• Reading & presen4ng books and other materials
• Refactoring / Dealing with technical debt
• Building safety nets / adding tests to legacy code
• Studying and documen4ng legacy code
• Technical Spikes / Proofs of concept
• New programming languages / environments
• Team collabora4on / communica4on exercises
• Hackathons / Coding Dojos
• Develop a knowledge base
• Product brainstorms / design thinking exercises
• Work on impediments detected on retrospec4ves

How to use Labs

• Establish a structured, fixed Eme for labs – like one Thursday agernoon every two weeks. 4 hours per
two weeks means 5% of your Eme – how less are you willing to invest on research, development,
innovaEon and learning?
• If available, book some space far from the regular team space, so they don’t get constantly
interrupted or lured into phone calls, emails, meeEngs…
• Labs are not meant to be extra project Eme. Don’t dedicate lab Eme to iteraEon backlogs or advance
short or mid-‐term assignments. Labs are about developing your people and improving on the long term
• Publish the Lab results so people don’t quesEon them. Make everyone aware of the improvements
achieved as a result of celebraEng labs
• Consider the idea of having a “Lab Facilitator” responsible of gathering all lab requests, prioriEzing
them and deciding with teams and managers which are the most pressing issues or which would deliver
more value next
Improvement
Events
Kaizen Events
• Kick-‐off / Incep@on mee@ngs: improve shared understanding and project plans, empathize with customer
problems and needs, discuss success criteria, analyze and plan for risks
• Backlog grooming: prepare Backlog for next planning sessions. Increase quality of user stories, research on
their backgrounds, break them in smaller, func4onal stories.
• Daily mee@ngs: spot impediments, follow-‐up on improvement plans
• Demos: check user focus and shared understanding, discuss product opportuni4es / alterna4ves
• Retrospec@ves: review process, team collabora4on, individual performance, mo4va4on, user sa4sfac4on,
organiza4onal support…
• Cross-‐retrospec@ves: invite members of other teams to review your process. Facilitate retrospec4ves for
other teams / departments / groups in your organiza4on
• Meta-‐retrospec@ves: run a retro on how to improve retros
• Fire Audits: amer any ‘Fire’, analyze root causes, common paMerns, how to prevent these
• Post-‐Mortem Analysis: amer project comple4on, analyze what to keep and what to change in future
projects
• Value Stream Workshops: select a process, map the Value Stream for that process, define the flow
efficiency, spot boMlenecks, plan for improvement
• Code reviews: select a piece of code, review it publicly and see what can be done differently or what can
we incorporate as standard prac4ce
• Root Cause Analysis Workshops: for a given problem (symptom), brainstorm and analyze all causes. Use
“five why” to find root causes that are ac4onable.
• Labs: reserve certain amount of 4me for team and individual improvement (learning, research,
development, innova4on, rehearsal, experiments…
• Kaizen Blitz / Week: For a selected product, service or customer experience, move the en4re team off-‐site,
who is involved in it. Map out and analyze the current situa4on, find improvement opportuni4es, come up
with improvement pilot plans.

How to Use Kaizen Events

• Are you just celebraEng retrospecEves? Review the list and discuss how / how ogen you could use them.
• Select one Kaizen event you’d like to incorporate. Research on how to facilitate this kind of event. Design an
event standard process. Share and iterate the process over Eme.
• Try to figure out what other kind of Kaizen events can you schedule periodically in your organizaEon. Try to
cover all Agile Kaizen dimensions (culture, process, people, product)
• Keep results of these events public; share every small success to make the case for Kaizen Eme investment.
Improving Retrospec@ves
1. Prepare: ask every team member to collect their issues during the itera4on.
2. Set-‐up: make sure everyone understand that retrospec4ves are not ‘blame games’. Check that
everyone feels comfortable speaking about our improvement areas.
3. Remember: review the last retrospec4ve’s improvement plan. See if we conducted the experiments
that we commiMed at last retrospec4ve (if not: abort current retro and fix this)
4. Storytelling: build a narra4ve with last itera4on’s story.
5. Highlight: iden4fy the most important parts of the narra4ve, both good ones (keep) and bad ones
(get rid of)
6. Divide and priori@ze: assess impediments impact on the team and team’s ability to remove them.
Select next impediments according to it. If impediments are big, divide them in small parts.
7. Root Cause Analysis: deep-‐dive into the selected impediment(s). Spot ac4onable root causes that
can be engaged by the team.
8. Plan: ask the team for commitment on what to do, how to do it, when to do it and who is going to
be responsible for the follow-‐up
9. Celebrate: ask team members to thank each other for specific ac4ons observed during last sprint.
Keep this apprecia4on cards visible for everyone near the team’s board
10. Follow up: use daily mee4ngs to review the improvement plan and make sure that new
impediments are spoMed
How to use Improving Retros

• Build a poster with these 10 steps, ask teams to have the poster visible during retrospecEves
• Go to hfp://www.improvement21.com/2015/09/02/21-‐Eps-‐for-‐effecEve-‐retrospecEves/ for an
extended version of this list. Join our newslefer for a complete White Paper on how to improve your
Kaizen events
• OpEonally, you can design and use a retrospecEve template / canvas that supports the process -‐ see
example:
Solu@on focused Retrospec@ve
1. What do you want to talk about that is useful for you?
2. What is the goal to reach?
3. If you already reached our goal, which effect would it have on you? Which else?
4. When you reach your goal, how would it affect others? And how else?
5. From 0 to 10, where do you see yourself about reaching this goal now?
6. What did you already do so you are at X and not lower? What was YOUR contribu4on? And what
else?
7. When you move up just one point, what differences would you no4ce? And what else?
8. What would YOU do differently when you are one step further on the scale? And what else?
9. How would OTHERS no4ce that you are already one step further? And how else?
10. On a scale from 0 to 10, how confident are you that you will make this step? How could you
become more confident?

Using SoluEon Focused RetrospecEve

• ‘Problem talk creates problems’ : don’t focus too much on the negaEve side of impediments, focus on
soluEons, alternaEves and opEons instead
• You can use these ten quesEons to go over any impediment and design acEon plans
• AlternaEvely, you can use them on one-‐on-‐one coaching sessions
• Use ‘What else’ and other exploratory formulas to go beyond the obvious answers and preconceived
ideas
Kaizen Board
• What is our purpose? How do we provide value to our customer and our stakeholders?
• What is the desired state? Why?
• What is the current state? How do you know?
• What have we improved already? How can we keep on doing this?
• What problems / impediments have we iden4fied? What are the root causes?
• How are these problems affec4ng us / others, including customers and stakeholders?
• What solu4ons / alterna4ves have we iden4fied for these impediments?
• What enablers have we iden4fied? Who / what can help us?
• Which are the risks? How can things go wrong? How can we prevent them?
• How do we plan to improve?
• What are the next steps? When are we going to take them?
• How will we measure improvement?

How to use Kaizen Boards

• Use the quesEons with your team to design a Visual Board; use the board to plan, execute, measure
and steer your improvement plan
• Keep the board visible to everyone in the organizaEon; consider organizing ‘guided tours’ to your
board every once in a while to raise awareness on improvement
• Iterate your board over Eme. Research other Kaizen board soluEons and see what can you include to
make it more effecEve
• AlternaEvely, you can start using Improvement 21 Kaizen Board design: it features impediment
backlog (problems), Next iteraEon (N+1) focus, Current IteraEon (N) with ongoing acEon plan, past
iteraEon with experiment results and a n improvement backlog (all things we improved)
Process
Improvement
Value Stream Mapping (VSM)
• Who is your customer and how do they define value?
• Through what main steps do you create value -‐ from customer request/idea to sa4sfying the
customer request -‐ in your company today?
• If you asked the customer, what were the steps that they are not willing to pay for? (i.e. not value-‐
adding to them?)
• What steps are value adding from your customer’s viewpoint?
• How long do you have to wait between steps? Are there any queues forming between steps? How big
are they? Can you spot any boMlenecks? Is the pace set by any par4cular step?
• For each step, how long are you actually adding value and how long you are doing other things
(wai4ng for approvals, searching for missing data…)
• For each step, how many things are you doing at the same 4me? (hint: divide value added 4me by the
total amount of items being worked at)
• What’s the total 4me to cross the whole value stream, concept to cash? (Lead Time)
• What is the overall % of the total lead 4me you are adding value to your customers? (flow efficiency)
• Map out your interac4on points (communica4on) with the customer of the value stream during the
process. Is there any way you can improve their wai4ng 4me experience?
• Mark improvement opportuni4es (“kaizen burst”) on your value stream. Start problem-‐solving here.
How to use Value Stream Mapping

• Never do value stream mapping alone! Always gather all the relevant stakeholders who work on the
value stream into a room, around a large whiteboard. If you can get a friendly customer to afend, also
do that, this will help you stay focused on the customer perspecEve!
• Do value stream mapping visually, on a whiteboard or on a large brown paper on the wall with post
its. There is plenty of great sogware to document the outcomes later, but doing it in the sogware
straight away takes away the parEcipaEon and discussion, which is so criEcal.
• Keep your value stream map up-‐to-‐date, on the wall/whiteboard next to your stakeholders who work
on it. The value stream mapping is not a one-‐Eme acEvity, but an acEvity that drives kaizen -‐ update the
map with the successful improvements that you have implemented and the new problems that you
have discovered!
Waste Sources
• Muda: Waste
• Wait 4mes, mee4ngs, bureaucracy
• Bugs, technical debt
• Misunderstandings, wrong / unwanted features, rework
• Mura: Varia@on
• Huge stories / projects
• High peak / Off peak seasons
• Context switching
• BoMlenecks, queues
• Lack of standards
• Muri: Overburden
• Lack of resources
• Overprocessing (“gold pla4ng”), too much documenta4on
• Unreasonable deadlines
• Subop4miza4on, Lack of collabora4on
How to use Waste Sources

• Discuss the definiEon of waste (acEviEes that are non-‐value-‐adding from the customer’s point of view,
“anything that we’d like to reduce to the minimum or even get rid of”) with your teams to rise common
understanding and concern
• Ask your team to spot waste in the process around them and see in which category they fall. Assess
the impact of these waste sources on your overall process, value stream and customer value
• Conduct Root Cause Analysis workshops over the most relevant waste sources. Devise plans to make
their impact visible and reduce it.
Bodlenecks – Theory of Constraints
• Exploit: make sure that the boMleneck is opera4ng at its full capacity. Remove any other
responsibili4es or workload from the boMleneck that can be assigned somewhere else on the value
stream. Make sure the input to the boMleneck has as much quality and pre-‐processing as possible.
• Subordinate: once the boMleneck is opera4ng efficiently, make the whole value stream reduce their
pace to the boMleneck’s capacity. Adjust workload to current capacity. Spot the idle resources and
assign them to work at improving the boMleneck capacity.
• Elevate: only when the bodleneck has been exploited, the whole value stream subordinated and
you see that the whole system works as close as 100% efficiency as possible, consider adding more
resources. Do not add more resources to a flawed, constrained process!

How to deal with Boflenecks?

• Spot boflenecks by defining the value stream, making it visual and represenEng every piece of work
on the visual value stream (Kanban system)
• Boflenecks can produce big queues or, if they are at the beginning of the process, big blank spaces on
the Kanban board (starvaEon)
• Conduct root cause analysis to exploit boflenecks
• Limit Work In Progress (WIP) to subordinate to exploited boflenecks. Enforce T-‐Shaped professionals
who can help their colleagues with lower complex tasks when they are subordinated to a bofleneck
(like, for instances, developers helping at a tesEng bofleneck)

Root Cause Analysis
• Define a problem you’d like to discuss. The goal is to find ac4onable items that solve the problem at
its origin instead of just correc4ng the symptoms
• Start by asking “why?” as many 4mes as possible. For each “why?”, there shall be several different
answers -‐ several elements impac4ng a complex problem. Branch them and keep asking “why?” on
each branch.
• If asking “why?” makes no sense, try with “who?” (like, “why? to become healthier -‐ HOW?”).
• Try to group causes (a common approach is to search for Man, Machine, Method, Material, but you
can try different categories)
• Stop when you find things you can try to change (ac4onable causes). Keep this analysis visible
How to Use Root Cause Analysis?

• Make R.C.A. one of your preferred tools when talking about problems and impediments
• Combine it with SoluEon Focused RetrospecEves
• Use it to treat causes instead of symptoms
• Use it to raise awareness of causal relaEonships between impediments and their effects
• You can use Ishikawa / Fish Bone Diagrams as a support, like in this example:

Product
Improvement
Product Management Checklist
• Be able to successfully iden4fy our market, our customers, their problems and their needs. Define
value from the customer’s perspec4ve.
• Be able to collect opportuni4es, priori4ze them according to the company strategy and characterize
them according to their inherent assump4ons. Validate those assump4ons through customer
experiments.
• Be able to propose valuable, usable, and feasible solu4ons to our customer’s problems.
• Be able to provide a viable and validated business model for our solu4on to customer’s problems.
• Be able to manage the limited development capacity to produce the maximum customer value. Guide
product development in order to provide an op4mal solu4on.
• Be able to provide constant feedback and customer collabora4on.
• Be able to maximize our solu4on’s market success.

How to use Product Management definiEon

• Whether you have a dedicated product manager for your development team or you distribute this
funcEon amongst your team members, you can use the definiEon as a checklist to improve this role.
• Make sure that you have all the informaEon menEoned above – market, customers, their problems
and needs, opportuniEes, assumpEons etc. – transparent and shared on big visible informaEon
radiators (posters, video walls, drawings etc) to your development team members. It will enable befer
decisions made on an everyday basis.
• Always share customer feedback and prioriEes with your team and stakeholders.

Product Vision
• Everything starts with a vision. People work harder, smarter and longer when they know their efforts
are in service of something bigger than themselves.
• Before you build anything, you should collabora4vely set the stage for why you think your product
should exist at all.
• A good product vision is a compelling short statement describing you will make the world beMer for
your clients.
• Furthermore, you should consider if your product vision is
• Memorable and Simple
• Relevant and Inspiring
• client-‐focused
• Ambi4ous but feasible
• Tangible and measurable
• A five-‐to-‐ten word, verb-‐target-‐outcome format is a great way to start.
• Use stories, metaphors, words, pictures and different forms of media (e.g. video).

How to use the Product Vision

Before you start building a new product or business, whether it is inside a large corporaEon or a
separate enEty, define your purpose of existence, your visionary agenda.
Collect your funding team, key stakeholders and crag your product vision together – using stories,
images, videos, metaphors, drawings, etc -‐, describing how you are going to change the world for your
clients.
Translate all this input into a short, memorable vision statement for your product .

Incep@on Deck
• Why are we here?

• Create an Elevator Pitch
• Design a Product Box
• Create a NOT list
• Meet your neighbours
• Show the solu4on
• Ask what keeps up at night
• Size it up
• Trade-‐off sliders : be clear on what’s going to give
• Show what it is going to take

How to use the IncepEon Deck

• The IncepEon Deck is a set of tools to help you design your product and launch your project. The main
idea is to get together the people who have a need (customers) and the ones who can provide for that
need (development team) and make the lafer understand as much as possible about the problem to be
solved
• There are several blog posts, arEcles and guides on how to run an IncepEon meeEng – research them
with your Product Management team
• “The Agile Smurai” book provides a great guide on IncepEon meeEngs and the IncepEon Deck

Product Management “process”
• Collect opportuni4es
• Priori4ze opportuni4es
• Define the core assump4ons
• Early-‐Validate the core assump4ons
• Schedule first releases
• Define Epics / User Stories
• Iterate the backlog
• Collect and share customer feedback
• Late-‐Validate assump4ons
• Build, Measure and Learn itera4vely

How to use Product Management “Process”

• Don’t understand it as a linear process – everything should be happening at the same Eme. We should
be collecEng opportuniEes for the future while we are developing and delivering current features. We
should be prioriEzing opportuniEes and early-‐validaEng them at the same Eme as late-‐validaEng the
ones that have already been delivered. We should schedule releases for the next months, but also plan
for the next iteraEon…
• Use the list as a checklist and try to idenEfy how these processes are executed in your company. Who
is responsible for them? How ogen are they executed? What should be improved in it?
Business Model Canvas
• The Business Model Canvas is a living, visual business plan. It is living, because you need to constantly
update it with new assump4ons and learning about your customers and market. It is visual with all the
building blocks of your business laid out in a canvas.
• It includes all your validated and invalidated assump4ons about
• Your target customers and their problems, needs, fears and wants you are about to solve
• Your assumed unique value proposi4on
• Key channels to market, and how you will maintain customer rela4onships
• The partners and resources required to build a scalable business
• Your macro and micro-‐economic environment, compe4tors, consumer trends
• Your revenue model
• Your cost model

How to use the Business Model Canvas

• Use the Business Model Canvas from step 1 on new business ideas and in any stage on an exisEng
business to clarify key elements and look for value-‐creaEng opportuniEes.
• The benefits of using a Business Model Canvas include:
• To be able to pitch your business internally and externally to anyone in less than 1 minute.
• To discuss and iterate different versions of value (and profit) creaEon
• To track risk-‐level of your business, i.e. assumpEons vs validated elements of your business
model
• To assess investment readiness or pitch to investors
Design Thinking
• Empathize: Learn about the audience for whom you are designing for by observa4on and interviews.
Who is my user? What maMers to my user?
• Define: Create a point of view that is based on user insights. What are their needs, wants, fears?
• Ideate: Brainstorm and come up with as crea4ve solu4ons as possible! Wild ideas welcome!
• Prototype: Build a representa4on of one or more of your ideas in a simple form that you can show to
others! Remember, the prototype is just a rough dram!
• Test: Share your prototyped idea with your original user and observe, ask for feedback! What
worked? What did not? Show, don’t tell.
• Repeat the process again!

How to use the Design Thinking

• Design Thinking is a mindset that everyone can create a more desirable future using a simple creaEve
process. It can transform the way we create or improve services, products and even strategy!
• While the Design Thinking process can be used best on new ideas, business opportuniEes, it can be
also useful to re-‐design or improve exisEng products or services.
• Come together with your cross-‐funcEonal product discovery team, if possible face-‐to-‐face!
• Have a facilitator role, to focus the discussions and quesEons asked at each stage of the process.
• Allow for divergence in Empathize and Ideate stages, and converge in Define and Test stages!
Minimum Viable Experiment
• De-‐risk your business with frequent customer-‐facing experiments, collec4ng customer feedback and
observing customer behavior!
• A good ball-‐park metric for your discovery team is to talk to at least 20 users every week, and to
monitor qualita4ve as well as quan4ta4ve user metrics.
• Your MVE Minimum Viable Experiments will gradually become experiments on an early prototype or
version of your product. We call this product version an MVP, Minimum Viable Product.

How to use the MVE / MVPs?

• Create an Experiment Board on a whiteboard or wall space in your office.
• List all the experiments MVEs you need to run to validate your most risky assumpEons in the TODO
column.
• Have a SELECTED column for prioriEzing the most important experiments to run next.
• Every week, make sure you run a few experiments, put these into the RUNNING and when completed,
into the FOR EVALUATION column.
• Take Eme to evaluate your experiments for learning, check metrics, customer feedback. What is the
next acEon? A pivot (change) of your iniEal assumpEon? Or an addiEonal, unexpected learning?
• Make sure you summarize learnings from each experiment on ‘learning cards’ and on your business
model and other arEfacts!
• Be careful to build your product versions minimally, with the fast and early customer feedback in
mind! Design a landing page, a paper prototype, a 3D printed mock up and get it in front of your real
users! (MVP)
Customer / User interviews
• The primary purpose of customer/user interviews is to collect insights and feedback about how we
can help our customers/users solve their problems beMer.
• Note that we use the customer and user dis4nc4on here as these might be two different people or
organiza4ons. The point is that customers buy, users use your product.
• There are basically two types of interviews: Discovery and Valida4on interviews. The discovery
interviews aim to get insights on our assumed target customers. To help us empathize with them and to
deeply understand what problems they face and how they go about solving them. The valida4on
interviews on the other hand are more targeted on an assump4on we have about the customer. For
example, we might assume that our proposed solu4on will generate interest from them, or they will
like the early prototype designs of the proposed product. The purpose of the valida4on interviews is to
either validate or invalidate these assump4ons via customer feedback.
• Possible customer interview formats include:
Customer need discovery workshop
Customer/user experience mapping
SWITCH interview (with new customers, who recently switched to your product)
Rapid prototyping joint session
Prototype A/B tes4ng session
Customer experience improvement sessions
Customer focus groups

How to use the Customer/User Interviews

• We should make sure that we regularly use both types of interviews in our product design and
development process.
• Always plan customer interviews ahead with your team, what’s the purpose of them (discovery,
validaEon), what’s the format and the script of key quesEons.
• Customer interviews are most effecEve when you carry them out in the customer’s natural
environment potenEally dealing with your product in the future.
• Another pracEcal advice is to always try to run interviews face-‐to-‐face over video/Internet so you can
noEce emoEonal/body language hints besides what the customer says.
• Run the interviews as a pair – one asking quesEons, one taking notes – if possible. Record the
interviews if your customer agrees so that you can show customer feedback to your product
stakeholders, teams later.
• Vary the format of customer interviews according to the informaEon or insights you would like to
learn!
• Don’t forget, what customers say and do is ogen different – therefore you need to use other methods
such as observaEon of behavior, sales smoke tests, quanEtaEve metrics to gain more reliable insights
on your soluEon.
Funnel Metrics
In order to improve your product management process and understanding of where your customers
come from and why they stay users of your product is key. Lean analy4cs is a field of collec4ng
ac4onable, preferably real-‐4me metrics of how users use your product.

Metrics of your marke4ng funnel are a key subset of product analy4cs that you can start with.
• Acquisi4on: the customer learns about your product. Example metrics are customer cost of
acquisi4on and effec4veness of your different marke4ng channels.
• Ac4va4on: the customer performs some kind of ac4vity related to our product – eg. Gives us an email
address, creates an account or puts some products into our basket. Example metrics include: 4me
spent tes4ng our product, bounce rate (customers who try our product and reject it), % of customers
that complete their ac4va4on step.
• Reten4on: the customer keeps coming back over 4me and interac4ng with our product. We could
measure visits over 4me, frequency of visits,
• Revenue: the customer spends some money or other type of currency on your product. Example
metrics are Average Revenue Per User (ARPU), Life4me Value (LTV) or Monthly Recurring Revenue
(MRR).
• Referral: the customer recommends our products to other customers. Usual metrics include the Net
Promoter Score (NPS), virality coefficient and overall customer sa4sfac4on.

How to use the Funnel Metrics

Let’s start with a word of cauEon: use metrics to gain insights on how to improve your product rather
than to subsEtute your overall business goal or product vision. Using a specific metric as a performance
indicator of the development team can be detrimental to innovaEon!
To get an overview of your markeEng funnel health, you can use % numbers for each AARRR metric. For
example, what % of total available customers can you Aquire? What % of Aquired customers are
AcEvated? What % of AcEvated customers are converted to Revenue of some sort? Etc.
Define the right point in your product’s customer (user) journey to measure each AARRR metric. In other
words, what specific acEon(s) by the customer count as AcEvaEon in your product? And so on.
Measure funnel metrics over Eme, such as by defining user cohorts with similar afributes. Eg. You could
define a user cohort as all users who have signed up within the last week. Compare metrics for cohorts
over Eme.
Make sure your Funnel Metrics are visual, accessible and available to all your product management
team.
In fact, you can build Funnel Metrics into your goals and user stories, so that every new feature or
improvement you do on your product drives a Funnel Metric KPI.
Resources
Your improvement
journey has just started!
Keep on learning with these useful
resources
This course is based on the book “Agile Kaizen” by Ángel Medinilla
(Springer, 2014). You can find informa4on on new courses and events at
www.improvement21.com. Through this site, you can also join our
newsleMer and be updated on new versions of this guide, white papers,
ar4cles, field reports, interviews…
We share a lot of interes4ng stuff at our Facebook (hMps://

www.facebook.com/improvement21) and TwiMer (@improvement_21).
You can also follow our founders, Ángel Medinilla (@angel_m) and
Andrea Darabos (@adarabos).
Improvement21 is a proud Happy Melly funder – learn more at

www.happymelly.com
Remember to visit www.improvement21.com for more

useful resources and news!
Improvement21 on-‐site
improvement programs
We offer on-‐site training and consul4ng services to help companies kick-‐
start their con4nuous improvement habits. Our program features 16 on-‐
site consul4ng days and the equivalent of 5 remote follow-‐up days on the
span of five months. This helps companies create the cues and rou4nes to
con4nuous improvement habits, and provides expert assessment on how
to improve your organiza4on’s culture, people, teams, process and
products. Contact us to learn more about this improvement opportunity!
Recommended books
Improving Culture:

Freddy Ballé, Michael Ballé: The Gold Mine
Zappos: Culture Book
Ne~lix Values presenta4on
Dave Logan and John King: Tribal Leadership
Tony Hsieh: Delivering Happiness
Ricardo Semler: Maverick
Change Management:
Linda Rising & Mary Lynn: Fearless Change

Jurgen Appelo: How to Change the World
Malcom Gladwell: The Tipping Point
Geoffrey A. Moore: Crossing the Chasm
Chip & Dan Heath: Switch
Kaizen Events:
Mike Rother: Toyota KATA

Luis Gonçalves and Ben Linders: GeRng Value Out of Agile Retrospec4ves
Esther Derby and Diana Larsen: Agile Retrospec4ves
Diana D. Whitney: Apprecia4ve Enquiry

Improving Processes:

Mary Poppendieck: Lean Somware Development
Niklas Modig: This is Lean
Eliyahu GoldraM: The Goal
Jim Womack: Gemba Walks
Masaaki Imai: Gemba Kaizen

Improving Teams:

Jurgen Appelo: Management #Workout
Jurgen Appelo: Management 3.0
Henry Kimsey-‐House, Karen Kimsey-‐House et al. : Coac4ve Coaching
Lyssa Adkins: Coaching Agile Teams
LiseMe Sutherland: Collabora4on Superpowers (pre-‐order)
Marshall B. Rosenberg: Non Violent Communica4on

Improving Products:

Eric Ries: Lean Startup
Steve Blank: The Four Steps to Epiphany
Jeff PaMon: User Story Mapping
Giff Constable: Talking to Humans
-‐
Course Handout
-‐
We help people and companies create

conEnuous improvement habits
www.improvement21.com

Improvement21 Handouts V1.3

Uploaded by

Document Information

Original Description:

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

Improvement21 Handouts V1.3

Uploaded by

Copyright:

Available Formats

V1.

Habit-­‐building improvement prac4ces

We are Happy Melly Funders – check us out at www.happymelly.com!

Angel Medinilla and Andrea Darabos,

How to use Kaizen Roles:

How to use Impact Mapping Value Stories:

How to use Problem-­‐Solving Team Checklist

• Proper communica4on and respect amongst team members.

1. Tell: just communicate your decision

• What’s the conﬂict we are trying to solve?

How to use Conﬂict ResoluEon

How to use Improving Retros

How to use Value Stream Mapping

How to use Waste Sources

How to Use Root Cause Analysis?

• Why are we here?

We share a lot of interes4ng stuﬀ at our Facebook (hMps://

Improvement21 is a proud Happy Melly funder – learn more at

Remember to visit www.improvement21.com for more

Linda Rising & Mary Lynn: Fearless Change

Mike Rother: Toyota KATA

We help people and companies create

You might also like

Habit-‐building improvement prac4ces

How to use Problem-‐Solving Team Checklist