Shipulski On Design

Archive for the ‘Clarity’ Category

Since resources are expensive, it can be helpful to see the environment around your product as a source of inexpensive resources that can be modified to perform useful functions.  Here are some examples.

Gravity is a force you can use to do your bidding. Since gravity is always oriented toward the center of the earth, if you change the orientation of an object, you change the direction gravity exerts itself relative to the object. If you flip the object upside down, gravity will push instead of pull.

And it’s the same for buoyancy but in reverse.  If you submerge an object of interest in water and add air (bubbles) from below, the bubbles will rise and push in areas where the bubbles collect.  If you flip over the object, the bubbles will collect in different areas and push in the opposite direction relative to the object.

And if you have water and bubbles, you have a delivery system.  Add a special substance to the air which will collect at the interface between the water and air and the bubbles will deliver it northward.

If you have motion, you also have wind resistance or drag force (but not in deep space).  To create more force, increase speed or increase the area that interacts with the moving air. To change the direction of the force relative to the object, change the orientation of the object relative to the direction of motion.

If you have water, you can also have ice.  If you need a solid substance look to the water.  Flow water over the surface of interest and pull out heat (cool) where you want the ice to form. With this method, you can create a protective coating that can regrow as it gets worn off.

If you have water, you can make ice to create force.  Drill a blind hole in a piece of a brittle material (granite), fill the hole with water, and freeze the water by cooling the granite (or leave it outside in the winter).  When the water freezes it will expand, push on the granite and break it.

These are some contrived examples, but I hope they help you see a whole new set of free resources you can use to make your magic.

Thank you, VF.

Image credit – audi_insperation

Clearing a logjam is not about increasing the force of the water.  It’s about moving one log out of the way, watching what happens, and choosing the next log to move.

Crossing a raging river is not about pushing against the current.  It’s about seeing what’s missing and using logs to build a raft.

Trekking across the tundra after crossing the raging river is not about holding onto the logs that helped you cross. It’s about seeing what’s not needed and leaving the raft by the river.

The trick is to know when to move the logs, when to use them to build a raft, and when to leave them behind.

Image credit: “Log Jam Mural _ Stillwater MN” by Kathleen Tyler Conklin 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.

If you don’t know why you’re doing what you’re doing, you can try to remember why you started the whole thing or you can do something else.  Either can remedy things, but how do you choose between them? If you’ve forgotten your “why”, maybe it’s worth forgetting or maybe something else temporarily came up that pushed your still-important why underground for a short time.  If it’s worth forgetting, maybe it’s time for something else.  And if it’s worth remembering, maybe it’s time to double down.  Only you can choose.

If you still remember why you’re doing what you’re doing, you can ask yourself if your why is still worth its salt or if something changed, either inside you or in your circumstances, that has twisted your why to something beyond salvage. If your why is still as salty as ever, maybe it’s right to stay the course.  But if it’s still as salty as ever but you now think it’s distasteful, maybe it’s time for a change.

When you do what you did last time, are you more efficient or more dissatisfied, or both?  And if you imagine yourself doing it again, do you look forward to more efficiency or predict more dissatisfaction? These questions can help you decide whether to keep things as they are or change them.

What have you learned over the last year?  Whether your list is long or if it’s short, it’s a good barometer to inform your next chapter.

What new skills have you mastered over the last year? Is the list long or short? If you don’t want to grow your mastery, keep things as they are.

Do the people you work with inspire you or bring you down? Are you energized or depleted by them? If you’re into depletion, there’s no need to change anything.

Do you have more autonomy than last year? And how do you feel about that? Let your answers guide your future.

What is the purpose behind what you do? Is it aligned with your internal compass? These two questions can bring clarity.

You’re the only one who can ask yourself these questions; you’re the only one who can decide if you like the answers; and you’re the only one who is responsible for what you do next.  What you do next is up to you.

“Fork in the road” by Kai Hendry is licensed under CC BY 2.0.

If there’s one superpower to develop, it’s to learn how to assess a project and get a good feel for when it will launch.

When you want to know how long a project will take, ask this simple question: ‘What must the project team learn before the project can launch?”  By starting with this single question, you will start the discussion that will lead you to an understanding of what hasn’t been done before and where the uncertainty is hiding.  And if there’s one thing that can accelerate a project, it’s defining where the uncertainty is hiding. And knowing this doubly powerful, like a pure two-for-one, because if you know where uncertainty is, by definition, you know where it isn’t. Where the uncertainty isn’t, you can do what you did last time, and because you’ve done it before, you know how long it will take.  No new tools, no new methods, no new analyses, no new machines, no new skillsets, no new anything. And for the remaining elements of the project, well, that’s where the uncertainty is hiding and that’s where you will focus on the learning needed to secure the launch.

But it can be difficult to understand the specific learning that must be done for a project to launch.  One trick I like to use is the Same-But-Different method. It goes like this.  Identify a project that launched (Project A) that’s most similar to the one that will launch next (Project B) and perform a subtraction of sorts.  Declare that Project B (the one you want to launch) is the same as Project A (the one you already launched) but different in specific ways and then define those differences as clearly and tightly as possible.  And where it’s different, that’s where the learning energy must be concentrated.

Same-But-Different sounds simplistic and trivial, but it isn’t.  More than anything, it’s powerful.  For the elements that are the same, you do what you did last time, which is freeing.  And for the small subset if things that are different, you dig in!

Same-But-Different drives deep clarity and extreme focus, which result in blistering progress and blinding effectiveness.

And for some reason unknown to me, asking a team to define the novel elements of a project is at least fifty times more difficult than asking them how Project B is different than Project A.  So, it feels good to the team when they can use Same-But-Different to quickly easily define what’s different and then point directly to the uncertainty.  And once the team knows where the uncertainty is hiding, it’s no longer hiding.

And if there’s one thing a project team likes, it’s knowing where the uncertainty is hiding.

“The same, but different by the Paris Photographic Co. (c.1880)” by pellethepoet is marked with CC BY 2.0.

Clean-sheet designs are fun, right up until they don’t launch.

When you feel the urge to do a clean-sheet design, go home early.

When you don’t know how to make it better, make it worse and do the opposite.

Without trying, there is no way to know if it will work.

Trying sometimes feels like dying.

But without trying, nothing changes.

Agreement is important, but only after the critical decision has been made.

When there’s 100% agreement, you waited too long to make the decision.

When it’s unclear who the customer is, ask “Whose problem will be solved?”

When the value proposition is unclear, ask ‘What problem will be solved?”

When your technology becomes mature, no one wants to believe it.

When everyone believes the technology is mature, you should have started working on the new technology four years ago.

If your projects are slow, blame your decision-making processes.

Two of the most important decisions: which projects to start and which to stop.

All the action happens at the interfaces, but that’s also where two spans of control come together and chafe.

If you want to understand your silos and why they don’t play nicely together, look at the organizational chart.

When a company starts up, the product sets the organizational structure.

Then, once a company is mature, the organizational structure constrains the product.

At the early stages of a project, there’s a lot of uncertainty.

And once the project is complete, there’s a lot of uncertainty.

“Toys Never Forget” by Alyssa L. Miller is marked with CC BY 2.0.

When you design something, you create a solution to a collection of problems.  But it goes far beyond creating the solution.  You also must create objective evidence that demonstrates that the solution does, in fact, solve the problems.  And the reason to generate this evidence is to help the organization believe that the solution solves the problem, which is an additional requirement that comes with designing something.  Without this belief, the organization won’t go out to the customer base and convince them that the solution will solve their problems.  If the sales team doesn’t believe, the customers won’t believe.

In school, we are taught to create the solution, and that’s it.  Here are the drawings, here are the materials to make it, here is the process documentation to build it, and my work here is done. But that’s not enough.

Before designing the solution, you’ve got to design the tests that create objective evidence that the solution actually works, that it provides the right goodness and it solves the right problems.  This is an easy thing to say, but for a number of reasons, it’s difficult to do.  To start, before you can design the right tests, you’ve got to decide on the right problems and the right goodness.  And if there’s disagreement and the wrong tests are defined, the design community will work in the wrong areas to generate the wrong value.  Yes, there will be objective evidence, and, yes, the evidence will create a belief within the organization that problems are solved and goodness is achieved.  But when the sales team takes it to the customer, the value proposition won’t resonate and it won’t sell.

Some questions to ask about testing. When you create improvements to an existing product, what is the family of tests you use to characterize the incremental goodness?  And a tougher question: When you develop a new offering that provides new lines of goodness and solves new problems, how do you define the right tests? And a tougher question: When there’s disagreement about which tests are the most important, how do you converge on the right tests?

Image credit — rjacklin1975

This seems like a repeat of the last time we set a project launch date without regard for the work content.  Do you see it that way?

This person certainly looks the part and went to the right school, but they have not done this work before.  Why do you think we should hire them even though they don’t have the experience?

The last time we ran a project like this it took two years to complete.  Why do you think this one will take six months?

If it didn’t work last time, why do you think it will work this time?

Why do you think we can do twice the work we did last year while reducing our headcount?

The work content, timeline, and budget are intimately linked. Why do you think it’s possible to increase the work content, pull in the timeline, and reduce the budget?

Seven out of thirteen people have left the team. How many people have to leave before you think we have a problem?

Yes, we’ve had great success with that approach over the last decade, but our most recent effort demonstrated that our returns are diminishing.  Why do you want to do that again?

If you think it’s such a good idea, why don’t you do it?

Why do you think it’s okay to add another project when we’re behind on all our existing projects?

Customers are buying the competitive technology.  Why don’t you believe that they’re now better than we are?

This work is critical to our success, yet we don’t have the skills sets, capacity, or budget to hire it out.  Why are you telling us you will get it done?

This problem seems to fit squarely within your span of responsibility. Why do you expect other teams to fix it for you?

I know a resource gap of this magnitude seems unbelievable but is what the capacity model shows.  Why don’t you believe the capacity model?

We have no one to do that work. Why do you think it’s okay to ask the team to sign up for something they can’t pull off?

Based on the survey results, the culture is declining.  Why don’t you want to acknowledge that?

“I have a question” by The U.S. Army is licensed under CC BY 2.0

For work that has not been done before, there’s no right answer.  The only wrong answer is to say “no” to trying something new.  Sure, it might not work.  But, the only way to guarantee it won’t work is to say no to trying.

If innovation projects fail nine out of ten times, you can increase the number of projects you try or you can get better at choosing the projects to say no to.  I suggest you say learn to say yes to the one in ten projects that will be successful.

If you believe that nine out of ten innovation projects will fail, you shouldn’t do innovation for a living.  Even if true, you can’t have a happy life going to work every day with a ninety percent chance of failure.  That failure rate is simply not sustainable.  In baseball, the very best hitters of all time were unsuccessful sixty percent of the time, yet, even they focused on the forty percent of the time they got it right.  Innovation should be like that.

If you’ve failed on ninety percent of the projects you’ve worked on, you’ve probably been run out of town at least several times.  No one can fail ninety percent of the time and hold onto their job.

If you’ve failed ninety percent of the time, you’re doing it wrong.

If you’ve failed ninety percent of the time, you’ve likely tried to solve the wrong problems.  If so, it’s time to learn how to solve the right problems.  The right problems have two important attributes: 1) People will pay you if they are solved. 2) They’re solvable.  I think we know a lot about the first attribute and far too little about the second. The problem with solvability is that there’s no partial credit, meaning, if a problem is almost solvable, it’s not solvable. And here’s the troubling part: if a problem is almost solved, you get none of the money.  I suggest you tattoo that one on your arm.

As a subject matter expert, you know what could work and what won’t.  And if you don’t think you can tell the difference, you’re not a subject matter expert.

Here’s a rule to live by: Don’t work on projects that you know won’t work.

Here’s a corollary: If your boss asks you to work on something that won’t work, run.

If you don’t think it will work, you’re right, even if you’re not.

If it might work, that’s about right. If it will work, let someone else do it. If it won’t work, run.

If you’ve got no reason to believe it will work, it won’t.

If you can’t imagine it will work, it won’t.

If someone else says it won’t work, it might.

If someone else tries to convince you it won’t work, they may have selfish reasons to think that way.

It doesn’t matter if others think it won’t work. It matters what you think.

So, what do you think?

If you someone asks you to believe something you don’t, what will you do?

If you try to fake it until you make it, the Universe will make you pay.

If you think you can outsmart or outlast the Universe, you can’t.

If you have a bad feeling about a project, it’s a bad project.

If others tell you that it’s a bad project, it may be a good one.

Only you can decide if a project is worth doing.

It’s time for you to decide.

“Good example of Crossfit Weight lifting – In Crossfit Always lift until you reach the point of Failure or you tear something” by CrossfitPaleoDietFitnessClasses is licensed under CC BY 2.0

Speak up.  Your ideas can’t see daylight unless others know about them.

Be wrong. When you’re wrong, you sharpen the rightness.

Be right. When you’re right in the face of wrongness, everyone wins, except for you.

Stand tall. Stand behind your decisions, but you can’t be responsible for their outcome.

Be truthful, but not hurtful.

Be overwhelmed.  This is difficult.

Give it away. When things go well, delegate credit to the up-and-coming.  They’ll remember.

Support others. When someone’s in the bucket, pull them out. They’ll remember.

Pay it forward. A kind soul gave it to you, and it’s time to give it to someone else. They’ll remember.

Say “thank you.” And mean it.

Be quiet. When things are on the right track, there’s no need to derail.

Take the heat. When there’s a mistake, own it so the young don’t have to. They’ll remember.

Make room for others. Nothing blocks their growth like your career aspirations.

Say nothing negative, unless you can’t. And if you must, say it in private.

Praise publicly, loudly, and often.

Set up others for success. And when accused of doing so, plead ignorance.

Share your frustrations, but sparingly. Done skillfully, it’s a compliment.

Be human.  People will notice.

“Uncomfortable Fisher” by DaveFayram is licensed under CC BY-SA 2.0

When there’s disagreement between words and behavior, believe the behavior.  This is especially true when the words deny the behavior.

When there’s disagreement between the data and the decision, the data is innocent.

When there’s agreement that there’s insufficient data but a decision must be made, there should be no disagreement that the decision is judgment-based.

When there’s disagreement on the fact that there’s no data to support the decision, that’s a problem.

When there’s disagreement on the path forward, it’s helpful to have agreement on the process to decide.

When there’s disagreement among professionals, there is no place for argument.

When there’s disagreement, there is respect for the individual and a healthy disrespect for the ideas.

When there’s disagreement, the decisions are better.

When there’s disagreement, there’s independent thinking.

When there’s disagreement, there is learning.

When there’s disagreement, there is vulnerability.

When there’s disagreement, there is courage.

When there’s disagreement, there is trust.

“Teamwork” by davis.steve32 is licensed under CC BY 2.0