The pressure to get your product to market early is ever-present. Your team, key stakeholders and investors will want something to show for all the hard work and funding.
So, you start telling yourself, "It won't be that bad. Faster to market means better, right? If I release it now, I can always come back and fix bugs or adjust features to suit what users want."
You could, but you probably won't.
Releasing your product too early – potentially incomplete or buggy – is a recipe for running your product aground. You might not notice it immediately, but eventually, it will erode your users' trust in your product. And trust is tough to get back.
The drive to release early is often done under the guise of "it's just an MVP". But don't be fooled – this is a commonly misunderstood or misused term.
According to Eric Ries, pioneer of the Lean Startup movement, "...the minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.
A true MVP is the smallest version of your product that still provides value to your users. It should include the fundamental features users need to solve their problems, be usable and reliable, and have considered design elements.
A model proposed by designer Jussi Pasanen (see below) illustrates a great way to think about an MVP. Don't just concentrate on building the functionality first and wait for future iterations of your product to make it reliable, usable and enjoyable. Ensure that every feature release also gives your users enough value, a level of reliability to earn their trust, and is usable enough that they aren't frustrated. Pasanen advises building a slice across the pyramid each time rather than starting from the bottom.
Unfortunately, many product teams misunderstand or misuse the MVP principle and instead opt for a 'ship fast, fix later' approach to get products up and running quickly. This often results in a basic, incomplete, or buggy user experience, leaving users (your customers) frustrated and looking for alternative solutions.
Such approaches are more suited to closed betas or community-sourced projects. In these contexts, users are likely to be more understanding if quality is lacking.
So, how do you know if your product is, in fact, ready to ship?
Make sure you have thought through answers to these critical questions:
- Who are your primary user groups for the product?
- Does your product satisfy the core needs of these primary user groups?
- Has it been tested by a cross-section of your key target market(s)?
- Does your product contain known bugs that might stop users from completing core tasks or leave them with a frustrating experience?
- Have you provided a mechanism for users to provide feedback? And do you have a strategy to triage and respond to this feedback once you receive it?
- Have you decided which product metrics to measure to know if your users find your product valuable?
Ultimately, a high-quality product should meet the core needs of its users, whether that means helping them purchase tickets, find the nearest restaurant, or transfer money to a friend or loved one. It's worth the wait if it means they'll keep coming back for more.