When companies become larger they inevitably lose the capacity for innovation, creativity and growth.
Start up teams require three structural attributes: scarce but secure resources, independent authority to develop their business, and a personal stake in the outcome.
Start up’s are both easier and more demanding to run than traditional divisions: they require much less capital overall, but that capital must be absolutely secure from tampering.
Start up teams need complete autonomy to develop and market new products within their limited mandate. They have to be able to conceive and execute experiments without having to gain an excessive number of approvals.
Start up teams have to be able to build and ship actual functioning products and service, not just prototypes. Handoffs and approvals slow down the Build-Measure-Learn feedback loop and inhibit both learning and accountability.
The imperative to innovate is unrelenting. Without the ability to experiment in a more agile manner, this company eventually would suffer the fate described in The Innovator’s Dilemma: ever-higher profits and margins year after year until the business suddenly collapsed.
Do not hide the innovation team. People defend themselves when they feel threatened, and no innovation can flourish if defensiveness is given free rein. The common suggestion to hide the innovation team is misguided. Hiding from the parent organisation (a start up within a large org) can have long-term negative consequences.
To empower innovation out in to the open, create a sandbox for innovation that will contain the impact of the new innovation but not constrain the methods of the start up team.
Any team can create a true split-test experiment that affects only the sandboxes parts of the product or service (for a multipart product) or only certain customer segments or territories (for a new product). However:
- One team must see the whole experiment through from end to end
- No experiment can run longer than a specified amount of time
- No experiment can affect more than a specified number of customers
- Every experiment has to be evaluated on the basis of a single standard report of five to ten actionable metrics
- Every team that works inside the sandbox and every product that is built must use the same metrics to evaluate success
- Any team that creates an experiment must monitor the metrics and customer reactions (support calls, social media reaction, forum threads, etc.) while the experiment is in progress and abort it if something catastrophic happens.
- Can we use the theory to predict the results of the proposed change?
- Can we incubate the change in a small team and see what happens?
- Can we measure its impact?
You have to be able to predict the outcome of the changes you make to tell if the problems that result are really problems.
Force teams to work cross-functionally to achieve validated learning. Techniques for doing this – actionable metrics, continuous deployment, and the overall Build-Measure-Learn feedback loop.
It does not matter how fast we can build, it does not matter how fast we can measure.
What matters is how fast we can get through the entire loop