There’s something special about the initial phases of a project. Stepping into the realm of endless possibilities, and picking a direction to push forward and turn an idea into something real.
This week I’ve been sketching in my notebook, working through a big list of potential features and functionality of the app.
The fun part is working out what is needed, what’s nice to have, and what could be a fun direction some time in the future when the app is being used by lots of people.
What’s a Minimum Viable Product?
If you spend anytime reading startup blogs, books or attending talks you’ll eventually come across the phrase Minimum Viable Product, or more commonly, MVP.
Originally coined by Frank Robinson, and made popular by Steve Blank and Eric Reis of the Lean Startup movement, it’s used to describe the first version of a product that doesn’t have all the bells and whistles of something fully matured and widely used.
MVP has become such a buzzword that it’s inevitably lost its original meaning, often being used to explain why a product is buggy or doesn’t work as expected.
In my experience the word Viable seems to be the word that causes most confusion, it’s a subjective term; should we build something that’s Viable for the product owner? Or for the developers? What about the customers? What’s Viable in their world? What’s Viable in yours?
An excerpt from Frank Robinson’s original definition:
The MVP is the right-sized product for your company and your customer. It is big enough to cause adoption, satisfaction and sales, but not so big as to be bloated and risky.
The key words here for me are “adoption, satisfaction and sales”; treating them equally is a good place to start. Getting to a product that customers can easily get on board with, satisfies them, and of course encourages them to pay for it, is the goal of any business in its infancy.
Henrik Kniberg, who has worked with Spotify, Lego, and Minecraft, has written a lot about understanding product development, and has a wonderful article breaking down the MVP, and explaining what it takes to build something to help you learn what the customer needs, and eventually to a successful, well used, profitable product.
He chooses to ditch the term MVP, choosing to refer to the steps needed to get to customer happiness & business success:
- Earliest Testable Product
- Earliest Usable Product
- Earliest Loveable Product
The key at each step is to maintain as high a level of quality and usability, without getting stuck in a loop of perfecting the product.
Getting to my Earliest Testable Product
Keeping past experiences of MVPs in mind, and Henrik's guidance, I’ve spent the past week sketching out the potential features that would make a testable first version of the app.
Starting with a long list of conceptual features and ideas that have been brewing since I first had the idea for this app back in 2007(!), I’ve managed to get down to a core set of functionality that I consider to be a testable product that meets the core aim of the product vision I set down in week 1.
I've also started sketching out customer flows & paths through the app, so that I can get a better idea of which steps & screens require further thought.
While I work through these steps, I make notes and write down questions that might need answering at some point. Rather than trying to answer everything now, I use the questions to prime my subconscious and let that work away while I’m focusing on other things.
Then my favourite part of designing a product begins: taking the ideas and workflows, I layout wireframes to flesh out the functionality of each step on the customer journey, keeping the definition of specific interaction points as low-resolution for as long as possible.
This week I’ll work through each of the steps in the customer journey and will write up more about my process of wireframing in the near future.