Organizations rarely suffer from a lack of ideas. Management sees opportunities, problems and things that could be improved: new features, integrations, automations, capabilities and system changes. And when there are more ideas than we have capacity to pursue, we need to prioritize.
The question is what we prioritize.
When we are operating in complexity, the outcome may depend on how people behave, technology, organizational dependencies, competing needs or how a wider system responds. In these situations, we cannot know upfront which solution will create the effect we want. We may have data, experience and good reasons to believe an idea will work, but until we see how people and the system respond, it remains a hypothesis.
Yet it is surprisingly easy to prioritize as if we did know. Requirements, demands and solution ideas become backlog items. We may even start calling them Epics. We refine them, compare them and put them in order. The structure has changed, but the underlying question may still be the same: Which solution should we build first?
That is a reasonable question once we know what needs to be built. In complexity, however, there is an earlier question:
Which changes matter most for us to achieve now?
That small shift changes what we create direction around. A prioritized backlog of solutions gives us an order for things we might build. An outcome gives us a change to pursue.
Management will still have ideas about solutions, and those ideas can be valuable. But instead of automatically becoming future work, an idea can remain one possible way of achieving an outcome. This leaves room for the team to find a different solution, a simpler one or something much smaller that creates the same effect.
It also changes how we use the backlog. When solution ideas become future work, the backlog can gradually stretch months or even years ahead. What started as possibilities begins to look like a plan for future output.
But what we learn from what we build today should influence what we choose to build tomorrow. The more of the future we fill with predefined output, the less room we leave for future learning.
Thinking long term is not the problem. We should think far ahead about where we want to go and the changes we want to create. What we don’t need to decide far ahead is exactly what we will build to get there. A backlog can preserve ideas about the future. It doesn’t have to decide the future.
When decisions about output are made closer to the learning, we may discover that we need much less than we thought. If three Stories create enough of the desired outcome, Stories four through ten are not unfinished work. They are output we discovered we did not need.
That matters because every feature, integration and capability we add becomes something we need to maintain, support, test, secure and change. Unnecessary output costs twice: first to build, then to own.
That is the Solution Prioritization Trap: in complexity, we can become very good at prioritizing possible solutions when what we first need to prioritize is the change we want to create.
Prioritizing solutions is not the same as creating direction. Create clarity about the outcomes that matter, and decide what to build when you know enough to decide.
More traps
The Negotiation Trap in Prioritization is one of several traps in the series Traps when moving from projects to product teams.
See the bigger picture
The solution prioritization trap is one example of what can happen when we change the way we work without fully changing the underlying logic.
Our Project vs Product Organization in a Nutshell poster explores this shift from several perspectives — including strategy, execution, governance, teams, funding, culture and organization.
