Shipulski On Design

Posts Tagged ‘Understanding Physics’

You know the space is new when you don’t have the right words to describe the phenomenon.

When there are two opposite sequences of events and you think both are right, you know the space is new.

You know you’re thinking about new things when the harder you try to figure it out the less you know.

You know the space is outside your experience but within your knowledge when you know what to do but you don’t know why.

When you can see the concept in your head but can’t drag it to the whiteboard, you’re swimming in new soup.

When you come back from a walk with a solution to a problem you haven’t yet met, you’re circling new space.

And it’s the same when know what should be but it isn’t – circling new space.

When your old tricks are irrelevant, you’re digging in a new sandbox.

When you come up with a new trick but the audience doesn’t care – new space.

When you know how an experiment will turn out and it turns out you ran an irrational experiment – new space.

When everyone disagrees, the disagreement is a surrogate for the new space.

It’s vital to recognize when you’re swimming in a new space.  There is design freedom, new solutions to new problems, growth potential, learning, and excitement.  There’s acknowledgment that the old ways won’t cut it.  There’s permission to try.

And it’s vital to recognize when you’re squatting in an old space because there’s an acknowledgment that the old ways haven’t cut it.  And there’s permission to wander toward a new space.

Image credit — Tambaco The Jaguar

Software may be eating the world, but the hardware elements of a startup’s work define when lunch is served.

Hardware takes longer than software.  With hardware, after the product and its parts are designed, companies are vetted/selected to make the parts; contracts are signed to make the parts; the parts are made; the parts are shipped; the parts are received; the parts are inspected; and the parts are put in their locators.  Then, the manufacturing process is defined, the manufacturing tooling is designed and purchased; the manufacturing documentation is created; the final test system is designed and built; and the parts are assembled into the product. Then, the product is run through final test and tested for robustness.  After it’s learned the manufacturing process created too much variation and the insufficient robustness manifests, the manufacturing process and its documentation are changed to reduce variation; the parts that failed are redesigned, purchased, made, shipped, and received; and the next iteration of the product is built and tested.  This process is repeated until the product is robust and the manufacturing process is repeatable.  This is why hardware takes longer than software.

If the software is done but the hardware isn’t, the software must wait for the hardware and the customer must wait for the finished product. To get the hardware done faster, recognize that redesign loops are part of the game and invest in the capability to iterate quickly.  Line up the suppliers to make parts quickly; keep utilization low on the support resources so they can jump on the work when it arises (think fire stations who can respond quickly when there’s a fire); and avoid part-time resources on the critical path.  There may be other things to focus on, but only after taking care of these three.

Software may be eating the world, but the hardware elements of a startup’s work govern the cost of getting to the dinner table.

Hardware costs more to make than software.  Hardware is made of steel, aluminum, injection molded plastics, and rare earth elements, all of which cost money.  And because startups do things that have not been done before, the materials can be special (costly).  And unlike software, the marginal cost of an incremental unit is non-zero.  With hardware, if you want to make another one you’ve got to buy more of the materials; you have to pay people to make it; you have to buy/build the manufacturing system; you have to buy the measurement systems and engineering infrastructure; and you have to pay people to break-test-fix the product until it’s ready.

What’s a startup to do?

To do hardware faster, focus on learning.  And to do hardware more cost-effectively, focus on learning.

For both time and money, learning efficiency is a good starting point.  The most efficient learning is the learning you don’t have to do, so be ruthless in how you decide what you DON’T learn. Where possible, declare all but the most vital problems as annoyances and save them for later. (Annoyances don’t require learning.)  This will concentrate your precious resources on fewer problems, improve your learning rate, and keep costs to a minimum.

Here’s a good test to decide if the learning is worth learning.  Ask yourself “If we accomplish this learning objective, how will the customer benefit?”  If there is low or no customer benefit, say no to the learning objective.  If there is medium customer benefit, say no to the learning objective.  If there is significant customer benefit, do the learning.

For those learning objectives that make it through the gauntlet, learn what you need to learn, but no more.  To do this, create a formal learning objective: “We want to learn [enter learning objective here].”  With learning objectives, the tighter the better. And define the criteria for decision making: “If the result of the test is [define objective measurement here], we will decide [enter decision here].” With decision criteria, the clearer the better.

Learn effectively, not elegantly.  Be bold, rough, and crude with how you learn.  Design tests that take advantage of the resources you have on hand so you can learn quickly.  If you can run a crude test in one hour and the perfect test will take a week, run three crude tests and be done by the end of the day.

Learn with less confidence and more judgment.  If a wrong decision can be overcome quickly and with low cost, be less confident and use more judgment.

Whether driven by hardware, software, or the integration of both, project completion is governed by the critical path.  And with longer time constants, it’s more likely that the hardware defines the critical path.  The total cost of the project is the sum of the three costs: software, hardware, and integration.  And because hardware requires expensive materials, factories, engineering labs, people to run the tests, and people to make the products, hardware is likely a large percentage of the project costs.

Image credit — Günter Hentschel

When you work in domains of high uncertainty, creating goals for the next year is exceptionally difficult.

When you try to do something that hasn’t been done before, things may blow up instantly, things may work out after two years of hard work, or things may never work.  So, how do you create the goal for that work? Do you give yourself one month to complete the work? And things haven’t worked out at the end of the month, do you stop the work or do you keep going?  If it blows up instantly, but you think you know why, do you keep going? Do you extend the due date for the goal?  At the start of the work, should the timeline have been set to one year instead of one month?  And who decides that?  And how do they decide?

When you have to create your goals for something that hasn’t been done before and the objectives of the work are defined by another team, yet that team hasn’t done the prework and cannot provide those objectives, what do you do? Do you create a goal for the other team to define the objectives? And what if you have no control over that team’s priorities and you don’t know when (or if) they’ll provide the needed information?  What does a goal look like when you don’t know the objectives of the work nor do you know when (or if) you’ll get that information.  Can you even create a goal for the work when you don’t know what that work is?  And how do you estimate a completion date or the resource requirements (both the flavor and quantity) when you don’t know the objectives?  What does that goal look like?

When you have to create your goals for a team of ten specialized people who each have unique skills, but you don’t know the objectives of the work, when that work can start, or when that work will finish, how do you cascade the team’s goals to each team members?  What do their goals look like?  Is the first goal to figure out the goal?  How many goals does it take to fill up their year when you don’t know what the work is or how long it will take?

When working in domains of high uncertainty, the goals go like this: define the system as it is, define something you want to improve, try to improve it, and then do the next right thing.  Unfortunately, that doesn’t fit well with the traditional process of setting yearly goals.

And your two questions should be: How do you decide what to improve? and How do you choose the next right thing?

Image credit — Rab Lawrence

Just before it’s possible, it’s impossible.

An instant before you know how to do it, you don’t.

After searching for the answer for a year, you may find it in the next instant.

If you stop searching, that’s the only way to guarantee you won’t find it.

When people say it won’t work, their opinion is valid only if nothing has changed since the last time, including the people and their approach.

If you know it won’t work, change the approach, the specification, or the scope.

If you think it won’t work, that’s another way of saying “it might work “.

If you think it might work, that’s another way of saying “it might not work”.

When there’s a difference of opinion, that’s objective evidence the work is new.

If everyone sees it the same way, you’re not trying hard enough.

When you can’t predict the project’s completion date, that’s objective evidence that the work is new.

If you know when the project will be done, the novelty has been wrestled out of the project or there was none at the start.

When you don’t start with the most challenging element of the project, you cause your company to spend a lot of money on a potentially nonviable project.

Until the novel elements of a project are demonstrated, there is no real progress.

“Jumping Backwards – Cape Verde, Sal Rei” by Espen Faugstad is licensed under CC BY 2.0.

As geopolitical pressures rise, some countries that supply the parts that make up your products may become nonviable.  What if there was a way to reinvent the supply chain and move it to more stable regions?  And what if there was a way to guard against the use of child labor in the parts that make up your product? And what if there was a way to shorten your supply chain so it could respond faster? And what if there was a way to eliminate environmentally irresponsible materials from your supply chain?

Our supply chains source parts from countries that are less than stable because the cost of the parts made in those countries is low.  And child labor can creep into our supply chains because the cost of the parts made with child labor is low.  And our supply chains are long because the countries that make parts with the lowest costs are far away.  And our supply chains use environmentally irresponsible materials because those materials reduce the cost of the parts.

The thing with the supply chains is that the parts themselves govern the manufacturing processes and materials that can be used, they dictate the factories that can be used and they define the cost.  Moving the same old parts to other regions of the world will do little more than increase the price of the parts.  If we want to radically reduce cost and reinvent the supply chain, we’ve got to reinvent the parts.

There are methods that can achieve radical cost reduction and reinvent the supply chain, but they are little known.  The heart of one such method is a functional model that fully describes all functional elements of the system and how they interact.  After the model is complete, there is a straightforward, understandable, agreed-upon definition of how the product functions which the team uses to focus the go-forward design work.  And to help them further, the method provides guidelines and suggestions to prioritize the work.

I think radical cost reduction and more robust supply chains are essential to a company’s future.  And I am confident in the ability of the methods to deliver solid results.  But what I don’t know is: Is the need for radical cost reduction strong enough to cause companies to adopt these methods?

“Zen” by g0upil is licensed under CC BY-SA 2.0.

If there’s a recurring problem, take the time to make sure the system hasn’t changed since last time and make sure the context and environment are still the same.  If everything is the same, and there are no people involved in the system, it’s a problem that resides in the clear domain.  Here’s a link from Dave Snowden who talks about the various domains.  In this video, Dave calls this domain the “simple” domain.  Solve it like you did last time.

If there’s a new problem, take the time to understand the elements of the system that surround the problem.  Define the elements and define how they interact, and define how they set the context and constraints for the problem.  And then, define the problem itself.  Define when it happens, what happens just before, and what happens after.  If there are no people involved, if the solution is not immediately evident, if it’s a purely mechanical, electromechanical, chemical, thermal, software, or hardware, it’s a problem in the complicated domain (see Dave’s video above) and you’ll be able to solve it with the right experts and enough time.

If you want to know the next evolution of the system, how it will develop and evolve, the situation is more speculative and there’s no singular answer. Still, the first step is the same – take the time to understand the elements of the system and how they interact.  Then, look back in time and learn the previous embodiments of the system and define its trajectory – how it evolved into its current state.  If there has been consistent improvement along a singular line of goodness, it’s likely the system will want to continue to evolve in that direction.  If the improvement has flattened, it’s likely the system will try to evolve along a different line of evolution.

I won’t go into the specifics of lines of evolution of technological systems, as it’s a big topic.  But if you want to know more, here’s a nice description of evolution along the line of adaptability by my teacher, Victor Fey – The best products know how to adapt.

If there are people involved with the system, it’s a complex system (see Dave’s video).  (There are complex systems that don’t involve people, but I find this a good way to talk about complex systems.) The first step is to define the system as it is, but because the interactions among the elements are not predictable, your only hope is to probe, sense, and respond by doing more of what works and less of what doesn’t.  Thanks to Dave Snowden for that language.

The first step is always to understand the system as it is.

“Space – Antennae Galaxies” by Trodel is licensed under CC BY-SA 2.0.

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

Next year will be different, but we don’t know how it will be different. All we know is that it will be different.

Some things will be the same and some will be different.  The trouble is that we won’t know which is which until we do.  We can speculate on how it will be different, but the Universe doesn’t care about our speculation.  Sure, it can be helpful to think about how things may go, but as long as we hold on to the may-ness of our speculations.  And we don’t know when we’ll know. We’ll know when we know, but no sooner. Even when the Operating Plan declares the hardest of hard dates, the Universe sets the learning schedule on its own terms, and it doesn’t care about our arbitrary timelines.

What to do?

Step 1. Try three new things. Choose things that are interesting and try them.  Try to try them in parallel as they may interact and inform each other. Before you start, define what success looks like and what you’ll do if they’re successful and if they’re not.  Defining the follow-on actions will help you keep the scope small.  For things that work out, you’ll struggle to allocate resources for the next stages, so start small.  And if things don’t work out, you’ll want to say that the projects consumed little resources and learned a lot.  Keep things small.  And if that doesn’t work, keep them smaller.

Step 2. Rinse and repeat.

I wish you a happy and safe New Year.  And thanks for reading.

Mike

“three” by Travelways.com is licensed under CC BY 2.0

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.