Introduction
In my previous two articles Why do we need a ‘Three Track’ Lean-Agile Product Development?, and ‘Three Track’ Lean-Agile Development: Part 2 – Opportunity Space , 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.
Three Tracks of Activities
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. 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.
Activity Spaces mapped to Tracks
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.
Opportunity Space in brief
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.
I touched upon some useful techniques and practices like Benefit Hypothesis which captures the key benefits to the customer persona and also explicit about assumptions and also alignment with the business objectives. Some other techniques like Impact Mapping, Lean-Value Tree were listed. The team focuses on user or customer persona and identifies the potential need. This need has to be satisfied through a product feature or service. It can also be a problem the customer intends to solve. This can broadly be termed as product definition. This is usually owned by roles called Product Leader, Product Manager or Product Owner.
In this article, I will describe in detail the Solution Activity Space.
Solution Space
The second activity space is called the Solution Space. Within the Opportunity space several opportunities that have been identified have to be realized and brought to life. This is done through converting them to a specific solution in the form of a feature or functionality. The starting point is the product definition from the Opportunity space. Thus, an opportunity gets converted into value. The solution gets designed, developed and delivered to end customers or proxy customers. The activities within the Solution space are driven by the following questions
Is the Solution worth building?
The team gets down to architecting a solution and building it. In cases where the hypothesis has been defined at a higher level, then the question of how quickly and economically a potential solution can validate the customer need becomes important. That is when the teams could take a prototyping approach where full-fledged features are not yet necessary. Through prototypes or even proofs-of-concept, teams can test the assumptions and determine whether the solution is really of value to the customer. Is the solution worth building?
How can we build the Right Solution?
In cases where the product is already in use and the teams are trying to add new features to enhance the product, then the teams can build the same in smaller increments and in iterations so that these features can reach the customers or end users early and often. This way the teams get a chance to find their path towards the right solution and can make coarse corrections along the way. This is opposed to the traditional way of building huge sets of features into the product and realize only late in the life-cycle that some or many of them were not acceptable to customers. This approach can be broadly termed as Lean-Agile approach.
Let me outline some key characteristics of such an approach to building solutions.
Agile Teams
First and foremost, it is ideal to have the solution team as a cross-functional team with all the skills needed to develop that part of the solution. This team is usually fixed in size and is long standing so that they develop the team bonding, know each other’s capabilities and can operate as a winning team. Such teams are generally referred to as Agile teams.
Rhythm & Cadence
Secondly, they operate in a rhythm and develop the solution in a fixed duration and cadence called sprints. This cadence can vary from a week to longer according to the nature of the solution and the domain they are operating in.
Release Early & Often
The third key characteristic is that they continuously integrate the functionality into the main product and ensure that a stable version of the product can be released at any point in time. At the end of every sprint, the agile team strives to release a software (either a feature or functionality) which can be directly linked to customer value. Thereby a customer can see value getting delivered early and often. This is popularly called ‘develop in cadence and release on demand’. In this way, the risk of the team spending time and money in building a large up-front solution without knowing the customer acceptance is mitigated. At the same time the customer or the product manager in charge is not forced to think about the whole solution all at one time at the beginning of the product development.
Evolving Architecture and Design
The team defines key aspects of user experience from the customer or user persona perspective and many teams employ specialists in this area. Some user personas get prioritized over others in terms of development. Likewise, the architecture and design of the product to suit the features and functionality get done. Rarely they start with the full understanding of the final architecture. The iterative development means that the architecture evolves over a period of time. The team has to consciously build in flexibility and adaptability keeping in mind the product roadmap. The key idea again is that there is no big upfront fixed design at the beginning of the product development.
Feature Roadmap
The team also works with the Product manager to define a feature roadmap which lays out the chronology of the features roll-out which is again linked to user personas. Where there is clarity on features get planned earlier and the later features get discovered as elaborated in the Opportunity Space.
Feature Prioritization
Just as opportunities got prioritized in the opportunity space, the product features that are part of the solution get prioritized for development. This is critical to manage because of the fixed size of teams as opposed to elastic nature of traditional teams. This again can be guided through the benefit hypothesis and techniques like Weighted Shortest Job First (WSJF). The core idea being the least amount of Effort that the team has to put in to get Maximum benefit. The equation reads as WSJF = (Cost of Delay / Size of the Job). The Cost of Delay quantifies the benefit as determined by a combination of Time Criticality, Customer Value and Opportunity Enablement. The size of the job quantifies the effort needed to develop and deliver the feature. This is one approach but the teams can use many other techniques.
Discovery & Develop Tracks – Touch points
There are intentional touch points created through events where the key people from Discovery track and the Develop track get involved with an intention of constantly asking what value has been realized through the product features and design. Two key touch points between these two tracks are Sprint planning and Sprint Demo events. Demo is where the key product stakeholders are available to review customer value delivered by the team. Where possible, even the end customers will receive these releases and value gets delivered and realized. These events are powerful mechanisms to align the two activity spaces.
Summary
In this part of the article, I defined Solution space where the Product teams develop and deliver features as part of a product which is of customer value. There is huge merit in teams following a Lean Agile methodology in this solution space. I outlined some essential hallmarks of an Agile team and the way they approach activities within the Solution space.
They are first of all cross-functional in membership so that they can develop end to end customer value. This customer value is delivered as early and often so that the team knows they are in the right direction and has a chance to apply course corrections before too much investments and efforts. A fixed team size is usually maintained which creates a solid team environment and as a team they can deliver.
Opportunities that flow into the Solution Space gets defined as features. High maturity Agile teams find efficient ways of regulating and prioritizing them so that the teams can work on ideas that can deliver the best value to both customer and business. They can use techniques like Weighted Shortest Job First (WSJF) or any other.
Another thing that teams have to manage well in the solution space is the ability to evolve their product design and architecture to accommodate features as they grow. There is no big-bang approach to design at the launch of new development. The teams have to build-in robustness in such a design to absorb new features on a continuous basis.
In the next article in the series, I deep-dive into the 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.
