The Iterative Process

Design is the activity of turning vague ideas, market insights, and evidence into concrete value propositions and solid business models. Good design involves the use of strong business model patterns to maximize returns and compete beyond product, price,and technology.
The risk is that a business can’t get access to key resources (technology, IP,
brand, etc.), can’t develop capabilities to perform key activities, or can’t find key partners to build and scale the value proposition.

To test a big business idea you break it down into smaller chunks of testable
hypotheses. These hypotheses cover three types of risk. First, that customers aren’t interested in your idea (desirability). Second, that you can’t build and deliver your idea (feasibility). Third, that you can’t earn enough money from your idea (viability).
You test your most important hypotheses with appropriate experiments. Each
experiment generates evidence and insights that allow you to learn and decide. Based on the evidence and your insights you either adapt your idea, if you learn you were on the wrong path, or continue testing other aspects of your idea, if the evidence supports your direction.

Having worked with teams all around the world, we have learned that behind every successful new venture is a great team. If you are at a startup, the founding team is the glue that holds it all together. If you are in a corporation, you’ll still need a solid team to create a new business venture. If you are a solopreneur, the team you eventually bring in will make or break your business.

  1. We recommend only one experiment
    per sticky, to keep things organized.
    You don’t have to write down hundreds
    of experiments—only the ones you feel
    you’ll be running over the upcoming

Draw a simple experiment board
This is one of the simplest forms of
an experiment board you can create.
We’ve been playing with this format for
quite some time and used to like the
“Validate” column, which we got originally from Eric Ries. Over time, we’ve
started to back off a bit on that language
because teams will set the bar so low on
their hypotheses that they’ll artificially
validate them and move on too quickly.
We prefer “Learn” over “Validate.

Add your experiments to the
Backlog column
Rank your experiments from top to
bottom, where the top is the one you are
going to do next. Pull them across as
you begin to work on each, moving from
Setup, to Run, to Learn.