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:

  1. Explore the market and interest in your product
  2. 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?