The more work we put into backlogs, roadmaps, and the portfolio, the more product certainty we appear to have. But can we trust that product certainty?
No. There's the Aging problem. Then, there's the fact that we can't tell what the future will bring. Even if a team has a relatively low and consistent cycle time, the world does not stop waiting for us to finish our product. It's even worse when the team does not have a relatively consistent cycle time, because they do not know what they can finish or when.
When I plan a project or a program, I start off with a direction. (I inform that direction with a project charter that contains the product vision.) But, experience has told me that things will change. That's why I don't like a lot of product certainty too early. Instead, I want to create experiments and options to still deliver that product vision to the customer.
Plans can help. But they create too much certainty.
Why Plans Create Certainty
The longer a backlog or a roadmap, the more thought someone (or many someones) has put into this product. But have they validated any of their assumptions?
Worse, the more thought any product leaders put into the product, the more attached they tend to be to those ideas. But product leaders need to be committed to the value they create for the customer. Not the features in a feature set.
The longer the plan, the more certainty and weight that plan has. (See Large Features and Long Deadlines Mean You Have a Gantt Chart, Not a Roadmap for more details.) There's a small reinforcing feedback loop there:
- The larger the feature set, the more certainty it appears to have.
- The more certainty, the more likely people will add to that feature set instead of asking if these features still have value.
- As a result, requirements spawn more requirements, the product grows, and the team can't ever seem to catch up and finish.
Instead of thinking we “just” need steps, as in the image at the top of this post, it's time to consider what we need to do now and what we can postpone to later.
Reexamine What We Need to Do Now
I see this problem everywhere: What do we do now? The biggest issue I see is that “what we need to do now” is so big. Too often, that's an entire feature set. Instead, we can consider a variety of product minimums. How little can we do to validate our current assumptions? That would allow us to use the “steps” image at the top of this post to see what might be next.
Sometimes, we need a short experiment, as in this image.
I don't mean to make this image look more complex, but faster experiments create faster learning opportunities. Is there a short experiment (under a team week) we can run that will offer useful information?
If we consider “now” and “later,” we can reconfigure all these extensive plans into future experiments and options.
Consider Future Experiments and Options
The point of product development is to deliver value to a customer. The more customers, the more revenue.
If your customers ever said, “I know you gave me what I asked for, but that's not what I need now,” your plans are too long and extensive. Instead, consider how to hold those plans lightly, creating future experiments and options, instead of long and extensive backlogs and roadmaps.
That's the essence of continual planning: short feedback loops, learning as we go. Much less certainty and many more options to create value.
We cannot have product certainty the way our world is changing. Instead, we can capitalize on fast feedback cycles to inform our next steps and experiments. And create options so the product can deliver value to those customers.