A prototype can often be seen as an artefact, as something we deliver to check off an item on the project to-do list. To me, prototyping is a mentality — a way of approaching assumptions and clarifying doubts.
If you were to consider a scenario in everyday life where you were asked to hand over a large amount of cash in exchange for an unbuilt product, you’d likely be reluctant, no? This is exactly what I did 10 years ago when I bought my first house. I had secured a significant amount of money from the bank for a house which was not even built yet. Why?
You see, I probably would not have done so completely blind of the product that I was going to buy. Luckily, the house builders had already constructed their show home for the type of home that I was looking to buy. I was able to walk in and see the rooms. I could touch the walls and begin to imagine the spaces and how I might fill them. Granted this was not the house I was buying, but it had enough features and details to help me make the decision. This is exactly what a prototype should do.
“If a picture is worth 1000 words, a prototype is worth 1000 meetings.”
— Tom & David Kelley
What exactly is an MVP?
By definition, an MVP is a Minimum Viable Product. As Eric Ries, author of Lean Startup proposes: an MVP is “[the] version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort”.
From this statement alone, we can quickly understand that there is a distinct correlation between effort and learning.
Simply put, the more effort we put into something, we expect to learn more from it. Of course, simply putting a lot of innefficient effort into something will not yield the fruits of learning that you would hope for, so that effort has to be calculated and impactful. It’s not just a matter of spending more time on something to learn more.
Swapping products for assumptions
A while back, when I worked at Skycanner, one of the Product Owners, Rik Higham wrote an article on Hacker Noon titled: The MVP is dead. Long live the RAT. In my opinion, the strongest summations of this concept is:
A Riskiest Assumption Test is explicit. There is no need to build more than what’s required to test your largest unknown. No expectation of perfect code or design. No danger it will prematurely become a product.
With this in mind, you could almost argue that following the RAT, the plot on our graph above would be inverted and would instead look something like this:
As highlighted in Rik’s article, the MVP assumes a product. It sets the expectation that something needs to be made in order to test it. This may be true of some solutions, but not for all. Restructuring the way we think to adopt a RAT state-of-mind may reveal that a simple survey or short data list may be more than sufficient. Allowing you to summise whether or not you should proceed with your plans and, may in turn, unearth new assumptions which you should consider testing.
The ultimate goal here would be to look at the yellow curve above as the risk in the project. With intention and a little extra time, you can reduce a (potentially) significant risk into something far lower— for an external client or an internal budget.
Where to start?
There is no single way to test your riskiest assumption. I won’t promise this will be the silver bullet to all your potential pitfalls, but one concrete piece of advice that I can give is to stop. Yes, just stop. As soon as an idea or problem is raised, acknowledge it’s receipt, pause and then start asking questions.
Do not reach for the sketch book or open the lid to your laptop, as tempting as that can be. Really try to understand what the problem is, who are we proposing to design a solution for and what are all of the assumptions that come with this? Only once that is clear, do you want to start thinking about how to test those assumptions — keeping in mind that it still may not mean that you need to create a design.
I have to admit, I’m also guilty of running off in eagerness to get started, but challenge yourself next time a brief is handed in your direction to take that pause and start asking questions.