Archive for the ‘New Thinking’ Category

How It Goes With Demos

Demoing something for the first time is difficult, but doing it for the second time is easy.  And when you demo a new solution the first time, it (and you) will be misunderstood.

What is the value of this new thing?  This is a good question because it makes clear they don’t understand it. After all, they’ve never seen it before.  And it’s even better when they don’t know what to call it. Keep going!

Why did you do this?  This is a good question because it makes clear they see the demo as a deviation from historically significant lines of success.  And since the lines of success are long in the tooth, it’s good they see it as a violation of what worked in the olden days.  Keep going!

Whose idea was this? This is code: “This crazy thing is a waste of time and we could have applied resources to that tired old recipe we’ve been flogging for a decade now.”  It means they recognize the prototype will be received differently by the customer.  They don’t think it will be received well, but they know the customer will think it’s different.  Keep going!

Who approved this work? This is code: “I want to make this go away and I hope my boss’s boss doesn’t know about it so I can scuttle the project.”  But not to worry because the demo is so good it cannot be dismissed, ignored, or scuttled. Keep going!

Can you do another demo for my boss?  This one’s easy.  They like it and want to increase the chances they’ll be able to work on it.  That’s a nice change!

Why didn’t you do this, that, or the other? They recognized the significance, they understood the limitations, and they asked a question about how to make it better. Things are looking up!

How much did the hardware cost? They see the new customer value and want to understand if the cost is low enough to commercialize with a good profit margin.  There’s no stopping this thing!

Can we take it to the next tradeshow and show it to customers?  Success!

Image credit — Bennilover

Show Them What’s Possible

When you want to figure out what’s next, show customers what’s possible.  This is much different than asking them what they want.  So, don’t do that.  Instead, show them a physical prototype or a one-page sales tool that explains the value they would realize.

When they see what’s possible, the world changes for them.  They see their work from a new perspective. They see how the unchangeable can change.  They see some impossibilities as likely.  They see old constraints as new design space.  They see the implications of what’s possible from their unique context.  And they’re the only ones that can see it.  And that’s one of the main points of showing them what’s possible – for YOU to see the implications of what’s possible from their perspective.  And the second point is to hear from them what you should have shown them, how you missed the mark, and what you should show them next time.

When you show customers what’s possible, that’s not where things end.  It’s where things start.

When you show customers what’s possible, it’s an invitation for them to tell you what it means to them.  And it’s also an invitation for you to listen.  But listening can be challenging because your context is different than theirs.  And because they tell you what they think from their perspective, they cannot be wrong.  They might be the wrong customer, or you might have a wrong understanding of their response, but how they see it cannot be wrong.  And this can be difficult for the team to embrace.

What you do after learning from the customer is up to you.  But there’s one truism – what you do next will be different because of their feedback.  I am not saying you should do what they say or build what they ask for.  But I think you’ll be money ahead if your path forward is informed by what you learn from the customers.

Image credit —  Alexander Henning Drachmann

When You Don’t Know What To Do…

When you don’t know what to do, what do you do?  This is a difficult question.

Here are some thoughts that may help you figure out what to do when you really don’t know.

Don’t confuse activity with progress.

Gather your two best friends, go off-site, and define the system as it is.

Don’t ask everyone what they think because the Collective’s thoughts will be diffuse, bland, and tired.

Get outside.

Draw a picture of how things work today.

Get a good meal.

Make a graph of goodness over time.  If it’s still increasing, do more of what you did last time.  If it’s flat, do something else.

Get some exercise.

Don’t judge yourself negatively.  This is difficult work.

Get some sleep.

Help someone with their problem.  The distraction will keep you out of the way as your mind works on it for you.

Spend time with friends.

Try a new idea at the smallest scale. It will likely lead to a better one. Repeat.

Use your best judgment.

Image credit – Andrew Gustar

Small Teams are Mighty

When you want new thinking or rapid progress, create a small team.

When you have a small team, they manage the handoffs on their own and help each other.

Small teams hold themselves accountable.

With small teams, one member’s problem becomes everyone’s problem in record time.

Small teams can’t work on more than one project at a time because it’s a small team.

And when a small team works on a single project, progress is rapid.

Small teams use their judgment because they have to.

The judgment of small teams is good because they use it often.

On small teams, team members are loyal to each other and set clear expectations.

Small teams coordinate and phase the work as needed.

With small teams, waiting is reduced because the team members see it immediately.

When something breaks, small teams fix it quickly because the breakage is apparent to all.

The tight connections of a small team are magic.

Small teams are fun.

Small teams are effective.

And small teams are powered by trust.

 

LEGO Octan pit crew celebrating High Five Day (held every third Thursday of April)” by Pest15 is marked with CC BY-SA 2.0.

Wrong Questions to Ask When Doing Technology Development

I know you’re trying to do something that has never been done before, but when will you be done? I don’t know.  We’ll run the next experiment then decide what to do next.  If it works, we’ll do more of that.  And if it doesn’t, we’ll do less of that. That’s all we know right now.

I know you’re trying to create something that is new to our industry, but how many will we sell? I don’t know. Initial interviews with customers made it clear that this is an important customer problem. So, we’re trying to figure out if the technology can provide a viable solution.  That’s all we know right now.

No one is asking for that obscure technology. Why are you wasting time working on that?  Well, the voice of the technology and the S-curve analyses suggest the technology wants to move in this direction, so we’re investing this solution space.  It might work and it might not.  That’s all we know right now.

Why aren’t you using best practices? If it hasn’t been done before, there can be no best practice.  We prefer to use good practice or emergent practice.

There doesn’t seem like there’s been much progress.  Why aren’t you running more experiments? We don’t know which experiments to run, so we’re taking some time to think about what to do next.

Will it work?  I don’t know.

That new technology may obsolete our most profitable product line.  Shouldn’t you stop work on that? No. If we don’t obsolete our best work, someone else will. Wouldn’t it be better if we did the obsoleting?

How many more people do you need to accelerate the technology development work? None.  Small teams are better.

Sure, it’s a cool technology, but how much will it cost?  We haven’t earned the right to think about the cost.  We’re still trying to make it work.

So, what’s your solution? We don’t know yet.  We’re still trying to formulate the customer problem.

You said you’d be done two months ago.  Why aren’t you done yet? I never said we’d be done two months ago. You asked me for a completion date and I could not tell you when we’d be done.  You didn’t like that answer so I suggested that you choose your favorite date and put that into your spreadsheet. We were never going to hit that date, and we didn’t.

We’ve got a tight timeline.  Why are you going home at 5:00? We’ve been working on this technology for the last two years.  This is a marathon.  We’re mentally exhausted.  See you tomorrow.

If you don’t work harder, we’ll get someone else to do the technology development work.  What do you think about that? You are confusing activity with progress.  We are doing the right analyses and the right thinking and we’re working hard.  But if you’d rather have someone else lead this work, so would I.

We need a patented solution.  Will your solution be patentable? I don’t know because we don’t yet have a solution. And when we do have a solution, we still won’t know because it takes a year or three for the Patent Office to make that decision.

So, you’re telling me this might not work?  Yes. That’s what I’m telling you.

So, you don’t know when you’ll be done with the technology work, you don’t know how much the technology will cost, you don’t know if it will be patentable, or who will buy it? That’s about right.

Image credit — Virtual EyeSee

The zero-sum game is a choice.

With a zero-sum game, if you eat a slice of pie, that’s one less for me; and if I eat one, that’s one less for you. A simple economic theory, but life isn’t simple like that. Here’s how life can go.

Get with expectation – I expect you to give, and you do.

Get without expectation – I don’t expect you to give, but you do. I’m indifferent.

Get with thanks – I don’t expect you to give, and when you do, I thank you graciously.

Get then give – I get from you, then a couple weeks later, I think of you and give back.

Get and give – I get from you, and I give back immediately. I choose what I give.

Give and get – I give to you, and you give back immediately. You chose what you give.

Give as get – I give to you so I can feel the joy of giving.

Give – I give because I give.

The zero-sum game is a choice. Which game will you chose to play?

Image credit – Mark Freeth

See differently to solve differently.

There are many definitions for creativity and innovation, but none add meaningfully to how the work is done. Though it’s clear why the work is important – creativity and innovation underpin corporate prosperity and longevity – it’s especially helpful to know how to do it.

At the most basic level, creativity and innovation are about problem solving.  But it’s a special flavor of problem solving.  Creativity and innovation are about problems solving new problems in new ways.  The glamorous part is ‘solving in new ways’ and the important part is solving new problems.

With continuous improvement the same problems are solved over and over. Change this to eliminate waste, tweak that to reduce variation, adjust the same old thing to make it work a little better.  Sure, the problems change a bit, but they’re close cousins to the problems to the same old problems from last decade. With discontinuous improvement (which requires high levels of creativity and innovation) new problems are solved.  But how to tell if the problem is new?

Solving new problems starts with seeing problems differently.

Systems are large and complicated, and problems know how to hide in the nooks and crannies. In a Where’s Waldo way, the nugget of the problem buries itself in complication and misuses all the moving parts as distraction. Problems use complication as a cloaking mechanism so they are not seen as problems, but as symptoms.

Telescope to microscope. To see problems differently, zoom in.  Create a hand sketch of the problem at the microscopic level.  Start at the system level if you want, but zoom in until all you see is the problem.  Three rules: 1. Zoom in until there are only two elements on the page. 2. The two elements must touch. 3. The problem must reside between the two elements.

Noun-verb-noun. Think hammer hits nail and hammer hits thumb.  Hitting the nail is the reason people buy hammers and hitting the thumb is the problem.

A problem between two things. The hand sketch of the problem would show the face of the hammer head in contact with the surface of the thumb, and that’s all.  The problem is at the interface between the face of the hammer head and the surface of the thumb. It’s now clear where the problem must be solved. Not where the hand holds the shaft of the hammer, not at the claw, but where the face of the hammer smashes the thumb.

Before-during-after. The problem can be solved before the hammer smashes the thumb, while the hammer smashes the thumb, or after the thumb is smashed.  Which is the best way to solve it? It depends, that’s why it must be solved at the three times.

Advil and ice. Solving the problem after the fact is like repair or cleanup. The thumb has been smashed and repercussions are handled in the most expedient way.

Put something between. Solving the problem while it happens requires a blocking or protecting action. The hammer still hits the thumb, but the protective element takes the beating so the thumb doesn’t.

Hand in pocket. Solving the problem before it happens requires separation in time and space. Before the hammer can smash the thumb it is moved to a safe place – far away from where the hammer hits the nail.

Nail gun. If there’s no way for the thumb to get near the hammer mechanism, there is no problem.

Cordless drill. If there are no nails, there are no hammers and no problem.

Concrete walls. If there’s no need for wood, there’s no need for nails or a hammer. No hammer, no nails, no problem.

Discerning between symptoms and problems can help solve new problems. Seeing problems at the micro level can result in new solutions. Looking closely at problems to separate them time and space can help see problems differently.

Eliminating the tool responsible for the problem can get rid of the problem of a smashed thumb, but it creates another – how to provide the useful action of the driven nail.  But if you’ve been trying to protect thumbs for the last decade, you now have a chance to design a new way to fasten one piece of wood to another, create new walls that don’t use wood, or design structures that self-assemble.

Image credit – Rodger Evans

Diabolically Simple Prototypes

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

Moving Away from Best Practices

rotten-appleIf the work is new, there is no best practice.

When you read the best books you’ll understand what worked in situations that are different than yours.  When you read the case studies you’ll understand how one company succeeded in a way that won’t work in yours.  The best practices in the literature worked in a different situation, in a different time and a under different cultural framework.  They won’t work best for you.

Just because a practice worked last time doesn’t mean it’s a best practice this time.  More strongly, just because it worked last time doesn’t mean it was best last time. There may have been a better way.

When a problem has high urgency it should be solved in a fast way, but if urgency is low, the problem should be solved in an efficient way. Which way is best? If the consequences of getting it wrong are severe, analyses and parallel solutions are skillful, but if it’s not terribly important to get it right, a lower cost way is better.  But is either the best way?

The best practices found in books are usually described a high level of abstraction using action words, block diagrams and arrows.  And when described at such a high level, they’re not actionable.  You may know all the major steps, but you won’t know how each step should be done.  And if the detail is provided, the context of your situation is different and the prescriptive steps don’t apply.

Instead of best practices, think effective practices.  Effective because the people doing the work can do it effectively.  Effective because it fits with the capability and capacity of the people doing the work.  Effective because it meshes with existing processes and projects.  Effective because it fits with your budget, timeline and risk profile.  Effective because it fits with your company values.

Because all our systems are people systems, there are no best practices.

image credit — johnwayne2006

When doing new work, you’ll be wrong.

OOPSWhen 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

How To Learn Quickly

ProblemsWhen 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

Mike Shipulski Mike Shipulski
Subscribe via Email

Enter your email address:

Delivered by FeedBurner

Archives