A picture say a thousand words. The design of the UXDX model has been chosen to highlight the importance of working as one autonomous team. There should be no barriers between design and development as the understanding of the customers needs to be shared by everyone. In addition it provides a visual reminder to teams of the importance of Outcome-Driven development which can protect against the natural tendency to people to revert to Feature-Driven development.
It Takes a Team
To Build a Product
The UXDX Model
How do you increase the odds of success?
Instill a desire for better
Demonstrate how people's jobs will improve in order to get them to embrace change.
Align on a shared vision
Align on clear customer, business and process goals. Then enable teams to deliver.
Enable quality execution
Upskill in the new ways of working and remove any hesitations to change.
33% of product features negatively impact the product
Are you validating your new features before development?
Low performing teams spend 22% more time on unnecessary rework
Are you merging and testing regularly enough?
DevOps teams have a 440x faster lead time for changes
How quickly can you get code to Production?
Building the wrong features incurs the following four costs:
- The cost of ongoing maintenance
- The opportunity cost of not building the right feature
- The potential cost of the negative effect that the feature has on the product
- The cost of development
UX - DX Handovers
Outcome Driven Development
The UXDX model promotes Outcome-Driven development instead of traditional Feature-Driven development. By expanding the DevOps loop to include the Research, Hypothesis and Design stages it forces teams to validate their assumptions about new features before building them.
Outcome-Driven development relies on the product team defining the outcomes that they expect to achieve with each feature. These outcomes are documented as hypotheses as follows:
- We believe that (feature)
- Will result in (outcome - aligned to product purpose)
- And we will prove it based on (measurable metric)
- Within (time period)
The hypothesis structure allows teams to remove their bias towards features and verify whether their assumptions about a feature hold true. The design step, while not mandatory for every feature, encourages teams to validate their assumptions without writing any code. If, after the Research or Design steps, the hypothesis doesn't hold true it forces the team to update their understanding of their customers. These course-corrections accelerate the product teams learning and enables them to build better products, faster.
Teams who haven't implemented DevOps spend 22% more time on unnecessary rework
State of DevOps, 2016
33% of features produce a statistically significant negative effect on the product
Ronny Kohavi, General Manager Experimentation, Microsoft