The Five Dysfunctions of Product Management Teams, and is Scope Creep Really a Thing?

"Back to the Future" originally didn't star Michael J Fox but Eric Stoltz. After a few weeks of shooting, the director and screenwriter felt it wasn't working and fired Stoltz. They reshot all the scenes at a cost of $3M, and a classic was born.

The lesson for product managers: It's never too late to pivot. Try to avoid sunk cost fallacy and make sure you’re always doing the best for your product, no matter how uncomfortable it feels at the time!

---

A word from the sponsor - me!

Yes, yes, that's me. But listen up. I started One Knight Consulting because I have seen variations of the same problems plaguing growing startups, scale-ups and larger, digitally transforming companies again & again. These problems can cause friction between teams, slow product development, lacklustre sales, and ultimately lead to constrained growth. If you're scaling your product organisation, struggling with cross-team alignment or having trouble executing your product strategy to support your business goals, book a call with me and we can discuss your needs and how I can help.

---

New Podcast Episode: The Five Dysfunctions of Product Management Teams

I’ve known Saeed Khan for quite a while now, and we chat regularly. He was actually one of my first-ever podcast guests. Now, let’s call out that I’ve never been a natural podcaster and the first episodes of my podcast had a certain “Simpsons Season 1” quality about them (voices not quite right, badly drawn etc). And, of course, the podcast hadn’t found its audience, which meant that poor old Saeed didn’t get the love his wisdom deserved.

I was therefore delighted to invite him back to discuss his recent blog post “The Five Dysfunctions of Product Management Teams” and dig into what he’s uncovered in his 20 years of product management consulting.

The dysfunctions are:

• Poor Job Definitions

• Under-skilled product managers

• Poor Processes

• Unclear Objectives

• Weak Product Leadership

Saeed has some tough love for PMs, but he thinks that…

It's important to be honest about the state of product management

It's not about being negative or blaming "bad product managers" for everything. But, there are repeated dysfunctions across a large number of companies and we can't fix them if we ignore them.

Check the episode out on your favourite podcast app, or right here.

---

Is Product/Market Fit Dead?

My good friends Andrea Saez and Dave Martin recently put out a white paper claiming “Product-Market Fit is Dead”. We tried to have a live Twitter Spaces discussion about this but the technology fell apart around our ears. Undeterred, we recorded an “as live” podcast discussion to talk all about it. Check it out!

---

Is Scope Creep Really a Thing?

I posted this little Tweet on Twitter recently to see what trouble I could stir up. The core premise? People complaining about “scope creep” are just succumbing to waterfall thinking, and that scope creep does next exist in truly agile product development.

Do I believe this? Yes. And No!

What is scope creep?

A quick Google for “scope creep” turns up a bunch of project management articles. For example, projectmanager.com describes it thus:

Scope creep is what happens when changes are made to the project scope without any control procedure like change requests. Those changes also affect the project schedule, budget, costs, resource allocation and might compromise the completion of milestones and goals. Scope creep is one of the most common project management risks.

And, to be fair, if you’re worried about project schedules, budget/costs and resource allocation then scope creep is definitely something you should be worried about.

Product managers might look at the “iron triangle” and say “well, time/cost is fixed then scope has to be reduced!” But if scope is also fixed then you either have to put cost or time (fundamentally two sides of the same coin) up or reduce quality. None of these is appetising in project-based environments.

But, wait! We don’t operate in project-based environments, right? Not so fast. For all of the talk of outcomes over outputs, MVPs, now/next/later roadmaps and the like, there are still many companies out there that, at best, see agile development as a series of small waterfalls. Many companies have leaders that want the benefits of agile development with the comforting predictability of knowing what they’re going to get and when they’re going to get it. Our job as PMs is to try to demonstrate the benefits of a more agile, iterative approach.

Is scope creep a thing in agile?

Let’s check the Agile Manifesto. The final point says:

Responding to change over following a plan

Ok, that seems to suggest that change is good. But what about the Agile Principles?

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Seems to be a slam dunk, right? Change all the things, whenever you want! We don’t need any stinkin’ plan!

Well, not so fast. Let’s think about the ways that scope creep can come about. Scope creep is going to manifest itself through either:

• Adding new tasks to the list of tasks to do

• Loading in-flight tasks with more stuff

And the source of that work is either going to be:

• Intrinsic - from an internal stakeholder without any validation

• Extrinsic - from at least one customer, based on new facts

The key word here is “customer” - making sure that, if we adjust our plans at all, we adjust based on real feedback from real people that are going to be using or buying the product rather than “wouldn’t it be nice if” interventions from internal stakeholders.

I’m going to go out on a limb here and say that, if you break tasks down small enough, there are very few (if any) reasons to load an in-flight task with anything. Almost all of these tasks should be completed as is unless there’s a truly compelling reason not to do it (e.g. abandoning the whole initiative). Get the task done and then work out what to do next.

Beyond that, I don’t think scope creep really exists in agile product development. When building products, we’re supposed to be concentrating on the most important stuff always. We show our work regularly, which means that “the most important stuff” can change based on new information. This is not “scope creep”, but a sign of a healthy, agile product development process!

The biggest problem with the term “scope creep” is that it’s used to describe both of these scenarios. Constantly stuffing JIRA tickets with more and more requirements before you’ll give it the Gladiator thumbs up is not good product management! Get the tickets done, create new ones with your new stuff and do that stuff if it’s legitimately the next most important thing. But we should never be afraid of adjusting what comes next based on real customer insights.

Wrapping up

No one gets points for “being agile”. People don’t buy products based on how closely you followed this or that framework. The only thing that matters to them is that you solve a problem for them in a way that is better than other solutions and at a price that they can afford. The agile hypothesis is that we can better serve that goal by working small and adapting as we go. No one has yet persuaded me that a 6-month detailed plan with no variations is a better way to do that.

Thanks for reading, do please send feedback and let me know if there are any topics you’d like me to cover. And remember to share the newsletter with your friends!

If you want to buy me a coffee, you can buy me a coffee.