Shipulski On Design

Posts Tagged ‘Problems’

Before you can make improvements, you must identify improvement opportunities.

Before you can identify improvement opportunities, you must look for them.

Before you can look for improvement opportunities, you must believe improvement is possible.

Before believing improvement is possible, you must admit there’s a need for improvement.

Before you can admit the need for improvement, you must recognize the need for improvement.

Before you can recognize the need for improvement, you must feel dissatisfied with how things are.

Before you can feel dissatisfied with how things are, you must compare how things are for you relative to how things are for others (e.g., competitors, coworkers).

Before you can compare things for yourself relative to others, you must be aware of how things are for others and how they are for you.

Before you can be aware of how things are, you must be calm, curious, and mindful.

Before you can be calm, curious, and mindful, you must be well-rested and well-fed.  And you must feel safe.

What choices do you make to be well-rested? How do you feel about that?

What choices do you make to be well-fed? How do you feel about that?

What choices do you make to feel safe? How do you feel about that?

Image credit — Philip McErlean

Improvement is progress.  Improvement is always measured against a baseline, so the first thing to do is to establish the baseline, the thing you make today, the thing you want to improve.  Create an environment to test what you make today, create the test fixtures, define the inputs, create the measurement systems, and write a formal test protocol.  Now you have what it takes to quantify an improvement objectively.  Test the existing product to define the baseline.  No, you haven’t improved anything, but you’ve done the right first thing.

Improving the right thing to make progress.  If the problem invalidates the business model, stop what you’re doing and solve it right away because you don’t have a business if you don’t solve it. Any other activity isn’t progress, it’s dilution.  Say no to everything else and solve it.  This is how rapid progress is made.  If the customer won’t buy the product if the problem isn’t solved, solve it.  Don’t argue about priorities, don’t use shared resources, don’t try to be efficient.  Be effective.  Do one thing.  Solve it.  This type of discipline reduces time to market.  No surprises here.

Avoiding improvement of the wrong thing to make progress.  For lesser problems, declare them nuisances and permit yourself to solve them later.   Nuisances don’t have to be solved immediately (if at all) so you can double down on the most important problems (speed, speed, speed).  Demoting problems to nuisances is probably the most effective way to accelerate progress.  Deciding what you won’t do frees up resources and emotional bandwidth to make rapid progress on things that matter.

Work the critical path to make progress. Know what work is on the critical path and what is not.  For work on the critical path, add resources.  Pull resources from non-critical path work and add them to the critical path until adding more slows things down.

Eliminate waiting to make progress.  There can be no progress while you wait.  Wait for a tool, no progress.  Wait for a part from a supplier, no progress.  Wait for raw material, no progress.  Wait for a shared resource, no progress.  Buy the right tools and keep them at the workstations to make progress.  Pay the supplier for priority service levels to make progress.  Buy inventory of raw materials to make progress.  Ensure shared resources are wildly underutilized so they’re available to make progress whenever you need to.  Think fire stations, fire trucks, and firefighters.

Help the team make progress. As a leader, jump right in and help the team know what progress looks like.  Praise the crudeness of their prototypes to help them make them cruder (and faster) next time.  Give them permission to make assumptions and use their judgment because that’s where speed comes from.  And when you see “activity” call it by name so they can recognize it for themselves, and teach them how to turn their effort into progress.

Be relentless and respectful to make progress. Apply constant pressure, but make it sustainable and fun.

Image credit — Clint Mason

Do the project right or do the right project – which would you choose?

If you improve time to market, the only thing that improves is time to market.  How do you feel about that?

Customers pay for things that make their lives easier.  Time to market doesn’t do that.

There’s no partial credit with new product development projects.  If the product isn’t 100% ready for sale, it’s 0% ready.

If you made 1/8^th progress on 8 projects, you made zero progress. But you did consume valuable resources.

If you made 100% progress on one project, you made progress.

When you have too many projects, you get too few done.

If you don’t know how many projects your company has, you have too many.

Would you rather choose the right project and run it inefficiently or choose the wrong project and run it efficiently?

When you choose the wrong project but run it efficiently, that’s called efficient ineffectiveness.

You can save several weeks making sure you choose the right project by starting the project too soon and running the wrong one for two years.

If your projects are slow, it’s likely the support functions are too highly utilized.  Add capacity to keep their peak utilization below 85%.

When shared resources are sized appropriately, they’re underutilized most of the time.  Think fire station and firefighters – when there’s a fire they respond quickly, and when there’s no fire they improve their skills so they can fight the next one better than the last.

If your projects are slow, check to see if you have resources on the critical path that work part-time.  Part-time resources support multiple projects and don’t work full-time on your project.  And you can’t control when they work on your project.  There’s no place for that on the critical path.

If you’re thinking about using part-time resources on the critical path, don’t.

Know where the novelty is and work that first.  And before you can work on the novelty you’ve got to know where it is.

You can have too little novelty, meaning the new product is so much like the old one there’s no need to launch it.  Mostly, though, projects have too much novelty.

If you are working on a clean-sheet design, there is no such thing.  There are no green-field projects.  All projects are brown-field projects. It’s just that some are browner than others.

Novelty generates problems and problems take three times longer to solve than anyone thinks.  To reduce the number of problems, declare as many as possible as annoyances.  Unlike problems, annoyances don’t have to be solved by the project.  Remember, it’s okay to save some work for the next project.

Even though you have a product development process, that process is powered by people.  People make it work and people make it not work.  If you get one thing right, get the people part right.

Image credit – claudia gabriela marques

The time to start getting ready is before we need to be.

We don’t get ready because the problem hasn’t yet kicked us in the head.  It has only started getting ready to do so.

We don’t get ready because we don’t see the early warning signs.  Like the meteorologist who doesn’t make time to look at the radar and satellite images, if we don’t look, we can’t see.  And if we’re really busy, we don’t make time to look.  What if it was part of our job to look at the satellite images? Who in our company should have that job?

We don’t get ready because we don’t heed the early warning signs. Seeing the warning signs is much different than justifying the reallocation of resources because someone says the tea leaves suggest an impending problem.

We will solve no problem until it’s too late to do anything else.

We don’t get ready because we forget that it takes time to get ready.  We do so little getting ready, we’re unfamiliar with the work content and timeline of getting ready.  We forget that getting ready is on the critical path of problem-solving.

We don’t get ready because everyone is fully booked and we have no excess capacity to allocate to getting ready.  And by the time we free up the resources to get ready (if we can do that at all), we miss the window of opportunity to get ready.

We will solve a problem only after exhausting all other possibilities.

We don’t get ready because the problem is someone else’s.  If we don’t have capacity to get ourselves ready for our problems why would we allocate the capacity to get ready for someone else’s?

We don’t get ready because we try to give our problem to someone else.  Isn’t it easier to convince someone else to get ready than to do the getting ready ourselves?

We will solve no problem until we know we’ll get the credit.

We don’t get ready because problem avoidance won’t get us promoted, though putting out a fire that could have been avoided will.

If a problem is avoided, there is no problem. And since there’s no problem, there’s no need to avoid it.

We don’t get ready because there’s no certainty a problem will be a problem until we have it.  And we can’t get ready to solve a problem once we have it.  Getting ready requires judgment and trust – judgment by the person who sees the early warning signs and trust by the person who allocates the resources.  It’s that simple.

Because we’ve conditioned people to be afraid to use their judgment, they don’t use it.  And because we’ve conditioned people to be afraid to spend the time needed to build trust, they don’t build it.

Now that we have these two problems, how can we make it safe for people to use their judgment and spend the time needed to develop trust?

Image credit — Leonard J Matthews

When you are stuck, often the problems you can describe are not the problems that are in the way.

The problems you solved last time make it more difficult to see new problems this time.

The problems you know of are not the problem.

When you have no problems, you have big problems.

When you have no problem, there is no way to justify additional resources.

When you have no problem, you better finish on time.

When you’re stuck on a problem, make it worse and solve it by doing the opposite.

Problems are not bad, even though bringing them to everyone’s attention may be bad for your career.

And if talking about problems is bad for your career, you are working at the wrong company.

Until you can explain the problem in plain language, you do not understand it.

And when you do not understand a problem, you can’t solve it.

Solutions start with a problem.

Two questions to ask: Where is the problem and when does it occur?

Problems are solved with microscopes and not telescopes. Get close to the problem.

Your problem is not new.  Someone has solved it in a different application, context, or product.

There are at least three ways to solve a problem: before it occurs, while it occurs, or after it occurs,

Sometimes solving a difficult problem requires the generation of an easily solvable problem. So be it.

Problems are more powerful than opportunities.  Call them by their name.

Because without problems, there can be no solutions.

Image credit – Andy Morffew

When you have something special but don’t know it, the Universe is there to take it away from you so you can appreciate what you no longer have.  Seems backward, but the Universe knows how to be a good teacher.

When someone asks you to help them, but you know they are asking for the wrong thing, what do you do?  Do you feel pressure to maintain a good working relationship? Do you suggest something different?  Or do you simply decline to help?  What would the Universe do?  It would probably play the long game.

When a team does not follow good practice even though they have the tools, talent, and time, and then asks you to do that very work, what do you do?  Do you do the work they should have done? Do you suggest they allocate their resources to the problem? Do you ask them why they didn’t do the right work in the first place? What would the Universe do? Would do a little bit of everything. What would it want that team to learn?

When there’s disagreement on the approach, there can be no agreement on lower-level elements of the work.  What do you do?  Flip a coin? Arm wrestle? Yell at each other? I think the Universe would want to understand the design space in the most effective way, and I think it would try all the coherent approaches in a small way and see what happens.  Then, it would ask everyone to get back together to review the results and decide what to do next.

There are teaching moments every day.  But it’s never clear what to teach.  Does the urgency and significance of the moment mean that the immediate problem should be solved and the teaching should wait until the next time? Is the teaching that the higher-level systemic problem is so significant that the short-term pain must be experienced to create momentum around solving the systemic problem? Is the teaching that the team should be given help in a way that preserves their emotional well-being so they can finish the project in good spirits and help them elevate their work next time?

With teaching moments there are no right answers.  Sometimes you take the opportunity to teach and sometimes you look the other way.  Sometimes you hold people accountable and sometimes you soothe egos. Sometimes you withhold resources and sometimes you jump in with both feet.

And like the Universe, you get better at teaching the more you do it.

Image credit — Andrew Kuznetsov

The projects you choose define the problems you solve.

The problems you choose to solve define the novel value delivered to the customer.

The people you choose to run the projects set the character of the projects.

The choice of the projects’ character defines how the people feel about working on the projects.

How people choose to feel about working on the projects influences the character of the projects.

The people on the projects choose how the problems are solved.

How people choose to solve problems defines how well the problems are solved.

The choice around how well problems are solved sets the level of goodness delivered to the customer.

The level of goodness you choose to deliver to the customer governs the incremental revenue you create.

It doesn’t seem right that the amount of incremental revenue is a choice.

But, when you choose the right projects and the right people to run them and you choose the right problems and the right people to solve them, incremental revenue becomes your choice.

image credit — officallychaz

X: Of the pool of candidate new product development projects, which project should we do first?

Me: Let’s do the one that makes us the most money.

X: Which project will make the most money?

Me: The one where the most customers buy the new product, pay a reasonable price, and feel good doing it.

X: And which one is that?

Me: The one that solves the most significant problem.

X: Oh, I know our company’s most significant problem.  Let’s solve that one.

Me: No. Customers don’t care about our problems, they only care about their problems.

X: So, you’re saying we should solve the customers’ problem?

Me: Yes.

X: Are you sure?

Me: Yes.

X: We haven’t done that in the past. Why should we do it now?

Me: Have your previous projects generated revenue that met your expectations?

X: No, they’ve delivered less than we hoped.

Me: Well, that’s because there’s no place for hope in this game.

X: What do you mean?

Me: You can’t hope they’ll buy it.  You need to know the customers’ problems and solve them.

X: Are you always like this?

Me: Only when it comes to customers and their problems.

image credit: Kyle Pearce

Nothing changes unless there’s a problem.

In fact, without a problem, there can be no solution.

One of the devious ways to solve your problem is to create conditions for others to think it’s their problem.

Shame on you if you try to get me to solve your problem.

And shame on me if I try to solve your problem.

The best way for the problem to find its rightful owner is to leave the problem unsolved.

But leaving the problem unsolved also increases the pressure on all the innocent non-owners that work near the problem.

Leaving the problem unsolved is like a game of chicken, where the person who flinches first loses.

No one can give you their problem without your consent, but that doesn’t mean they won’t try.

So, when someone tries to give you their problem, put your hands in your pockets.

Leaving the problem unsolved isn’t a sign of non-caring, it’s a sign of higher-level caring.

Leaving the problem unsolved is the only way to pressure the company into the higher-level (and unpleasant) organizational learning of who is not solving their own problems.

“Prepare for Squirting” by Wootang01 is licensed under CC BY-ND 2.0.

If you know the right answer, you’re working on an old problem or you’re misapplying your experience.

If you are 100% sure how things will turn out, let someone else do it.

If there’s no uncertainty, there can be no learning.

If there’s no learning, your upstart competitors are gaining on you.

If you don’t know what to do, you’ve started the learning cycle.

If you add energy to your business model and it delivers less output, it’s time for a new business model.

If you wait until you’re sure you need a new business model, you waited too long.

Successful business models outlast their usefulness because they’ve been so profitable.

When there’s a project with a 95% chance to increase sales by 3%, there’s no place for a project with a 50% chance to increase sales by 100%.

When progress has slowed, maybe the informal networks have decided slower is faster.

If there’s something in the way, but you cannot figure out what it is, it might be you.

“A bouquet of wilting adapters” by rexhammock is licensed under CC BY-SA 2.0.

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.