🔄 Reverse Prototype

Simplification through reduction by highlighting what a category is not.

If you're starting with nothing, and designing your first product, you'd likely start by asking what the necessary features were to deliver value (and your vision).

This process is often named an MVP (minimal viable product).

A reverse prototype is a method of reaching this same MVP, but starting with a live product and removing unnecessary functionality.


You may wonder why (and when) this would be necessary, so let's give a few examples:

  • You've been building a product for a growing audience, but over time have built many features that you're not convinced are valuable to every user. You may aim for a niche-specific MVP.

  • Your product has been built over decades, as users, tastes, industry best-practice, technology and context has changed. You now no longer know what's necessary, and what people just are used to having.

  • You're trying to paywall specific features, but aren't sure what's necessary for 'core value', and what are paid 'nice-to-haves'.

✅Churn

  • By reducing complexity, you may also reduce frustration and confusion, thereby reducing churn.

  • It is also possible that by removing features, you increase churn, as some users no longer feel that it's sufficient for their workflow.

✅Feature usage

  • Clearly, adding or removing features will have a direct and indirect impact on what your users do.

  • The remaining features will likely see more attention.

✅Productivity & efficiency

  • By making your product simpler, people may be more efficient.

  • e.g., after removing unnecessary (and unused) functionality in a dashboard, it'll be easier to use what remains.

✅Perception of value

  • People don't like paying for features that they don't use, it can distort the perception of value.

  • "Ah, the subscription is $100, but I only need 3 of the features, I don't want to overpay for the rest".

✅Complexity & understanding

A good start is to theorise which features are no longer necessary, but you'll still get confusing feedback from both users, and internal teams:

  • "We spent 12 months building that feature, we can't remove it"

  • "This feels like a step backwards"

  • "Why would we remove that, it's only one button, it's not in the way"

The real test requires data.

If you remove this feature, does anybody miss it? Or rather; what impact did it have on broad usage? Is that a positive change?

A reverse prototype is aiming to tip over "too far", it's only by tipping too far, that you can work out what really was necessary.