Enhance your Process, Advance your Product
The UXDX Model
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.
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
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
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.
Find out more
We are currently drafting the full details of the model, including the necessary pre-planning steps for Outcome-Driven development, the strategies for development based on your product purpose and the detailed steps on how to manage each step of the process. We are reaching out to product delivery professionals for their input on the model and will incorporate this feedback into the final documentation.