GUEST POST from Mike Shipulski

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

Sign up here to join 17,000+ leaders getting Human-Centered Change & Innovation Weekly delivered to their inbox every week.

GUEST POST from Mike Shipulski

If you want to gain ground on your competition you’ve first got to know where things stand. Where are their advantages? Where are your advantages? Where is there parity? To quickly understand the situations there are three tricks: stay at a high level, represent the situation in a clear way and, where possible, use public information from their website.

A side-by-side comparison of the two companies’ products is the way to start.  Create a common set of axes with price running south to north and performance (or output) running west to east. Make two copies and position them side-by-side on the page – yours on the left and theirs directly opposite on the right. Go to their website (and yours) and make a list of every product, its price, and its output. (For prices of their products you may have to engage your sales team and your customers.) For each of your products place a symbol (the company logo) on your performance-price landscape and do the same for their products on their landscape.

It’s now clear who has the most products, where their portfolio outflanks yours and where you outflank them. The clarity and simplicity will help everyone see things as they are – there may be angst but there will be no confusion and no disagreement. The picture is clear. But it’s static.

The areal differences define the gaps to close and the advantages to exploit. Now it’s time to define the momentum and trajectories of the portfolios to add a dynamic element. For your most recent product launch add a one next to its logo, for the second most recent add a two and for the third add three. These three regions of your portfolio are your most recent focus areas. This is your trajectory and this is where you have momentum. Extend and arrow in the direction of your trajectory. If you stay the course, this is where your portfolio will add mass. Do the same for your competitor and compare arrows.

You now have a glimpse into the future. Are your arrows pointing in the same directions as theirs? Are they located in the same regions? How would feel if both companies continued on their trajectories? With this addition, you have a glimpse into the stay-the-course future. But will they stay the course? For that, you need to look at the patent landscape.

Do a patent search on their patents and applications over the previous year and represent each with its most descriptive figure. Write a short thematic description for each group like themes and draw a circle around them. Mark the circle with a one to denote last year’s patents.  Repeat the process for two years ago and three years ago and mark each circle accordingly.

Now you have objective evidence of the future. You know where they have been working and you know where they want to go. You have more than a glimpse into the future.

You know their preferred trajectories.  Reconcile their preferred trajectories with their price-performance landscapes and arrows 1, 2 and 3.  If their preferred trajectories line up with their product momentum, it’s business as usual for them.  If they contradict, they are playing a different game. And because it takes several years for patent applications to publish, they’ve been playing a new game for a while now.

Repeat the process for your patent landscape and flop it onto your performance-price landscape. I’m not sure what you’ll see, but you’ll know it when you see it. Then, compare yours with theirs and you’ll know what the competitive landscape will look like in three years. You may like what you see, or not. But, the picture will be clear. There may be discomfort, but there can be no arguments.

This process can also be used in the acquisition process to get a clear picture a company’s future state. In that way, you can get a calibrated view three years into the future and use your crystal ball to adjust your offer price accordingly.

image credit – Rob Ellis

Sign up here to join 17,000+ leaders getting Human-Centered Change & Innovation Weekly delivered to their inbox every week.

GUEST POST from Mike Shipulski

Expectations result from mental models and wants. When you have a mental model of a system and you want the system to behave in a way that fits your mental model, that’s an expectation. And when you want the system to behave differently than your mental model, that’s also an expectation. When the system matches your wants, the world is good. And when your wants are out of line with the system, the world is not so good.

Speculation is not expectation.

Speculation happens when you propose, based on your mental model, how the system will behave. With speculation, there’s no attachment to the result, no wanting it to be one way or another. There’s just watching and learning.  If the system confirms your mental model, the applicability of the model is reinforced (within this narrow context.) And when the system tramples your mental model, you change your mental model. No attachment, no stress, no whining, no self-judgement.

When doing work that’s new, system response is unknown. Whether the system will be exercised in a new way or it’s an altogether new system, metal models are young and untested. When it’s the first time, speculation is the way to go. Come up with your best mental model, run the experiment and record the results. After sitting in data, refine your mental model and repeat.   If your mental model doesn’t fit the system, don’t judge yourself negatively, don’t hold yourself back, don’t shy away. Refine your mental model and build-test-learn as fast as you can. And if your mental model fits the system, don’t judge yourself in a positive way. This was your first test and you don’t understand the system fully. Refine your model and test for a deeper understanding.  [Note – systems have been known to temporarily conform to mental models to obfuscate their true character.]

When doing work that’s new, expectation gets in the way.

If you expect your models to be right and they’re not, you learning rate is slower than your expectations. That’s not such a big deal on its own, but the rippling self-judgement can be crippling. Your emotional state becomes fragile and it’s difficult to keep pushing through the work. You doubt yourself and your abilities; you won’t put yourself out there; and you won’t propose radical mental models for fear of looking like you don’t know what you’re doing. You won’t run the right experiments and you never the understand the fundamental character of the system. You block your own learning.  If you expect your models won’t to fit the system, you block your learning from the start. Sometimes your lack of confidence blocks you from even trying. [Note – not trying is the only way to guarantee you won’t learn.]

Within the domain of experiments, mental models and generic systems, it’s relatively easy to see the wisdom of speculations and the perils of expectations, where wanting leads to judging and judging leads to self-blocking. But it’s not so easy to see in the domain of life where experiments are replaced with personal interactions and generic systems are replaced with everyday situations and mental models are ever-present. But in both domains the rules and consequences are the same.

Just as in the lab, in day-to-day life expectations are dangerous.

Sign up here to join 17,000+ leaders getting Human-Centered Change & Innovation Weekly delivered to their inbox every week.

GUEST POST from Mike Shipulski

If 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 under a 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: scorpiomasonry.com

Sign up here to join 17,000+ leaders getting Human-Centered Change & Innovation Weekly delivered to their inbox every week.

GUEST POST from Mike Shipulski

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 Winston Churchill, the only thing to fear was fear itself.  For business, the only thing to fear is the cow path of success.

image credit – JasonParis

Sign up here to join 17,000+ leaders getting Human-Centered Change & Innovation Weekly delivered to their inbox every week.

GUEST POST from Mike Shipulski

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 to 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 waving, 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 the previous two questions, there are variants that work 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: © Jerry Goldner Profiles of Nature

Sign up here to join 17,000+ leaders getting Human-Centered Change & Innovation Weekly delivered to their inbox every week.