When to Cut Scope to Get a Product Out the Door

This blog post was first called “When to Cut Corners to Get a Product Out the Door,” but we thought that sounded bad, so we changed it to “When to Cut Scope to Get a Product Out the Door.”

At Shortcut, we believe that shipping iteratively is great. We also think it’s good to ship often. But with so much to do, and only 24 hours in each day, how can you make this happen?

Sometimes, it’s okay to cut corne– no, scope!

Read more: The Shortcut Way

When it’s Okay to Cut Scope

Ideally, sparingly. If you have to do it, make sure you take a very critical look at making sure the feature or product still delivers value. We highly recommend using your customers as research participants to make sure this is true.

• When you can maintain a minimum viable product, still deliver value, and still capitalize on the business opportunity

It’s okay to cut scope if, for example, a new feature will still deliver value, even if you have to cut the "nice to have features".

This often comes up when you have a deadline that your customers are aware of. For example: we have an event on X date and it will put the business at risk if we don't hit that date.

• When the cost of additional features/functionality outweighs the benefit of getting them built
  

It’s okay to cut scope when, for example, adding an extra feature will only be a small additional value to customers, but will be a large engineering effort.

• When you can ensure that "fast follow" work can be done
  

It's okay to cut scope to deliver value to customers sooner, but it's always a good idea to leave some space for "fast follow" or "cleanup" work post-launch.

As teams approach deadlines, it's inevitable that bugs or unforeseen issues will come up. It's important to leave space to clean those issues up so that you don’t compromise the overall quality of your product.

Read More: How to Prioritize Work When There’s So Much to Do

When it’s Not Okay to Cut Scope

Sometimes it’s just not a good idea - usually if you’re sacrificing value.

• When reducing scope means you are chipping away at the core value of the product/feature

It’s not okay to cut scope when it means you are no longer solving the problem you set out for your customers. This means that: If X functionality solves X problems, you cannot cut features that make it so that problem is no longer being solved.

• When you can't ensure that "fast follow" work can be done
  

Lots of people are optimistic that they can make time and space for "cleanup" post-launch, but the reality of the business is that you often want to move resources onto the next most important initiative.

So, we recommend underestimating the amount of "cleanup" time you think you will have post-release, and encourage leaning toward thinking you won't have enough time for follow-up work.

Read More: Use Product Analytics to Improve User Experience

Tips for Cutting Scope

• Be explicit

Be honest with yourself about the value each additional feature/functionality is delivering. Is that additional feature really adding additional value? If not, should it be cut?

• Spike!
  

Spike, spike, spike! Do your work ahead of time to know the true effort needed to deliver features so that it is easy (and reliable) to weigh the benefit of releasing the feature against the cost of building it.

Read More: Why Agile Product Management Works

Try Shortcut For Free

There are no shortcuts in life, except that there kind of are, because that’s what we named ourselves. Our name is Shortcut not because we believe in cutting corners, but because we believe in finding the best route from point A to point B - the most efficient track from idea to finished product to measuring its success.

Shortcut helps you cut through the chaos, noise, and confusion around ongoing work to help you get that work done faster and without becoming annoyed.

We provide a shortcut to getting work done.

Our goal is to be the single source of truth, single source of planning, and single source of conversation about ongoing work. A place where everyone can feel like a natural part of the development process without needing to be constantly prodded to check in on it. It’s a shortcut to collaboration. Try it for free.

‍