7 signs of scope bloat I no longer ignore
You sat at your desk for hours.
You got it all figured out: this epic is your masterpiece.
You hand it over to your team as if it were a gift from the gods.
No. Even better. A gift from you.
As your team reads your PRD and user stories, you turn around and slowly walk towards the sunset. "Enjoy this one, everyone", you say.
But wait.
In the distance, you hear a faint voice. What was that? A question about this epic? "Sure", you smile, "I can clarify a few bits for you".
Two hours pass by. You wipe a drop of sweat off your brow. It has been intense. Questions haven't stopped. You're parched, lightheaded, and looking for an exit (or a rock to hide under). Please make it stop.
You've done it again. You've gone too far. You've over-extended the requirements. This epic is massive and the devs are (rightly) questioning the reason behind some of these crazy acceptance criteria.
Time to painfully backtrack, reduce the scope, and perform some fly-by-the-seat-of-your-pants product management.
These are 7 scope bloat red flags I keep an eye out for.
I can't rationalise a requirement using the trifecta: margin, retention, or growth.
If my requirement doesn't contribute to any of the three, I take a second look at it.
My dev lead estimates 2+ weeks to ship a prototype.
The more I work in product, the stronger proponent I become for fast prototyping. Getting to a working prototype is my priority number one on any project. With AI, getting to a prototype should get exponentially faster, too. No excuses:
If I'm told it'll take >2 weeks to get to a clickable prototype, I reconsider the requirements.
I have too many requirements.
Simple.
If I find myself typing requirement after requirement, something's probably gone wrong. I'm likely over-engineering the project and likely doing so because there's just too much.
Cut back and phase it out.
I have parallel requirements for a similar goal.
I've experienced this a few times recently.
Let's imagine the project is to create a signup page. One of my (obvious) goals is to let users sign up. Under this goal, I have two requirements:
Users must be able to sign up with email & password.
Users must be able to sign up with Microsoft OAuth.
This is what I call parallel requirements. They both achieve the same goal (signing up).
I started noticing these recently and cutting them down. Can we start with one way of signing up and see if another is needed later? Can we support importing Word documents and see if we need to support PDFs later?
My requirements are interdependent.
This is typically a red flag for two reasons:
If requirement #2 relies on requirement #1 to be completed, I'm introducing risk to the project. If we can't complete #1 we can't complete #2.
At the time of writing these requirements, we haven't solved requirement #1 yet. How can I know we'll need requirement #2?
The most common ways this creeps up are with automation, design, and cross-functionality.
My only justification for a requirement is "I thought it might be cool to..."
We're not here to do 'cool stuff'. We're here to create a useful product for customers and return value to the business.
The obvious caveat is, sure, sometimes we get to do cool stuff. But that can't be the only justification (and it should be rare regardless).
I have a gut feeling.
I have enough experience now to 'know' when I'm bloating the scope of my projects. I might even feel a knot in my stomach as I say the requirements out loud.
That's a yikes for me dawg. Cut it.
How to prevent scope bloat:
Ideally, we don't hand over an over-engineered, extended, insane project to a bunch of angry devs. We can do better by:
Keeping ourselves in check. As you prepare your projects, consider the red flags above.
Follow The Algorithm. I love this. I'll write a separate post about this one day.
Don't be afraid to re-do it. We all make mistakes. Your projects/scopes/epics are not set in stone. I recently cut one of my projects in half midway through it. I've cut scopes out of projects on week 5 of a 6-week cycle before. It's ok. Most decisions are two-way doors.