ART Osetrov
USA, Florida, Fort Lauderdale
DESIGN THINKING & PRODUCT LIFE CYCLE
Art Osetrov
After 14 years of experience working in studios, outsource, product, and even trying to build my own startups, I use with a simple classification of project phases and designed a 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.
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.
The Purpose.
The goal of 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.
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.
Product Lifecycle.
On the top 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 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.
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.
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, Design Sprints and Double Diamonds technique. The outcome would be a high-level roadmap, project brief, resource plan and other artefacts.
Discovery.
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.
Learn.
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.
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.
Prototype.
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.
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.
Experiment.
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.
We will come back to this phase when there are new requirements and bugs from the Experiment and Demonstrate phases.
Build.
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.
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.
Demonstrate.
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.
Improve.
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:
1. Return to the Learn phase and make a more significant improvement.
2. Continue improving the functionality on the Improve phase.
3. 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.
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:
1. Return to the Learn phase and make a more significant improvement.
2. Continue improving the functionality on the Improve phase.
3. 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.
Measure.
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.
The golden rule — fail fast and pivot.
Finalization.
