Lean prototypes: all different and yet the same
There are tons of lean startup experiment and prototyping methods described online. In my opinion they all boil down to (almost) same goals.
Prototyping something is always done with a purpose. Mainly it is about learning something new about the business/customers/market/product. Think of it as a business experiment from which you can learn and improve your service idea or offering.
Building prototypes isn’t just for the design or user testing phase. You can use this technique to quickly and cheaply roll out, *khm*, ‘roll-out’ new features and gather necessary feedback.
Prototyping = experimenting, learning, getting conclusions
Before you prototype
Before you start setting up an experiment, make sure you have the basics clear. Know why you are prototyping and what you want to get out of this. A one of my mentors said:
There is no such thing as a failed experiment. An experiment fails if you did not learn anything from it.
So remember to have your test hypothesis, measurement methods and criteria for success clear. You can use this handy sheet to keep an overview of your preparations.
As with a lot of things in life, prototyping your features isn’t a rocket science. There are many articles online describing specific methods (links at the end), but in my opinion, all of them can be slightly different depending on how general or detailed the feedback is that you need:
- Explore the market and interest in your product
- Quickly implement features to imitate the intended functionality
Both of these (and thus of all prototyping methods) have a goal if validating your assumptions about the market and the users. The only difference is that the first category requires a bit less work and detail to the prototype.
Explore the market and interest in your product
This is an inquiry to find out the scale of interest in your product.
Tests which fall into this category:
- With Dry wallet you keep track of the people purchasing your product, but on the last step show ‘out of stock’
- Create a Fake button for subscribing/activating/purchasing a product and see how many times it is clicked
- Smoke screen is a landing page with a Fake button (see above) to check if and how many people subscribe
- Let people Pre-order your product to see if you get sufficient interest. Kickstarter makes a good use of this method
- Be a Concierge for your customer by delivering the service in-person and with pen and paper
- Resort to a Video-explainer if you have a complex product that you cannot explain easily through a landing page or text, and watch for reaction
The purpose: check the reaction and interest of potential users. In terms of time, there is a sweet spot regarding when doing such tests has the most impact. Ideally, the you should do this before actually developing your product, but after the value to the user and the business proposition is defined. This way you have your message and product idea crystallized so that you can tell a good story about it, yet you have not invested yet into building it.
Which risks it helps to avoid: Developing the ‘wrong’ product, investing time in assumptions that were not validated yet. This all boils down to not losing time and money.
What you can test with it: Is there an interest from the customer? How big is it? Is the interest strong enough to risk the investment? Which type of customer interacts the most with the product?
Quickly implement features to imitate the intended functionality
There are multiple methods, all targeted to slightly different situations:
- Pretend the service/product is there without really building it with Imposter judo(example: burger delivery for when you are at a concert? Repackage and resell (existing brand) burgers to cut costs)
- Organize a Wizard of Oz service by having people perform the software tasks at the back-end (different from Concierge)
- Mechanical turk method does pretty much the same as above
The purpose: Ultimately, the goal of prototyping functionality is again to get a market feedback on specific details and processes and learn from it. When compared to the other category, this type of prototypes goes deeper than just surveying interest, but rather checking if the value is delivered through the right means.
What risks it helps to avoid: By 'faking' the algorithms amd imitating the workings of the real code you can focus on getting a sharper view on which specific features add more value, adjust your service on-the-go and see if it gets a better response that way.
It can help you fine-tune the background processes, discover hurdles or questions that your customers might have when using your product, or simply launch a feature before your competitor does
What you can test with these methods: Is this the fastest way that the customer gets the results? Which questions and when in the process did the customers have? Does this solution solve the problem of the user? How can the process flow be improved?
Whatever method you choose, what matters is that you can learn or discover what you wanted to with it. It is quite possible that in some cases methods from one category can be used to test something what would fit another one better — this is not a hard science. You know best what kind of experiment/prototype suits your goals better, no matter what specific name it tends to go by nowadays.
Because we are ‘just’ entrepreneurs and not trained scientists, 10 concrete examples of experiment designblog.next.amsterdam
There are many techniques to consider when designing an effective lean startup experiment, so we decided to capture a…www.movestheneedle.com
In the last post I talked about the importance of validated learning. Trying to validate your way to a working…blog.next.amsterdam