This post is a bit different from our usual content. Our goal is to explain the danger of scope creep when developing the first phase of a project, the Minimum Lovable Product (MLP). If you’re unfamiliar with an MLP, you can read about it here.

Scoping the MLP

Before starting development work for the first phase of a project, we scope the MLP and identify the core functionality it needs. We then go through a design process.

The Onset of Change Requests

Once development begins, we start receiving change requests. Clients are passionate about their products and eager to bring the best possible version to market. This enthusiasm often leads to new ideas and additional feature requests. Hence, the point of this post: stop adding features before you launch!

Adding features before gaining user feedback is like building a factory before designing the product you’re producing. 

The Cost of Adding Features

It makes sense in your head because you anticipate all these features will exist at some point. The issue is you don’t know how they’ll integrate.

Every feature you add incurs three costs:

1. Development
2. Removal
3. Redevelopment

A Hypothetical Example

Let’s consider a hypothetical event application where users can create and post events. For the MVP, we might scope that events require a name, description, location, and time.

Consider all the possible features you could add:

• Tickets and payments
• Event types
• Music event details like genre and artists
• End times
• Virtual event URLs
• Photo sharing post-event

The list is endless without limitations.

Suppose we add event types and genres for music events. It seems simple, just two drop-down menus. 

Then we launch and discover our app is being used for birthday party RSVPs. Unexpected, right? So, we want to remove the event type and genres.

Now, we have to change:

• The event creation form
• The event edit form
• Event details page
• Event lists
• The database

This is a conservative example. In most apps, hundreds of changes like these can exponentially increase development costs.

The Factory Analogy

We titled this post "Building the Factory Before the Product" because it helps to think of this physically. Imagine a factory with robots, pallets, welders, conveyor belts, etc. Buying these before the product is designed doesn’t make sense.

• You don’t know how big the factory should be
• You don’t know the electrical requirements
• You don’t know the layout
• You don’t know the equipment needed
• You don’t know the personnel needed to run it

In short, it’s an expensive lesson compared to building a prototype, gaining traction and validation, and then building the factory.

Instagram Case Study

Most people don’t know this, but before Instagram, the app was called Burbn. It was too confusing and didn’t gain traction. The team ended up redoing the entire app, focusing on three key features.

Here’s a quote from The Cold Start Problem:

"We wanted to focus on being really good at one thing. We saw mobile photos as an awesome opportunity to try out some new ideas. We spent one week prototyping a version that focused solely on photos. It was pretty awful. So we went back to creating a native version of Burbn. We actually got an entire version of Burbn done as an iPhone app, but it felt cluttered and overrun with features. It was really difficult to decide to start from scratch, but we went out on a limb and basically cut everything in the Burbn app except for its photo, comment, and like capabilities. What remained was Instagram. (We renamed it because we felt it better captured what you were doing—an instant telegram of sorts. It also sounded camera-y.)"

The Instagram team is remembered for an incredibly successful product and acquisition. We’re quick to forget they had to tear their entire app apart and go back to basics to get there.

In Closing

This post comes from a challenging project that experienced budget and time overruns due to adding and removing features that weren’t part of the original MLP scope.

It’s a reminder for us and our clients that no one is immune to scope creep, and over-engineering isn’t beneficial. Save yourself time and budget: stick to the required basic feature set, get user feedback, and then add features.

‍