UXDX Blog
The UXDX Blog has its own subscriptions, separate from our newsletters.
The Product Model #252 - Why We Work The Way We Work
Our organsiational structures and management practices exist because they were the most successful way of working in the 20th Century. Unfortunately they are no longer the best fit given the expectations of the world today.
Read edition ↗
Why We Work the Way We Work: The Industrial Legacy of Modern Work
At the turn of the 20th century, work was primarily performed by craftspeople who maintained complete control over their production processes. Each craftsperson would build entire products from start to finish, using methods passed down through generations. This changed dramatica
Read edition ↗The Product Model #251 - A Product Is Not The Sum Of Its Parts
Ford was the poster-child for the benefits of the assembly line way of working. But the approach of breaking down every process into its constituent parts, then optimising each one separately is now backfiring.
Read edition ↗
A Product is not the Sum of its Parts
The assembly line was a simple but effective idea: complex products could be broken down into their smallest components, each optimised independently for maximum efficiency. This approach was based on the work of Frederick Taylor's book, The Principles of Scientific Management. T
Read edition ↗The Product Model #250 - The Inefficiency Crisis In Software Development
When companies like Airbnb and Netflix measured the success rate of new features they found that only 8-10% achieved the expected benefits.
Read edition ↗
The Inefficiency Crisis in Software Development
In 2009, Ronny Kohavi, then a leading data scientist at Microsoft, analysed the effectiveness of product experiments across various teams. His findings were stark: 33% of features had no measurable impact, and another 33% actually made the product worse. That means two-thirds of
Read edition ↗The Product Model #249 - Increasing Development Efficiency
Before we can improve efficiency we need to first agree on our definition of efficiency. Many companies look at team utilisation (% of time allocated to capitalisable projects) and predictability metrics (on-time and on-budget). But research from the DevOps Research and Assessmen
Read edition ↗
Increasing Development Efficiency
The first step in improving efficiency is to agree what we mean by development efficiency because there are at least three, and possibly many more, ways that companies measure efficiency today.
Read edition ↗The Product Model #248 - Evolutionary Architectures
One of the big risks of empowering teams is that you lose the centralised control over the system architecture. Empowered teams require the ability to go from idea to satisfied customers without relying on external approvals like architecture reviews. So how do companies prevent
Read edition ↗
Evolutionary Architecture: Because Change is the Only Guarantee
Bjarte Bogsnes, former CFO of Statoil, talked about the beauty of a perfectly balanced budget. But the feeling would only last for a fleeting amount of time because inevitably real world changes would mess up the perfect balance in the budget. The same is true of software archite
Read edition ↗The Product Model #247 - Rethinking Software Estimation
Who loves estimating how long it will take to deliver some features? The reason we don't like it is because we never have enough information. We have high level requirements with so many uncertainties that we have to make a lot of assumptions. We then pad our estimates with conti
Read edition ↗
Rethinking Software Estimation: From Outputs to Outcomes
Estimation, or more accurately guesstimation, is a backbone of traditional project delivery. From executives seeking budget approval to development teams planning their sprints, we constantly make predictions about time, effort, and cost. It's easy to understand why - businesses
Read edition ↗The Product Model #246 - Every Feature Can Be Broken Down into Separate Releases
I'm sure you've seen the picture from Henrik kniberg depicting the iterative development showing a skateboard, bicycle and then a car. The theory made sense to me but whenever I was faced with a project I couldn't figure out how to apply it. The solution only worked when all of t
Read edition ↗