Last week, we explored the differences between a Minimum Viable Product (MVP) and a Minimum Loveable Product (MLP). In looking at the two processes, an important distinction was made.
While it’s important to identify a core need that a product is providing, what are the elements that users can connect to and become a part of? What do they not only need, but what do they love?
In our strategy sessions, we try and identify this “x-factor” and represent it in the design, and what we call stretch features — elements of a product that may be above the bare bones of a core feature set. While these may be all great ideas, we need a way to validate the assumptions that we’re making about those potential love-connections with our users before we take too many expensive or sacrificial steps towards build-out.
In some instances, developers will take what they created in their strategy session and spend lots of time and money building that product that was born in a conference room (or let’s be honest, someone’s basement). Then, it’s released to users in a fairly mature form and feedback comes rushing in. However, when a product is released at a later stage in development, it becomes hard to discern which features or design elements are being reacted to and why. For example, consider if an author of a book only showed their editor their writing once the book was finished. There would have been many layers along the way that needed revising, story-lines that could use a nudge in a different direction, or a character gone undeveloped too early in the plot. Now, the final product is much more of a challenge to improve and transform. In the tech world, this is sometimes referred to as the Waterfall Method.
“Waterfall Method is a sequential (non-iterative) design process, used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, production/implementation and maintenance.”
An alternative to this clumsy approach exists, called Agile. Instead of spending months developing, testing, and releasing with fingers crossed, Agile focused on an improved way to navigate the software engineering process. It entails two-week sprints which are evaluated at the conclusion of each cycle. This proved to be much more fluid than a six month development schedule that the Waterfall Method demonstrated. It enabled the product to change every two weeks and evolve, but here’s the thing; things can change even in a 14-day period. Agile remains limiting as it locks in two weeks development sprints that can’t be altered before their cycle has finished. What happens if on day one you have a pivotal sales meeting or user feedback session and realize you need to change features? With Agile you would need to finish the sprint, only to pay again to remove or improve features. The six month window, reduced to 14 days, still showed signs of inefficiency; a true testament to just how “agile” new products have to be to stay ahead. This same concept is echoed in the Lean Startup method, which champions the use of an MVP and testing it often. While they got it right with the increased flexibility and frequency, the actual subject matter being tested remains potentially unhelpful and irrelevant to validating the right assumptions (we talked about that last week, check it out).
The approach we’ve seen proven successful time and again is Rapid Iteration. This is another way to reduce the cycle time from release to feedback, while gathering accurate and isolated insights from users. This method mimics Agile in aligning your company’s workflow–and the Lean Startup ideology in that it pushes for fast feedback loops. However, it takes things a step further by leaning into the “gut features”, or aspects of your product that you think will most support your MLP. It recognizes that there are things you will likely know, and focuses on testing the things you likely don’t know. Ultimately, Rapid Iteration gets us closer to quickly validating the things that are most important to us.
Here are some of our favorite reasons for using this method.
Spark that love (validate your MLP and add the right stretch features).
Let’s say that your product is gaining early loyal users who seem to love what you’ve released. Using Rapid Iteration, there is time to ask the question, “what element of this product is sparking that love?” When information like this is discovered, it allows you to do more of what seems to be spawning that connection to your users. It can inform which other stretch features could be added to strengthen your MLP. And that leads us to our next point…
Small steps mean small fixes.
We mentioned reducing the cycle time from release to feedback. Engaging with your users intermittently through the development process creates an opportunity for powerful edits, to powerful aspects of your product, on a small scale. You won’t have to go back and spend a considerable amount of time on reworking large portions of the development, or putting too much stress features that may not support your MLP. Gradual steps and frequent feedback keep you light on your feet, and ready to pivot the angle of your product fairly painlessly.
Connect with your users.
Rapid Iteration provides lots of opportunities to connect with your users and discover more about your MLP. By finding simple ways to engage with them, gather their feedback, and understand their experience with your product, you are building a relationship with them and learning what they love. You are listening in a way that will make it nearly impossible to avoid an end result that reflects their needs and desires. You are building a base of early loyal users; an incredibly important facet of building an impactful product.
Stay on message.
While Rapid Iteration supports frequent testing, it brings the focus to the most influential and special features. It is a way to validate assumptions ensuring that your product connects with those who you want to engage. In order to stay on message, pausing for this type of feedback on the features your gut is telling you are important, is essential.
Reduce waste (and spend less money).
We’re strong advocates for staying light on the budget in these early stages. We know lots of products that strive to do this; but where to save money is the commonly missing piece to this puzzle. It’s impossible to know which parts to stay lean on if you’re not gathering feedback along the way. Rapid Iteration reduces waste, and makes the dollars you are spending as worth-while as they can be.
Reducing waste and spending less money is so important to remember, especially early on in development. The financial decisions made during this initial period can make or break the rest of your project.
Tune in next week as we ask, Are you spending too much on your MVP?