Defining a Lean Experiment

Flesh out the base concept defined in step 1. This defines the basics of your Value Strategy.

Keep it simple - focus only on what matters; ignore anything extraneous. Ideally, this is a couple of pages in length, and is a bulleted rather than narrative document.

Answer these questions, as a hypothesis, at a high level - i.e., a paragraph for each:

  • How will value be delivered to the sponsors? And how can that be measured or indicated? Are there numeric projections?

  • How will value be delivered to the uses? And how can that be measured or indicated? Are there numeric projections?

  • How will the concerns of other stakeholders be addressed?

  • What capabilities are required to start delivering value?

  • What is the basic technical approach for how each capability will work?

  • What is the long term vision, in terms of a full set of capabilities?

  • What is the general plan or roadmap for developing the capabilities?

  • What funding stream is needed?

  • Who are the partners in this, and what are their roles?

  • What kinds of cooperation or support are needed from each partner, and from other stakeholders?

Distill Out Your Causal Model

A Lean experiment is a hypothesis about a working model of cause-and-effect. For example, you might observe that users need a particular capability. Your hypothesis might be that a certain feature will satisfy that need and that users will then buy your product. Your experiment is to create a prototype of the capability and introduce it to users: if they buy, then the hypothesis is partially validated. We say partially because the word “prove” is too strong: we never have proof—we only have evidence.

Read more about causal models in Always Have a Working Model.

Alignment with Strategy

Your vision needs to be refined so that it is expressed as a hypothesis.

If your initiative is part of a larger portfolio of initiatives, then it needs to align with overall strategy. Strategy is usually somewhat top-down, but it is often bottom-up as well. In fact, grass roots initiatives can sometimes be so disruptive that they result in a complete change in strategy. The IBM PC is a great example of that: it was a niche effort but it changed IBM.

Therefore, be careful about compromising your core idea just to fit into a larger strategy. But strategy is important: an organization goes farther if everyone is rowing the same way.

An effective strategy is not merely a spending decision: it is also a set of approaches.

As we explain in Defining Strategy, an effective strategy is not merely a spending decision: it is also a set of approaches. For example, if the organization decides that one of its strategies is to vertically integrate some capabilities, then there are methods and behaviors that must go along with that to make it feasible. What are those? Is your initiative using those methods and behaviors, or is your situation exceptional so that some of them do not apply?

If the strategy is well formed, then any desired methods and behaviors will be championed by someone in leadership, and probably measured in some way. Try to align with that effort by having some thoughtful discussions with the people who are championing the strategy, and invest the effort to automate (if possible) the measurement of their requested measurements.

Refine the Product Concept Into as Set of Capabilities

The goal of any initiative is to either change something, or to create a capability to change something. The latter includes product development: we are creating a capability to distribute a product that will change—hopefully increase—the value that is being realized.

If your initiative falls into the latter category, such as product development, then you should be clear about what capabilities that product will represent. In other words, what will it enable users to do?

This is not just in a functional sense. Both form and function matter. When product designers talk about delighting a user, they are speaking about the capability to create delight—to generate emotion. That is important for consumer products.

What are the capabilities that need to be created? In step 5 we will delve into this more, to define a capability tree that serves as a kind of backlog. Right now you need to be clear on the capabilities that are key to the Lean business case. What capabilities are essential in order to realize value? That is, what must the user be able to do (or feel) with the product?

An Example

Consider a company that makes medical equipment for both clinical and home settings. They discover that home users are dissatisfied with digital thermometers, because they remain in a drawer for a year, and then when needed, the battery is dead. But people are accustomed to the rapid response of digital thermometers. A product design team envisions that people might want to have a thermometer that has a built-in solar cell to keep it charged.

The team consisting of two product designers, an engineer, and a clinician mock up potential designs. One issue that arises is how large the solar cell needs to be. Another is the optimal price point and manufacturing cost. The team distills these key capabilities:

  1. Charging to a usable level must be rapid - less than half an hour - otherwise, the device will not be ready when people need it if it has been in a drawer and its power has fully drained.

  2. It must be comfortable to hold in one’s mouth.

  3. It must be manufacturable in volume for less than $.90 per unit. Otherwise, it might not be able to compete with less expensive units that only have a battery.

These capabilities are all assumptions, and each represents as hypothesis: that if the assumption holds, then the product will be appealing to customers.

To test hypotheses 1 and 3, we will need to perform a more realistic design so that we can determine the product’s size and weight envelope. We can then create mockups of the product and conduct surveys with prospective users, to ask if they would buy such a product. We would tell them the projected retail price, given an assumed manufacturing cost of less than $.90.

To test hypothesis 2, we would have to provide the mockups to users and have them hold the mockup in their mouth and ask them if it is uncomfortable.

If the product idea survives these trials, a real device prototype can be made, and field tested with volunteer users who are then surveyed. If that is successful, a limited run can be manufactured, and test marketed in a few stores.

Another Example

An airplane manufacturer believes that it would be useful for pilots to be able to hear what is happening in the passenger cabin. The need arose because of an increase in the unruliness of passengers. However, because microphones have limited dynamic range, it would be necessary to embed a microphone in each seat. That is a potential invasion of personal privacy.

They form a team consisting of some electrical engineers, a manufacturing engineer, and a privacy expert. After some ideation, they come up with a concept in which cockpit crew can enable any microphone, but it requires two crew members to do it, and a log is kept of the action. It also turns off automatically after ten minutes. The privacy expert feels that those features are sufficient to address privacy concerns.

They decide that the key capabilities are:

  1. To select any seat in the plane.

  2. To select an area of seats, say all seats in a certain row or a pair of rows.

  3. To automatically turn off listening after a timeout period that beings when listening is enabled.

  4. To log every action.

  5. Top transfer logs to a ground-based servers on landing or in real time over satellite Internet.

  6. To retrieve logs from the gound-based servers for a specified flight.

  7. To require that two people activate it, ensuring that it cannot be done without the knowledge of another crew member.

  8. It can be manufactured and installed for less than $30,000 per airplane.

The hypotheses are:

  • Airlines will desire the system and purchase it at a price that is compatible with the cost.

  • They system can actually work well: cockpit crew can actually hear clearly what is going on.

  • Passengers who become aware of the system will not object, and will be confidence in the protection of their privacy.

These hypothesis can be validated progressively using methods similar to the methods used for the first example.