Triple Loop Product Lifecycle. Learn, Build, Measure and Maturity Levels
Inspired by Lean startup process with the build-measure-learn methodology, I designed an enhanced version of it called Triple Loop Product lifecycle. After getting a lot of positive feedback, I would like to share with you. Maybe one day I can meet Eric Ries in person😄 He is the author of Lean Startup Methodology.
The Purpose.
If you ever encountered a problem when other people in your team were not aligned or there was no unified process, this article might help you address this issue!
After 9 years of experience working in studios, outsource, product, consulting companies and even trying to build my own startups, I came up with a simple classification of project phases and designed a Triple Loop Product Lifecycle.
Its purpose is the creation of an aligned high-level view with all main project phases for a business goal project type. This way, competencies like business, design and technologies are able to map their activities and deliverables.
Your feedback is really valuable, so please don’t hesitate to share the reasons if these practices are not working in your environment. Just add a comment below or write to me directly on Facebook ✌️
Triple Loop Product Lifecycle
The goal of Triple Loop Product Lifecycle is depicting the progression of a project from idea to a solution, where the main focus is on learning and measuring the results.
Nowadays the market is competitive and things are becoming more complex. Each of these phases has its own goals, activities, deliverables; involves various specialists to deliver valuable decisions filtered on each step through multiple iterations. We are only going through the product stream (business goal project type).
Here is the preview of how it works:
On the animation above, each circle represents one iteration that can happen repeatedly. Additionally, collected during an iteration results won’t necessarily be inherited by the next circle. The goal of this approach is to avoid becoming a feature factory and focus on delivering only valuable results (goals, assumptions, hypothesis, insights, solutions, decisions).
Here is another preview as a timeline. You can use it to map your activities and deliverables, plan all the work in advance and make sure you didn’t forget anything.
Let’s quickly cover the main points.
Discovery
The goal of this phase is to answer the question “Why?” and align the team with business goals, strategy and vision. Moreover, it assists in identifying the main problems and planning the work in advance. To achieve faster results use activities like Discovery Workshops, Interviews or Design Sprints. The outcome would be a high-level roadmap, project brief, resource plan and other artefacts.
Learn
The goal of this part is to validate problems, analyze insights and formulate hypotheses to test. Initiate activities like user interviews and user testing. The deliverables would be personas, value proposition canvas, Customer Journey Map, prioritized hypotheses etc. This stage could be repeated once more insights from the experiment and measure phases are collected.
Prototype
That’s where the ideation and low-fidelity prototyping comes into play. It’s not only about information architecture, user flows and wireframes. For example, solution architects could kick off the preparation of high-level implementation diagrams.
At this point, we start to visualize solutions for further testing. As a result, we will get a low-fidelity prototype that will represent possible options.
Experiment
This is the part where the truth might come out, as most of the hypotheses could be tested in the Experiment Phase. Usability testings and other qualitative research methods can be conducted here. As a result, we will get a bunch of insights that will help us in the future. As you might see from the diagram above we could have a couple of iterations with the prototype phase.
It’s important to keep in mind, that it’s too early to draw any conclusions regarding the success of any specific solution. Instead, our goal is to validate hypotheses. Only after releasing functionality on production with real users, it will be possible to measure the created value.
During Experiment Phase, we could test our ideas on a small number of users without any development efforts. Rough mistakes will be found at this stage.
It’s hard to plan the work in advance for the Learn phase and that’s why it’s better to restrict this phase with a specified time frame. Kanban methodology with releases works perfectly at this point.
Build
When we have a clear understanding of why, how and what exactly we are going to build we can focus on the build phase. That’s the phase with plenty of iterations. As a result, we will get a working functionality on the testing environment to evaluate.
We will come back to this phase when there are new requirements and bugs from the Experiment and Demonstrate phases.
Demonstrate
The key is to cover edge cases and test everything that was developed to this point. QA teams are thoroughly examining the product to discover vulnerable parts and bugs before deployment to production. Some companies might have more than 5 environments to test on.
Side note:
It’s important to focus on accessibility. For example, if designers used non-accessible patterns, Accessibility team could spot these issues visually during Experiment OR look for problems in code after development was done during the Demonstration phase.
Improve
At this stage, the whole team is trying to fix the problems and prepare for the release. We might have an extensive number of iterations with the Demonstrate phase at this point.
Measure
That’s the final step to evaluate value created for the company by the efforts made so far. Running surveys, user feedback reviews, tagging, segmentation, feature retention and bounce rates can give a lot of information on how we improved or worsened the main business metrics specified in the beginning.
Side note:
The best way is to release on small groups of people first. You can use different segments, audiences or specific markets based on the countries.
At this point, we have three possible scenarios:
- Return to the Learn phase and make a more significant improvement.
- Continue improving the functionality on the Improve phase.
- Go to the Finalization phase.
Surprisingly, but even after a round of development, some successful companies can roll back new functionalities. The reasons that justify those decisions usually are based on unmet target metrics or lack of desired engagement. By the way, check out articles about the feature flagging for that purposes.
Finalization
If a business understands that the project is not evolving into something valuable, it’s time for Finalization phase. Take a look at the Google Graveyard if you still think that all the projects/features have to adopt whatever was developed. The golden rule — fail fast and pivot.
Different teams have different approaches to development — often some of the mentioned earlier activities and phases are omitted. Therefore teams fall into various maturity levels.
Maturity Levels
Team classes below have specific skills and competencies based on the phases that teams go through. For example, for C class teams, it’s crucial to have product managers and user research team to perform the research activities. E class teams require data analytics and a large user base to ensure that the collected data is relevant.
Recently, it’s desired on the market to be an S class team, since this approach leads to efficient delivery. Therefore Operations is the key. You might have already heard about BusinessOps, DesignOps, DevOps and Design Systems.
These topics are in demand right now. The market showed that increasing the number of employees, does not necessarily yield more results. So the challenge now is not only going for the “right” solutions but also to deliver fast.
Follow me and add me on Facebook if you want to know more about the DesignOps.
Bonus
To set up a common process that helps your team to be more goal-oriented, engage people and make sure that everyone understands how the process works. For those purposes, I’ve created a poster that you can download and print! Please comment or share with colleagues if you found this article helpful.
Please share the photos with hashtag #TripleLoopProductLifecycle! I’m very excited to know if my work helps and motivates people around!
Challenge
It’s not enough just to absorb the information, start adopting in your work what you have learned! I would like to help other people and that’s why I started the new challenge. More information below!
Try to implement Triple Loop Product Lifecycle approach in your teams and write back if you have any challenges. Let’s share the practices and cases here, so we can learn together!
Your feedback is really valuable and I would like to know the reasons if these practices are not working in your environment. Just add a comment here or write me directly on Facebook ✌️
