Shipulski On Design

Archive for the ‘Decisions’ Category

What would you do if:

You had to push through your fear of being judged?

You had to break some rules to get an idea off the ground?

You had a concept that would displace your most successful product?

Your colleague tried to scuttle your best idea?

You knew it was time to stop judging yourself negatively?

Your colleague asked you to help with a hair-brained idea?

You were asked to facilitate a session to create new concepts, but no one could explain what would happen after the concepts were created?

You weren’t afraid your prototype would be a success?

You thought you knew what the customer wanted, but didn’t have the data to prove it?

You were asked to create patentable concepts you knew would never be commercialized?

Your prototype threatened the status quo?

You were asked to facilitate a session to create new concepts and told how to do it?

You were told “No.”

You saw a young employee struggling with a new concept?

You were blocking yourself from starting the right work?

You thought your idea had merit, but you needed help testing it in the market?

You were asked to follow a standard process but you knew there wasn’t one?

You were asked to come up with new concepts though there were five excellent concepts gathering dust?

You were told there was no market for your new-to-world prototype?

You had to bolster your self-confidence to believe wholeheartedly in your idea?

There is a name for what you would do. It’s called innovation.

image credit – UnknownNet Photography

Ideas are all talk and no action.  Ideas are untested concepts that have yet to rise to the level of practicality.  You can’t sell an idea and you can’t barter with them. Ideas aren’t worth much.

A prototype is a physical manifestation of an idea. Where ideas are ethereal, prototypes are practical. Where ideas are fuzzy and subject to interpretation, prototypes are a sledge hammer right between the eyes.  There is no arguing with a prototype. It does what it does and that’s the end of that. You don’t have to like what a prototype stands for, but you can’t dismiss it. Where ideas aren’t worth a damn, prototypes are wholly worth every ounce of effort to create them.

If Camp A says it will work and Camp B says it won’t, a prototype will settle the disagreement pretty quickly.  It will work or it won’t.  And if it works, the idea behind it is valid.  And if it doesn’t, the idea may be valid, but a workable solution is yet-to-be discovered.  Either way, a prototype brings clarity.

Prototypes are not elegant.  Prototypes are ugly. The best ones do one thing – demonstrate the novel idea that underpins them. The good ones are simple, and the best ones are diabolically simple. It is difficult to make diabolically simple prototypes (DSPs), but it’s a skill that can be learned.  And it’s worth learning because DSPs come to life in record time. The approach with DSPs is to take the time up front to distill the concept down to its essence and then its all-hands-on-deck until it’s up and running in the lab.

But the real power of the DSP is that it drives rapid learning.  When a new idea comes, it’s only a partially formed.  The process of trying to make a DSP demands the holes are filled and blurry parts are brought into focus.  The DSP process demands a half-baked idea matures into fully-baked physical embodiment.  And it’s full-body learning.  Your hands learn, your eyes learn and your torso learns.

If you find yourself in a disagreement of ideas, stop talking and start making a prototype. If the DSP works, the disagreement is over.

Diabolically simple prototypes end arguments. But, more importantly, they radically increase the pace of learning.

Image credit – snippets101

When doing new things there is no predictability. There’s speculation, extrapolation and frustration, but no prediction. And the labels don’t matter.  Whether it’s called creativity, innovation, discontinuous improvement or disruption there’s no prediction.

The trick in the domain complexity is to make progress without prediction.

The first step is to try to define the learning objective.  The learning objective is what you want to learn. And its format is – We want to learn that [fill in the learning objective here].  It’s fastest to tackle one learning objective at a time because small learning objectives are achieved quickly with small experiments.  But, it will be a struggle to figure out what to learn.  There will be too many learning objectives and none will be defined narrowly.  At this stage the fastest thing to do is stop and take a step back.

There’s nothing worse than learning about the wrong thing.  And it’s slow. (The fastest learning experiments are the ones that don’t have to be run.) Before learning for the sake of learning, take the necessary time to figure out what to learn. Ask some questions: If it worked could it reinvent your industry? Could it obsolete your best product? Could it cause competitors to throw in the towel?  If the answer is no, stop the project and choose one where the answer is yes. Choose a meaningful project, or don’t bother.

First learning objective – We want to learn that, when customers love the new concept, the company will assign appropriate resources to commercialize it.  If there’s no committment up front, stop.  If you get committment, keep going. (Without upfront buy-in the project relies on speculation, the wicked couple of prediction and wishful thinking.)

Second learning objective – We want to learn that customers love the new concept.  This is not “I think customers will love it.” or “Customers may love it.” In the standard learning objective format – We want to learn that [customers love the new concept].  Next comes the learning plan.

What will you build for customers to help them understand the useful novelty of the revolutionary concept?  For speed’s sake, build a non-functional prototype that stands for the concept.  It’s a thin skin wrapped around an empty box that conveys the essence of the novelty.  No skeleton, just skin.  And for speed’s sake, show it to fewer customers than you think reasonable.  And define the criteria to decide they love it.  There’s no trick here. Ask “Do they love it?” and use your best judgement.  At this early stage, the answer will be no.  But they’ll tell you why they don’t love it, and that’s just the learning you’re looking for.

Use customer input to reformulate the learning objective and build a new prototype and repeat.  The key here is to build fast, test fast, learn fast and repeat fast.  The art becomes defining the simplest learning objectives, building the simplest prototypes and making decisions with data from the fewest customers.

With complexity and newness prediction isn’t possible. But learning is.

And learning doesn’t have to take a lot of time.

Image credit — John William Waterhouse

Urgency is important, but it’s not everything. It creates focus, but washes out the radical fringe. It’s easy to measure, but easy to measure doesn’t mean it’s the best thing to work on.

In the heat of the moment urgency is king. Frantic project managers take shortcuts to meet a deadline defined fourteen months ago; Lean Startup-ers ready-fire-aim their way from pivot to pivot; And resources flow to projects that are scheduled to finish soonest.

Urgency is attractive because it’s so clear cut, so objective, so easy to measure.

Due Date – Today’s Date = Urgency.

There’s always consensus on today’s date, everyone knows the due date and subtraction come easily.  There you go. No debate, no discussion.  This project has more urgency than that one.  Just do the math. But where did the due date come from? Did the work content define the due date?  If so, projects with the least work content, with their immanent due date, are the most urgent and resources should flow to the shortest projects.  Did the annual trade show set the due date?  If so, projects with earliest trade shows should get priority.  Did the CEO define the due date for reasons unknown to mere mortals?  If so, projects that finish before the declared date should get priority and projects that finish after the due date should get put on the back burner.

Project scope defines work content and start date plus work content equals due date.  For two projects with equal work content, the project that starts first has more urgency. Should projects start sooner to increase urgency? Should project plans pile on resources to pull in the completion date to increase urgency? Should project managers strip the sizzle out of projects so they finish sooner?

Urgency isn’t important. Importance is important.

The problem with importance is its subjective nature. Because there is no objective measure of importance, judgement is required.  The cold scoring systems to rank projects don’t work.  There are no scoring rubrics, no algorithms, no customized weighting factors that can objectively quantify importance.  It’s either important or it isn’t.  It’s important in the chest, or it’s not. It’s all about judgement.

The context defines what’s important. Market share has dropped five years in a row, some projects are more important than others. Market share has increased five years in a row, a different set of projects is important. Can’t make payroll, urgency-based project selection is best. Technology is long in the tooth, it’s important to fund projects that buy or build new technology. Which projects are most important? It depends.

The best way to sort projects by importance is to ask “Is this project important?” and have a discussion. Some projects will have more upside and others will have more certainty.  Some could create new markets and other will proved two percent growth in a guaranteed way. Which are most important? It depends.

Importance is relative. Use the “Is this project important?” methodology to force rank your projects by importance.  Once complete, take a step back and ask if the ranked list makes sense.  Reshuffle if needed.  Starting from the top, fully staff the most important project. For the next most important project, allocate the remaining resources and repeat the process project-by-project until the resources are gone.  This process ensures the most important projects on the list get the resources. But there’s a hole in the methodology.

What if our innate urgency bias keeps the most important projects off the list?

Image credit – Stephen Depolo

When doing something from the first time you’re going to get it wrong.  There’s no shame in that because that’s how it goes with new work. But more strongly, if you don’t get it wrong you’re not trying hard enough.  And more strongly, embrace the inherent wrongness as a guiding principle.

Take Small Bites. With new work, a small scope is better than a large one.  But it’s exciting to do new work and there’s a desire to deliver as much novel usefulness as possible.  And, without realizing it, the excitement can lead to a project bloated with novelty.  With the best intentions, the project team is underwater with too much work and too little time.  With new work, it’s better to take one bite and swallow than three and choke.

Ratchet Thinking. With new work comes passion and energy.  And though the twins can be helpful and fun to have around, they’re not always well-behaved.  Passion can push a project forward but can also push it off a cliff. Energy creates pace and can quickly accelerate a project though the milestones, but energy can be careless and can just as easily accelerate a project in the wrong direction.  And that’s where ratchet thinking can help.

As an approach, the objective of ratchet thinking is to create small movements in the right direction without the possibility of back-sliding.  Solve a problem and click forward one notch; solve a second problem and click forward another notch.  But, with ratchet thinking, if the third problem isn’t solved, the project holds its ground at the second notch.  It takes a bit more time to choose the right problem and to solve it in a way that cannot unwind progress, but ultimately it’s faster.  Ratchet thinking takes the right small bite, chews, swallows.

Zero Cost of Change. New work is all about adding new functions, enhancing features and fixing what’s broken.  In other words, new work is all about change. And the faster change can happen, the faster the product/service/business model is ready for sale.  But as the cost of change increases the rate of changes slows.  So why not design the project to eliminate the cost of change?

To do that, design the hardware with a bit more capability and headroom so there’s some wiggle room to handle the changes that will come.  Use a modular approach for the software to minimize the interactions of software changes and make sure the software can be updated remotely without customer involvement.  And put in place a good revision control (and tracking) mechanism.

Doing new work is full of contradictions: move quickly, but take the time to think things through; take on as much as you can, but no more; be wrong, but in the right way; and sometimes slower is faster.

But doing new work you must.

image credit – leasqueaky

Today’s work is complicated with electronic and mechanical subsystems wrapped in cocoons of software; coordination of matrixed teams; shared resources serving multiple projects; providing world class services in seventeen languages on four continents. And the complexity isn’t limited to high level elements.  There is a living layer of complexity growing on all branches of the organization right down to the leaf level.

Complexity is real, and it complicates things.  To run projects and survive in the jungle of complexity it’s important to know how to put the right pieces together and provide the right answers.  But as a leader it’s more important to slash through the complexity and see things as they are.  And for that, it’s more important to know how ask diabolically simple questions (DSQ).

Project timelines are tight and project teams like to start as soon as they can.  Too often teams start without clarity on what they’re trying to achieve.  At these early stages the teams make record progress in the wrong direction.  The leader’s job is to point them in the right direction, and here’s the DSQ to set them on their way: What are you trying to achieve?

There will likely be some consternation, arm waiving and hand wringing.  After the dust settles, help the team further tighten down the project with this follow-on DSQ:  How will you know you achieved it?

For previous two questions there are variants that works equally well for work that closer to the fuzzy front end: What are you trying to learn? and How will you know you learned it?

There is no such thing as a clean-sheet project and even the most revolutionary work builds on the existing system.  Though the existing business model, service or product has been around for a long time, the project team doesn’t really know how it works.  They know they should know but they’re afraid to admit it. Let them off the hook with this beauty: How does it work today?

After the existing system is defined with a simple block diagram (which could take a couple weeks) it’s time to help the project team focus their work.  The best DSQ for the job: How is it different from the existing system?  If the list is too long there’s too much newness and if it’s too short there’s not enough novelty.  If they don’t know what’s different, ask them to come back when they know.

After the “what’s different” line of questioning, the team must be able to dive deeper.  For that it’s time one of the most powerful DSQs in the known universe: What problem are you trying to solve? Expect frustration and complicated answers.  Ask them to take some time and for each problem describe it on a single page using less than ten words.  Suggest a block diagram format and ask them to define where and when the problem occurs.  (Hint: a problem is always between two components/elements of the system.)  And the tricky follow-on DSQ: How will you know you solved it? No need to describe the reaction to that one.

Though not an exhaustive list, here are some of my other favorite DSQs:

Who will buy it, how much will they pay, and how do you know?

Have we done this before?

Have you shown it to a real customer?

How much will it cost and how do you know?

Whose help do we need?

If the prototype works, will we actually do anything with it?

Diabolically simple questions have the power to heal the project teams and get them back on track.  And over time, DSQs help the project teams adopt a healthy lifestyle.  In that way, DSQs are like medicine – they taste bad but soon enough you feel better.

Image credit – Daniela Hartmann

How a company allocates its resources defines its strategy.  But it’s tricky business to allocate resources in a way that makes the most of the existing products, services and business models yet accomplishes what’s needed to create the future.

To strike the right balance, and before any decisions on specific projects, allocate the desired spending into three buckets – short, medium and long.  Or, if you prefer, Horizon 1, 2 and 3.  Use the business objectives to set the weighting. Then, sit next to the CFO for a couple days and allocate last year’s actual spending to the three buckets and compare the actuals with how resources will be allocated going forward.  Define the number of people who will work on short, medium and long and how many will move from one bucket to another.

To get the balance right, short term projects are judged relative to short term projects, medium term projects are judged relative to medium term projects and the long term ones are judged against their long term peers.  Long term projects cannot be staffed at the expense of short term projects and medium term projects cannot take resources from long term projects.  To get the balance right, those are the rules.

To choose the best projects within each bucket, clarity and constraints are more important than ROI.   Here are some questions to improve clarity and define the constraints.

How will the customer benefit? It’s best to show the customer using the product or service or experiencing the new business model.  Use a hand sketch and few, if any, words.  Use one page.

How is it different?  In the hand sketch above, draw the novel (different) elements in red.

Who is the new customer? Define where they live, the language they speak and how they get the job done today.

Are there regional constraints?  Infrastructure gaps, such as electricity, water, transportation are deal breakers.  Language gaps can be big problems, so can regulatory, legal and cultural constraints. If a regional constraint cannot be overcome, do something else.

How will your company make money?  Use this formula: (price – cost) x volume.  But, be clear about the size of the market today and the size it could be in five years.

How will you make, sell and service it?  Include in the cost of the project the cost to overcome organizational capacity/capability constraints.  If cost (or time) to close the gaps is prohibitive, do something else.

How will the business model change?  If it won’t, strongly consider a different project.

If the investigations show the project is worthwhile, how would you staff the project and when?  This is an important one.  If the project would be a winner, but there is no one to work on it, do something else.  Or, consider stopping a bad project to start the good one.

There’s usually a general tendency to move medium term resources to short term projects and skimp on long term projects.  Be respectful of the newly-minted resource balance defined at the start and don’t choose a project from one bucket over a project from another.  And don’t get carried away with ROI measured to three significant figures, rather, hold onto the fact that an insurmountable constraint reduces ROI to zero.

And staff projects fully.  Partially-staffed projects set expectations that good things are happening, but they never come to be.

Image credit – john curley

At the most basic level, business is about allocating resources to the best projects and executing those projects well.  Said another way, business is about deciding what to work on and then working effectively.  But how to go about deciding what to work on?  Here is a cascade of questions to start you on your journey.

What are your company’s guiding principles?  Why does it exist? How does it want to go about its life?   These questions create context from which to answer the questions that follow.  Once defined, all your actions should align with your context.

How has the business environment changed? This is a big one.  Everything is impermanent.  Change is the status quo.  What worked last time won’t work this time.  Your success is your enemy because it stunts intentions to work on new things.  Define new lines of customer goodness your competitors have developed; define how their technologies have increased performance; search YouTube to see the nascent technologies that will displace you; put yourself two years in the future where your customers will pay half what they pay today.  These answers, too, define the context for the questions that follow.

What are you working on? Define your fully-staffed projects. Distill each to a single page. Do they provide new customer value?  Are the projects aligned with your company’s guiding principles? For those that don’t, stop them.  How do your fully-staffed projects compare to the trajectory of your competitors’ offerings?  For those that compare poorly, stop them.

For projects that remain, do they meet your business objectives?  If yes, put your head down and execute.  If no, do you have better projects?  If yes, move the freed up resources (from the stopped projects) onto the new projects.  Do it now.  If you don’t have better projects, find some.  Use lines of evolution for technological systems to figure out what’s next, define new projects and move the resources.  Do it now.

The best leading indicator of innovation is your portfolio of fully-staffed projects.  Where other companies argue and complain about organizational structure, move your best resources to your best projects and execute.  Where other companies use politics to trump logic, move your best resources to your best projects and execute.  Where other successful companies hold on to tired business models and do-what-we-did-last-time projects, move your best resources to your best projects and execute.

Be ruthless with your projects.  Stop the bad ones and start some good ones. Be clear about what your projects will deliver – define the novel customer value and the technical work to get there.  Use one page for each.  If you can’t define the novel customer value with a simple cartoon, it’s because there is none.  And if you can’t define how you’ll get there with a hand sketch, it’s because you don’t know how.

Define your company’s purpose and use that to decide what to work on.  If a project is misaligned, kill it. If a project is boring, don’t bother.  If it’s been done before, don’t do it.  And if you know how it will go, do something else.

If you’re not changing, you’re dying.

Image credit – David Flam

Successful commercialization of products and services is fueled by one fundamental – making the new one better than the old one.  If the new one is better the customer experience is better, the marketing is better, the sales are better and the profits are better.

It’s not enough to know in your heart that the new one is better, there’s got to be objective evidence that demonstrates the improvement.  The only way to do that is with testing.  There are a number of types testing mechanisms, but whether it’s surveys, interviews or in-the-lab experiments, test results must be quantifiable and repeatable.

The best way I know to determine if the new one is better than the old one is to test both populations with the same test protocol done on the same test setup and measure the results (in a quantified way) using the same measurement system.  Sounds easy, but it’s not.  The biggest mistake is the confusion between the “same” test conditions and “almost the same” test conditions.  If the test protocol is slightly different there’s no way to tell if the difference between new and old is due to goodness of the new design or the badness of the test setup.  This type of uncertainty won’t cut it.

You can never be 100% sure that new one is better than the old one, but that’s were statistics come in handy.  Without getting deep into the statistics, here’s how it goes.  For both population’s test results the mean and standard deviation (spread) are calculated, and taking into consideration the sample size of the test results, the statistical test will tell you if they’re different and confidence of it’s discernment.

The statistical calculations (Student’s t-test) aren’t all that important, what’s important is to understand the implications of the calculations.  When there’s a small difference between new and old, the sample size must be large for the statistics to recognize a difference.  When the difference between populations is huge, a sample size of one will do nicely.  When the spread of the data within a population is large, the statistics need a large sample size or it can’t tell new from old. But when the data is tight, they can see more clearly and need fewer samples to see a difference.

If marketing claims are based on large sample sizes, the difference between new and old is small.  (No one uses large sample sizes unless they have to because they’re expensive.) But if in a design review for the new product the sample size is three and the statistical confidence is 95%, new is far better than old.  If the average of new is much larger than the average of old and the sample size is large yet the confidence is low, the statistics know the there’s a lot of variability within the populations. (A visual check should show the distributions to more wide than tall.)

The measurement systems used in the experiments can give a good indication of the difference between new and old.  If the measurement system is expensive and complicated, likely the difference between new and old is small.  Like with large sample sizes, the only time to use an expensive measurement system is when it is needed.  And when the difference between new and old is small, the expensive measurement system’s ability accurately and repeatably measure small differences (micrometers vs. meters).

If you need large sample sizes, expensive measurement systems and complicated statistical analyses, the new one isn’t all that different from the old one.  And when that’s the case, your new profits will be much like your old ones.  But if your naked eye can see the difference with a back-to-back comparison using a sample size of one, you’re on to something.

Image credit – amanda tipton

There’s a special type of confusion that has blocked many good ideas from seeing the light of day.  The confusion happens early in the life of a new technology when it is up and running in the lab but not yet incorporated in a product.  Since the new technology provides a new flavor of customer goodness, it has the chance to create incremental sales for the company.  But, since there are no products in the market that provide the novel goodness, by definition there can be no sales from these products because they don’t yet exist.  And here’s the confusion.  Organizations equate “no sales” with “no market”.

There’s a lot of risk with launching new products with new value propositions to new customers.  You invest resources to create the new technologies and products, create the sales tools, train the sales teams, and roll it out well. And with all this hard work and investment, there’s a chance no one will buy it.  Launching a product that improves on an existing product with an existing market is far less risky – customers know what to expect and the company knows they’ll buy it.  The status quo when stable if all the players launch similar products, right up until it isn’t.  When an upstart enters the market with a product that offers new customer goodness (value proposition) the same-old-same-old market-customer dynamic is changed forever.

A market-busting product is usually launched by an outsider – either a big player moves into a new space or a startup launches its first product.  Both the new-to-market big boy and the startup have a far different risk profile than the market leader, not because their costs to develop and launch a new product are different, but because they have not market share.  For them, they have no market share to protect any new sales are incremental.  But for the established players, most of their resources are allocated to protecting their existing business and any resources diverted toward a new-to-market product is viewed as a loss of protective power and a risk to their market share and profitability.   And on top of that, the incumbent sees sales of the new product as a threat to sales of the existing products.  There’s a good chance that their some of their existing customers will prefer the new goodness and buy the new-to-market product instead of the tried-and-true product.  In that way, sales growth of their own new product is seen as an attack no their own market share.

Business leaders are smart.  Theoretically, they know when a new product is proposed, because it hasn’t launched yet, there can be no sales.  Yet, practically, because their prime directive to protect market share is so all-encompassing and important, their vision is colored by it and they confound “no sales” with “no market”.  To move forward, it’s helpful to talk about their growth objectives and time horizon.

With a short time horizon, the best use of resources is to build on what works – to launch a product that builds on the last one.  But when the discussion is moved further out in time, with a longer time horizon it’s a high risk decision to hold on tightly to what you have as the market changes around you.  Eventually, all recipes run out of gas like Henry Ford’s Model T.  And the best leading indicator of running low on fuel is when the same old recipe cannot deliver on medium-term growth objectives.  Short term growth is still there, but further out they are not.  Market forces are squeezing the juice out of your past success.

Ultimately, out of desperation, the used-to-be market leader will launch a new-to-market product.  But it’s not a good idea to do this work only when it’s the only option left.  Before they’re launched, new products that offer new value to customers will, by definition, have no sales.  Try to hold back the fear-based declaration that there is no market.  Instead, do the forward-looking marketing work to see if there is a market.  Assume there is a market and build some low cost learning prototypes and put them in front of customers.  These prototypes don’t yet have to be functional; they just have to communicate the idea behind the new value proposition.

Before there is a market, there is an idea that a market could exist.  And before that could-be market is served, there must be prototype-based verification that the market does in fact exist.  Define the new value proposition, build inexpensive prototypes and put them in front of customers.  Listen to their feedback, modify the prototypes and repeat.

Instead of arguing whether the market exists, spend all your energy proving that it does.

Image credit — lensletter

At every meeting you have a chance to move things forward or hold them back.  When a new idea is first introduced it’s bare-naked.  In its prenatal state, it’s wobbly and can’t stand on its own and is vulnerable to attack. But since it’s not yet developed, it’s impressionable and willing to evolve into what it could be.  With the right help it can go either way – die a swift death or sprout into something magical.

Early in gestation, the most worthy ideas don’t look that way.  They’re ugly, ill-formed, angry or threatening.  Or, they’re playful, silly or absurd.  Depending on your outlook, they can be a member of either camp. And as your outlook changes, they can jump from one camp to the other.  Or, they can sit with one leg in each.  But none of that is about the idea, it’s all about you.  The idea isn’t a thing in itself, it’s a reflection of you. The idea is nothing until you attach your feelings to it.  Whether it lives or dies depends on you.

Are you looking for reasons to say yes or reasons to say no?

On the surface, everyone in the organization looks like they’re fully booked with more smart goals than they can digest and have more deliverables than they swallow, but that’s not the case.  Though it looks like there’s no room for new ideas, there’s plenty of capacity to chew on new ideas if the team decides they want to.  Every team can spare and hour or two a week for the right ideas.  The only real question is do they want to?

If someone shows interest and initiative, it’s important to support their idea.  The smallest acceptable investment is a follow-on question that positively reinforces the behavior.  “That’s interesting, tell me more.” sends the right message.  Next, “How do you think we should test the idea?” makes it clear you are willing to take the next step.  If they can’t think of a way to test it, help them come up with a small, resource-lite experiment.  And if they respond with a five year plan and multi-million dollar investment, suggest a small experiment to demonstrate worthiness of the idea.  Sometimes it’s a thought experiment, sometimes it’s a discussion with a customer and sometimes it’s a prototype, but it’s always small.  Regardless of the idea, there’s always room for a small experiment.

Like a staircase, a series of small experiments build on each other to create big learning.  Each step is manageable – each investment is tolerable and each misstep is survivable – and with each experiment the learning objective is the same: Is the new idea worthy of taking the next step?  It’s a step-wise set of decisions to allocate resources on the right work to increase learning.  And after starting in the basement, with step-by-step experimentation and flight-by-flight investment, you find yourself on the fifth floor.

This is about changing behavior and learning.  Behavior doesn’t change overnight, it changes day-by-day, step-by-step.  And it’s the same for learning – it builds on what was learned yesterday.  And as long at the experiment is small, there can be no missteps.  And it doesn’t matter what the first experiment is all about, as long as you take the first step.

Your team will recognize your new behavior because it respectful of their ideas.  And when you respect their ideas, you respect them.  Soon enough you will have a team that stands taller and runs small experiments on their own.  Their experiments will grow bolder and their learning will curve will steepen.  Then, you’ll struggle to keep up with them, and you’ll have them right where you want them.

image credit — Rob Warde