Agile Product Life Cycle-Practices & Tools
In the previous article, I discussed in detail about Agile Product Life Cycle and its different phases and outcomes that allow an organization to function end to end in an agile product life cycle. This is in continuation to the previous article in which I’ll be discussing the tools and practices corresponding to each of the phases that help teams drive end to end agile product life cycle. I have consolidated some widely used practices in this article across all four phases - Discover, Develop, Deployment, and Maintenance - of the agile product life cycle.
These tools and practices are standalone sufficient and they can be picked as what fits best for the team and organization. It is a long term investment of any team or org to pick a process/practice/tool, so knowing the pros and cons and related tactics and tricks become important before choosing one of these practices. In image 1 I have listed some practices in sticky notes below each of the phases to drive the Agile product life cycle.
Nowadays, many companies and startups are champions in adopting and acquiring agile methodologies in the development phase. Thus I would cover more on D&F, backlog as a partial outcome of the D&F process, and maintenance stage where much handholding is required.
Discovery (D)
D&F is an important part of the framework and kind of an entry point for the product life cycle to address changing ecosystems and market dynamics. During discovery, user interview is a well-known practice to understand the customer requirement and pain-point, however other alternatives help understand the customer problem more effectively and efficiently. One such approach is the customer journey map which is widely used by the design and UX team to understand the pain and delight of the customers at different touchpoints of the product. The trick is to revisit this customer journey map constantly and make an important artefact for your discovery process. Another very effective method is the Opportunity problem tree by Teresa Torres. In this approach, all pains and gains of customers can become potential opportunities to improve the product. The best part is that the Opportunity-sol tree is self-sufficient to cover both Discovery and Framing processes. Solutions underlying the opportunities are tagged with experiments that can be further validated. It will be amazing to see how opportunity and solution tree grows as the product expands. Read more about the opportunity sol tree here.
Pro Tactics: Make data the backbone of any practice you follow during the Discovery. For example, pain points in the customer journey are backed by data insights. Likewise, your opportunity vis-a-vis problem should be backed with the data as well in the opportunity-sol-tree else it could be the waste of the overall discovery effort. Collecting feedback for B2B products directly from end-user is little cumbersome, so rather than simply relying on the sales/marketing inputs it is much better to analyze customer journey map and user story mapping to outline the desired feature and later validate with the buyers if possible.
Framing (F)
It depends on the maturity of the product. I have mentioned various practices and techniques in image 1 used during the framing concerning the focus area of a startup/enterprise at different stages of the product. One can pick any one practice which is suitable as per their focus area & product stage. The outcome of the framing is the top solution(s) of the discovered problems which also includes validating the riskiest assumptions/solutions/ideas to validate before moving into the development stage. The listed practices work well alone or in combination with others. Framing is not just creating a solution post-discovery of the problem, but it also requires to test before giving time/effort/money in building it. Image 2 shows some of the experimental techniques for validating the framing outcomes.
Pro tactics: Conducting quarterly Design sprint/Thinking workshops with key stakeholders, and product teams those cross-cut each other work well for mature product companies. That said it doesn’t mean it can’t be done for early-stage startups. However, the only issue is that these quarterly D& F workshops are formal and sometimes a bit slow-paced as too many stakeholders, their availability and concerns are heard and discussed whereas startups should connect more often to discover, frame and validate the ideas before pushing them as a part of final product development.
Pro tips on running experiments: All solutions shouldn’t go for validation especially for those certainties of success rate is higher based on experience and historical data. Running experience for de-risking the solution is an important activity for the agile product life cycle, but it is surely not for small features, changes or UI experience which potentially don’t keep the product at stake concerning risk, effort, time and money.
Product backlog :
The agile product life cycle’s backbone is to respond to the changes quickly. Hence, product backlog plays an important role in product development so they must be prioritized. The enlisted techniques (Image 1), for example, 2x2 matrix supports moving the needle toward adopting the agile product life cycle by quickly prioritising the backlogs. Product backlogs are ideally the output of D&F and before moving the product backlogs into sprint backlogs, a product manager must prioritize the top backlogs based on the business value and effort before refining them.
Pro Tactics: Out of all the practices I mentioned in image 1, 2x2 matrix value vs effort works well for backlog prioritization. Also, the Kano framework is good but it doesn’t take into account effort vs value. MOSCOW technique is good in setting launch criteria and acts as a means of communicating with the team. Last but not the least100$ test is good for quick prioritization if external stakeholders are available on the spot, but like Kano it misses the important aspect of value vs effort. I would still chime in to use a 2x2 matrix which works well due to its agility, ease and success.
Maintenance
This stage is an important phase of the agile product life cycle. It covers the product maturity, growth and decline aspects of the product life cycle (refer fig1 https://surbhibsooni.medium.com/agile-product-life-cycle-55ff1396701b). Having said that the data insights are the backbones of this phase. I have jotted down some common metrics and processes that help in gathering data corresponding to the market and customer in this phase. The agile product life cycle takes a full circle since the data insights become the inputs to the D&F process and continue helping in discovering the problem, opportunity and solution. I have already called out in the beginning that discovery should be backed by data, and the data insights generally flow from the maintenance phase to D&F.
In this way, all 4 phases — discovery, development, deployment and maintenance - complete a cycle while using the practices discussed above. The loop continues and drives the end to end agile product life cycle.
