Shipulski On Design

Posts Tagged ‘Understanding Physics’

When you want someone to understand your new idea, draw a picture for yourself. Set the constraint that you cannot use words on the page.  Shapes, arrows, cartoons – yes.  Words – no.  Once you’re convinced your one-pager captures your idea, set another constraint.  When you show your picture to someone, you cannot speak.  Your one-page picture must stand on its own.  I think you’ll find that this second constraint will cause you to improve your image, which will help others (and you) better understand your idea.  You can use your words when you explain your one-pager to your target audience, which will improve clarity and understanding.

When you want someone to understand that your new idea is possible, build a prototype and do a demo.  Use your one-pager to create a storyboard of the demo.  The storyboard can be a series of cartoons that describe what will happen during the demo. And like with the one-pager, your storyboard cannot use words.  And once you think your storyboard communicates your idea, set the constraint that you cannot speak during the demo, and try to improve the storyboard to support a no-word demo.  You can use your words during the demo to further improve clarity and understanding.

Make no mistake, the one-pager and the storyboard are for you.  They will help you better understand your idea so you can help people understand it better.

Image credit – Jennifer Moo

For the past two decades, I’ve actively developed engineering leaders.  A good friend asked me how I do it, so I took some time to write it down.  Here is the curriculum in the form of How Tos:

How to build trust.  This is the first thing.  Always.  Done right, the trust-based informal networks are stronger than the formal organization chart. Done right, the informal networks can protect the company from bad decisions.  Done right, the right information flows among the right engineers at the right time so the right work happens in the right way.

How to decide what to do next. This is a broad one.  We start with a series of questions: What are we doing now?  What’s the problem? How do you know? What should we do more of?  What should we do less of?  What resources are available? When must we be done?

How to map the current state.  We don’t define the idealized future state or the North Star, we start with what’s happening now.  We make one-page maps of the territory.  We use drawings, flow charts, boxes/arrows, and the fewest words. And we take no action before there’s agreement on how things are.  The value of GPS isn’t to define your destination, it’s to establish your location.  That’s why we map the current state.

How to build momentum. It’s easy to jump onto a moving steam train, but a stationary one is difficult to get moving.  We define the active projects and ask – How might we hitch our wagon to a fast-moving train?

How to start something new. We start small and make a thought-provoking demo.  The prototype forces us to think through all the elements, makes things real, and helps others understand the concept. If that doesn’t work, we start smaller.

How to define problems so we can solve them easily. We define problems with blocks and arrows, and limit ourselves to one page.  The problem is defined as a region of contact between two things, and we identify it with the color red.  That helps us know where the problem is and when it occurs. If there are two problems on a page, we break it up into two pages with one problem.  Then we decide to solve the problem before, during, or after it occurs.

How to design products that work better and cost less. We create Pareto charts of the cost of the existing product (cost by subassembly and cost by part) and set a cost reduction goal.  We create Pareto charts of the part count of the existing product (part count by subassembly and part count by individual part number) and define a goal for part count reduction.  We define test protocols that capture the functionality customers care about. We test the existing product and set performance improvement goals for the new one.  We test the new product using the same protocols and show the data in a simple A-B format. We present all this data at formal design reviews.

How to define technology projects. We define how the customer does their work.  We then define the evolutionary history of our products and services, and project that history forward.  For lines of goodness with trajectories that predict improvement, we run projects to improve them.  For lines of goodness with stalled trajectories, we run projects to establish new technologies and jump to the next S-curve.  We assess our offerings for completeness and create technologies to fill the gap.

How to file the right patents.  We ask these questions: How quickly will the customer notice the new functionality or benefit? Once recognized, will they care? Will the patent protect high-volume / high-margin consumables? There are more questions, but these are the ones we start with.  And the patent team is an integral part of the technology reviews and product development process.

How to do the learning.   We start with the leader’s existing goals and deliverables and identify the necessary How Tos to get their work done. There are no special projects or extra work.

If you’re interested in learning more about the curriculum or how to enroll, send me an email mike@shipulski.com.

Image credit — Paul VanDerWerf

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

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