Introduction
In the part-1 of my article (Why do we need a ‘Three Track’ Lean-Agile Product Development?), I had introduced the idea of how the product creation process is all about transformation of Ideas into Value. Success can come only after value gets created and realized through the product. The product success can be measured in terms of outcomes. These outcomes can be along one or more of these dimensions: customer, business or product. The product creation process needs to be improved to maximize success.
I then proposed that an improved product creation process needs three tracks of Practices to effectively transform ideas to value. These practices are guided with a set of questions and incorporate corresponding activities.
The first track is Lean-Discovery and is all about discovering the ‘what’ aspect of the product. It also is about ‘who’ to build it for, emphasizing customer and user centricity. The product contour gets defined in this track. The second is Lean-Agile development where the product actually gets built and comes to life. The user experience, product architecture and technical aspects of the product get defined. Many teams adopt an iterative and incremental approach to development. The third is Lean-Analytics Deployment where the product gets into the hands of end users. The usage gets monitored and measured to first validate the original assumptions of the need and second, to make improvements in the future.
As mentioned earlier, conceptually each of the tracks can be mapped to an Activity Space, which encapsulates a set of key activities the teams perform. As I take a look at each activity space, we look at the specialty of the space and what are the important objectives and activities for the product teams in each space?
Activity Spaces
An activity space is a cognitive space where the teams perform essential activities. These are guided by a set of key questions and driven by practices related to the product.
There are 3 activity spaces mapped to the three tracks:
Opportunity Space: It is common to see usage of the term Problem space to define the practices proposed here. Why do I give it this name rather than Problem space? The term Problem is restrictive because teams have to not think only about solving customer problems. In addition, they also need to proactively look for customer gains, experience and delighters. So it is all about opportunities and possibilities that the teams can explore to create value.
Solution space is where some of the opportunities can converted to a specific solution in the form of a feature or functionality. This is where opportunity gets converted into value.
Deployment space or Usage space is how the product or service actually gets deployed for end customer use. This is the moment of truth where value actually gets realized.
In the following section, I dwell deeper into the first space where the product gets defined.
Opportunity Space
Over the course of product development, it is normal for many different ideas that keep landing on the team and each of these can turn out to be opportunities to realize one or more benefits. Some ideas may help in satisfying the customers’ needs, or solve a customer problem, or create a delightful experience. In other cases, ideas could also be in the form of just improving the current way of doing things. Even though, ideas are important, not all opportunities can have an equal impact on outcome.
“Opportunities are Unlimited but Resources are Limited”
The teams have to adopt some systematic prioritization approach to pick the right opportunities to take the ideas forward. There are several techniques, but one simple yet powerful one is stating the Hypothesis.
Benefit Hypotheses
A Good starting point is a Benefit Hypothesis. The initial version of the hypothesis can be simple and capture the most essential aspects of the idea. This gets elaborated over a period of time. Some of the must-have sections in the initial hypothesis is the target customer persona, description of their current context, key assumptions and how the idea can deliver tangible benefits to this persona (customer value).
Writing down the hypotheses and a disciplined approach to validating the likely benefits to the persona & assumptions surfaces some critical issues before the team commits resources in full-fledged development.
Customer Persona Benefit
Is the Need worth Satisfying? Is the Problem worth solving?
The team thereby discovers the answers to two important questions:
As far as possible, the set of validation activities happen within the opportunity space. However, the entire team can contribute to these activities depending upon the nature of the idea and validation approach. There are several ways this can be done for example, customer interviews, proofs of concept, running experiments or rapid prototypes. The decision of what to build as a product or within an existing product is then made based on the results of the above activities.
The above set of validation activities are directed at customer persona benefits. However, there is another set of validation activities which are related to the operating business context of the teams. The business outcomes cannot be ignored to pursue any new opportunity.
Business Benefit
Is it aligned to our business objective?
This validation is done usually through some techniques like Impact mapping or Opportunity Solution Tree or Lean Value Tree. The idea here is to be able to link the idea and the value it could create for the business. A high-level business goal can be mapped to a set of initiatives or capabilities and this specific idea within a larger set that can contribute to these initiatives thereby realizing business value post realization.
An active participation of the product team members in the prioritization, definition and validation activities in the Opportunity Space leads to better alignment between themselves and business stakeholders.
Importance of Prioritization
Product teams will always be confronted with a large number and variety of ideas. They should find an efficient way of dealing with and prioritizing them to push further to work upon. They can use tools like benefit hypotheses, impact mapping, Lean value tree or opportunity solution tree, which forces them to summarize the benefits not only from a customer perspective but also how it can be linked to business outcomes.
The teams then have to find most economic ways to validate the benefit hypotheses, using the least investment in resources. Then prioritize the opportunities to take forward for development. For opportunities that are validated and prioritized, they need to give clarity on implementation about what to build. This is done by elaborating usage scenarios from the persona perspectives, how high-level ideas can be transformed to customer value.
Many Product teams get into the habit of doing a set of activities in the opportunity space in a big-bang approach once before the start and launch into new development. I propose that the Discovery process through new Ideas, big or small should be happening continuously through a set of guided activities within the Opportunity Space. These should then flow in a prioritized and regulated manner to the Solution Space so that the teams can work on ideas that can deliver the best value to both customer and business.
Conclusion
In this article, I dwelled on the Opportunity space and how the team can adopt practices to continuously explore opportunities to create value. It included prioritization, validation and definition of the opportunities to create value.
In the next article, I deep-dive into the Solution Space and Deployment Space. Finally, I address how to ensure that these three tracks can have adequate bridges in between and there can be friction-less flow of information between these spaces on a continuous basis. By running focused activities within each space, and sufficient touch points between the three tracks, the likelihood of product success becomes high, meaning intended benefits to customers and business alike.
Let me know your comments and thoughts.
