Shipulski On Design

Posts Tagged ‘Understanding Physics’

If you don’t know what the problem is, that’s your first problem.

A problem can’t be a problem unless there’s a solution.  If there’s no possible solution, don’t try to solve it, because it’s not a problem.

If there’s no problem, you have a big problem.

If you’re trying to solve a problem, but the solution is outside your sphere of influence, you’re taking on someone else’s problem.

If someone tries to give you a gift but you don’t accept it, it’s still theirs. It’s like that with problems.

If you want someone to do the right thing, create a problem for them that, when solved, the right thing gets done.

Problems are good motivators and bad caretakers.

A problem is between two things, e.g., a hammer and your thumb.  Your job is to figure out the right two things.

When someone tries to give you their problem, keep your hands in your pockets.

A problem can be solved before it happens, while it happens, or after it happened.  Each time domain has different solutions, different costs, and different consequences.  Your job is to choose the most appropriate time domain.

If you have three problems, solve one at a time until you’re done.

Solving someone else’s problem is a worst practice.

If you solve the wrong problem, you consume all the resources needed to solve the right problem without any of the benefits of solving it.

Ready, fire, aim is no way to solve problems.

When it comes to problems, defining IS solving.

If you learn one element of problem-solving, learn to see when someone is trying to give you their problem.

“My first solved Rubik’s cube” by Nina Stawski is licensed under CC BY 2.0

When your idea is novel, no one will steal it. No NDA required.

If your idea is truly novel, no one will value it. And that’s how you’ll know it’s novel.

When your idea is novel, no one will adopt it. This isn’t much of a stretch as, due to not-invented-here (NIH), no one will adopt anyone else’s idea – novel or not.

When your idea is novel, it will be misunderstood, even by you.

When your idea is novel, it will evolve into something else and then something else. And then it might be ready for Prime Time.

Novel ideas are like orchids – they need love beyond the worth of their blossom.

If your idea hasn’t failed three times, it’s not worth a damn.

The gestation period for novel ideas is long; if it comes together quickly, it’s not novel.

The best way to understand your novel idea is to make a prototype. And then another one.

Your first novel idea won’t work, but it will inform the next iteration. And that one won’t work either, and the cycle continues. But that’s how it goes with novel ideas.

If everyone likes your novel idea, it isn’t novel.

If no one likes your novel idea, you may be on to something.

If you’re not misunderstood, you’re doing it wrong.

If your dog likes your idea, you can’t say much because he loves you unconditionally and will always tell you what you want to hear.

If you think your novel idea will create a whole new product line in two years, your timeline is off by a factor of three, or five.

If your most successful business unit tries to squash your novel idea it’s because it threatens them. Stomp on the accelerator.

When you are known to give air cover to novel ideas, the best people want to work for you.

“it seemed like a good idea at the time” by woodleywonderworks is licensed under CC BY 2.0

Without a problem, there can be no progress.

And only after there’s too much no progress is a problem is created.

And once the problem is created, there can be progress.

When you know there’s a problem just over the horizon, you have a problem.

Your problem is that no one else sees the future problem, so they don’t have a problem.

And because they have no problem, there can be no progress.

Progress starts only after the calendar catches up to the problem.

When someone doesn’t think they have a problem, they have two problems.

Their first problem is the one they don’t see, and their second is that they don’t see it.

But before they can solve the first problem, they must solve the second.

And that’s usually a problem.

When someone hands you their problem, that’s a problem.

But if you don’t accept it, it’s still their problem.

And that’s a problem, for them.

When you try to solve every problem, that’s a problem.

Some problems aren’t worth solving.

And some don’t need to be solved yet.

And some solve themselves.

And some were never really problems at all.

When you don’t understand your problem, you have two problems.

Your first is the problem you have and your second is that you don’t know what your problem by name.

And you’ve got to solve the second before the first, which can be a problem.

With a big problem comes big attention. And that’s a problem.

With big attention comes a strong desire to demonstrate rapid progress. And that’s a problem.

And because progress comes slowly, fervent activity starts immediately. And that’s a problem.

And because there’s no time to waste, there’s no time to define the right problems to solve.

And there’s no bigger problem than solving the wrong problems.

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

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 the fate of your company rests on a single project, who are the three people you’d tap to drag that pivotal project over the finish line? And to sharpen it further, ask yourself “Who do I want to lead the project that will save the company?” You now have a list of the three most important people in your company.  Or, if you answered the second question, you now have the name of the most important person in your company.

The most important person in your company is the person that drags the most important projects over the finish line.  Full stop.

When the project is on the line, the CEO doesn’t matter; the General Manager doesn’t matter; the Business Leader doesn’t matter.  The person that matters most is the Project Manager.  And the second and third most important people are the two people that the Project Manager relies on.

Don’t believe that? Well, take a bite of this. If the project fails, the product doesn’t sell. And if the product doesn’t sell, the revenue doesn’t come. And if the revenue doesn’t come, it’s game over. Regardless of how hard the CEO pulls, the product doesn’t launch, the revenue doesn’t come, and the company dies.  Regardless of how angry the GM gets, without a product launch, there’s no revenue, and it’s lights out.  And regardless of the Business Leader’s cajoling, the project doesn’t cross the finish line unless the Project Manager makes it happen.

The CEO can’t launch the product. The GM can’t launch the product. The Business Leader can’t launch the product.  Stop for a minute and let that sink in.  Now, go back to those three sentences and read them out loud. No, really, read them out loud.  I’ll wait.

When the wheels fall off a project, the CEO can’t put them back on. Only a special Project Manager can do that.

There are tools for project management, there are degrees in project management, and there are certifications for project management.  But all that is meaningless because project management is alchemy.

Degrees don’t matter. What matters is that you’ve taken over a poorly run project, turned it on its head, and dragged it across the line. What matters is you’ve run a project that was poorly defined, poorly staffed, and poorly funded and brought it home kicking and screaming. What matters is you’ve landed a project successfully when two of three engines were on fire. (Belly landings count.) What matters is that you vehemently dismiss the continuous improvement community on the grounds there can be no best practice for a project that creates something that’s new to the world. What matters is that you can feel the critical path in your chest. What matters is that you’ve sprinted toward the scariest projects and people followed you. And what matters most is they’ll follow you again.

Project Managers have won the hearts and minds of the project team.

The Project manager knows what the team needs and provides it before the team needs it. And when an unplanned need arises, like it always does, the project manager begs, borrows, and steals to secure what the team needs.  And when they can’t get what’s needed, they apologize to the team, re-plan the project, reset the completion date, and deliver the bad news to those that don’t want to hear it.

If the General Manager says the project will be done in three months and the Project Manager thinks otherwise, put your money on the Project Manager.

Project Managers aren’t at the top of the org chart, but we punch above our weight. We’ve earned the trust and respect of most everyone. We aren’t liked by everyone, but we’re trusted by all. And we’re not always understood, but everyone knows our intentions are good. And when we ask for help, people drop what they’re doing and pitch in. In fact, they line up to help. They line up because we’ve gone out of our way to help them over the last decade. And they line up to help because we’ve put it on the table.

Whether it’s IoT, Digital Strategy, Industry 4.0, top-line growth, recurring revenue, new business models, or happier customers, it’s all about the projects. None of this is possible without projects. And the keystone of successful projects?  You guessed it.  Project Managers.

Image credit – Bernard Spragg .NZ

When your most important product development project is a year behind schedule (and the schedule has been revved three times), who would you call to get the project back on track?

When the project’s unrealistic cost constraints wall of the design space where the solution resides, who would you call to open up the higher-cost design space?

When the project team has tried and failed to figure out the root cause of the problem, who would you call to get to the bottom of it?

And when you bring in the regular experts and they, too, try and fail to fix the problem, who would you call to get to the bottom of getting to the bottom of it?

When marketing won’t relax the specification and engineering doesn’t know how to meet it, who would you call to end the sword fight?

When engineering requires geometry that can only be made by a process that manufacturing doesn’t like and neither side will give ground, who would you call to converge on a solution?

When all your best practices haven’t worked, who would you call to invent a novel practice to right the ship?

When the wheels fall off, you need to know who to call.

If you have someone to call, don’t wait until the wheels fall off to call them. And if you have no one to call, call me.

Image credit — Jason Lawrence

Everything has a half-life, but we don’t behave that way.  Especially when it comes to success.  The thinking goes – if it was successful last time, it will be successful next time.  So, do it again. And again.  It’s an efficient strategy – the heavy resources to bring it to life have already been spent. And it’s predictable – the same customers, the same value proposition, the same supply base, the same distribution channel, and the same technology. And it’s dangerous.

Success is successful right up until it isn’t. It will go away. But it will take time.  A successful product line won’t fall off the face of the earth overnight. It will deliver profits year-over-year and your company will come to expect them.  And your company will get hooked on the lifestyle enabled by those profits. And because of the addiction, when they start to drop off the company will do whatever it takes to convince itself all is well.  No need to change.  If anything, it’s time to double-down on the successful formula.

Here’s a rule: When your successful recipe no longer brings success, it’s not time to double-down.

Success’s decline will be slow, so you have time.  But creating a new recipe takes a long time, so it’s time to declare that the decline has already started. And it’s time to learn how to start work on the new recipe.

Hardship 1 – Allocate resources differently. The whole company wants to spend resources on the same old recipes, even when told not to.  It’s time to create a funding stream that’s independent of the normal yearly planning cycle.  Simply put, the people at the top have to reallocate a part of the operating budget to projects that will create the next successful platform.

Hardship 2 – Work differently. The company is used to polishing the old products and they don’t know how to create new ones. You need to hire someone who can partner with outside companies (likely startups), build internal teams with a healthy disrespect for previous success, create mechanisms to support those teams and teach them how to work in domains of high uncertainty.

Hardship 3 – See value differently. How do you provide value today? How will you provide value when you can’t do it that way? What is your business model? Are you sure that’s your business model? Which elements of your business model are immature? Are you sure? What is the next logical evolution of how you go about your business? Hire someone to help you answer those questions and create projects to bring the solutions to life.

Hardship 4 – Measure differently. When there’s no customer, no technology and no product, there’s no revenue.  You’ve got to learn how to measure the value of the work (and the progress) with something other than revenue.  Good luck with that.

Hardship 5 – Compensate differently. People that create something from nothing want different compensation than people that do continuous improvement. And you want to move quickly, violate the status quo, push through constraints and create whole new markets. Figure out the compensation schemes that give them what they want and helps them deliver what you want.

This work is hard, but it’s not impossible. But your company doesn’t have all the pieces to make it happen.  Don’t be afraid to look outside your company for help and partnership.

Image credit — Insider Monkey

If you run a company, the most important thing you can control is how you allocate your resources. You can’t control how the people in your company will respond to input, but you can choose the projects they work on.  You can’t control which features and functions your customers will like, but you can choose which features and functions become part of the next product. And you can’t control if a new technology will work, but you can choose the design space to investigate.  The open question – How to choose in a way that increases your probability of success?

If you want to buy a company, the most important thing you can control is how you allocate your resources. In this case, the resources are your hard-earned money and your choice is which company to buy. The open question – How to choose in a way that increases your probability of success?

If you want to invest in a startup company, the most important thing you can control is how you allocate your resources. This case is the same as the previous one – your money is the resource and the company you choose defines how you allocate your resources. This one is a little different in that the uncertainty is greater, but so is the potential reward. Again, the same open question – How to choose in a way that increases your probability of success?

Taking a step back, the three scenarios can be generalized into a category called a “system.”  And the question becomes – how to understand the system in a way that improves resource allocation and increases your probability of success?

These people systems aren’t predictable in an if-A-then-B way. But they do have personalities or dispositions. They’ve got characteristics similar to hurricanes. A hurricane’s exact path cannot be forecasted, the meteorologist can use history and environmental conditions to broadly define regions where the probability of danger is higher.  The meteorologist continually monitors the current state of the hurricane (the system as it is) and tracks its position over time to get an idea of its trajectory (a system’s momentum). The key to understanding where the hurricane could go next: where it is right now (current state), how it got there (how it has behaved over time), and how have other hurricanes tracked under similar conditions (its disposition).  And it’s the same for systems.

To improve your understanding of how your system may respond, understand it as it is.  Define the elements and how those elements interact.  Then, work backward in time to understand previous generations of the system.  Which elements were improved? Which ones were added? Then, like the meteorologist, start at the system’s genesis and move forward to the present to understand its path.  Use the knowledge of its path and the knowledge of systems (it’s important to be the one that improves the immature elements of the system and systems follow S-curves until the S-curve flattens) to broadly define regions where the probability of success is higher.

These methods won’t guarantee success.  But, they will help you choose projects, choose acquisitions, choose technologies, and choose startups in a way that increases your probability of success.

Image credit — Alexander Gerst

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.

Wanting things to be different is a good start, but it’s not enough. To create conditions for things to move in a new direction, you’ve got to change your behavior. But with systems that involve people, this is not a straightforward process.

To create conditions for the system to change, you must understand the system”s disposition – the lines along which it prefers to change.. And to do that, you’ve got to push on the system and watch its response. With people systems, the response is not knowable before the experiment.

If you expect to be able to predict how the system will respond, working with people systems can be frustrating.  I offer some guidance here. With this work, you are not responsible for the system’s response, you are only responsible for how you respond to the system’s response.

If the system responds in a way you like, turn that experiment into a project to amplify the change.  If the system responds in a way you dislike, unwind the experiment.  Here’s a simple mantra – do more of what works and less of what doesn’t. (Thanks to Dave Snowden for this.)

If you don’t like how things are going, you have only one lever to pull.  You can only change.your response to what you see and experience. You can respond by pushing on the system and responding to what you see or you can respond by changing what you think and feel about the system.

But keep in mind that you are part of the system. And maybe the system is running an experiment on you. Either way, your only choice is to choose how to respond.