0

A pocket guide of Lean Inception

R
Renato Souza

By basic definition, Lean Inception is a methodology created so that through a collaborative workshop, a group of people align themselves to build a minimum viable product.

Created by Paulo Caroli, its main objective was to reduce the time of "traditional" Inceptions, which took two to four weeks to complete with a plan almost always complete with the release of a product, for only one week.

Inspired by the publication of the book "The Lean Startup" by Eric Ries, Caroli found in MVP, the "Minimum Viable Product", reduce the focus of planning in minimal and essential functionalities of a product that can be released already adding value to the business.


The Lean Inception Workshop

During the collaborative week, the workshop presents several dynamic activities to define the objectives, strategies, product definition and key users, mapping and prioritization of functionalities, user journeys using the functionalities and construction of the MVP.


Agenda of the Week

Lean Inception is a collaborative workshop with very brainstorming sessions and conversations, and it usually takes place over the course of a week.


The agenda is a simple and effective tool for planning and controlling the workshop's time and progress. It should be created and explained to everyone in the first hour of Lean Inception.

The highlight in gray color in the activities of Kick-Off and Showcase is used to make it clear that stakeholders necessarily need to be present in these sessions, knowing that in the others may incur scheduling conflicts and unavailability.

You can Brainstorm Features before Creating User Journeys if you want feature ideation to be based on and influenced by business objectives and personas needs. However, is also possible to Show Users' Journeys before performing Features Brainstorming when you want functionality to be based and directly influenced by users' journeys.

War Room

It is important that the room used for workshop still the same during the week, known as War Room, it must be large enough to hold all members, needs to have a table and wall with clean spaces, flipcharts to be constant target of the cards, colorful post-its and papers, which should be available next to pens.


Everyone is allowed to make their notes, put them on walls, tables, flipcharts - Everything that is created there, must remain there.

With the strong home-office trend, it is possible to organize remote War Rooms using conferencing tools such as Teams, Zoom and Webex, collaboration tools such as Miro, Mural and Figma. And even tools to perform retrospectives such as FunRetrospectives.com.


Facilitating Person

For ideas to flow and conversations between all team members are really active, the workshop needs a good mediator. This person needs to have experienced some lean inceptions and being familiar with their shape.

Their main role is to support each person so that they feel comfortable to participate effectively in all planned activities, proposing their ideas and dedicating themselves to the process.

Product Vision

It is essentially what defines the value of the business.

It will help you decide the initial characteristics of your product, how to start their creation and should pass a clear message, which convinces your customers.

The following structure helps to create the Product View:

"For:                     [end customer],

whose                   [problem that needs to be solved],

the:                        [product name]

is a:                       [product category]

that:                       [key benefit, reason for acquiring it],

differently from: [alternative competitor]

our product:        [key difference]."

 

Clarifying the Goal

Each team member must write and present what understand individually as the business objective.

Everyone should share the cards and the similars must be grouped, then three business objectives will be collectively rewritten. This will help to making clear the focus of the project.

The product Is, Is Not - Does, Does Not

In this session the team will be able to define and clarify the product on what, in fact, the product will do and what it will not do. It is possible to identify things its will never do, as well as things it’s still will not do, for example.


A flipchart can be divided into four parts then the team will write the characteristics in post-its and place them in the desired areas.

Describing Personas

A persona must be represented realistically, describing its role and specific needs, so that the team can create empathy and based on them can imagine and describe the functionalities of the product or service.

In this session team members will be divided into groups and create a persona with:

  • Nickname and drawing.
  • Profile.
  • Behaviors; and
  • Needs.

 

All the personas must be presented to the entire team, then new groups will be created to repeat the process - a good number of personas will be created and different types of users will have been detailed.


Features Brainstorm

With the goals and personas defined, both must be arranged on a common canvas then the team will add the features that each of one understand that make sense for each Goal x Persona.

Each proposed feature should be described in a simple way – as simple as possible.

 

Technical, Business and UX Review

This session is used to discuss about the features generated in the previous one in detail and reevaluated, grouped (in case of similar or duplicated functionalities) and even discarded when realized that make no sense for the purpose of the project.

The review covers an individual assessment of effort, business value, and user experience on a three-level scale.


Still in this activity, for refinement to be effective, the team will classify the level of confidence in common as to 'what should be done' and 'how to do it', between low, medium and high.

Combining the level of technical trust with the level of business confidence and user experience, each feature will be classified with a color – between green, yellow and red, such as a traffic light – and placed on a chart.


Features that receive the low rating for the confidence level of how and what would need to be done, should be considered discardable or else the team will need to spend more time to clarifying it better.

Users' Journey

What purpose does such a persona wish to achieve? How does this persona start the day? What does he/she do before that? What is next?

With these simple questions you can start the journey design from each selected persona and goals.

Put Features in The Journeys

Once one or more journeys are defined, you can associate the features in each of the activities on the user journeys.

While each step of the journey is read by a team member, other members are responsible to figure out what features could be used to improve the journey.

Sequencer

The purpose of this session is to create the phases – also called as waves – in which the features will be delivered.

The focus is on prioritize the features with most business impact in the first phases and give clear in which of the waves the MVP will be delivered as well as its increments and other features.

To help the team define the set of features that each wave will deliver, there are six rules.

1.    A wave can contain a maximum of three cards.

2.    A wave cannot contain more than one red card.

3.    A wave cannot contain three yellow or red cards only.

4.    The sum of effort of the cards cannot exceed five 'E'.

5.    The value sum of the cards cannot less than four '$' and four 'hearts'.

6.    If one card depends on another, that other must be on previous wave.


Effort, Time and Cost

The most common questions in these cases are "What are you going to deliver?", "When are you going to deliver?" and "How much will it cost?".

This activity is important to respond each of them to the stakeholders. It can be incorporated and performed right after the sequencer is finalized.

With the benefits of the sequencer rules, all of the waves have a similar size, so this can be done with two or three of them to generate an average effort, time and cost that makes sense and applies to the other waves.

For each feature, the team will create a task list that must be performed to complete the development - In Scrum, these tasks are known as the stories of users. The tasks will be classified as S, M or X and based on this classification it will be possible to know how long it will take to complete each functionality and consequently each wave.


Canvas MVP

This is the last session of the workshop and should not take much more than an hour to finish - when the team has discussed very well in each of the previous sessions.

The MVP Canvas is divided into seven parts and for each to be filled your questions must be answered.


Part 1: MVP Proposal - What is the proposal of this MVP?

Be clear and be sure what your MVP's proposal is. It should be as focused as possible and validate a need for a specific segment of personas and business hypothesis.

Part 2: Segmented Personas - Who is this MVP for? Can we target this MVP into a smaller group?

Here there is a need to be more specific. You should target the personas based on the MVP instead of the product as a whole.

The goal is to launch of MVP for this small group of people, validate and collect feedback so that then progressively the access to the product is released to more people.

Part 3: Journeys - What journeys are met or improved with this MVP?

The journeys should be reevaluated, however, only those that directly meet the personas segmented in the MVP are selected.

At this point, if there is any difficulty in describing or passing on some journey, it is recommended to reevaluate the MVP, as it may not deliver anything to any persona.

Having too many journeys can also be a problem that completely contradicts the concept of MVP, which to remember means Minimum Viable Product.

Part 4: Features - What are we going to build on this MVP? What actions will be simplified or improved in this MVP?

With a much more refined view of the MVP proposal, personas, and journeys, now is it time to look at the sequencer and wonder if for MVP delivery the team have really selected the minimum list of features that make the product viable? Couldn't something simpler be created?

If the team realize that something essential has gotten in the way and needs to be included, talk to each other, make the necessary adjustments, and move on.

Part 5: Expected result - What learning or result are we looking for in this MVP?

The MVP must be fully connected to the expected results and business assumptions. And there's a model that helps to reach this connection:

"We believe that this MVP will achieve (expected result).

We'll know this happened based on (metrics to validate business assumptions).

Part 6: Metrics to validate business assumptions - How can we measure the results of this MVP?

Learning is also an indispensable result in launching an MVP and it is very important that the team knows how to define how measure the progress of the learning. Fill the following definition can help in this step:

"We want to understand better, learn more about ______ ______ and ______. To do this, we will collect such data that will help us verify that we are achieving the desired learning."

Part 7: Cost and Schedule - What is the cost and expected date to deliver this MVP?

In addition to the sampling calculation performed in "Effort, Time, and Cost" external variables that could exist in a project, as infrastructure tasks, needs to be considered and demonstrated here.


Auxiliary Tools


Activities Icebreaker

Fast and fun, these activities are used as a warm-up tool to promote team interaction.

Extremely valuable for the early stages of team building, where people know little about each other – Highly engaged, participatory and having fun people are more effective in collaborative activities.

In the early days, activities to share information such as name and hobbies are recommended. After lunch, guests can use energetic activities that awaken the team.


Parking Lot

Essential to the facilitator, it is used to none of the ideas or issues raised by any of the members which will not be useful for discussion at that specific time is lost.

Your concept should be presented at the beginning of the Lean Inception and as soon as there is the first deviation the mediator needs to explain that the discussions were diverting from the focus of the activity in question and it should be created on a flipchart and placed separately on one of the walls of the room.

At the end of each day, 10 minutes should be dedicated to review the items in the parking lot, and they can be removed in case that the team have already been addressed or maintained for the next review.


Trade-offs

It is used so that in an open and collaborative conversation, team members define a prioritization sequence for categories of a product such as: safety, usability, scalability, performance, etc, to avoid disagreements and decisions to be made more quickly, based on trade-offs.


Empathy Maps

Originally used for analyzing consumer segments, it is very useful to better understand the different types of personas.

With four main areas, which fill in the following sentence: "What do I ______ (See/Think/Hear/Speak)?".

The map also has two other areas for "Pains" and "Gains".


Final Thoughts

Using Lean Inception can be exciting and is a great gateway to transforming the way to create new products and services with agility and huge focus on people.

This methodology enables us to create a good plan in just a week, with a lot of collaboration and creativity in an environment where the focus is to deliver the greatest value to the customer or group of people quickly and assertively, developing a minimal set of features.

The details and step by step of each of the steps described above can be found in the book "Lean Inception: How to Align People and Build the Right Product", published by Paulo Caroli.


References

CAROLI, Paulo. Lean Inception: How to Align People and Build the Right Product / Paulo Caroli. 1st updated edition - São Paulo: Caroli Editors, 2018.

Caroli.org: Knowledge and Agile and Lean Transformationhttp://caroli.org/en


0
0

Comentários (0)

None

Brasil