In a project organization, we define what needs to be delivered, organize the work and follow its progress. Scope is broken down, activities are planned and status is reported. We can see what has been done, what remains and whether delivery is following the plan.
When we move towards product development, the goal changes. We are no longer trying to complete a predefined body of work, but to create a change; an effect for customers, users or the business. And that changes what we need to steer towards and measure.
We still need to understand what is happening, where our capacity goes and what is getting in our way. But the work itself is no longer our primary measure of progress.
It is not enough to know what we have done. We need to know what it has led to.
Yet it is surprisingly easy to introduce Product Backlogs, Epics, Stories, Tasks and boards while bringing the old logic with us. The project plan has disappeared, but the questions remain much the same: What is done? What is left? How much have we delivered? Are we following the plan?
More of the work has become visible, but we are still using the structure primarily to follow the work and control what gets done.
This is where the distinction between transparency and control becomes important. In product development, we make work visible so that the people working with and funding the product can understand what is happening, coordinate, learn and make better decisions about what to do next.
The same transparency can serve two very different purposes: controlling the work or steering towards outcomes.
The control logic becomes particularly visible when we try to give all work a place in the structure. There will always be maintenance, support, smaller fixes, technical work and other things that need attention without coming directly from the changes we have chosen to pursue.
This is where it is easy to start using Epics for something they are not intended for: as containers for different types of work. Maintenance Tasks might be collected under an Epic called Maintenance, support Tasks under Support. The backlog looks tidy and everything has found its place.
But in doing so, we have also lost the point of an Epic. What does it actually mean to prioritize Maintenance over Support? Individual Tasks within them may be more or less important, but the containers do not describe changes we can choose between. Nor do they ever finish, because new work keeps arriving.
An Epic is not a container for work. It represents a change we want to achieve.
Reduce recurring production incidents by 50 percent could, for example, be an Epic describing an internal improvement. Get twice as many first-time customers to return within a month could be another, with a more direct effect on customers and the business. Both describe changes we can prioritize against other changes, work towards, measure and eventually achieve.
Some maintenance Tasks may contribute to the first Epic, while others do not. All of them can still be visible in the Product Backlog. A Task does not need an Epic simply to have somewhere to belong.
The difference between tracking work and steering towards outcomes becomes perhaps clearest when we discover that we do not need to do everything we thought we would.
Suppose we believe ten things are needed to create a certain effect. We do three, measure what happens and discover that the effect has already been achieved.
If we follow up on the work, we see seven things remaining. If we follow up on the effect, we have discovered seven things we do not need to do.
Same reality. A completely different view of progress.
Nor do we need to know or structure all work in advance. Incidents, support requests and other unplanned work will consume capacity without us knowing exactly what it will be. We can leave room for it and make the work visible when it appears. And not everything needs to become a backlog item – just because work can be tracked does not mean there is value in tracking it.
We still need to understand the work, our capacity and what is happening. But we do not need to build our governance around controlling whether the work gets done.
The Control Trap happens when we introduce product structures and transparency but continue to use them with the project logic of focusing on scope, delivery and completed work: becoming better at tracking what we do than at understanding what we achieve.
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 control 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.
