Introduction
In the previous three parts of my article (Why do we need a ‘Three Track’ Lean-Agile Product Development?, ‘Three Track’ Lean-Agile Development: Part 2 – Opportunity Space , ‘Three Track Lean-Agile Development: Part 3 – Solution Space‘), I had introduced the concept that a 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.
Three Tracks of Practices
I then proposed that product creation process can be improved by using 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. This is also referred to as Product Definition. 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. The third is Lean Deployment where the product gets to the end users and its usage gets monitored and measured to first validate the original assumptions of the need and to make improvements in the future.
Three Activity Spaces
Then I linked the tracks to Activity Spaces where certain activities get done with respect to the product. These are guided by a set of key questions and driven by practices related to the Product.
I elaborated on the Opportunity space and why I did not use the term Problem space as has been commonly used. The term Problem is restrictive because teams have to not only think about solving customer problems, but also need to proactively look for customer gains, experience and delighters. So, it is more about teams being able to explore opportunities and possibilities to create value. The team focuses on product definition which defined the specific opportunities that can get converted into Product Features. This is usually owned by roles called Product Leader, Product Manager or Product Owner.
Then following this, I described in detail the Solution Activity Space. This is where the features in the product actually comes to life and useable by the users. The team and especially the Product manager or Owner keeps reflecting upon the question – are we building the right solution? Also how do we build the right solution?
In this article, I get on to the last activity space called the Deployment Space. This is where the Product gets into the hands of the user. I propose that the teams have to close the loop by becoming aware of the usage of the product, to be able to gather feedback and then act on the insights for making the product better.
Deployment Space
As the name suggests, this is where the product gets deployed for usage by the intended user personas. The users will be using the product in different environments depending upon their needs. These could range from Apps on Smartphones to Web Apps to Embedded devices.
The key questions that drive the activities in Deployment Space is Did we build the Right Solution? How can we make it better?
Why is this Important?
The activities in the spaces earlier described (Opportunity and Solution) were driven by Hypotheses and assumptions, about the need for a feature or functionality in a product. Whereas the Deployment space is where the moments of truths emerge on how the user can use the product and did it actually help to solve a problem or meet a need. Engineering teams in many cases tend to ignore this space as they focus on only building the solution and packing the product with new features based on their own assumptions. Or they focus only on fixing issues as bugs that get reported from the field.
Data Driven Decision Making
The key principle is to make product decisions based on data. This data has to be relevant to the product usage. There cannot be universal metrics that might be applicable to all products. However there needs to be clarity around what is the goal for collecting the data and how it will be used for making decisions. What insight does one want of the product usage? Is it about customer adoption of some features? Is it about ease of usage of the product from users?
Decision Metrics
The Metric that helps make decisions about the Product can come in 2 broad categories –
- Relative usage of Features – which features get used more than others? Is there a disproportionate usage of certain features? How is this linked to user personas?
- In the usage journey of the product, where do the users break often? Where do they abandon the journey – job could not be completed? Was it intentional or because of the difficulties in using the product?
Sensing – How do we get the Data?
In some products, gathering usage data can be designed into the product where usage metrics can be collected and insights can be drawn upon. In some embedded products, these could be bundled under the diagnostic information. This approach is called product instrumentation and has to be built-in during product design and not as an after-thought. The product team can use the customer journey as a reference to define the data points to be collected for later use.
In cases where instrumentation is not possible, then product teams might need to gather information through interviews or surveys of end users. This is time consuming and needs more effort and coordination. One could resort to some techniques like focus groups and even A/B testing approaches.
Decisions based on Insights
Product teams can take appropriate actions based on the insights, which can be one of the following:
- Make the features frequently used even better in terms of user experience and possible enhance the features – improved product definition around specific features and better User experience design
- Relatively less used features can be modified to make the user experience different or easier to use.
- Re-examine the Need Hypothesis for relatively less used features and modify the product definition to either re-define the feature and remove the same.
Conclusion
In this part of the article, I defined Deployment Space where the Product teams focus on the actual usage of the Product. This is the stage where data is intentionally gathered to make key decisions about the product. One approach is to use Product instrumentation to sense data from the deployment space and where it is not possible, approaches like customer interviews and focus groups can be employed. These insights then help product teams make decisions on refining the product definition with respect to some features or re-examining user experience design.
Thus, the idea of a Three-Track Agile Product Development approach, where Product teams must run the activities in parallel as opposed to in a sequence. As the Customer need discovery process is progressing, parts of the product that can deliver high value to users have to be built and deployed for usage. Data on the usage must be gathered and insights used to make decisions on the Product which could be to make improvements in existing features or add new ones.
To make this effective, there needs to be some product development process events that can facilitate the different competencies to come together often and align on the common goal of building a useful product for the customers.
Please share your thoughts with us on what you think about the Three-Tracks !
