Product Leaders — 4 Signs You May Be Stuck In Analysis & Planning Paralysis

A colorful pop — art widescreen image in the style of Roy Lichtenstein of a stressed out woman in a business suit trying to make many decisions. Image via Midjourney from this author prompt.

And how Strategy and Product leadership skills & mindsets provide ways to get unstuck & deliver outcomes that matter

As a busy product leader, you might feel like you’re in the business of trying to please your internal stakeholders by shipping every single one of their feature requests as fast as you can.

All the while, you try to shield your Product Managers and their teams from floods of new requests, and you still keep getting hit from all sides by

  • Constant barrages of new stakeholder priorities to juggle
  • Risks and external dependencies to manage
  • Continuously increasing technical debt to pay down
  • Ongoing challenges keeping your programs and teams staffed, happy, and motivated.


Yet despite your best efforts, everything seems to keep slipping farther behind.

Morale is down, your best engineers, designers, and data people are either demotivated or leaving, and keeping the people who stay engaged, continuously improving, and shipping great work becomes ever harder.

How did we get here?

Let’s start at the top to understand how one or more of these four upstream choices may have contributed to your current day-to-day challenges.

1. You start with plans to deliver features before being clear on your strategic choices to achieve outcomes

You and your product managers may have detailed plans for the features you’re trying to deliver this quarter, but how closely have you aligned with your stakeholders on a clear set of strategic choices, and used those to design strategy for your product managers and their teams?

Your “Plan” is not a strategy

Your “plans” are internal-centric task lists you and your product managers hope will allow your teams to deliver their commitments as quickly as possible — efficiently. Your strategy represents something else entirely — a set of client-centric, integrated choices that position your group to deliver outsize value to both internal stakeholders as well as external clients — effectively.

True effectiveness comes from agreeing on the few but hard strategic choices around

  • Where to Play
  • How to Win

And, most importantly, being clear where you and your product managers have deliberately chosen:

  • Where not to Play
  • Specific ways of “winning” you’ve decide not to pursue?

In much the same a way a “Don’t Do” list can be even more powerful than a “To Do” list, having an agreed-upon set of guardrails around what your group has decided it won’t pursue will keep people and their teams from choosing strategies that may directly compete, and effectively cancel each other out.

As a powerful example, if one of your product managers has decided to ramp up your product’s growth, while another has focused on retention efforts, they’ll both be frustrated, as large numbers of lower-quality prospects flood into your system and quickly churn out.

And you always want to focus on Retention before Growth, or else you’re just pouring random people into a leaky bucket.

2. Nothing you’re building is directly connected to one of your target customer’s compelling problems

Any work worth doing is grounded in your core customers’ unmet needs.

Stop and consider the multiple features your teams are delivering, and the many more in the pipeline — could you honestly imagine any of the clients you care about most asking for them in their own words?

Or are you just focused on the things you’ve decided to build, for your own reasons?

For example:

  • How many clients have specifically asked for interstitial pop-ups promoting some random offer you’re trying to push while they’re trying to accomplish a goal (search, browse, check out)?
  • How many times have clients said they prefer engaging with automated chatbots instead of speaking with a human being, just because you’re trying to reduce your customer support costs?

Think deeply about this: Are you really working on the things your product’s best customers are most lacking?

Instead of starting with what you want to build, consider first understanding and then addressing what matters most to your core customers in ways that also deliver value to your company.

3. You don’t know your teams’ actual capacity

It seemed as though it would be so easy.

Some of your best people seemed to be “available,” so you pulled them from their main team “just this once,” and moved them onto another high-ranking stakeholder’s “must-have” initiative. You’ve essentially guaranteed that neither of the two efforts will be delivered in any reasonable timeframe. In almost every case I’ve seen this happen, these decisions have been made without understanding what that team’s capacity was.

When we don’t know how much work a team can actually handle, the temptation is always to try to shovel “just a little bit” more work into the software system of delivery.

Before you do that, understand:

Like it or not, Capacity and Flow constraints are fixed

Appearances can be deceiving.

While it might have seemed at the time as though the people on those teams “weren’t all that busy,” it’s been mathematically proven that increasing individual employee Utilization (ex., from 80–90% to 110–120%) will cause their average time for any given piece of work to move through your system of delivery to take exponentially longer to complete.

The high cost of switching

Add in the “switching costs” of shifting from one work context to another, and the likelihood of creating an environment for high-achieving cross-functional, collaborative knowledge work becomes nearly impossible.

It’s way more expensive than you think to “peanut-butter” your Product Managers and their people and spread them across multiple projects. From Steve Trapp, “The Financial Cost of Task Switching,” courtesy of

Ironically, the results of trying to squeeze more out of your people and teams:

Skyrocketing development costs, poor quality, bad solutions, unhappy employees, unhappy customers.


And a cycle that continually reinforces itself.

4. You don’t work with your teams to set success metrics before you start building features

How would you define success for any of the features currently in progress in your backlog?

This is closely related to #2 above — if either don’t understand who your core customer is, unaware of their journey, and don’t understand what “success” means for them from their perspective, you could launch every one of your proposed roadmap features, and they could all literally fall flat after months of effort and tens of thousands of dollars in development costs.

Before any hands hit the keyboard, understand what success looks like.

Conclusions — TL:dr;

An enormous part of your ability to lead people and teams through effective value delivery depends on:

  1. Working with your leadership, stakeholders, Product Managers, and teams to understand your current strategy, and intentionally design your strategic choice sets around where you choose to play, and where you choose not to play
  2. Grounding your strategy by working backwards from actual client needs through regular target client contact
  3. Measuring and working within your delivery teams’ actual capacity
  4. Collaborating with your teams to set success metrics for any feature before you start to design or code anything

Many thanks to Justin Hunsaker for his extensive review & feedback of this story.


How Does Utilization Impact Lead-time of Work?
Does system utilization impact the amount of time it takes to complete work? This notebook examines the impact of…

The Financial Cost of Task Switching
In the Peoples And Teams section of the Professional Scrum Master course, we discuss the impact of Task Switching. We…

Interviewing Customers

The Product Trio

The Strategy Choice Cascade

Follow me for more on Strategy, Goal-setting, and Product Managementdig into my articles on the “Playing to Win” Strategy Framework, and sign up for my Upstream, Full-Stack newsletter, where subscribers get exclusive early access to my articles.


%d bloggers like this: