The Stacey Matrix is a well-known tool in the tech world for predicting how much peril you might encounter when you set out on a project.
Start with unclear requirements (sometimes called social complexity) and you will have a hard time gaining enough agreement about what to build to actually create something of value. This is the classic problem of trying to be all things to all people.
On the other side of the problem is technical complexity. Anyone who has ever been close to a significant technology project knows there are a tremendous number of potential technical complexities that can pop up and create unpredicted costs and schedule overruns.
Combine social complexity and technical complexity and it is easy to see why it is so common that projects suffer such overruns and often damage business rather than create value.
Attempting to Manage Complexity with Iteration
The response to the problem articulated by the Stacey Matrix is that we need to proceed with a methodology that is adaptive. Enter agile development. We can avoid ending up in chaos if we can accommodate learnings as we go.
“We will plan as we go,” is the mantra.
However, with an aversion to upfront planning and far too low a bar for what counts as the perspective of the customer, all-too-often agile teams simply iterate right into more chaos.
At this point, permit me a couple of caveats.
One: I am not advocating for waterfall methodologies. Clearly the Stacey Matrix shows that proceeding with a plan you cannot easily deviate from is a recipe for delivering little value when things are complex.
Two: I am not claiming that all agile teams out there are simply bad planners or that they do not care about the actual customer perspective.
Simplifying Complex Problems by Listening to Your Customers
To steer us away from chaos, we need concrete and repeatable practices that will reliably provide Agile product teams with deep customer insights.
Too often, teams often substitute sitting around and guessing at what customers really need instead of developing an actual understanding of a customers’ jobs to be done.
David Whited, the Director of Highland’s CX Practice, likes to say:
“Telling people to delight the customer is like a conductor telling the the orchestra to delight the audience, but then not telling them what piece of music to play or providing them with the leadership during the actual performance.”
We need real insights into the people who are using the products we are building, not fluffy aphorisms. This is why human-centered design, customer experience, product, UX, and lean development practices have taken off in recent years.
Take customer experience as an example.
We could take an idea for an application and just run with it, assuming that we have a killer new product and nothing could be more important than rushing it out to users so we can learn. The issue here is that we are assuming our trajectory is right in the first place.
We are setting out to sea without a map or a compass (into stormy waters to boot) and saying, “We’ll learn as we go.” This is a recipe for disaster, especially if “learning as we go” means continuing to sit around at regular intervals to guess and argue about what users will want.
Something like a simple customer journey map or a design sprint could help us set out on a much more focused trajectory. What we need at the outset of such a journey is to do something that pulls the trajectory in from the realm of chaos into complicated or simple.
If we can also combine this with regular practices of user experience research and testing, we can ensure that we are on the path to creating value. Think of customer experience as the map you set out with, and user experience research and testing as your compass along the journey.
Every product manager should care about customer experience. Those who do will have smoother projects, happier teams, and are more likely to build products that deliver real value.