10 Sources of Waste in Product Management
10 Sources of Waste in Product Management
There's nothing more disappointing than seeing a team's energy and effort go to waste.
Hey, Paweł here. Welcome to the free edition of The Product Compass!
Every week, I share actionable tips and resources for PMs.
Here are a few posts you might have recently missed:
Introduction to AI PM: Neural Networks, Transformers, and LLMs
12 Proven Sources of Insights to Fuel Your Product Discovery
5 Steps to Negotiate Your Product Manager Job Offer in a Tough Market
Consider subscribing and upgrading your account for the full experience.
There's nothing more disappointing than seeing a team's energy and effort go to waste when their hard work doesn't truly move the needle.
Being part of such a team can feel demotivating, frustrating, and, frankly, hopeless.
I've been there many times.
So, in today’s post, we discuss ten sources of waste that I've witnessed in my career. And more importantly, I’ll share advice on how to avoid them.
Let’s dive in.
1. Broken Team Topologies
One of the key responsibilities of product leaders is designing team topologies to minimize cognitive load. This involves creating small, cross-functional teams that can achieve their objectives end-to-end with minimal dependencies and handoffs.
Why is this critical?
Handoffs and dependencies
Every stage gate in your workflow means waiting. The more stage gates, the longer your lead time, cycle time, and time to learn become.
Example anti-patterns:
Handoff from researchers to engineers: Integrate research into team activities instead of treating it as a separate handoff.
Handoff from engineers to quality assurance (QA): Make QA an integral part of the team’s workflow.
Handoff from developers to DevOps: DevOps should enable teams to seamlessly build and deploy solutions across environments.
On top of that, each handoff results in knowledge loss. According to Jonathan Smart:
“As much as 50% of knowledge is lost in every handoff. That means that by the time work has had 4 handoffs, the recipient is potentially only getting 6% of the knowledge associated with the work. Move with the work, as a multi-disciplinary team, minimizing hand offs” — Jonathan Smart, Sooner Safer Happier
Teams that are too large
Small teams are essential. Amazon introduced the “two pizza team rule:” If a team cannot be fed two pizzas, it's too large.
The more people on a team, the more complex communication becomes, leading to communication overhead and waste:
In my experience, the upper limit for effective teams is 8-10 members, with 5-6 engineers.
More information
For more information, see our previous post, Team Topologies: A Handbook to Set and Scale Product Teams.
2. Leading With Processes
Everyone hates complex processes. But it’s even worse when the process doesn’t fit your team’s unique needs or results in bottlenecks.
As Marty Cagan noticed:
“(…) if you believe as I do that there is no one right way of doing product, then the very notion of standardizing a process across a large organization just means that you’ll be institutionalizing a process that will be a poor fit for most teams.” - Marty Cagan, Process People
That’s similar to what Jeff Bezos believes:
“Good process serves you so you can serve customers. But if you’re not watchful, the process can become the thing. This can happen very easily in large organizations. The process becomes the proxy for the result you want.” - Jeff Bezos, 2016 Letter To Shareholders
This way of thinking is also deeply embedded in the culture of Netflix:
“If you give employees more freedom instead of developing processes to prevent them from exercising their own judgment, they will make better decisions and it’s easier to hold them accountable.” - Reed Hastings, No Rules Rules
I’m not saying all processes are bad. For example, the Amazon PR/FAQ process works for them.
But when introducing any process, ask yourself:
What problems are we trying to solve with that process?
Are we sure that the root cause of those problems was the lack of the process?
What is the cost? Does it justify the potential benefits?
Can we set it as a good practice, not a requirement?
What elements of the process can be simplified? Are they all required?
Did we start by consulting those who will be affected by the process?
How can we test it and get feedback on a smaller scale?
More information
For more information, see the Four Product Team Principles and Four Product Culture Principles, which I discussed with Marty Cagan.
3. Over-Documentation
Many Product Managers create detailed documentation—like five 20-page PRDs—for the sake of documentation, only to complain that "product management is too much work." These documents can consume a huge amount of time and quickly become outdated.
And guess what?
Nobody is going to read it—especially stakeholders and engineers.
Complex documentation
The first rule is to keep everything concise, for example:
A User Story that follows the 3 C’s format. Creating a user story should take up to 10-15 minutes. And you need no more than several of them a week.
A minimal PRD with only essential information.
Most importantly, remember that documentation doesn’t replace communication. Rather than trying to capture every detail (which is impossible), focus on ensuring everyone understands:
What is our strategy?
What are our objectives?
How will this help us create value for customers?
How will this capture value for the business?
Why do we want to do it now?
Building a shared understanding is key. When guided by strategic context, others can make good, autonomous decisions and fill in the details you have missed.
Documentation prepared too early
Another form of over-documentation is creating materials too far in advance.
For example:
OKRs with all Key Results set for the next four quarters.
Detailed User Stories planned out for the next 3-4 months.
In my experience, these decisions are best made “just in time” when you know more.
If you look into my Product Backlog, you’ll see that I keep detailed User Stories for only the next 3-4 weeks. By the time we need them, we’ll know more about our users, gain business insights, and get feedback from production.
Doing otherwise would be wasteful.
Other forms of documentation
Some things should go without saying:
Creating multiple sources of truth: For example, copying User Stories to Excel so you constantly need to manage their synchronization.
Creating complex roadmaps that span many months to the future: It’s just another form of documentation. A costly one. Rather than documenting fiction, shorten the planning horizon, do not commit too soon, and focus on the outcomes. My favorite approach is the Now-Next-Later roadmap.
Documentation prepared only to facilitate large meetings: We’ll cover that in the next section, Meeting Circus.
More information
For more information, see How to Write User Stories, How to Write a Product Requirements Document, OKRs 101, and 3 Ways to Create 10X Better Product Roadmaps.
4. Meeting Circus
Many people understand that no real work gets done in meetings unless it's a workshop. Yet many teams struggle with endless meetings—all-hands, presentations, planning sessions, and status updates.
Those problems are particularly visible in rigid frameworks like SAFe, where structured planning can consume much of the team’s focus.
When you can’t contribute
The first rule I followed was to leave any meeting where I couldn’t contribute.
Whether you like him or not, Elon Musk gave great advice:
“(…) walk out of a meeting or drop off a call as soon as it is obvious you aren’t adding value. It is not rude to leave, it is rude to make someone stay and waste their time.” — Elon Musk
I have learned that, in most cases, nobody cares if you skip a meeting when you are only there to listen.
PowerPoint presentations
I also loved Jeff Bezos's approach and virtually stopped preparing “PowerPoint presentations.”
At Amazon, key meetings are used to discuss clear, well-prepared documents sent out before the meeting. Everyone is expected to come prepared, ready to ask questions and collectively find solutions—not to sit through a presentation.
In my work, I ensure everyone knows the agenda and gets information in advance. I try to keep my meetings as work-focused as possible.
5. Analysis Paralysis
Analysis paralysis happens when people gather excessive evidence, trying to “avoid failure” at all costs. While product management is largely about managing risks, it’s impossible to eliminate risks entirely.
I loved the quote shared by Marty Cagan in TRANSFORMED:
“100% predictability = 0% innovation” - Henrik Kniberg
Similarly, Jeff Bezos believes leaders should act with urgency. Most decisions can be reversed (aka “two-way doors”):
“Speed matters in business. Many decisions and actions are reversible and do not need extensive study. We value calculated risk taking.” — Bias for Action, Amazon’s ninth leadership principle.
So, as a leader, make sure your teams feel safe to experiment and fail and that when they fail, they can learn from it:
“A good failure is when the value of the lesson is greater than the cost of the lesson. A bad failure is when the value of the lesson is much less than the cost of the lesson.” — Alberto Savoia, author of The Right It
More information
For more information, check out How to Manage Risks as a Product Manager and Learn From the Best: 8 Secrets of Amazon Web Services Success.
6. The Lack of Tools You Need
Many companies try to cut costs by choosing cheaper alternatives for essential tools. An example might be opting for Microsoft Teams instead of Slack because “we already pay for Microsoft 365,” even though employees clearly formulate their expectations (that's an abstract example, I hope you get the point).
While this might seem practical, companies often overlook the effects on productivity and team morale. After all, how can you be held accountable for outcomes if you don’t have the tools you truly need?
I personally heavily invest in tools that support my work, including paid subscriptions to Grammarly, Poised, Canva, Flaticon, Adobe, Zoom, Ahrefs, Figma, Kajabi, Accredible, Chat GPT, Claude, Notion, Airtable, Bitly, Buzzsprout, Xmind, and about ten others.
Many of them have free alternatives. And, of course, nobody enjoys extra expenses. But I only ask myself one question: “Will the outcomes justify the investment?”
As a rule of thumb, it almost never makes sense to trade your time for cheaper tools.
Ideally, companies understand that, too.
But if your company doesn’t provide a GPT subscription or other essential tools, consider this—how much time could you save by investing in them? Could you use that time to spend time with family, learn and increase your market value, or start a side project?
7. Context Switching
Let me say this clearly. Multitasking is a myth.
Gerald M. Weinberg's research shows that each additional project or task results in a 20% productivity loss. When we add a third project, context switching consumes almost 50% of the effort.
As described in Working Backwards, single-threaded, cross-functional teams are one of the secrets of Amazon's success.
So, you, too, should focus on what’s most important and eliminate the rest.
8. No Product Discovery
We've discussed this many times: in product management, the simple truth is that most of your ideas won’t work.
Marty Cagan puts it well in Inspired:
„The first truth is that at least half of your ideas are just not going to work.”
This is due to risks like value, usability, viability, or feasibility challenges that arise along the way. I see the same patterns in my work.
Some say that it’s enough to be Agile. But the issue with Agile frameworks like Scrum, when not properly adapted, is that they focus on “learning by delivering.”
While these frameworks encourage regular inspection, applying them without reflection can lead to regular waste and rework, with production-ready increments that are ultimately discarded.
This is where Product Discovery comes in. It allows you to:
Come up with better ideas.
Test high-risk assumptions before selecting ideas for implementation.
More information
You can learn more from the free introduction, What Is Product Discovery? Product Discovery 101 and How to Manage Risks as a Product Manager.
And above all, make sure you enroll in my Continuous Product Discovery Masterclass. Product Discovery is the single most critical area for a Product Manager. That’s probably the most important resource of the entire newsletter.
9. Compromising Quality
Here’s an eye-opening statistic from Applied Software Measurement: Global Analysis of Productivity and Quality by Capers Jones.
If it costs $100 to fix a bug in unit tests, it can cost $16,000 to fix that same bug in production:
While this exact figure might vary in a product management context, the overall message is clear: quality is free. Cutting corners and rushing to release only lead to greater costs in the long term.
For example, one of my teams has three full-time QA and test automation engineers. Their role is crucial in catching issues early.
10. Striving For Perfection
Last but not least, the pursuit of perfection.
While we never want to compromise on quality, we should be willing to compromise on the scope.
Product Discovery results in a validated Product Backlog, meaning high risks are addressed before implementation begins. But it can’t eliminate all risks:
It's impossible to identify and test every potential hypothesis.
Experiments are never 100% conclusive.
The ultimate test is real customers using your product in the real world, with real data.
Striving for perfection can lead to delays and missed opportunities—sometimes, we need to learn by putting our product or feature in front of users.
More information
You can learn more by reading Continuous Product Delivery: Why It's Critical to Release Frequently.
Conclusions
There’s nothing more frustrating than seeing a team’s hard work go to waste. I’ve been there and know how demotivating, frustrating, and discouraging it can feel.
Today, we covered ten sources of waste I’ve encountered throughout my career. While we can’t eliminate waste entirely, we can manage and minimize it.
Take a moment to reflect:
Can you see any of these ten sources of waste in your teams or processes?
Which one resonates the most with your current challenges?
What will you do about it?
I recommend choosing one area to focus on this week—maybe it's reducing unnecessary meetings, streamlining documentation, or communicating the strategic context more effectively.
Develop a simple plan:
Set Clear Objectives: Define what you want to achieve.
Engage Others: Discuss the issue openly and gather feedback.
Take Action: Implement small changes to understand the impact.
Reflect and Adjust: Assess what works and what doesn’t and adapt.
By addressing these areas, you'll empower your team, increase motivation, and help them achieve the desired outcomes.
Thanks for reading The Product Compass!
It's great to learn and grow together with you.
Have a fantastic weekend and a productive week ahead,
Paweł
The best teams don’t manage projects—they manage the flow of value.