At its core, organizations are demonstrating meaningful business agility when they are able to deliver value to the market in progressively smaller increments, minimizing the delay required to gather market and customer feedback. Almost all agile methods will include some technique to take a large loosely defined increment of work, break it up into smaller increments, and then delivery these increments independently of each other. During this post I'm going to go over three different ways to think about breaking down work in the smaller increments, each of these different approaches require thinking about value from a fundamentally different mindset.
The Minimum Viable Product: Getting to Value Faster
The Minimum Viable Product (or MVP for short) is a term that is gaining increasing traction within the enterprise over the last couple of years. The term has become somewhat loaded to mean different things to different people. Some define an MVP as a product increment defined in such a way as to get value into the customer’s hands as soon as possible, measure their response, and use that data to inform the choice of what to work on next.
A more formal definition of an MVP would be the smallest increment of effort that can enable us to learn whether we have a viable product in the context of a highly uncertain market. Using this thinking teams would deploy different strategies to introduce features to customers in such a way as to be able to test how those customers would react to the speeches. In many cases the early MVPs of a team would contain little to almost no software, favouring interviews, mock-ups, and manual prototypes. Even as the product start to mature in terms of feature completeness, the focus stays on continually learning while delivering value.
How we approach thin slicing our work into smaller increments of value can depend on what the term Minimum Viable Product means to us. In this post I'll give a brief overview of these different approaches and some of the advantages they offer. These approaches include:
- Breaking work down into discrete deliverables, milestones, and activities.
- Decomposing an end product in the smaller increments of value
- Focusing work on identifying key assumptions about value, and decomposing work to maximize validated learning
Traditional Work Decomposition
It's fairly common for teams getting started with agile to continue to think about their work from a more traditional mindset. Using this thinking, the team takes larger work items, such as projects, stakeholder requests, customer demand, etc., and decompose the work into smaller deliverables, interim milestones, and explicit tasks. The team will then go about managing their work using a mixture of agile practices such as visual management, sprint planning, standups, etc to improve collaboration within the team and with stakeholders. This can be a fair starting point for some teams, especially non-technology teams, as it allows them to get comfortable with some of the mechanics of agile while minimizing disruption.
Teams working in this manner tend to track their work as a set of deliverable/milestones or activities that go through a very simple task management workflow (ie: Plan, In Progress, Next). The approach has the advantage of being intuitive, as it tends to be similar to how people often currently think about their work. Using this breakdown technique with visual management provides focus on getting things done, and this can help prevent the team from being overloaded. It's easy to understand who's doing what, and the team can plan future work based on a more informed throughput and understanding of the team's capacity to deliver.However, the approach has very real disadvantages, the biggest one being is that while the teams are introduced to some agile techniques, they are still thinking about value from a traditional perspective. I have seen a number of teams moving along the agile journey stop here, as a result customer value doesn't get delivered more frequently, and true business feedback does not increase .The focus stays on deliverables and tasks, which often does not lead to any real improvement from end to end perspective.
A Value Centric Approach to Decomposing Work
An alternative approach involves taking a more value centric mindset. This includes understanding the type of value that is being delivered, and mapping the workflow of states and steps required to deliver each type of value. Different types of demand can be catalogued into distinct services. The workflow required for each service can then be defined, including the common activities and deliverables that are created for each state in the workflow.
This workflow can then be visualized and made operational for each value type , typically through a Kanban system. Use techniques such as work in process limits to maximize flow and feedback. As the team discovers new things about their work, or identifies improvements around how to do the work, they can make changes to their workflow and process to reflect their latest learnings.
The advantages of taking this approach to decomposing work is that the emphasis on value and the flow of value puts focus on getting to market faster. It's easier to see bottlenecks that get in the way of value delivery, and the flow of value can be improved over time based on recognizable patterns and repeatable workflow. Team members can work with each other and other teams to define clear knowledge worker agreements in terms of how to complete work and transition work from one team to the other.That being said there are some disadvantages that some teams encounter when starting with this type of approach. The most obvious one being that it is somewhat counterintuitive and requires a shift in mindset. It is not always easy for some to shift from a deliverable/task approach to a more value increments/flow based approach. It can be harder to see exactly what tasks are in progress, which can cause further concern for some. On top of this, frequently the teams visual management will need to be re-factored a number of times before it is effectively showing the right kind of flow that works for them. Finally, being able to effectively take advantage of the flow-based approach often requires that teams also take the time to understand how to thin slice their work, reducing the scope and complexity of each individual increment of value. When work items are too big, it can often be hard to see where flow is happening and where it's being stalled.
MVP Splitting Patterns: Delivering Increments of Value that are both Minimal and Viable
Reducing the scope of value increments enables the feedback and agility gained through managing the flow of value. The idea here is to remove functions and features until we have the a much smaller incremental value. We still want this increment of work to be valuable in the eyes of real customers, hence we are always balancing the concept of minimum with the concept of being viable.When thinking about reducing the scope of what you are trying to deliver to market, consider one or more of the following MVP splitting patterns:
Users:Can the MVP be targeted at users that are grouped by role and/or context?Eg. Tablet app for High End Customers
Workflow:Does the MVP describe a series of actions or variations in workflow that can be implemented independently? Can you implement a simple workflow before a complex variant?Eg. New Product that has manual error management
Interfaces:Does the user interact with the MVP in different ways?Eg. New product where customers can get service online
Business Rule Variations:What constraints need to be implemented within the capability?Eg. New account product with limited set of fraud checks
Data Variations:Can you process one kind of data first and other kinds later?Eg. New offer with monitoring only on redemption rate
Environment:Where will this capability be used? What technologies and physical means will be used to deliver the capability?Eg. Marketing campaign focused on Latin America only
Subjective Quality:Does the MVP’s complexity depend on meeting non-functional requirements (performance, amount of visual polish, ease of use)?Eg. New Mobile pilot for 100 early adopters
Uncertainty:When all else fails, break out a spike (extremely rough implementation that is thrown away after getting desired learning)
Determining your MVPs for for larger, more complex initiatives
For larger initiatives, it can become easy to get lost in all the different options, features, customers, etc. that could go in to scoping your first (or subsequent) MVPs that you would like to deliver. Story mapping is an excellent tool that can be used to describe the various features that could be used in your solution in such a way that facilitates scoping of your effort into one or more MVPs. When a story map is used for this purposes you typically aren't laying out a set of fine-grained stories but rather trying to map map out what epics or features could fit into a particular MVP.With a story map typically start out by laying out the personas/actors that will engage with your solution, and then map out the major epics/features, as well as supporting activities/actions required to realize each feature. The map can be read from top to bottom showing a hierarchical decomposition, up until the Action level of the map is reached. When laying out the Actions, (blue cards on the diagram below) the map is typically read from left and right to show sequential activity, or top to bottom to show optional activity.
What's great about a story map is that you can start to shuffle the various Actions vertically based on priority,with items shuffled to the top being the highest priority. You can then draw vertical slices across the map to indicate which of these activities belong to a specific MVP.
The Learning MVP, Maximizing Feedback to Tackle Uncertainty
Increasingly, organizations are trying to deliver value under conditions of uncertainty. In this environment, outpacing the competition means accelerating the learning required to understanding whether particular product or feature is going to gain enough market traction to be worth the organization's time. This involves delivering value as a set of experiments, using an approach called validated learning. Using this approach work is defined as an increment of learning, and the goal is to minimize the leadtime between up hypothesis of whether a certain activity generate customer value and validation of that hypothesis.
When using visual management, teams will often map the flow of learning on top of the flow delivering value and not consider a particular piece of work to be complete until market feedback has been gathered, analyzed and incorporated into the next set of activities. When thinking about delivering value using this mindset, an MVP is best thought of as an increment of learning that (can) also deliver lasting value.
MVP Validation Patterns: Accelerating Learning about Critical Assumptions Required To Validate Value in the Face Of Uncertainty
Validating Learning often involve early stage validation techniques focused on understanding whether you have a problem worth solving, and an identifiable customer base that would pay for your solution. Low fidelity, qualitative, in-person techniques are used to narrow down the number of options that teams may want to pursue. As the product starts gaining early traction, teams often move to more quantifiable research techniques, using a number of manual and automated approaches. A number of MVP validation patterns are described below, each one describing a different way to validate specific assumptions behind a product or feature.
Problem Exploration:Validate that you have a problem worth solving through problem exploration interviews
Mafia Offer:Validate your solution by making an offer so compelling that it is an offer “you can’t refuse”
Smoke Test: those terribleValidate your solution has the right messaging to attract a sizable market by tracking clicks on a “dummy” landing page
Preorder Nonexistent Product:Receive purchases for a product that doesn’t yet existEg. Every Kickstarter product
Concierge:Validate you have the right solution through a hands-on, manual implementation
Piecemeal:Mock up your product using only currently available tools and technologies, manually integrating them
Wizard of Oz:Create a polished customer-facing product, but with no back-end (all done manually)
A/B Testing:Evaluate solution options by releasing them to a subset of your users and validating the impact on customer related metricsOther methods of research and validation include:•Ethnographic research & contextual inquiry•Competitor usability tests•Anonymous user testing•Guerrilla prototype testing•Paper prototyping•Surveys•Feature stubs•Cohort, funnel, and segmentation analyticsLike the thin scoping approach, validated learning experiments can also be used to thin slice your story map making it clear how you are traversing the map in order to both mitigate risk and deliver value.
