10 Features your MVP Doesn’t Need: if it is an MVP.

TLDR:

• Know your different minimum layers: walking skeleton, MVP, MMP and MDP.
• MVPs are primarily for validation; time is of the essence.
• To place an order, users do not also need to be able to view past orders; as one example.
  ‍

MVP is about validating an idea.

And the sooner you can do this, the better.

If you’re building a genuine MVP (and there is a good chance you’re not), all the ballast needs to go.

Conclusion: Some features might seem necessary. They’re not. Here is my top 10 to drop.
‍

The many layers of ‘Minimum’

The original definition of MVP actually left it open for interpretation: do whatever is minimally satisfactory for the business and its primary users and no more.

Which does mean the definition of MVP is open for interpretation and that is pretty much where most people land.

Whilst one person's MVP might be different to another, describing them all as MVP is not necessarily correct. (Not that I want to get held up on that debate or am the right person to facilitate it.)

Instead, let's look at the sliding definition of 'MVP' as layers of 'minimum' so that for purposes of this article, we're agreed on what many regard as true 'MVP':

‍

• Walking Skeleton: if I had spent Saturday evening writing a scrappy Chrome extension that scrapped content for a personal project, arguably, I could share that walking skeleton without too much concern about blow-back. Any nibbles, and I might keep developing it…
• Minimum Viable Product: if I wanted to validate an idea, I’d go further than the walking skeleton. I’d need enough meat and thinking on the bone so people could understand and engage with my idea. No more, no less. The insight would then validate the idea (or kill it off) and instruct where to go from here. (Note: this is a new idea to validate with no established user base).
• Minimum Marketable Product: in my experience, this is realistically where most of my clients land with a new or relaunched product. The risk appetite is lower, expectations (both internally and by users) are higher and as long as time-to-market remains the focus and decisions are objective, this is a reasonable target for ‘Minimum’.
• Minimum Delightful Product: where Sonos should have landed: feature-for-feature parity, excellent and tested UX and ready to rock and roll.
  ‍

For this article, I am sticking to Minimum Viable Product. Rightly or wrongly.

My goal is to validate as quickly as possible.

The 10 features MVP doesn’t need

In no uncertain order.

1. Complex authentication system

Don’t build your authentication system, even post MVP (probably).

You will never be able to do it better than existing, off-the-shelf solutions:

• Social sign-in (such as Sign-in with Google)

• Biometric authentication.

Usernames and passwords are on the way out, and investing in such a solution - even with 2FA - is both a waste of money and an unacceptable risk.

I recently analyzed the different and popular sign-in strategies, and if this is where you are at, it’s worth reading.

2. Custom admin dashboards

Data is critical, though most CMSs or existing libraries will suffice for MVP.

At some point, you should start exploring tools like Looker Studio or Tableau, though not at the expense of your MVP.

They’re not needed to validate.

3. Multiple payment options

The answer here is not that you won’t necessarily need multiple payment options.

Apple Pay on mobile sites is outstanding. PayPal has a role in many circumstances.

However, start somewhere and not everywhere.

A basic implementation of payment providers such Stripe or PayPal is the fastest way to get off the ground.

4. Localisations

We all dream of a multi-country app or service, though launch in one place, in one language.

You’re here to validate, not scale.

5. SSR

SSR (Server Side Rendering) comes with plenty of benefits in plenty of circumstances:

• Faster load times.
• Improved SEO.
• Enhances security.
• Enhances user experience.
• Better for low-bandwidth situations.

Whilst it isn’t an easy retrograde, it doesn’t make the MVP cut unless your app specifically needs SSR.

You don’t have time.

6. Documentation

I’ve written about the folly of extensive upfront documentation a few times.

• It takes up time.
• Nobody reads it.
• It will be quickly redundant.

Aligning the team with the vision and goals of your MVP is essential, and this can be done with a one-pager.

If you have any more than this, you have too much documentation.

7. PWA

Progressive Web Apps are cool. They allow us to make websites that perform like apps in a browser.

Spotify is a great example.

• Better user experience.
• Improved engagement.
• Lower bounce rate.
• The ability to offer offline functionality.
• Faster load time.
• Adaptive design

If you have a hunch your website is going down that path, plan for it.

However, don’t build for it in the MVP.

8. AI Bots

I am increasingly sold on the application of AI in certain circumstances, though an AI bot isn't an MVP inclusion unless it is central to your business.

And whilst I am increasingly loving the application of AI for particular applications - something I am writing another article on - I am so far from being convinced that AI Chatbots are useful or wanted by anyone to think they should ever be included.

Nobody likes them; nobody wants them.

9. Automations

You don’t need automation and workflows in an MVP.

Emails, messages, notifications, orders, data collection… this can all be done manually.

10. No invoice or order page

I’ve never not purchased something because a website or product didn’t have an order page listing out invoices.

Super frustrating when I need an invoice, though all your MVP needs is an email address where users can request an invoice be emailed.

Four must-have features in an MVP

This is open to debate, though in my experience:

1. Email collection

The power of email never ceases to amaze me, and collecting emails with marketing consent is just a 101.

2. Analytics/User Feedback

I probably don’t need to say it, though the point of an MVP is to gather insight.

It kills me when I see poorly configured analytics that cannot accurately be attributed.

This is critical.

What insight do you have if you can’t measure cause and effect?

Going the extra mile and gaining some qualitative insight from users is also enormously beneficial.

3. The working functionality your product is seeking to solve: not a waitlist page

Building a ‘Waitlist’ page to collect early bird emails is fine, though it does not validate what you need to validate.

It’s just telling you that people might be interested in your idea.

Your MVP is where you ship the functionality that sufficiently solves the problem you’re seeking to solve.

4. Basic Legals

I had a good debate with a colleague, who believed that a true MVP didn’t need basic legal documents like terms and conditions.

That is strictly true.

However, tools such as Google Ads, SSO auth-type stuff, and Stripe (and other payment providers) will require such pages/legal to be in place. A catch 22.

(Obviously*, as an MVP you’ll pilfer them from a comparable product or website and get your most legal mate to run through them: though you still need basic legals! 🥴)

* General advice only!

‍