Shipulski On Design

Archive for June, 2016

Doing new work isn’t difficult, thinking about is difficult.  Stop thinking and start starting; there’s no other way.

If you’re a scientist, everything has a half-life.  If you’re Buddhist, everything is impermanent.  If you’re a CEO, your business model is out of gas.  It’s scary to admit everything goes away, but it’s far scarier to deny it.

Just because an idea is threatening doesn’t mean it’s threatening.  It probably means it’s one hell of a good idea.

If it’s not different, it can’t be innovation.

Projects take too long because they’re poorly defined.  On a single page, define the novel usefulness the project will deliver, make a crude prototype and show it to potential customers. Refine, learn and repeat. Then launch it.  (This is the essence of Lean Startup without all the waste.)

If I could choose my competition, I’d choose to compete with no one.

Failure is never the right word.  Don’t use it.  Ever.  (Even failing forward or forward failing should not be used.)  No one wants to fail.  No one will ever want to fail.  Replace of the word “failure” with “learning” and learn quickly.

If you’re not scared, you’re not doing innovation.

Companies offer more-with-less for as long as they can; and when there’s nothing left they offer more-with-more. It would be better to offer less-with-far-less.

For Franklin D. Roosevelt, the only thing to fear was fear itself.  For business, the only thing to fear is the cow path of success.

Image credit – JasonParis

When the work is new, it all comes down to learning.  And with learning it all comes down to three questions:

• What do you want to learn?
• What actions will take to learn what you want to learn?
• How will you decide if you learned what you wanted to learn?

There are many definitions of learning.  To me, when your beliefs change, that’s learning.  If your hunch moves to a validated idea, that’s learning.  If your understanding of a system moves from “I don’t know” to “I know a little bit.”, that’s learning.  If you believed your customers buy your product for Feature A and now you know they really buy it because of Feature B, that’s learning.

What do you want to learn? The best place to start is to clearly define what you want to learn.  Sounds easy, but it’s not. Some of the leading thinking recommends you define a formal hypothesis.  I don’t like that word.  It’s scary, intimidating and distracting.  It’s just not helpful.  Instead, I suggest you define a Learning Objective.  To do that, complete this sentence:

I want to learn if the customer ____________________.

It may take several iterations/meetings to agree on a Learning Objective, but that’s time well spent.  It’s faster to take the time to define what you want to learn than to quickly learn something that doesn’t matter.  And define the Learning Objective as narrowly as possible.  The tighter the Learning Objective, the faster you can learn it.

What actions will you take to learn what you want to learn? In other words, for every Learning Objective create a Learning Plan.  Use the Who, What, When format.  Define Who will do What and When they’ll be done.  To increase the learning rate, define the minimum work to fulfill the narrowly-defined Learning Objective.  Just as you defined the Learning Objective narrowly, define the Learning Plan narrowly.  And to further speed the learning, set constraints like – no one can travel to see customers; no more than five customers can be contacted; and the Learning Plan must be completed in two days.  You’re not looking for large sample sizes and statistical significance; you’re looking to use your best judgement supported by the minimum learning to create reasonable certainty.

How will you decide if you learned what you wanted to learn? Learning requires decisions, decisions require judgement and judgement requires supporting information.  As part of the Learning Plan, define the Learning Information you’ll collect/capture/record to support your decisions.  Audio recordings are good and video is better.  For fast learning, you can record a phone call with a customer or ask them to share their webcam (and record the feed) as you talk with them.  Or you can ask them to shoot some video with their smart phone to provide the information needed to achieve you Learning Objective.

To analyze the data, it’s best to review the audio/video as a group and talk about what you see.  You should watch for body language as well as listen to the words.  Don’t expect complete agreement among your team and expect to create follow-on Learning Objectives and Learning Plans to answer the open questions.  Repeat the process until there’s enough agreement to move forward, but don’t wait for 100% consensus.

When you present your learning to company leadership, show the raw video data that supports your learning.  Practically, you’ll connect company leaders to customers and let the customers dispel long-held biases and challenge old thinking.

There’s nothing more powerful than a customer telling your company leaders how things really are.

Image credit – Thomas Hawk

With creativity, the leading thinking says the most important thing is to create many of ideas.  When asked to generate many of ideas, the thinking goes, the team lets go of their inhibitions and good ideas slip through their mental filters.  I’ve found that thinking misleading.  I’ve found that creating many ideas results in many ideas, but that’s it. Before the session to create new ideas, you already had a pile of ideas you weren’t working on, and after the session is bigger, but not better.

What’s needed is several outlandish ideas that make your hair stand on end. The ideas should be so different that they cause you to chuckle to mask your discomfort.  These ideas should be borderline unbelievable and just south of impossible. The ideas should have the possibility to change the game and tip your industry on its head.

The “many ideas” thinking has the right intent – to loosen the team’s thinking so they generate good ideas, but the approach is insufficient.   To force the team to generated outlandish ideas they must be turned inside-out and put on the rack.  Heretical ideas don’t come easily and drastic measures are needed.  The team must be systematically stripped of the emotional constraints of their success using the Innovation Burst Event (IBE) method.

To prepare for the IBE, a reward-looking analysis is done to identify traditional lines of customer goodness (for example, miles per gallon for automobiles) and define how that goodness has changed over time (position it on the S-curve.)  If the improvement has been flat, it’s time for a new line of customer goodness, and if the goodness is still steadily increasing, it’s time to create a new technology that will provide the next level of improvement.  With this analysis the disposition of the system is defined and potentially fertile design space is identified.  And within this design space, design challenges are created that force the team to exercise the highly fertile design space during the IBE.

Everything about the IBE is designed to strip the team of its old thinking.  The IBE is held at an offsite location to change the scenery and eliminate reminders of traditional thinking and good food is served to help the team feel the day is special.  But the big medicine is the design challenges.  They are crafted to outlaw traditional thinking and push the team toward new thinking.  The context is personal (not corporate) and the scale of the challenge is purposefully small to help the team let go of adjacent concerns.  And, lastly, the team is given an unreasonably short time (five to ten minutes) to solve the problem and build a thinking prototype (a prototype that stands for an idea, not at functional prototype.)

Everything about the IBE helps the team let go of their emotional constraints and emit eye-watering solutions.  The design challenges force them to solve problems in a new design space in a way and does not give them a chance to limit their thinking in any way.  The unrealistic time limit is all-powerful.

Four design challenges is about all team can handle in the one-day IBE.  With the IBE they come up with magical ideas clustered around four new areas, new areas that have the potential to flip your industry on its head.  In one day, a team can define market-changing ideas that obsolete your best products and even your business model.  Not bad for one day.

It may be popular wisdom that it’s best to create many new ideas, but it’s not the best way.  And it contradicts popular belief that a team can create three or four game-changing ideas in a single day.  But the IBEs work as advertised.

Don’t waste time creating a pile of ideas.  Spend the time to identify fertile design space and hold a one-day IBE to come up with ideas that will create your future.

Image credit – moonjazz

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

People ask why.

People buy products from people.

The right people turn activity into progress.

People want to make a difference, and they do.

People have biases which bring a richer understanding.

People use judgement – that’s why robots don’t run projects.

People recognize when the rules don’t apply and act accordingly.

Business models are an interconnected collection of people processes.

The simplest processes require judgement, that’s why they’re run by people.

People don’t like good service, they like effective interaction with other people.

People are the power behind the tools.  (I never met a hammer that swung itself.)

Progress is powered by people.

Image credit – las – intially