I've seen countless projects fail before they even begin, and more often than not, the culprit is poor scoping. Projects where the scope is too large make it difficult to deliver meaningful value quickly, while projects where the scope is too narrow often fail to address the core problem effectively. The key to accurate scope is finding the middle ground that maximizes value while maintaining focus.
This article focuses on finding the right scope for your projects. It won’t go into detail on how to make trade-offs or the mechanics of refining scope. Instead, it will dive into what makes for good scope and how to evaluate if you’re correctly weighing the variables.
Scope = Value + Timeline
Scope defines the volume and depth of solutions that are to be built to achieve an outcome. Scope is not something you want to define in full upfront; instead, it is a range of acceptable solutions that is continuously refined until you’ve reached a deliverable.
At its core, scope is defined by two key questions:
What specific value are we trying to create?
How long/much is the business willing to invest into extracting this value?
These two questions anchor the entire process of determining scope. The Goldilocks zone for scope is the place where your solution extracted an outcome while staying within the business’ tolerated investment level. When we correctly answer these two questions we end up with projects that are likely to succeed. Over-scoped or under-scoped projects are often projects that fail to effectively answer one or both questions.
Value
Starting with value, value is the benefit to be gained for both the customer and the business as a result of pursuing the project. In other words, it’s the reason we’re doing the project.
One of the most important insights I've gained about value is that it’s easy to mistake function for value. The failure to understand this distinction can doom your project before it begins. Let me illustrate with a series of examples:
Example 1
Function: "I want to put water in a cup so I can drink it"
Value: "I want to feel hydrated"
Example 2
Function: "We need a messaging system with channels and direct messages"
Value: "Teams need to communicate effectively (whether that’s in a 1-to-1, 1-to-many or many-to-many setting) so that they can collaborate effectively"
Example 3
Function: "We need to display 20 different metrics with filtering options"
Value: "Analysts need to quickly gain insight into issues so that they can make data-driven decisions quickly"
This distinction might seem obvious, but it's crucial. When we focus on function, we lock ourselves into a specific solution. When we focus on value, we open ourselves to innovative approaches we might have otherwise missed.
Because scope is a range of acceptable options, we look for value to be precise in terms of benefit but ambiguous in terms of implementation, as this allows teams the freedom to explore solutions until they find the right one.
The first key to finding your project’s scope is ensuring that you are rock solid on the value you’re creating and that you’ve decoupled the function from the value as much as you can.
Timeline
Timeline is how long the business is willing to fund the value extraction. Every business has a patience threshold - even when they say, "Take as long as you need." they actually mean, “Take as long as you need within reason.” I try to convert this appetite level into a range of time explicitly. For example:
"We need it ASAP" = Days-3 weeks
"Take the time to do it right" = 1-2 months
"Whatever it takes" = 4 months maximum
While most people hate having timeline awareness, I’ve found that these constraints are net-helpful because they remove options and force you and the team to really focus on what is required to hit the goal and what is not.
Note: A timeline is not the same as a deadline; timelines are guidance, and deadlines are restrictions; thinking of timelines is a better mechanism for teams to process scoping decisions as deadlines overpower value; you would rather the two be seen as linked, but where necessary, value always beats timeline.
Value is the target, timeline is the appetite
While value provides you with a clear target, a timeline tells you how long you have to hit it. A team with clear value targets will often hit these targets but take far too long to do so, a team with timeline constraints will hit a timeline but miss its target, a team with both will find its way to a successful feature.
It is essential that a team understands the answer to these questions and is bought in. I’ve found that conflict during projects is often tied to a misalignment around these questions or a lack of explicit answers.
Finding scope in practice
You will find a more in-depth article about the process of refining scope here, but at a high level, this is how I go about this process:
I always start by translating my project goals into simple, high-level user stories that focus on value rather than implementation. I then work with others/leadership to understand the acceptable investment level and develop my sense of what that looks like in terms of timeframe and how flexible it is. This gives me a clear picture of what value we’re trying to create and how long we’ll have to get there.
I will then take that context and bring it to the team, explaining my reasoning and beliefs in the process. This sets up the foundation for team exploration of a potential solution, which usually follows a general path of:
Open ideation around identifying possible solution paths
Evaluation of options against value and time constraints
Picking the strongest starting point solution that delivers the core value
Exploring that starting pointing and developing it into a lo-fi solution that validates if the path is worth continuing
As we gain confidence that the path works, prioritizing the list of enhancements needed to achieve a release.
Fundamentally, the process of refining scope is focused on exploring paths and quickly and effectively identifying the best one. By doing this, you permit yourself and the team to make scoping decisions along the way as you gain more information as opposed to all upfront (which often leads you to bloating releases and then having to cut scope at the last mile). This incremental path allows your scope to gradually get narrower and narrower until you’re left with the ultimate vision of what your solution should be.
Find scope along the way, nail down scope at the end
It is my belief that scope should be finalized as late as possible while being defined as gradually as possible. In an ideal world you’re getting to 100% final scope at about 80-90% completion of the project. This allows you and the team to continue being flexible and making decisions about what matters late into the project.
Now this doesn’t mean you have defined scope and are cutting at the end, it means that you have options and are choosing which ones make sense within the release and which ones don’t. To achieve this outcome, here are some practical tips I've found valuable:
Always start smaller than you think you need to.
The smaller the starting point, the easier it is to move and make decisions, as there will be less tying you down. Always start in the order of most important and add along the way. It’s always easier to add scope than it is to remove it.
Add scope incrementally as you confirm progress.
Oftentimes, teams make decisions before needing to - this leads to bloat. Allow yourself the pain of needing something, as that pain is the clearest guide you’ll have for scope. Focus on making incremental decisions that expand the depth and volume of the solution as these decisions become necessities or forks in the road.
Never delete, just backlog and prioritize for follow-up releases
Teams will often fight tooth and nail for scope because they fear this is the only chance they’ll have to build it. Create a culture where each release is not an end but instead is a stepping stone, this will allow the team to make scope decisions more comfortably. Question every "must-have" feature against your value definition and keep a list of “nice-to-have” features for future releases.
Make scope decisions (and their stakes) shared across the team
The more the team feels responsible and empowered to achieve value within the timeline, the better the decision-making will be, and the easier it will be to find the right solution for your problem. As much as you can avoid being the sole individual responsible for scoping decisions.
Parting thoughts:
Managing scope is one of those things in product management that will never stop being a challenge, as each project has its own world of scoping decisions. While a framework can help you more consistently navigate this opportunity, be ready for each challenge to have its own unique quirks and necessities.
Over time, finding the Goldilocks zone for scope becomes more natural. The key is reminding yourself to always stay focused on value while maintaining the flexibility to adjust as you learn.