8. Beware the scope creep

Step aside Grinch, it’s time to meet the real secret villain of the season, and every other season

Welcome! I’m Vincent and this is a Product Manager’s Notebook, a series of notes for people who are interested in sharing and learning the art of product management and career development. You can read my archive here.

If you appreciate reading this post, please consider liking and subscribing.

---

Today's piece talks about the dangers of scope creep, why we care about it, how to recognise it, and how to combat it from happening; all centred around a lovely little cautionary tale.

What is “Scope Creep”?

Defining a project’s scope is one of a product manager’s key responsibilities: what are the requirements for the features that the product have in its first iteration or second iteration?

What are we going to build and, more importantly, what are we not going to build?

Scope creep is when extra features start “creeping” in. "Hey, what if the product could do X?". Suddenly additional requirements appear on the roadmap. The team adjusts. They appear again. One after another, until the requirements look very different from the initial scope.

Like a creep….

Why does this happen?

1. A change in strategic direction ↩️

2. A reaction to an ask from internal stakeholder eg leadership or sales, or clients: eg “XY competitor product can do this and so we need this too.” 💥

3. Unvalidated Assumptions: "Customers definitely need this" 🫵🏻

4. No Scope was ever set in the first place. 😶

Is it possible for there to be no scope? Well, yes.

---

I once worked on a project with no scope.

“Let me tell you a story….”

The Bloomberg Terminal is made of tens of thousands of functions, ranging from instant messaging to complex derivative calculators and everything in between. PMs on the “Core” side are responsible for Terminal functions and work closely with their Engineering partners throughout the development process, including creating proof of concepts and prototypes.

That can take time, especially when queued up with other priorities.

When a new internal data science platform was built, a crack team with programming skills and financial know-how was put together with the idea that it could be more agile than the established engineering set up. This would allow them to rapidly produce prototypes for various product teams, without the need to consider scale, internal dependencies or competing priorities such as infrastructure migrations. Luckily, I was delighted to be asked to be a member of the team, and I couldn’t wait apply my skills and build a network of product people in the process. A new legendary team up was formed.

…I may have exaggerated my swordmanship.

It started simple, as we built a prototype that decomposed US CPI inflation into its components to show the real driver of price increases. Python libraries like Plotly made interactive visualisations straightforward, and the data is publicly available. Although the effort to manipulate the data was manual, it allowed you to tell fascinating stories such as what drove inflation during periods such as Covid. Was it fuel prices that pushed prices up and what sub-type of fuel was it? What kind of trend can we see? Being able to get these kinds of insights from dense information can be gold dust to investors.✨

As we had hoped, the result generated an enthusiastic response from leadership. Job done! 🤙🏻

---

Hmm..not quite.

Having demonstrated a quick turnaround, demand quickly came for enhancements to the prototype. Wider country coverage, more concepts, deeper granularity, longer history, more widgets, more visuals, more analytics.

Each release created more requests.

The codebase rapidly grew from a nimble application to a loaded backend that built in more and more dependencies with each release. Performance and stability started to deteriorate and required refactoring over and over and over again. With daily shifting goalposts, there was no definition of done. Each rushed new release also brought the risk of breaking everything else before it. We waited with bated breath on stand by and exhaled a sigh of relief when it didn't.

Unsurprisingly, Engineering didn’t want to own the Frankenstein behemoth that it had now become, containing a dizzying level of custom business logic that defined the relationships of different economic components to one another. A member of my team actually burned out and needed to be take an extended break for his mental state to recover. And yet, like a voracious alien lifeform, the scope continued to grow. 👾

“I think that’s ours”

Eventually, the strategy seemed to become to amass a critical mass of active users so that it had to become an official function, one way or another. After over a year of rewrites and translation to completely different coding language, ownership did eventually, begrudgingly, land with Engineering. Success?

Without a clear purpose or a scope that was ever defined, the team disbanded back into different parts of the company.

---

The Impact of Scope Creep

As the above tale demonstrates, scope creep can create risks for any project.

• It creates distractions to solving the problem we set out to solve

• It causes delays in the release, and we start missing critical milestones in delivery

• Additional features also have a technical impacts upstream and downstream, not to mention the tech debt and/or product inconsistencies that’s being created for future maintenance.

• Not only is this costly in resources…

  Most importantly, you start to lose trust.

• Trust from management that you'll deliver things on time to achieve business objectives 🗓️

• Trust from your engineering partners that their product partner has been honest about requirements and resources, and get frustrated and demotivated when there is no goal in sight. “We’ve been building this forever, when will this ever see the light of day?” 😡

• Trust from your customers and other internal teams that there’s a clear vision for the product and you understand the right priorities

As PMs, trust is our crucial currency to getting anything done. The tricky thing about trust: once it's gone it's hard to get back.

The people you work with when the scope keep creepin’.

---

So what do we do about Scope Creep?

Here are three suggestions to put into place immediately.

1. 🎯Focus on the target outcome: Put the target outcome and customer problem front and centre, and keep it there. This allows us to focus our efforts and anchor all conversations to what the outcome is meant to be. “What are we trying to solve?”

2. ❇️Define a clear scope: Make sure that there is a scope, that it's clearly defined and communicated to internal stakeholders. Create a central document that details how the product requirements link to the product and business outcomes. This is the scope.

3. 🕵🏼‍♀️Challenge assumptions with evidence: How important is this feature really? Does it make strategic sense for us to include or is this an edge case? Is there additional context to this ask? Can we release first and then assess demand based on customer feedback and usage data? (We are working in iterative design after all.) What trade-offs are we willing to make if we are to commit to additional requirements?

Providing transparency and clarity around the project scope centred around the customer problem and target outcome helps you to identify things that shouldn’t be there (at least not now) and prioritise the requirements that really matter.

---

What’s next?

The insidious nature of scope creep means that it can sneak in at any time. Whether it's right at the beginning of the project or sometime in between, it's often tempting to add to existing requirements. I’ve been guilty of it as well, and sometimes it’s a simple case of someone else saying: “is that part really necessary? Why do you think that?”

oh no, there it is again!

While PMs get very touchy around the confusion with project managers, being able to manage projects is a key skill for every PM to master. The reality is that working with uncertainty, which we often do, does mean that requirements are not set in stone. 🗿

To become a reliable PM who consistently delivers value, you must learn to recognise and manage changes in requirements, with the expectations and impact that come with it

If this has resonated, I'd love to hear how you’ve been impacted by requirement changes and how you’ve learned to cope with them too.