The best product planning approach does not focus on plans
Get ready to embrace change and emerge your path.
Budget season has just ended. You as the Product Manager have been assigned to own a major strategic initiative. As part of the budget process, your stakeholders have provided numerous ideas on how they want you to solve it and are eager to learn when you will be done.
Now what?
You tell yourself you need a detailed plan. In your mind, this exquisite plan will use clear requirements and meticulous designs. These will feed precise estimates for predicting a budget-conscious delivery date.
After all, a detailed plan provides comfort to you and your stakeholders you’re in control, right?
It may be surprising to you, but this approach is precisely the wrong move.
Detailed plans up front are the illusion of control when it comes to product development. They create premature convergence and do not embrace change.
You may be here to learn how to devise perfect requirements, a detailed design, and an orderly plan up front. Unfortunately, I can’t give you this (and nobody else can either).
But if you recognize product development as complex and uncertain, we are on the same page. Stick around if you are looking for guidance on how to navigate within the dense fog before you.
Ready? Let’s go.
Three missteps to avoid with product planning
A few traps are commonplace in our trade, so let’s explore them a bit first. There are three typical areas we stumble into when we attempt to plan products.
- Trying harder to plan up front better.
- Laying out the perfect stepwise plan by separating discovery, delivery, and testing.
- Placing big bets.
Each of these missteps thwart our ability to deliver the right thing in the right way at the right time.
Misstep 1 — Trying harder to plan up front better
Product development is a complex, uncertain journey.
When we face this unpredictability, we try to gain back control with careful planning. And when things inevitably don’t go as planned, we figure we need to do a better job of…yes, you guessed it, planning. This creates a wicked cycle of misguided rigor and gets us no closer to meeting our product goals.
Here are some examples of techniques we often turn to in error as we attempt to gain control as we plan our product:
- We set deadlines, driven from detailed, bottom-up estimates. Think about those multiple-tab, laborious estimation spreadsheets.
- We orchestrate elaborate, quarterly, big-room planning workshops. The SAFe Program Increment planning event comes to mind. While it is a step toward collaborative planning, it does not embrace change. It simply is neither frequent enough nor focused on a small enough batch of work.
- We craft pretty, sequential Gantt charts. But there is no such thing as an orderly, step-by-step path to your product outcome.
- We lock in a scope baseline early and devise a rigid scope change review process to keep change at bay. Oh, the pain of the scope change review board process.
These methods don’t work; they make you converge too early. You can’t remove the complexity and uncertainty with a detailed plan or by thinking more before acting. It actually works against you by locking you into one of many potential paths.
You may ask, “what uncertainty?” Many believe they can tame product development by thinking harder and planning better. But in product development, change is the only constant, and we actually know less than we think we know.
Every product has different customers with unique needs, and market forces change often. The technology to solve these problems is forever evolving. And the team members solving those problems are human with ever-evolving contexts.
With detailed planning, you try to control the uncontrollable by thinking of every nuance. Despite this rigor, a haze of uncertainty is still obscuring your best path. Your detailed plan is nothing more than an educated guess.
Planning in detail up front at the moment of the highest uncertainty is a waste of time. You commit to one path before you have ever tried to traverse it. It’s like creating a map you will blindly follow without having ever stepped onto the terrain.
Misstep 2 — Separating discovery, delivery, and testing into distinct teams and phases
Splitting discovery, delivery, and testing by team and phase is a common path to a step-by-step plan. But this approach has significant difficulties. It dampens collaboration in favor of specialization and separation of duties.
Many gravitate to splitting things out like this to create a neat, orderly plan. Yet, they don’t see how it dilutes common purpose, ignores learning, and elongates flow.
The members of each of these teams are, more often than not, quite adept at their localized focus. Yet, each team optimizes its own narrow step in product development. In the end, the customer and product goals get lost in the mix.
Let’s understand how this happens. For one, each team has a different understanding of what it means to be done:
- Discovery Done. The discovery team focuses on generating a backlog of final requirements and designs. These “Discovery Done” items go into a backlog for the delivery team to build.
- Delivery Done. The delivery team’s job is to generate a backlog of code complete items. Its goal is to meet the requirements and design performed by the discovery team. This “Delivery Done” work goes into a backlog for the testing team to integrate and test.
- Testing Done. The testing team ensures quality of the code complete items from the delivery team. It ensures the code meets the requirements and design of the discovery team, free of defects.
None of the teams can own end-to-end delivery of value, as each team’s purpose is to fulfill its one piece of the puzzle. The feedback loops of this approach are too long and slow. They can’t enable the rapid learning needed to build the right product.
Further, the product backlog forms a wall between these teams and limits collaboration. The delivery team can’t apply a lens of feasibility to the up-front work of the discovery team. And, similarly, the testing team can’t infuse quality throughout the entire flow.
At its worst, work moves in large batches between the three teams. And at its best, the teams work in smaller batches a few cycles ahead of each other. Regardless, the feedback loop is slow between the teams.
Rework and other problems end up infecting the product trajectory. Splitting discovery, delivery, and testing results in ineffective collaboration and sluggish learning.
To make things worse, the delivery and testing teams don’t interact with the end customer. The discovery team usually performs customer engagement (but sometimes it also doesn’t). Without customer contact, teams become disconnected from customer needs.
In the end, separating teams in this manner leads to longer than necessary lead times. Lead time is how long it takes you to get from concept-to-cash — from idea to user adoption and business impact.
Splitting the work into these distinct, specialized teams creates tremendous amounts of waste. It is not too difficult to imagine the hand-offs, rework, defects, and wait time from this approach.
Despite the pitfalls of splitting teams in this manner, in my experience, it is all too common. I often find it as the default pattern used by most.
Misstep 3 — Placing big bets
When we lock into a detailed plan and scope up front, we are betting the bank on one play. We are attempting to take one large step to our goal. In the uncertain, complex world of product development, putting all eggs in one basket isn’t a wise choice.
The bigger the bet, the higher the risk. Sure, every once in a while, a big bet pays off. But more often than not, failure awaits.
And the risk of failure is not linear. It increases exponentially with bet size. The failure impact radius for big bets is large, and reversing course is costly. So, it stands to reason, the positive outlook — the chance of success — drops fast as the size of the bet increases.
Risk is amplified in our big bets because we often imagine the most elaborate solution possible. We forget about simplicity. The product our customers need isn’t always the best product we can imagine. Large bets don’t factor in learning along the way to arrive at what’s best.
When our fancy, big plan inevitably does not play out as expected, we find out late. And when we are late in our timeline, we are low on money, time, and energy. The pressure is immense, and our success options dissipate.
Big product bets are not worth the risk and are not an effective planning strategy.
Three tips for charting your path (plan) to product success
Alright. We have established the wastes of detailed, upfront plans, specialized teams, and big bets. Check.
So, what is the alternative? How should we attack this beast called product development? We can’t just not plan, right?
Well, yes, and no.
“Respond to change over following a plan”
— Fourth value from the Agile Manifesto¹
We must bet small with empowered, complete product teams who adjust often in the face of new evidence. And of equal importance, we must not get tied to our initial plans. I have three tips for you on how to do this.
Tip №1 — Use end-to-end, complete, empowered product teams
Instead of a discovery team, a delivery team, and a testing team, we need one team — an empowered product team. This singular team contains all the skills and capabilities to produce end-to-end value.
“The best architectures, requirements, and designs emerge from self-organizing teams.”
— The eleventh principle of the Agile Manifesto
The model is simple. You have one small, cross-functional product team. It owns discovery and delivery with a quality-first mindset.
Members from discovery, delivery, and testing teams are now together on one team. The team’s collective goal is to emerge the right product in the right way at the right time.
“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
— The fifth principle of the Agile Manifesto
Customer and stakeholder interaction is no longer only an upfront activity. The product team must have rapid, early, and often product community touch. It must learn inexpensively and fast to emerge the path to the right product its customers need.
A static, big, upfront plan with siloed teams can’t compete with a complete, empowered product team. No plan can beat a rapid learning approach devoid of hand-offs.
Tip №2 — Make small bets and let your customer be your compass
We can take a cue from the Agile Manifesto on this. The Agile mindset focuses on the continuous delivery of value to customers.
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
— The first principle of The Agile Manifesto
Many organizations bet too big on their own ideas and don’t learn if those ideas match a customer need. They fall into the trap of building working product features for every idea they have. And most of these features fail to gain customer traction once launched.
The organization’s confidence in its own ideas outpaces its quest for customer empathy. And it ends up building the wrong thing.
This scenario is all too familiar to me, and I’m sure it is to you, too.
Instead, we need an in-depth understanding of our customers’ situation. This includes the pain points our users have across their workflow. Once we have this, we need to take many small steps — bets — to navigate to the right solution to meet those needs.
At times, we are uncertain on the right solution to a problem. In these cases, we must try out different options in a lightweight manner. We should test these ideas with customers fast and inexpensively — make small bets. Our goal is to get rapid insights to discover the right solution for our user’s need.
At other times, we know our customer well enough and are more certain of the right solution. Here, we can build a working product feature without extensive option verification. But even in these cases, we build small increments and test them with our customer.
Every bet we make is small to ensure we deliver on our customer promise. We aim to solve our customer’s problems early and continuously.
And if your initial increments aren’t quite right, customers will tell you to adjust course along the way. Continuous customer feedback helps simplify, clarify, and focus you. It guides you to exactly what needs building:
- “Don’t go any further with this solution, as it’s not working for me.”
- “This solution is just right, we don’t need to enhance it further.”
- “This solution needs a bit more to meet my needs.”
Putting the customer at the center of every action is what makes a product team effective. It is the shortest path to product success and beats a big, upfront plan every time.
Tip №3 — Practice continuous refinement of your plan to reach a goal
We do have to plan, but our planning must be light, so we can rapidly adapt to changing conditions. Holding on to stale plans won’t help us. So, when evidence presents a better path, we must pivot.
“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”
— The second principle of the Agile Manifesto
When organizations don’t refine their plan often, they can’t adapt fast enough to keep pace with change. They keep going down a path that no longer leads where they need to go.
Some organizations refine their plans once per year. Others do it twice per year. Some do it quarterly.
Continuous refinement, though, requires a much quicker pace of inspection and adaptation. The word “continuous” here implies the frequency. The product teams I have seen, who are at the zenith of embracing change, refine their plans daily.
Effective product teams refine their understanding and correct course based on emerging evidence. They don’t hold on to stale plans, planning light and pivoting fast when new evidence emerges. It’s a lot easier to throw away a short plan you spent a few moments on than a long, detailed plan you labored on for weeks.
These teams plan lightly across three time horizons — now, next, and later. These horizons form the basis of a goal-oriented product roadmap. Each horizon has a goal comprised of desired customer outcomes and business impacts. Their roadmaps aren’t cluttered with unvalidated feature promises; features emerge with experimentation.
And they keep an eye on what’s next as they deliver what is now. As they learn more about their customer, what should come next becomes obvious. Options for what’s next emerge just in time as the team nears completion of its now goal. This is intentional. Detailed planning too early can be wasteful when priorities change.
Light planning. Frequent planning. Relying on evidence to chart the course. These are the hallmarks of a product team who can respond to change with quick, easy grace.
Taking it forward
Contrary to popular belief, relying on big product planning activities up front to guide your path is risky.
Many of us fall into the trap of thinking we know more than we do when we are building a product. We split out discovery, delivery, and testing, and we make bigger bets than we should. Then, we proceed to plan out every detail early and follow it step-by-step to deliver on our big bet.
This is analogous to staring at a detailed map to guide you as you hike through a new, unfamiliar territory. Watch out! Don’t fall into a river or over a cliff.
A better approach:
- refers to a rough map you emerge as you learn
- uses a compass to ensure you head in the right direction
- responds to evidence from the terrain under your feet
Your team refines its map daily to get to its destination. The compass is your team’s customer. And your team’s response to the reality on the ground is much safer than following a plan.
Remember, an effective product team:
- is empowered, whole, and owns its product from concept-to-cash
- makes small bets and uses its customer as a guide
- continuously refines its path to its goals based on evidence
What will you do today to embrace change and become the ultimate product planner?
For more content like this on my pursuit of Lean Leverage, delivered to your inbox, you can just join my email list. Or see my other related posts below to dive even deeper.
Related Reads
You can read similar posts from the author below.
References
- The Agile Manifesto for Software Development, AgileManifesto.org, 2001, Beck et al.
- Mobius Outcome Delivery Map, Cutter Business Technology Journal, Volume 32, No 3, 2019, Page 33