Shipulski On Design

Archive for the ‘Imagination’ Category

We all have to-do lists. We add things and we check them off.  This list grows and shrinks.  We judge ourselves negatively when we check off fewer than expected and positively when we check off more than that.  But what’s the right number of completed tasks for us to feel good? How many completed tasks is enough?

If you complete one task per week that saves $5000, is that enough? Is it enough to complete fifty tasks per year?  If you create the conditions that make possible a new product line that delivers $1B over three years, but you do that only once every five years, is that enough? Is it enough to do just that one right thing over five years? What does it look like to others when you complete one exceptionally meaningful task every five years? I think it looks like most of the time you are doing very little.

Sometimes you complete small things and sometimes you don’t.  And sometimes you learn what doesn’t work and that’s the completed task.  And sometimes there are long stretches where nothing is accomplished until you create something magical. Counting tasks is no way to go through life.

But counting and measuring is all the rage.  Look at your yearly goals.  Do ten of these.  Run six of those. Complete twelve of the other.  Why do we think we can predict what we should do next year?  Even sillier, do we really believe we know how many of these, those, and the others we will be able to get done next year?  C’mon.  Really?

What if all this counting prevents us from imagining the future? And what if our unhealthy fascination with measuring blocks us from creating it?

If it’s all about the measurable, there’s no room for the Magical.

Why not make some room for the Magical?

Image credit — Philip McErlean

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

To have something is better than to have nothing, and to focus on everything dilutes progress and leads to nothing. In that way, something can be better than everything.

What do you have and how might you put it to good use right now?

Everything has a history. What worked last time? What did not? What has changed?

What information do you have that you can use right now? And what’s the first bit of new information you need and what can you to do get it right now?

It is always a brown-field site and never a green-field.  You never start from scratch.

What do you have that you can build on right now? How might you use it to springboard into the future?

When it’s time to make a decision, there is always some knowledge about the current situation but the knowledge is always incomplete.

What knowledge do you have right now and how might you use it to advance the cause? What’s the next bit of knowledge you need and why aren’t you trying to acquire that knowledge right now?

You always have your intuition and your best judgment.  Those are both real things. They’re not nothing.

How can you use your intuition to make progress right now? How can you use your judgment to advance things right here and right now?

There’s a singular recipe in all this.

Look for what you have (and you always have something) and build on it right now.  Then look again and repeat.

Image credit – Jeffrey

When you demo something new, you make the technology real.  No longer can they say – that’s not possible.

When you demo something new, you help people see what it is and what it isn’t.  And that brings clarity.

When you demo something new, people take sides. And that says a lot about them.

When you demo something new, be prepared to demo it again. It takes time for people to internalize new concepts.

When someone asks you to repeat the demo so others can see it, it’s a sign there’s something interesting about the demo.  Repeat it.

When someone calls out fault with a minor element of the demo, they also reinforce the strength of the main elements.

When you demo something new and it works perfectly, you should have demo’d it sooner.

When the demo works perfectly, you’re not trying hard enough.

When you demo something new, there is no way to predict the action items spawned by the demo.  In fact, the reason to do the demo is to learn the next action items.

When you demo something new, make the demo short so the conversation can be long.

When you demo something new, shut your mouth and let the demo do the talking.

When you demo something new, keep track of the questions that arise.  Those questions will inform the next demo.

When you demo something new and it’s misunderstood, congratulations. You’ve helped the audience loosen their thinking.

If you want to change people’s thinking, do a demo.

Image credit – Ralf Steinberger

If you can’t imagine it, it’s impossible.

But if you can imagine it, at worst it can only be almost impossible.

Who controls your imagination?

What you think about something affects you like it’s true, even when it isn’t.

And what you think is true often isn’t.

Are you responsible for what you think?

If you have two things to do, that’s doable.  So, do them.

And if you have twenty things to do, chose two and do them.

What if getting ten things done in a week is enough?

If the work is good, it’s likely you’re doing it with people you enjoy.

And if you work with people you enjoy, the work gets better.

Which comes first, the good work or the people you enjoy?

If you tell someone what to do and how to do it, they can do it.

But if you’re not there to tell them, they cannot.

Will you always be there?

If you show you care, people know you care.

And if you tell people you care, they’re not sure.

Why not show them so they can be sure?

If you tell the truth, people can work with you even if they don’t share your truth.

But if you sometimes tell the truth, it means sometimes you don’t.

And how does that work?

image credit — Miranda Granche

When choosing projects there are two competing questions: Is it big enough? And, is it small enough? The project must be big enough to generate the profits required by the company’s growth objectives.  Larger growth objectives require larger projects.  Yet the project has to be small enough to be completed within the time constraints defined by the growth objectives.  Tighter time constraints require smaller projects.

When the projected revenue generated by the candidate project is less than what’s needed to meet the growth objectives, the project is deemed “not big enough.”  But what if the candidate project is the largest project that the project team can imagine? Does that say something about the project team’s imagination or the growth objectives?  Open question: How do tell the difference between a project that is too small to meet the growth objectives and growth objectives that demand projects larger than the project team’s imagination?

When the projected launch date of the candidate project is later than the date of first revenue defined in the growth plan, the project plan is deemed “too long.”  The team is then asked to sharpen their pencils and return with a launch date that meets the revenue timeline.  And when the revised schedule also violates the revenue timeline, the project is deemed “too big.” Open question: How do you tell the difference between a project that is too big to meet the revenue timeline and a revenue timeline that is too stringent to allow a project of sufficient size?

Theoretically, there are candidate projects that are big enough to meet the growth objectives and small enough that their launch dates meet revenue timelines.  But in practice, candidate projects are either too small to meet growth objectives or too large to meet revenue timelines.  And, yes, I have seen candidate projects that are both too small and too large.  But this says more about the growth objectives, revenue timelines, and the number of projects that run concurrently (too few resources spread over too many projects).

Growth objectives are good, and so are projects that fit with the team’s capabilities to deliver.  Incremental revenue that comes sooner rather than later is good.  And so are project timelines that are governed by the work content, resources applied to the projects, and good product development practices.

Truth is, we need it all – projects that deliver the sizzle that sells and projects that launch sooner rather than later.  And year-on-year, we need to get better at delivering on all of it.  And the best way I know to do all that is to ritualistically invest in the people that do the work and the tools they use.

“Horse Yin and Yang” by onecog2many is licensed under CC BY 2.0.

One of the best problems to solve for your customers is the problem they don’t know they have.  If you can pull it off, you will create an entirely new value proposition for them and enable them to do things they cannot do today. But the problem is they can’t ask you to solve it because they don’t know they have it.

To identify problems customs can’t see, you’ve got to watch them go about their business.  You’ve got to watch all aspects of their work and understand what they do and why they do it that way.  And it’s their why that helps you find the transparent problems.  When they tell you their why, they tell you the things they think cannot change and the things they consider fundamental constraints.  Their whys tell you what they think is unchangeable.  And from their perspective, they’re right.  These things are unchangeable because they don’t know what’s possible with new technologies.

Once you know their unchangeable constraints, choose one to work on and turn it into a tight problem statement.  Then use your best tools and methods to solve it.  Once solved, you’ve got to make a functional prototype and show them in person.  Without going back to them with a demonstration of a functional prototype, they won’t believe you.  Remember, you did something they didn’t think was possible and changed the unchangeable.

When demonstrating the prototype to the customer, just show it in action.  Don’t describe it, just show them and let them ask questions.  Listen to their questions so you can see the prototype through their eyes.  And to avoid leading the witness, limit yourself to questions that help you understand why they see the prototype as they do.  The way they see the prototype will be different than your expectations, and that difference is called learning.  And if you find yourself disagreeing with them, you’re doing it wrong.

This first prototype won’t hit the mark exactly, but it will impress the customer and it will build trust with them.  And because they watched the prototype in action, they will be able to tell you how to improve it.  Or better yet, with their newfound understanding of what’s possible, they might be able to see a more meaningful transparent problem that, once solved, could revolutionize their industry.

Customers know their work and you know what’s possible.  And prototypes are a great way to create the future together.

“Transparent” by Rene Mensen is licensed under CC BY 2.0.

A prototype moves us from “That’s not possible.” to “Hey, watch this!”

A prototype moves us from “We don’t do it that way.” to “Well, we do now.”

A prototype moves us from “That’s impossible.” to “As it turns out, it was only almost impossible.”

A prototype turns naysayers into enemies and profits.

A prototype moves us from an argument to a new product development project.

A prototype turns analysis-paralysis into progress.

A prototype turns a skeptical VP into a vicious advocate.

A prototype turns a pet project into top-line growth.

A prototype turns disbelievers into originators of the idea.

A prototype can turn a Digital Strategy into customer value.

A prototype can turn an uncomfortable Board of Directors meeting into a pizza party.

A prototype can save a CEO’s ass.

A prototype can be too early, but mostly they’re too late.

If the wheels fall off your first prototype, you’re doing it right.

If your prototype doesn’t dismantle the Status-Quo, you built the wrong prototype.

A good prototype violates your business model.

A prototype doesn’t care if you see it for what it is because it knows everyone else will.

A prototype turns “I don’t believe you.” into “You don’t have to.”

When you’re told “Don’t make that prototype.” you’re onto something.

A prototype eats not-invented-here for breakfast.

A prototype can overpower the staunchest critic, even the VP flavor.

A prototype moves us from “You don’t know what you’re talking about.” to “Oh, yes I do.”

If the wheels fall off your second prototype, keep going.

A prototype is objective evidence you’re trying to make a difference.

You can argue with a prototype, but you’ll lose.

If there’s a mismatch between the theory and the prototype, believe the prototype.

A prototype doesn’t have to do everything, but it must do one important thing for the first time.

A prototype must be real, but it doesn’t have to be really real.

If your prototype obsoletes your best product, congratulations.

A prototype turns political posturing into reluctant compliance and profits.

A prototype turns “What the hell are you talking about?” into “This.”

A good prototype bestows privilege on the prototyper.

A prototype can beat a CEO in an arm-wrestling match.

A prototype doesn’t care if you like it. It only cares about creating customer value.

If there’s an argument between a well-stated theory and a well-functioning prototype, it’s pretty clear which camp will refine their theory to line up with what they just saw with their own eyes.

A prototype knows it has every right to tell the critics to “Kiss my ass.” but it knows it doesn’t have to.

You can argue with a prototype, but shouldn’t.

A prototype changes thinking without asking for consent.

Image credit — Pedro Ribeiro Simões

When there’s a big problem, the first step is to define what’s causing it. To do that, based on an understanding of the physics, a sequence of events is proposed and then tested to see if it replicates the problem. In that way, the team must understand the system as it is before the problem can be solved.

Seeing things as they are. The same logic applies when it’s time to improve an existing product or service. The first thing to do is to see the system as it is. But seeing things as they are is difficult. We have a tendency to see things as we want them or to see them in ways that make us look good (or smart). Or, we see them in a way that justifies the improvements we already know we want to make.

To battle our biases and see things as they are, we use tools such as block diagrams to define the system as it is. The most important element of the block diagram is clarity.  The first revision will be incorrect, but it must be clear and explicit. It must describe things in a way that creates a singular understanding of the system. The best block diagrams can be interpreted only one way.  More strongly, if there’s ambiguity or lack of clarity, the thing has not yet risen to the level of a block diagram.

The block diagram evolves as the team converges on a single understanding of things as they are. And with a diagram of things as they are, a solution is readily defined and validated. If when tested the proposed solution makes the problem go away, it’s inferred that the team sees things as they are and the solution takes advantage of that understanding to make the problem go away.

Seeing things as they may be. Even whey the solution fixes the problem, the team really doesn’t know if they see things as they are. Really, all they know is they see things as they may be. Sure, the solution makes the problem go away, but it’s impossible to really know if the solution captures the physics of failure.  When the system is large and has a lot of moving parts, the team cannot see things as they are, rather, they can only see the system as it may be. This is especially true if the system involves people, as people behave differently based on how they feel and what happened to them yesterday.

There’s inherent uncertainty when working with larger systems and systems that involve people.  It’s not insurmountable, but you’ve got to acknowledge that your understanding of the system is less than perfect. If your company is used to solving small problems within small systems, there will be little tolerance for the inherent uncertainty and associated unpredictability (in time) of a solution.  To help your company make the transition, replace the language of “seeing things as they are” with “seeing things as they may be.”  The same diagnostic process applies, but since the understanding of the system is incomplete or wrong, the proposed solutions cannot not be pre-judged as “this will work” and “that won’t work.”  You’ve got to be open to all potential solutions that don’t contradict the system as it may be. And you’ve got to be tolerant of the inherent unpredictability of the effort as a whole.

Seeing things as they could be. To create something that doesn’t yet exist, something does things like never before, something altogether new, you’ve got to stand on top of your understanding of the system and jump off.  Whether you see things as they are or as they may be, the new system will be different. It’s not about diagnosing the existing system; it’s about imagining the system as it could be. And there’s a paradox here. The better you understand the existing system, the more difficulty you’ll have imagining the new one. And, the more success the company has had with the system as it is, the more resistance you’ll feel when you try to make the system something it could be.

Seeing things as they could be takes courage – courage to obsolete your best work and courage to divest from success. The first one must be overcome first. Your body creates stress around the notion of making yourself look bad. If you can create something altogether better, why didn’t you do it last time? There’s a hit to the ego around making your best work look like it’s not all that good. But once you get over all that, you’ve earned the right to go to battle with your organization who is afraid to move away from the recipe responsible for all the profits generated over the last decade.

But don’t look at those fears as bad. Rather, look at them as indicators you’re working on something that could make a real difference.  Your ego recognizes you’re working on something better and it sends fear into your veins. The organization recognizes you’re working on something that threatens the status quo and it does what it can to make you stop. You’re onto something. Keep going.

Seeing things as they can’t be. This is rarified air. In this domain you must violate first principles. In this domain you’ve got to run experiments that everyone thinks are unreasonable, if not ill-informed. You must do the opposite. If your product is fast, your prototype must be the slowest. If the existing one is the heaviest, you must make the lightest. If your reputation is based on the highest functioning products, the new offering must do far less.  If your offering requires trained operators, the new one must prevent operator involvement.

If your most seasoned Principal Engineer thinks it’s a good idea, you’re doing it wrong. You’ve got to propose an idea that makes the most experienced people throw something at you. You’ve got to suggest something so crazy they start foaming at the mouth. Your concepts must rip out their fillings. Where “seeing things as they could be” creates some organizational stress, “seeing things as they can’t be” creates earthquakes. If you’re not prepared to be fired, this is not the domain for you.

All four of these domains are valuable and have merit. And we need them all. If there’s one message it’s be clear which domain you’re working in. And if there’s a second message it’s explain to company leadership which domain you’re working in and set expectations on the level of uncertainty and unpredictability of that domain.

Image credit – David Blackwell.

To create future success, you’ve got to outlaw the very thing responsible for your past success.

Sometimes slower is faster and sometimes slower is slower. But it’s always a judgement call.

We bite the bullet and run expensive experiments because they’re valuable, but we neglect to run the least expensive thought experiments because they’re too disruptive.

There’s an infinite difference between the impossible and the almost impossible. And the people that can tell the difference are infinitely important.

If you know how to do it, so does your competition. Do something else.

We want differentiation, but we can’t let go of the sameness of success.

People that make serious progress take themselves lightly.

If you can predict when the project will finish, you can also predict customers won’t be excited when you do.

If you don’t have time to work on something, you can still work on it a little a time.

Perfection is good, but starting is better.

Sometimes it’s time to think and sometimes it’s time to do. And it’s easy to decide because doing starts with thinking.

When your plate is full and someone slops on a new project, there may be a new project on your plate but there’s also another project newly flopped on the floor.

New leaders demand activity and seasoned professionals make progress.

Sometimes it’s not ready, but most of the time it’s ready enough.

There’s no partial credit for almost done. That’s why pros don’t start a project until they finish one.

In this age of efficiency, effectiveness is far more important.

Image credit — Silentmind8

In business and in life, one of the biggest choices is what to do next.  Sounds simple, but it’s not.

The decision has many facets and drives many questions, for example:  Does it fit with core competence? Does it fit with the brand? How many will we sell? What will the market look like after it’s launched? Do we have what it takes to pull it off?

These questions then explode into a series of complex financial analyses like – return on investment, return on capital, return on net assets (and all its flavors) and all sorts of yet-to-be created return on this’s and that’s.  This return business is all about the golden ratio – how much will we make relative to how much it costs.  All the calculations, regardless of their name, are variations on this theme. And all suffer the same fundamental flaw – they are based on an artificial system of financial accounting.

To me, especially when working in new territory, we must transcend the self-made biases and limitations of GAAP and ask the bedrock question – Is it worth it?

In the house of cards of our financial accounting, worth equals dollars. Nothing more, nothing less.  And this simplistic, formulaic characterization has devastating consequence.  Worth is broader than profit, it’s nuanced, it’s philosophical, it’s about people, it’s about planet. Yet we let our accounting systems lead us around by the nose as if people don’t matter, like the planet doesn’t matter, like what we stand for doesn’t matter. Simply put, worth is not dollars.

The single-most troubling artifact of our accounting systems is its unnatural bias toward immediacy.  How much will we make next year? How about next quarter? What will we spend next month? If we push out the expense by a month how much will we save? What will it do to this quarter’s stock price? It’s like the work has no validity unless the return on investment isn’t measured in days, weeks or months. It seems the only work that makes it through the financial analysis gauntlet is work that costs nothing and returns almost nothing. Under the thumb of financial accounting, projects are small in scope, smaller in resource demands and predictable in time.  This is a recipe for minimalist improvement and incrementalism.

What about the people doing the work? Why aren’t we concerned they can’t pay their mortgages? Why do we think it’s okay to demand they work weekends? Why don’t we hold their insurance co-pays at reasonable levels? Why do we think it’s okay to slash our investment in their development? What about their self-worth? Just because we can’t measure it in a financial sense, don’t we think it’s a liability to foster disenchantment and disengagement? If we considered our people an asset in a financial accounting sense, wouldn’t we invest in them to protect their output? Why do we preventive maintenance on our machines but not our people?

When doing innovative work, our financial accounting systems fail us. These systems were designed in an era when it was best to increase the maturity of immature systems.  But now that our systems are mature, and our objective is to obsolete them, our ancient financial accounting systems hinder more than help. The domains of reinvention and disruption are dominated by judgement, not rigid accounting rules.  Innovation is the domain of incomplete data and uncertain outcomes and not the domain of debits and credits.

Profit is important, but profit is a result.  Financial accounting doesn’t create profit, people create profit. And the currency of people are thoughts, feelings and judgement.

With innovation, it’s better to create the conditions so people believe in the project and are fully engaged in their work. With creativity, it’s better to have empowered people who will move mountains to do what must be done. With work that’s new, it’s better to trust people and empower them to use their best judgement.

Image credit – Jeremy Tarling