Minimum Viable Feature: 4 reasons why you should scope down

Minimum Viable Feature: 4 reasons why you should scope down

The best in product are ruthless at scoping things down.
Rather than thinking of everything they can cram into a project, they focus on what they can zap away. They design the Minimum Viable Feature.

"A journey of a thousand miles begins with a single step" - Laozi

This can be confusing for those new to product. Why water down your epic vision? Isn't great work supposed to be ambitious and bold? Shapeup (Basecamp's latest book on software development) describes this mindset:

"We made the mistake in the past of kicking off a “Files 2.0” project without really considering what that meant. Our excitement about improving a huge part of our app got the better of us. We know there were a lot of problems with our Files feature, but we didn’t ask ourselves what specifically we were going to do. The project turned out to be a mess because we didn’t know what “done” looked like. We recovered by splitting the project into smaller projects, like “Better file previews” and “Custom folder colors.”

A while ago I coached a PM that did the same. I reviewed his pitch and noticed his problem statement was too broad. To help him cut down scope I asked: "If you would have half the time, what would you focus on?" And while he was keen to learn, he shared his discomfort: "If we know what we need to do, why not just do it? Why make this project small?"

I told him there are 4 reasons why one should scope down.

1. It helps to prioritize what's important

When I joined my current job I inherited a project for a new onboarding flow. Stakeholders had many ideas and there was a big vision. After some digging, I suspected not everything in this vision was equally valuable. How was I going to break the news? I did not want to get sucked into a debate about the value of (arguably good) ideas. To circumvent this I decided to split the project into 6 smaller pieces (which I ranked):

  1. Ask users for their learning interests
  2. Ask users for their preferred languages
  3. Ask users for their preferred learning length
  4. An exit screen to contain the existing welcome video
  5. A welcome screen
  6. A progress indicator for the steps in the flow

Splitting allowed me to prioritize 1 & 2. On top of this, before we arrived at 3 I presented a more valuable project. And the rest is history, literally. Because we decided to skip the rest. Would this switch in focus have happened if this project was bundled? Maybe. But by explicitly exposing the smaller pieces of the whole, it became unavoidable. The lesson is that scoping down helps to prioritize what's important.

2. Easier to start

When you try to do something big, it's risky. You change the product in a large way and it's a serious commitment of time. This means that the bigger the project, the more you need to get everybody on board.

Now split that project into small pieces, and it becomes easy to agree. People care less about being involved in a series of small decisions than in a single large one (even though it amounts to the same). I don't understand why, but that's how it works.

So the next time you are stuck, ask: "What is the smaller thing I can do right now?" You might find it's easier to get started.

3. More attention to detail

Work on something big, like designing a house, and there's a lot to consider. It’s easy to miss something. Now focus on the choice of kitchen cabinets and its simpler. There are fewer variables to juggle in your head. This works for everybody involved.

It’s like zooming in. Make something small and the details get more attention than they would before.

4. Ship faster, learn faster, win faster

Shipping faster is not only great for users, it speeds up the feedback loop between your ideas and reality. You increase your pace of learning, and this is massive. Between project (A) that takes 3 months, or (B) the same project cut up in 3 smaller pieces of a month, I will always choose the latter. Because while project A will still be underway, B is already partially done and teaching you what works. Where A remains static, when you finally complete B it's likely to have changed for the better. Make things smaller, and you will learn faster.

On top of this, where a big project seems to slog on forever. Faster wins feel better. They give you that energizing momentum so that you can keep on shipping awesome stuff to users. And isn't that what product is all about?

So when should you stop?

Stop scoping down when there is nothing left to take away before your project loses its essential value. What's left is the minimum change required for the most value. The Minimum Viable Feature.

"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." - Antoine de Saint-Exupéry

What the MVF is, depends on the project and your judgment. However, as the natural tendency is to make projects too large, I recommend erring on the side of going too small. It's hard to go wrong this way.

Summing it all up

The best in product are ruthless at scoping down to the Minimum Viable Feature. This often feels counter-intuitive. There are 4 reasons to scope down anyway:

  1. It helps to prioritize what's important
  2. Easier to start
  3. More attention to detail
  4. Ship faster, learn faster, win faster

Stop scoping down when there is nothing left to take away before your project loses its essential value. It's natural to keep it big, so err on the side of small.

And that's it. The 4 reasons why you should scope down.
How can you apply this today?