Unfortunately I will not be attending the conference in Aarhus this year but look forward to meeting everyone at the 2013 events.
One of the foremost challenges we constantly encounter on development projects is the focus of teams and product managers on managing cost rather than value. In its most basic form this manifests itself daily in user stories where teams tend to concentrate on prioritisation, scope management and throughput in terms of the size of the work. The usual question I hear once a story is described is ‘What size it is?’, in short – how much is that going to cost?
Fundamentally these teams see software development as a ‘cost’ that must be managed. They forget that software development is a value creation process and hence the goal of our approach should be focused around creating and realising value, especially from the perspective of our users.
As Warren Buffet stated, ‘Price is what you pay. Value is what you get’. What is needed is a change in mindset toward value creation, or at least exposing and making the idea of value visible to these teams and the wider organisation.
Unlike waterfall approaches where all value is delivered at the very end of a long linear process of project analysis, development, testing and deployment, agile development emphasises the realisation of value much earlier and more often.
Using techniques such as iterative development – always having working software, continuous design and delivery – the value created can be more frequently realised during the development process itself. However, challenges still exist in how to prioritise value for the user.
Teams continuously put energy into prioritisation and focus on throughput to achieve efficiency, but lose sight of effectiveness. No matter how efficiently we work, if we are continually building software that is of no value to our end users we are essentially creating waste, regardless of the pace we achieve.
Teams and product managers need to take a holistic view of the entire product to support a user-centric approach to understanding, capturing and delivering value.
Teams and product managers tend to favour grooming the product backlog through prioritisation and story sequencing to create a production line of user stories for the development team to consume. This approach appeals to the rational human mindset that development is a linear process. We create stories for the team to pick up one at a time, as prioritised in sequence. But this approach is flawed in the context of value creation. Value is not linear, and thus we need to take a systemic and holistic approach to application development when looking to create value for our users.
To visualise the concept of value creation as systemic, holistic and in terms of the user, we have developed a framework we call the Systemico Model. The name is designed to reinforce the idea that value creation is not an isloated linear process. The model aims to make the requirements of the product visible to teams and product managers in terms of how it addresses user goals and engagement levels. We have found the Systemico Model to be especially useful when working on new products and domains that need to be customer and/or user-centric, especially when there is little or unknown validated learning in the product space.
Traditional analysis and design methods are often application-centric, defining the product in terms of what it will do, followed by how the user will interact with it. Instead, user-centric methods focus on why we should have a piece of functionality and how we can implement it.
By defining and prioritising the requirements of the product in terms of the users’ goals, we ensure that only functionality relevant to the user is created and visible to the team and product manager. Examples of user goals for a website may be to find content, add content, or purchase.
A challenge when assigning user stories to user goals is that there is not always a direct mapping of individual stories to goals – in some instances user stories can support multiple user goals. In this situation, we advise the team to agree on the goal that it believes to be the most appropriate based on the project landscape and customer insights they currently have. Should that view change in the future, the story can be moved to the most relevant user goal to reflect the latest available information.
Along with user goals we consider the perspective of user engagement to analyse the level of interaction between the user and the product. We associate different observed behaviours with different degrees of user engagement.
Core: Functionality that satisfies the users’ basic needs. These are the minimal expected features that users believe are standard on all products in a specific context e.g. user login/logout
Use: Enhanced functionality that increases usability of the product. Without these features the product has minimal appeal to the user e.g. displaying content on a page, user editing/manipulation features
Engage: Functionality that draws the user to interact further with the product. These features draw the user to return the product in the future e.g. contribute to a site, provide reviews/ratings
Explore: Functionality that entices the user to go beyond simple interactions. These features build the strength of connection between the user and the product e.g. personalised services or recognition/rewards
The varying degrees of user engagement are not designed to indicate an increasing level of value from ‘Core’ to ‘Explore’. Instead they are designed to support the focus of the product proposition to resonate with the users’ interaction with the product, thus offering value for the system.
A challenge when defining the degrees of user engagement is that they are subjective. This requires conversation between the team and product manager to create a shared understanding and definition of each category.
By using the two perspectives of user goals and user engagement we are able to attribute extra value dimensions to user stories, aside from the requirement and size or cost of the work. This provides a deeper insight into the value a story will deliver, and will support the team and product manager to understand where to prioritise and invest effort.
We ask the product manager to prioritise what they believe to be the key user goals of the system and assign each story to a goal. Then we challenge the product manager to define the level of engagement each story is targeted at, in order to provide a second dimension to the user story.
The end result is a value map of all user stories defined with extra dimensions beyond cost that relate specifically to the user of the product.
Another feature of the Systemico Model is its function as a visual tool to represent how and where effort has been invested in the product.
All user stories are mapped on a wall against the framework to visualise the user goal and engagement they are targeted at. We use blue cards to represent user stories that have not been picked up, replacing them with a yellow card when they enter our story wall.
By providing more dimensions to user stories and mapping them to the framework, the team are provided with a visual, holistic, systemic and engaging view of the entire product which is centered on the user.
This serves as a visual reminder to the team of what areas have been worked on to date. It also supports decisions on how much effort should be invested in each user goal/engagement component to satisfy a user requirement before focusing on other areas of the product.
The Systemico Model also reinforces the concept of creating just enough functionality to showcase a value proposition to the user for validation before investing further in the feature.
We challenge our product managers to release the product as soon as viable combinations of user goals and user engagement components are completed by the team. In many instances, especially when working on new product development, completing the “Core” engagement component of a user goal should be sufficient to release the product to gain validated learning and insights from the market place.
A danger with traditional approaches to software development is that teams and product managers spend too much time and effort drilling into features that support individual user goals before presenting it to users for feedback and validation e.g. trying to make it perfect before release. This can lead to large amounts of waste if users later deem the feature undesirable or of low value.
By focusing on completing thin user goal/engagement combinations of the product and then releasing immediately, rapid feedback can be collected from user themselves on which features are appealing or more desirable. Once we obtain this feedback we can clarify and validate our user goals, and build greater depth to features that further enhance the users’ engagement in that component.
The concept is referred to as ‘do less [of what doesn’t matter], deliver more [of what does]’. By focusing on what is truly important to our users we eliminate the creation of value propositions that are undesired and not useful to our customers.
The key concepts to remember are;
The Systemico Model and user goal/engagement components are designed to support the team and product manager along the value creation process by providing a visual framework that allows further dimensions to be added to value propositions. The goal is to enable the team to leverage their development process to maximise value realisation, while minimising waste and over-engineered solutions that do not fit user needs.