It is common for organisations or agile teams to have doubts about when to do a Lean Inception. There are many perspectives on this topic and, in this text, we are going to check some!
- Lean Startup and Lean Inception
- Dual track development and Lean Inception
- Innovative project with a lot of impact on the business
- 3Hs and Lean Inception
- Double Diamond and Lean Inception
- Experimentation Sprints and Lean Inception Sprints
- Start of a project and Lean Inception
- Business Model Canvas and Lean Inception
- When not to do a Lean Inception?
- A Lean Inception sandwich
Let’s start by looking at a Lean Startup style for starting a business, with a lot of learning and experimentation. In other words, several experiments were run, many build-measure-learn cycles and now, with an already consolidated learning, a Lean Inception must be carried out to decide what will be the first step for the product, what will be the MVP to be built towards to a very successful solution.
The build-measure-learn cycles can be driven by one or a combination of these three possible cases:
- New ideas or change requests comes from the business area: So, first you need to validate the hypotheses, go through the Lean Startup cycle and, with more learnings, data and insights about the original request, run the Lean Inception;
- Validation of experiments: By doing a lot of experiments, testing initial hypnotises and validating ideas, the learnings confirms a potentially valuable initiative. You should then plan Lean Inception to decide the next step;
- User research: research and surveys were carried out with users who shared their pains and desires, followed by the build-measure-learn cycle to experiment and validate what the user is really interested at. Once this research has evolved and generated good results, it’s time to run a Lean Inception with the proposal to build a product, a solution, something tangible and usable, putting it in the user’s hand and start getting the real usage feedback– that is, the MVP.
Another possible moment for a Lean Inception is when you follow a dual track development style. Dual track development are two tracks: continuous discovery and continuous delivery — that is, when you are having continuous discovery and continuous delivery.
By doing various discovery activities, user research, experimentation, etc., on an ongoing basis, you will generate useful information for making decisions about what to build, what to deliver.
At some point, if necessary, you’ll need to line up with more people to decide: which product to build? What is the solution to such a problem? What should be the first step in building this solution? This is the time to run a Lean Inception and create the MVP plan, so that you are ready to work with continuous delivery of that MVP and product increments.
In a few cycles you will have the MVP ready. You will put it in the user’s hand and continue in the build-measure-learn cycle, now with learning and (continuous) discovery based on real usage. In other words, you continue to evolve continuously on this dual track of continuous discovery and delivery.
It is important to emphasise the “if necessary” mentioned above. If you, for example, are already working on a product team with everyone aligned, you may not need to run a Lean Inception. However, if your reality is like the one I see in many organisations I go to, with different teams working on each track, from time to time it is essential to align everyone towards the same goal — and that’s what Lean Inception will help you with!
If you have a project, an initiative, that is very innovative and has a lot of impact on the business, you should schedule a Lean Inception. The situation calls for one, as it has a lot of innovation and there will probably also be a group of people who will need to better understand what to be done.
Whereas, if your project has little innovation, but a lot of impact on the business, this is your “dairy cow”, which are the existing products that do not require changes, but that continue to be important for the business. In such case, don’t do a Lean Inception. Don’t stress your dairy cow that is bringing sustenance to your business, as trying to change her may stop producing milk. Maybe you can do an inception not for the effectiveness part, but for the operational efficiency of the dairy cow.
Now let’s think about projects or initiatives that have a lot of innovation, but little impact for the business. These situations also do not require a Lean Inception as the impact is low. You need discovery, experimentation and ideation to generate more learning. So then, if you learn a lot, maybe you can bring more impact to the project and, thus, Lean Inception comes into play.
And the last quadrant of this topic is little innovation and little business impact — these also don’t need a Lean Inception, as that would be a waste of time. If your initiative is falling into this situation, you need to review it or discard it.
Horizon Two: This is a perspective that also calls for a Lean Inception. McKinsey created the three horizons framework for organizational growth. The authors of the framework went through several companies and found that those that were very successful for several consecutive years followed this way of investing in the portfolio and maintaining growth, which is what they called horizon one, horizon two and horizon three.
At all times, the organization needs to be investing a large percentage in horizon one, which is the dairy cow, which brings the company’s livelihood.
However, at the same time, the organisation also needs to invest a part of its capacity (either financial or intellectual) in horizon two, which are initiatives that do not bring sustenance to the company now, but that are generating results that, in the future, may become new dairy cows.
And horizon three are initiatives that generate learning and, even if they don’t generate results yet, they also need investment. That is, horizon one is revenue, horizon two is result (to become revenue in the future), and horizon three is learning.
Now see how interesting. Horizon one we’ve talked about before that you don’t need an inception so you don’t risk stressing your dairy cow (again, just consider doing an inception if you need to rethink something about operational efficiency). And does horizon three need Lean Inception? No, horizon three is experimentation, learning, innovation. Yes, it needs investments. But not from an inception.
Now horizon two, yes, it’s the scenario in which you want to bring a group of people to think about different paths and, from that, decide what will be done, what will be the minimum viable product for that initiative in order to validate the hypotheses of the initiative that, in the future, could become the dairy cow.
The second D of Double Diamond: From Design Thinking we have the Double Diamond (the four Ds), which is a very useful model for designers to organize their thoughts in order to improve the creative process.
The first D is discovery, generally opening up and exploring many options. The second is to define, which will narrow down the number of options and choose which one you are exploiting. Then we have the development, the construction of the solution; and delivery, all of which involves approval and launching.
Lean Inception isn’t ideal for every moment, but it’s the perfect fit for the second D: Define. This is the moment when you will narrow down the options, as you already understand the discovery, and decide where to start, decide the MVP, so you can assemble the first solution that will be developed and placed in the hands of users.
After ideation and experimentation sessions: … Lean Inception is perfect. If you have several sessions, whether experimentation sprints or ideation sessions, you are generating a lot of knowledge and a lot of learning. Typically, at some point, a light will be turned on by this accumulation of learning: “Look, it seems that this is a good idea, it seems that from this initiative we will achieve product market fit”. And then you can do a Lean Inception to align with a group of people and then everyone comes out of it with a product creation plan based on the MVP concept.
In the initial phase of a project: Many companies use Lean Inception as a lean initial step, and this happens even on very large and complex projects. Was the project approved? Great, so we need to start developing it. Even if it is very large, it is worth starting with Lean Inception to align people and build an aligned construction plan.
Today almost all projects are approved without an excess of details. And instead of spending time detailing all stages and activities of the project, the team does the inception, creates a lean plan and starts to deliver, incrementally. And why is that? For the team to take a safe first step and make sure it’s heading in the right direction.
The next step to the BMC (Business Model Canvas): The BMC is a wonderful artefact that shows your business strategy. There you have the proposal, you have the sales channels, you have everything in a clear and concise organisation. The strategy is clear, but what is the next step?
It’s great to have a comprehensive strategy and vision with lots of plans, but you need to start small. When you do Lean Inception, you come out of it with a MVP Canvas. Combining both, you will have a very well grounded business strategy in the BMC and a very firm plan for your MVP (something you achieved by doing Lean Inception, building your MVP Canvas). You know where you are going to, as well the very first step in such direction.
Listed above are some cases where Lean Inception fits very well. But it’s just as important to know when not to have one. It’s not because you have a hammer that you’re going to hammer everything, do you agree?
So let’s see some examples:
- If you’re doing discovery and research to generate learning, then it’s not an inception. You can use other methods and other techniques, focusing on generating learning.
- If you’re deciding on a prototype, do a Design Sprint, which addresses exactly that, the decision on a winning prototype. Do a Design Sprint and leave the workshop with the with a prototype already decided and tested. Don’t do a Lean Inception, as it is not focused on the prototype.
- If you need to align several teams on a work program, that doesn’t fit in a Lean Inception either. You can use a PI planning for this.
- If you are looking to prioritise a portfolio of initiatives, you should use the WSJF or RICE methods. List your initiatives, give rate them and decide what is the priority.
- If you want to map out technical details of a solution, many people even call it inception, but it’s a more technical workshop. Lean Inception always has the business, user and technology perspectives, so it doesn’t fit in that situation. Instead, organize a sequence of technical activities.
- If there is a need to define the work process of a team, you should not do a Lean Inception either. Instead, you should carry out various activities to define the ways of working. FunRetrospectives.com, for example, has several team building activities with excellent suggestions on how to handle such a situation. Lean Inception is not for that, because its focus is to align a group of people on a product to be built.
- If you are going to plan the Sprints backlog in user stories, do a PBB, by Fábio Aguiar, a wonderful technique to build and refine a few PBIs (Product Backlog Items) for your next hypnotises validation or product increment.
- If you want to map users’ journeys in user stories, it’s not the time to do a Lean Inception either, but to use Jeff Patton’s User Story Mapping.
What usually happens is that Lean Inception is in the middle, there’s something going on before and something going on after. Despite being called inception, it is rarely the beginning.
Design Sprint, Lean Inception, and then a PBB. This is a widely used combination in Brazil. You start with a Design Sprint to check the options and decide the winning prototype. Having the product prototype, then you do a Lean Inception to decide the MVP, where to start and what the next increments are. And then you do a PBB to create the user stories and work on the Sprints.
Another common combination shared by entrepreneurs is starting with the BMC to understand the business strategy; follow up with a Lean Inception to understand the MVP strategy; and finish with a Kanban of everything that has to be done to deliver the solution very successfully.
This option is being used by organisations going through Data Mesh transformation. You start with a Date Mesh Accelerate Workshop to align and understand the Data Mesh strategic goals and scope, then you choose the pilot initiative that will be worked on in Lean Inception. Then comes a more technical and more specific Event Storming in relation to that initiative that is mapped into an incremental delivery plan thanks to the Lean Inception.
This sequence has been shared by a few colleagues working with SAFe. You start with a PI Planning to align the overall program work and define the tracks. Then, for each track, you do a Lean Inception, followed by the Ways of Working for that team and, finally, the User Story Mapping to map user stories based on journeys.
And, finally, a typical combination used by many consultancies. You start with an on-boarding period for a group of people into the new project or initiative. On these, typically there is lots of context and knowledge sharing as well as many team building activities. Then, with the team already onboard, a Lean Inception is carried out to align on the product that will be built. And then it follows with a Sprint Zero so that the team prepare the ground to start working and delivering effectively on the following Sprints.
Based on everything presented here, you now have the information you need to decide when to do a Lean Inception and when to opt for other methods. I wish you an amazing and very successful workshop.