Do The Least You Need To Succeed

One key to thriving in the digital landscape is doing the least you need to, in order to succeed. We spend a lot of time at Undercurrent thinking about adaption, experimentation and survivable risk, and most recently, we’ve been examining what the smallest unit for successful adaptation is. One thing we’ve been wrapping our minds around lately is the minimum viable product.

Companies that will succeed in digital are those that can adapt – not only respond to changing conditions, but respond to the pace of change necessary. Key to adaptation is a focus on experimentation, no matter what your innovation strategy is, and experimentation is made sustainable by identifying and pursuing survivable risks. As Tim Harford notes, successful businesses and industries are built on failure and fumble. “Trial and error is a tremendously powerful process for solving problems in a complex world,” he writes, a statement that is intuitively true, but which many have trouble embracing because they’re scared of failing big. But by identifying survivable risks– risks that won’t bankrupt the business, destroy the team, or decimate the market you’re playing in– and encouraging early failure, weak ideas can be weeded out and successful ideas brought to the surface to be copied and built upon.

One way to take survivable risks is to focus on developing the minimum viable product (MVP) – the smallest iteration of your idea possible to test the validity and viability of your idea. Anthony Panozzo has a great post discussing the value of the MVP and outlining some of the challenges in designing one. Panozzo notes a lot of what is discussed as minimum viable products in the software world really aren’t because they’re not designed specifically around learning anything. The key to the usefulness of an MVP is you can validate the risks with a new venture or idea and really learn from its potential success or failure. To that end, the design of your MVP should be purposeful and aim to:

1. Help you test risky assumptions
2. Enable you to collect as much validated learning as possible about your users with the least effort

An MVP can be a paper prototype or a Facebook survey just as easily as an actual product – anything that helps you test a hypothesis and provides you with meaningful feedback about the direction you’re taking. (We can discuss meaningful feedback another time. As Harford points out in Adapt, knowing when you’re failing is a difficult thing).

We can see a great example of this in the process Tim Malbon outlines in his discussion of the Picle launch at SXSW this year. Picle is a camera app that captures a short snippet of audio when it takes a picture as a way of capturing a snap of the moment, mood, timbre, and flavor of the moment when you took the picture. Malbon discusses the way the Made By Many team evolved two feature sets in designing the app – a launch set and a set they stored in the “Icebox.” The launch set was the set of features that would establish the core functionality of the app, and which would allow the team to work out whether the entire project was viable. These were the features that defined the minimum viable product. By focussing on a core set of features and building a minimum viable product, the team was able to quickly get something out the door and establish a feedback loop with their users. Moreover, by staying lean, in their own words, by “deliberately building less” they were better poised for change once they got a sense of what was viable. As Malbon points out, “The leaner you are the easier it is to change.”

As we noted earlier, building an MVP is a process designed to allow you to put something out in the world and collect meaningful feedback about it. Panozzo outlines a few key questions to guide your design and maximize your learnings in developing an MVP, and they’re worth repeating here. If you set out to build an MVP, use these questions to guide your design and maximize your learnings:

1.  What are you trying to learn with this particular MVP?
2.  What data are you collecting about your experiment?
3.  What determines the success or failure of the experiment? (see his post here).

Thinking about the minimum viable product is “walk before you can run” thinking. Make sure you can do something before you head out into the world to try and do everything. By forcing yourself to think about what the smallest functional unit is of the thing you’re trying to build you’re automatically positioning yourself to adopt one of our favorite things: a bias for action. You’ll find the resolve, time, energy and resources to get something built by focussing on identifying the smallest, lightest most-minimum version of your grand wonder.

This post was co-authored by Joanna Beltowska.