Building an MVP: How to reconcile Breadth vs Depth

Note: This is inspired from an internal memo I wrote to the team to build a prioritization framework for the launch of our product, Maige. Hope you find it relatable. As always, this is a work in progress, so feel free to email us with feedback.

What is breadth?

• Breadth is a measure of how wide an effort is, what areas does it cover.
• For example, the number of pages in an app e.g: /home, /settings or number of features on a page e.g: create team, add projects, invite collaborators, handle permissions, etc. all can be used to measure breadth.
• In other words, breadth is quantity.
• It is a horizontal vector, think of it like the crown of a tree.

What is depth?

• Depth is the entire layers a feature or page interacts with.
• For example, a sign in feature has a User Interface (UI), database, session, cookies, etc. All these layers form the depth.
• In other words, depth is quality.
• It is a vertical vector, think of it as the stem or roots of a tree.

Building a Minimum Viable Product (MVP)

Context

In the past, I thought building an MVP was a combination of finding balance between breadth and depth to meet an accelerated timeline.

However, I think this is the wrong approach.

This approach leads to mediocre software with tonnes of tech debt, which leads to frustration, leading to slow software cycles, and eventually low motivation to continue building.

Our project, Neat, is a great example of this. It became increasingly hard to add features to the app because it had decent breadth, but poor depth. In a world where software is becoming increasingly easy to make, it's more important than ever to deliver killer User Experience (UX), and good UX requires solid depth.

A better approach

I think the better approach is compromising on breadth to meet an accelerated timeline, but never compromising on depth. Let me explain.

If we want to ship a new software by some date, we should cut down the number of pages, and features to the extent that we can deliver impeccable quality on each feature and page.

We should never compromise on tech decisions or choose the easier/faster option. We should always default to the "right" way even if it takes longer. If we want to move quickly, we should compromise on the quantity by cutting down the number of pages or features.

However, i understand the issue here: how deep can we really go? How deep is too deep?

How deep should you go?

To determine how deep is too deep, I think it's based on instinct.

Ask yourself: what's the best possible way to build feature X? What's the app that does this feature best? How can I build it to this quality? And then you execute to that standard.

This also needs to be guided by solid engineering principles that the entire team needs to have alignment on.

For example, this Supabase doc has some really good principles that have allowed hundreds of devs to contribute to the software without compromising on quality.

Some of my personal favourite principles are:

• be as granular as possible
• always be portable
• always be extensible

etc.

The discussion around best engineering principles is a conversation for another time, perhaps even a blog post. But even using a certain way to organize your UI components and pages, using a specific ORM (e.g Prisma), our own ESLint extension, specifying a type of relational database schema that works really well, is allowing us to build instincts and standards around depth.

Recap

To recap, MVPs are optimized for speed, however, speed should never compromise depth, only breadth.

It's clear to me, that if we had one brilliantly executed page or feature, it would be easier for us to test, iterate, and improve. We would have really good foundation.

A secondary benefit of this approach is critically evaluating which feature/page is most important to build first. This allows us to think through our ideas a lot clearly.