Our industry has gotten into the habit of “move fast and break things”. The Minimum Viable Product (MVP) is a manifestation of that - when getting an MVP out the door, it’s all about speed and iteration. It’s hardly ever about creating a product that users love. Despite the fact that we make product purchasing decisions with the same part of our brains that help us fall in love. As a consequence, shipping MVPs that are just “good enough” oftentimes turns them into Minimum Viable Problems. To avoid this, ship Minimum Lovable Products (MLPs) instead.

What we know about relationships also holds true for products. Where there’s soul and character, there’s also trust. If we are able to create a product where we give people the feeling of commitment, they give it back. And the more fun people have with a product, the more engaged they are. We’ve forgotten that fun is not the enemy of software products – even in the enterprise.

On the flip side, if you ship an initial experience your users can’t fall in love with, you won’t be able to collect proper data and the feedback you receive is mostly related to feature request. This quickly turns from a Minimum Viable Problem into a Messy Mountain MVP - a product that consists of a lot of features with very little ability to spark emotions in your users.

Words matter – a lot of the issues with the MVP come down to the word viable. It means good enough. And it’s hard to fall in love with good enough.

Instead, approach getting your V1, its user experience and its features out the door the same way you would throw a house party (or how you’ve tried to throw one back in the day). There should be a long line at the door to get in. Some guests will give you a quality party. Some will ruin it by being there. And a few will get the cops called on you. You need to figure out who gets in and at what speed so that everyone inside has a great time throughout the entire night and the party isn’t ended by the cops.

When building a product for people to fall in love with, ask yourself the following:

• It all starts with the team - is everyone aware that they’re responsible for impacting the user’s experience in a way that makes users fall in love with your product?
• Are you and everyone else involved focused and clear in your scope?
• And within that scope, are you compromising on fundamentals around how you build product for the sake of creating new features? Some of Stark’s fundamentals regarding product building include “Make them fall in love - opinionated products create fans”, “experience-driven and data-informed” and “scope small, ship fast, iterate often”

How Cat and Stark do this in practice:

• Hiring: Stark is laser focused on hiring "A" players that understand “Lovable Products” – taste is something you cannot train and ultimately, a product is a reflection of who creates it.
• Shared understanding: The (fully remote) Stark team hyper communicates and has established the shared understanding that they will never ship anything where the interactions don’t feel right / something looks off. Or in their own words: “We don’t ship shit”.
• Community: Their community is a big part of what makes Stark stand out and is reflected in their product. In cultivating their community and engaging with the members in (fun, supportive, and constructive) regular discussions, they receive useful and actionable feedback and insights that help them inform their beloved product. It’s a joint vested interest.

Thank you for sharing this insight Cat!

‍

-------

‍👋 - Looking For Pre-Seed Funding?

At focal, we lead pre-seed rounds backing software / platform / infrastructure builders across the 🇺🇸 / 🇨🇦 reinventing how industries operate and business is done.