rss
imprimer retour
Build experiments not products
Case study

Build experiments not products

We are a young startup working on a digital product. This gives us a lot of advantages over the giants we compete with: we are agile, we are creative and we are efficient. We don’t give a shit about due process. We can discover something new and adapt to it faster than our competitors can schedule a meeting about it.

 

Our big weakness though is that we don’t have very deep pockets. So decisions to invest in new features are really important moments.

 

So how do we adapt to that reality? Over the last few years, the Lean Startup movement has changed the way startups look at what they do – sidebar: established organizations can also learn from this and apply it to some of the more innovative programs they are running.

 

> The main concepts are simple yet they change everything:

– First, a startup is not the small version of a big company; it’s an agile entity in search of a repeatable business model.

– Second, As long as you have not validated your business model, you are not in fact building a product; you are conducting experiments in order to validate (or invalidate) assumptions. Only validated assumptions can make it into the product.

 

 

You can almost think of it as trying to prevent features from making it in your product unless they prove themselves.

 

The reason why smart startups think this way is simple: If we designed and fully build our product and then missed the target… it’d probably be game over. So by building small experiments and learning in an iterative way, we validate market fit with every experiment cycle.

 

The lessons:

> It’s your false assumptions that will kill you, not your mistakes. Experimenting is the only way to unmask them. So ready, fire, aim.

>  Build your product only from validated learning.

 

A simple framework that you can use. But in the heat of the action, it’s easy to give in to the temptation of adding features. That’s why we have built a simple tool to keep ourselves honest.

 

Example:

 

> Name:

Risk Mitigation Behavior (human behaviors are hard to predict and so experiments are especially valuable).

 

> Goal(s):

To validate that given the right context and tools, employees will take risk mitigation initiatives instead of simply escalating (current cultural behavior we are trying to curb).

 

> What we need to validate this:

– Event: Workshop with selected employees.

– Feature that allows users to form a team

– Feature that allows a user to define a risk to the group

– etc

 

During the development of the experiment, we will regularly argue about whether or not we should add a feature (recent example: the ability to attach a file). The reflex is then to turn around to the experiment sheet and debate whether or not this feature helps us. If it doesn’t further the goal, it should be discarded.

 

Experiments fail often but deliver a lot of learning. So by insuring that each experiment is as cheap as possible, we are in fact reducing the cost of validated learning. We learn faster and cheaper.

 

THAT will lead to a stronger product and a stronger company.

 


Eric Bourget is cofounder and CEO of Insyders, a Montreal-based startup crafting a social platform that sits on top of enterprise social platforms (like SharePoint, SalesForce) and provides employees tools to self organize into teams in order to solve complex problems (basically any problem that requires insight and creativity to solve).

 

comments powered by Disqus