The Lean Startup Innovate notes

These are my notes on this chapter from the book The Lean Startup. My original post is here.

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:

  1. One team must see the whole experiment through from end to end
  2. No experiment can run longer than a specified amount of time
  3. No experiment can affect more than a specified number of customers
  4. Every experiment has to be evaluated on the basis of a single standard report of five to ten actionable metrics
  5. Every team that works inside the sandbox and every product that is built must use the same metrics to evaluate success
  6. 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.
Whenever possible, the innovation team should be cross-functional and have a clear team leader. It should be empowered to build, market, and deploy products and features in the sandbox without prior approval. It should be required to report on the success or failure of those efforts by using standard actionable metrics and innovation accounting.
True Experiments are easy to classify as successes or failures because top-level metrics either move or they don’t.
If someone wants to sabotage the innovation team, he or she will have to learn all about actionable metrics and learning milestones to do it.
When people have a chance to see a project through from end to end and the work is done in small batches and delivers a clear verdict quickly, they benefit from the power of feedback. Each time they fail to move the numbers, they have a real opportunity to act on their findings immediately. Thus, these teams tend to converge on optimal solutions rapidly even if they start out with really bad ideas.
By making the batch size small, the sandbox method allows teams to make cheap mistakes quickly and start learning.
A common practice is for the inventor of a new product or feature to manage the subsequent resources, team, or division that ultimately commercialises it. As a result, strong creative managers wind up getting stuck working on the growth and optimisation of products rather than creating new ones.
The way out of this dilemma is to manage the four kinds of work differently, allowing strong cross-functional team to develop around each area. When products move from phase to phase, they are handed off between teams. Employees can choose to move with the product as part of the handoff or stay behind and begin work on something new.
People should be allowed to find the kind of jobs that suit them best.
Push for rapid iteration, data-driven decision making, and early customer involvement.
Responding dogmatically is unhelpful, compromising by automatically splitting the difference does not work either.
Every suggestion should be subjected to rigorous scientific inquiry:
  • 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


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: