Lean Inception: How We Tried to Make It Leaner and What We’ve Learnt

“Build it from scratch your own way and don’t let yourself be influenced by the existing system” – words that are rarely said by the stakeholders, right?

It’s been almost a month that I started working on this new engagement. New in all possible ways: we are advised to think of the future and build a future product from the very start without clear directions. This may sound like a wonderful opportunity (and it is), however, it came with an enormous sense of uncertainty. We had no idea what we are supposed to develop, there were 3 teams assigned and for 2 weeks all of us were trying to find out where we should start. There were no user stories or lower-level vision of a product. What is more, all 3 teams are starting with the back-end products which are just a first step towards the goal which will be this huge modern platform to be launched in several years.

The vague high-level vision and no directions from stakeholders led us to worry slightly. With the first checkpoint approaching in a couple of months, we had to try to understand the product more. So, we decided to try out a leaner version of already Lean Inception.

My role is a QA in this project, so being a part of such an early stage is pretty new to me. I took the Lean Inception book, read it over the weekend, and tried to understand the concept more so I could contribute as much as possible in the activity.

Starting the Lean Inception activities

Agile needs some pre-work and inceptions can help to find out about the project more. Usually, they last a few weeks, but because of time constraints, Paulo Caroli created a one-week version to find out what the product vision is, discover features, and define MVP (Minimum Viable Product). During this Lean Inception week these activities take place:

  • Product vision definition
  • What product is – isn’t – does – does not
  • Describing Personas
  • Discovering Features
  • Technical and business review
  • Defining the User Journey
  • Display Features in a Journey
  • Sequence the Features
  • Build the MVP Canvas

For the same reason as Lean Inception became a shorter version (time constraints!), we also felt like we have very big deadlines approaching and don’t have much time, so two activities were picked to be done by all 3 teams:

  • Describing Personas
  • Discovering User Journey

Within our teams, we tried to define product vision and do some pre-work. However, it still remained very high-level and teams had to align with their work, so the user journey seemed to be something we really would need. For the Persona definitions, we also invited the client’s departments with which we may need to work in the future. Our ways of doing exercises were not exactly following every step from the Lean Inception concept – we adjusted some exercises to fit us better.

Describing Personas

We had only 2 hours scheduled for the Personas description. When all of the participants met, we split into groups of 3-4 and discussed all the possible personas for the product. Firstly it was just like a brainstorm of all possibilities (funnily, some of our personas were other back-end systems because we had to cover those, too, so it was not only people). We needed this to actually start going somewhere – it was hard to think of a usual person using the product, the product looked way more complicated than that.

Each definition of a persona includes nickname and drawing, profile, behaviour, and needs. The exercise was also pretty fun as we could imagine funky characters that may be edge cases of actual user spectrum.

For example, let’s say our product is a ticket booking platform. Then, we should collect all kinds of personas who may use this platform. And some of personas could be: elderly man who wants to buy a ticket to gardening convention nearby (wants it to be easy to use, can be slower than usual, less tech-savvy), a teenager who follows trends and wants to quickly get the ticket to the hip concert or an employee of a tech company who is very tech-savvy and wants to use ticket platform’s API to build their own service for buying tickets, etc.

Illustration is taken from the post of Paulo Caroli at Martin Fowler’s blog on Describing Personas

Then, we discussed the persona ideas we had, combined them (for example, security conscious users or one type of the system, etc.) and assigned certain types of personas to the groups. Back in the groups, we had to think of personas for our assigned category of personas.

This exercise, unfortunately, took us way longer than we thought – we reached our time limit and had to schedule a follow-up session. So, in total, we spent around 4 hours and in the end, we had around 14 personas described.

After persona definition, we did not feel a relief. More of a vice versa – we still had no idea what we are building and personas in our context did not seem very helpful. We could not discover features as Lean Inception recommends. There were certain levels of stress with this outcome. We wanted results quicker and after spending 4 hours on something that did not really help – we were frustrated.

Discovering a User Journey (and Features!)

For the user journey discovery, we decided to involve more people and asked at least a pair of developers from each team to join (persona definition was done mainly with product owners, business analysts, QAs and UX designers).

First of all, after some heated discussions, we decided to choose 2 personas out of 14 only, we split into two groups and tried to come up with user journeys for both of the groups. It was a challenging task, especially, since our personas did not really touch on what we were doing it seemed. So, after two hours yet again we didn’t feel like it became clearer.

After this, we had another meeting to present the user journey to a wider audience. And this was actually extremely useful. What I think helped us a lot was having a great facilitator as well as a big group of people to add their questions.

What we tried to do is to look deeper – user wants to do an action, but what happens on the back-end? What kind of features should we provide for this action to happen?

We used a bunch of post-its to write down our assumptions and also must-do back-end actions for the user to succeed. These felt like features (finally!).

Our mapped user journey (blue post-its) with features (assumptions are above the user story)

After feature discovery

All three teams met to discuss all the features in the journey and assign them accordingly to the teams who are responsible. This actually helped us to even see the first MVP’s scope clearer. As we had a lot of assumptions and had the story in front of us – we could see where we could already deliver value working all together for the first iteration. All this, left us with certain features which will be split to user stories or become epics within the teams responsible. It was a great relief to finally come up with something.

How did we do it in the end?

As we had not much clarity about the product we were working on, our leaner Lean Inception had these steps and outcomes:

  • Personas definition
    • Took way longer than expected and was not as fruitful as we thought it would be.
    • We ended up with 14 personas and only 2 were used (out of which 1 was enough for the MVP).
  • User journey discovery
    • Was very challenging without features to create a user journey as we were not sure what actually should happen.
    • When reviewing the user journey, we went deeper and added what features we should have for certain steps – that was super useful!
    • In the end, user journey helped us to actually realize what features we may need for the MVP!
    • We ended up with MVP which was suggested by the user journey and left the business and tech review to be done within the exact teams.


A lot of us were involved in the Lean Inception for the first time. As a result, there were some learnings on the way. What we tried to do was to save time, but not always it was saving time actually. If we had to do it again, likely we would strongly aim for shorter Personas definition meeting (most of the work done there was not used anyway). Then, what our user journey discovery ended up being was a mix of feature discovery, sequencing features and even helping to form the MVP.

What helped us a lot was in the user journey session to have a great facilitator. Looking back, I realize that a good Lean Inception facilitator is something that can help a lot! If we had to do it again, we would not consider it as a game as we likely did for Personas definition, but rather find a strong facilitator who would be consistent and allow the group to maintain a good pace of outcome and not to deviate away too much.

Also, I feel that sometimes some of us were tired of meetings and would jump to conclusions which weren’t the best, so in the end, I would say these are my 3 summarised learnings:

  1. Strong facilitator helps Lean Inception to have a more structured format and better outcome.
  2. Take your time with Lean Inception activities not trying to skip steps, but also do not deviate too much on tasks which do not provide wanted results.
  3. Do not follow the book blindly. Lean Inception is not always the best format to take to find out about the product – it all is contextual and for your product, some steps may not be as necessary or useful. Try to adjust it accordingly to your needs.

In the end, being a QA and questioning from the start was a very challenging, but also a great experience. I would highly recommend aiming to have a diverse set of cross-team members in the Lean Inception – everyone may have something to add which can build a great basis for the product and clarify any possible misunderstandings.