Many of my clients have large “appetites”: they want to create ambitious products with many features. Even though I recommend they start small and iterate their way to that ambitious product, these (smart people) still say they want to start with “more.” They think the team needs to see this ambitious product vision to know what to do.
As a result, the roadmaps are long and extensive. The product leaders start to use MoSCoW prioritization instead of ranking the work. Too often, the result is a bloated product full of half-finished features. The teams do not have a concept of product options and minimums. Instead, because of this “more” thinking, the teams can only conceive of maximums, the “more” applied to everything they do: the features, their WIP, and all the possible customers.
I have delivered large products on tight deadlines. (I told some of those stories in Agile and Lean Program Management.) I've also delivered smaller projects on tight deadlines. (See Manage It! and Create Your Successful Agile Project for more stories and details.)
But I was never able to plan “more.” Instead, I planned “how little” and decided how often to iterate over which areas of the product.
My stories will not change anyone's mind because these are my stories.
Data, in the form of flow metrics and cycle time, tells us this does not work. But data never changes anyone's mind.
Stories change people's minds. Even better, their stories change their minds.
How to Prompt Those Stories
Because I'm a skeptic, I start with curiosity. I assume these people have had experiences I do not share. That's why I need to prompt them to tell me stories that can change my mind.
Here are some ways for people to tell you the stories of their successes. First, ground them in reality:
- From your personal experience, please give me an example of the most recent time you were able to plan more and deliver all of it. Or most of it.
- Tell me what everyone did to create success.
Many people believe things that differ from their experiences. These two questions ground people in their reality.
Sometimes, those questions and the person's answers will lead them to the next question:
- Especially if that experience was longer than 4 years ago, ask this question: How has the world changed since that time?
As I write this in 2025, remember the pandemic was in 2020. Most of us changed our in office work to work from home. Also, most people think they're using an agile approach. If this person believes in “more,” learn why they still think this is useful now.
Now, ask them to explain how their current organization can succeed with their previous successes:
- How can you use your past successes to inform this future success?
- How can the team use that previous experience now to create a successful product?
When you prompt questions like this, you're honoring their past successes. Have them tell you how to help the team succeed.
Or, if you're lucky, as I am, the person says, “Well. That was 20 years ago. We were not very agile then. Maybe we have other options now.”
Eureka! Now, they convinced themselves and you—together—can explore what might work for them now.
Help People See Their Current Reality
Our current reality in 2025 is this: We are in a state of disruptive change. How can we succeed with “more?” By creating a product strategy for the overall product with a strong project vision for the current project—for now. We need to expect change, often at the worst possible time. When change occurs, we can update the product vision and possibly update the product strategy.
The key is this: We can replan, assuming we finish more work. That's the point of more agility. (See Project Lifecycles for more details.)
Then, we can plan just enough to achieve the next milestone. What is that milestone? It might occur at a specific time, such as a weekly (recorded) demo. Or, it might be more often with small deliverables that achieve some kind of a product minimum. The point is this: Instead of “more” thinking, we use “how little” thinking to iterate to success.
This works for programs and projects alike. It especially works when we need to manage surprising risks or innovate in some way. (See How Product Risks Differ from Project Risks for more details.)
We rarely need “more.” Instead, we need the features our customers will want and use.
More is rarely better. How little thinking helps everyone see how this small increment of value fits into the greater product strategy. That's what helps better product development.