The purpose of this document is to provide a model for how to think about scope, and how to go about reducing the scope of a project. A common problem that every organization faces is scope creep (also known as “feature creep”). Scope creep is when, during the course of building something, complexity creeps in and the project ends up doing a lot more than you originally planned.

https://www.loom.com/share/f5761261782348c9b2512781e77475ee

Scope creep can manifest in many different ways, but it usually involves at least one of the following problems — though this is by no means an exhaustive list. We’ll go over each of these in their own sections below:

• Large Iterations: trying to do too many things in one release; related to feature creep
• Problem Definition: poorly defined problem statement, which often unintentionally leads to bikeshedding
• Definition of “Done”: poorly defined completion criteria, so you don’t know when the project is finished
• Unforeseen Complexity: something that’s discovered during the course of the project that turns out to be more complex than anticipated
• Surface Area Expansion: increasing the surface area of what needs to be built and supported going forward

In our own history, we’ve had several projects that suffered from scope creep. One project from 2022 was the eCommerce project, which was originally expected to be completed by April 2022, but wasn’t finished until November 2022 — and it took up nearly 10x the engineering resources we had originally budgeted for the project.

At some point, we did a re-assessment of the project to determine whether it was worth investing more into the project, and the document‣ is a great example of an engineer on our team taking a proactive approach to trying to constrain scope of a project that had already become much larger than anticipated.

Proactively finding ways to reduce scope (while achieving the intended objective) is an important leadership characteristic that we look for across the company, and it’s especially important in Product, Design, and Engineering.

Large Iterations

A large iteration is when one release has way too many features in it. A startup should aim to have a release at least once per week (earlier stage startups might be even more). It’s worth noting that shipping regularly is necessary but not sufficient for success — but it’s almost a guarantee that if you aren’t shipping, you’re going to fail.

https://twitter.com/paulg/status/1250061898671947777?lang=en

Also, the scope for features should be sufficiently small that they can be delivered within 1-2 weeks of engineering effort. A great book that touches on this topic is ‣, which if you haven’t read, I highly recommend it.

A bad iteration is one that takes several months to build with nothing delivered to users. The reason this is bad is that your feedback cycles are too slow, and it makes it much harder to learn and build what your customers want.

The way to solve this problem is to keep your iterations as small as possible and not use a “waterfall” approach of building something that is only useful at the very last step. You’ll hear us use the term “build skateboards” a lot in our Product org, which is in reference to the image below:

But keep in mind, that a skateboard needs to actually be functional! It’s possible to cut scope so much that the Minimum Viable Product (MVP) is more like “two wheels and a board” and not a skateboard, which is actually a worse experience than having nothing (hopefully we’re not stretching the metaphor too far here 😅).

Each iteration needs to be encapsulated and value-additive. It’s not worth doing incremental steps if the incremental step makes the experience worse.