Shipulski On Design

Posts Tagged ‘Understanding Physics’

When engineers see a big opportunity, we want desperately to move the company in the direction of our thinking, but find it difficult to change the behavior of others. Our method of choice is usually a full frontal assault, explaining to anyone that will listen the opportunity as we understand it. Our approach is straightforward and ineffective. Our descriptions are long, convoluted, complicated, we use confusing technical language all our own, and omit much needed context that we expect others should know. The result – no one understands what we’re talking about and we don’t get the behavior we’re looking for (immediate company realignment with what we know to be true).  Then, we get frustrated and shut down – opportunity lost.

To change the behavior of others, we must first change our own. As engineers we see problems which, when solved, result in opportunity. And if we’re to be successful, we must go back to the problem domain and set things straight. Here’s a sequence of new behaviors we as engineers can take to improve our chances of changing the behavior of others:

Step 1. Create a block diagram of the physical system using simple nouns (blocks) and verbs (arrows). Blue arrows are good (useful actions) and red arrows are bad (harmful actions). Here’s a link to a PowerPoint file with a live template to create your own.

Step 2. Reduce the system block diagram down to its essence to create a distilled block diagram of the problem, showing only the system elements (blocks) with the problem (red arrow).For a live template, see the second page of the linked file. [Note – if there are two red arrows in the system block diagram, there are two problems which must be solved separately. Break them into two and solve the first one first. For an example, see page three of the linked file.]

Step 3. Create a hand sketch, or cartoon, showing the two system elements (blocks) of the distilled block diagram from step 2. Zoom in so only the two elements are visible, and denote where they touch (where the problem is), in red. For an example, see page four of the linked file.

Step 4. Now that you understand the real problem, use Google to learn how others have solved it.

Step 5. Choose one of Google’s most promising solutions and prototype it. (Don’t ask anyone, just build it.)

Step 6. Show the results to your engineering friends. If the problem is solved, it’s now clear how the opportunity can be realized. (There’s a big difference between a crazy engineer with a radically new market opportunity and a crazy engineer with test results demonstrating a new technology that will create a whole new market.)

Step 7. If the problem is not solved, or you solved the wrong problem, go back to step 1 and refine the problem

With step 1 you’ll find you really don’t understand the physical system, you don’t know which elements of the system have the problem, and you can’t figure out what the problem is. (I’ve created complicated system block diagrams only to realize there was no problem.)

With step 2, you’ll continue to struggle to zoom in on the problem. And, likely, as you try to define the problem, you’ll go back to step 1 and refine the system block diagram. Then, you’ll struggle to distill the problem down to two blocks (system elements). You’ll want to retain the complexity (many blocks) because you still don’t understand the real problem.

If you’ve done step 2 correctly, step 3 is easy, though you’ll still want to complicate the cartoon (too many system elements) and you won’t zoom in close enough.

Step 4 is powerful. Google can quickly and inexpensively help you see how the world has already solved your problem.

Step 5 is more powerful still.

Step 6 shows Marketing what the future product will do so they can figure out how to create the new market.

Step 7 is how problems are really solved and opportunities actually realized.

When you solve the real problem, you create real opportunities.

Today’s answer to everything is process and tools. Define the desired outcome; create the process; create the tools.  Problem solved.

But if the desired outcome is lasting change, deterministic processes and static tools won’t get us there.  Lasting change comes from people and their behavior.

Going forward, instead of creating process, create an environment of trust so people will investigate the unfamiliar; and instead of creating tools, create time – time for people to prototype the unfamiliar.

We’re afraid of technology development because it’s risky. And figuring out where to go is the risky part. To figure out where to go companies use several strategies: advance multiple technologies in parallel; ask the customer; or leave it to company leader’s edict. Each comes with its strengths and weaknesses.

I think the best way to figure out where to go is to figure out where you are. And the best way to do that is data-driven S-curve analysis.

To collect data, look to your most recent product launches, say five, and characterize them using a goodness-to-cost ratio. (Think miles per gallon for your technology.) Then plot them chronologically and see how the goodness ratio has evolved – flat, slow growth, steep growth, or decline. The shape of the curve positions your technology within the stages of the S-curve and its location triangulated with contextual clues. You know where you are so you can figure out where to go.

Here’s what the stages feel like and what to do when you’re in them:

Stage 1: Infancy – New physics are used to deliver a known function, but it’s not ready for commercialization. This is like early days of the gasoline-electric hybrid vehicles, where the physics of internal combustion was combined with the physics of batteries. In Stage 1 the elements of the overall system are established, like when Honda developed its first generation Honda Insight and GM its EV1. Prototypes are under test, and they work okay, but not great. In Stage 1, goodness-to-cost is lower than existing technologies (and holding), but the bet is when they mature goodness-to-cost will be best on the planet.

If your previous products were Stage 4 (Maturity) or Stage 5 (Decline), your new project should be in Stage 1. If your existing project is in Stage 1, focus on commercialization. If all your previous projects were (are) in Stage 1, you should focus on commercializing one (moving to Stage 2) at the expense of starting a new one.

Stage 2: Transitional – A product is launched in the market and there is intense competition with existing technologies. In Stage 2, several versions of new technology are introduced (Prius, Prius pluggable, GM’s Volt, Nissan Leaf), and they fight it out. Goodness-to-cost is still less than existing technologies, but there’s some element of the technology that’s attractive. For electric vehicles, think emissions.

If your previous products were Stage 4 (Maturity) or Stage 5 (Decline) and your current project just transitioned from Stage 1, you’re in the right place. In Stage 2, fill gaps in functionality; increase controllability – better controls to improve battery performance; and develop support infrastructure -electric fueling stations.

Stage 3: Growth – Goodness-to-cost increases rapidly, and so do sales. (I think most important for an electric vehicle is miles per charge.)

If you’re in Stage 3, it’s time to find new applications – e.g., electric motorcycles, or shorten energy flow paths – small electric motors at the wheels.

Stage 4: Maturity – The product hits physical limits – flat miles per gallon; hits limits in resources – fossil fuels; hits economic limits – costly carbon fiber body panels to reduce weight; or there’s rapid growth in harmful factors – air pollution.

If you’re in Stage 4, in the short term add auxiliary functions – entertainment systems, mobile hotspot, heated steering wheel, heated washer fluid; or improve aesthetics – like the rise of the good looking small coupe. In the long term, start a Stage 1 project to move to new physics – hydrogen fuel cells.

Stage 5: Decline – New and more effective systems have entered their growth stage – Nissan Leaf outsells Ford pickup trucks.

If you’re in Stage 5, long ago you should have started at Stage 1 project – new physics. If you haven’t, it may be too late.

S-curve analysis guides, but doesn’t provide all the answers. That said, it’s far more powerful than rock-paper-scissors.

(This thinking was blatantly stolen from Victor Fey’s training on Advanced S-Curve Analysis. Thank you, Victor.)

Doing new things doesn’t take a long time. What takes a long time is seeing things as they are. Getting ready takes time, not doing new. Awareness of assumptions, your assumptions, others’ assumptions, the company’s – that’s critical path.

An existing design, product, service, or process looks as it does because of assumptions made during long ago for reasons no longer relevant (if they ever were). Design elements blindly carried forward, design approaches deemed gospel, scripted service policies that no longer make sense, awkward process steps proceduralized and rev controlled – all artifacts of old, unchallenged assumptions. And as they grow roots, assumptions blossom into constraints. Fertile design space blocked, new technologies squelched, new approaches laughed out of town – all in the name of constraints founded on wilted assumptions. And the most successful assumptions have the deepest roots and create the deepest grooves of behavior.

Cows do the same thing every day. They wake up at the same time (regardless of daylight savings), get milked at the same time, and walk the same path.  They walk in such a repeatable way, they make cowpaths – neat grooves walked into the landscape – curiously curved paths with pre-made decisions. No cow worth her salt walks outside the  cowpath. No need. Cows like to save their energy for making milk at the expense of making decisions. If it was the right path yesterday, it’s right today.

But how to tell when old assumptions limit more than they guide? How to tell when it’s time to step out of the groove? How to tell a perfectly good cowpath from one that leads to a dry watering hole? When is it time to step back and create new history? Long ago the first cow had to make a choice, and she did. She could have gone any which way, and she did. She made the path we follow today.

With blind acceptance of assumptions, we wither into bankruptcy, and with constant second-guessing we stall progress. We must strike a balance. We must hold healthy respect for what has worked and healthy disrespect for the status-quo. We must use forked-tongue thinking to pull from both ends. In a yin-yang way, we must acknowledge how we got here, and push for new thinking to create the future.

Creating new products that provide a useful function is hard, and insuring they function day-in and day-out is harder.  Plain and simple, engineering is hard.

Planes must fly, cars must steer, and Velcro must stick. But, at every turn, there are risks, reasons why a new design won’t work, and it’s the engineer’s job to make the design insensitive to these risks. (Called reducing signal to noise ratio in some circles.) At a fundamental level engineering is about safety, and at a higher level it’s about sales – no function, no sales.

That’s why at every opportunity engineers reduce risk . (And thank goodness we do.) It makes sense that we’re the ones that think things through to the smallest detail, that can’t move on until we have the answer, that ask odd questions that seem irrelevant. It all makes sense since we’re the ones responsible if the risks become reality. We’re the ones that bear ultimate responsibility for product function and safety, and, thankfully, it shapes us.

But there’s a dark side to this risk reduction mindset – where we block our thinking, where we don’t try something new because  of problems we think we may have, problems we don’t have yet. The cause of this innovation-limiting behavior: problem broadening, where we apply a thick layer of problem over the entirety of a new concept, and declare it unworkable. Truth is, we don’t understand things well enough to make that declaration, but, in a knee-jerk way, we misapply our natural risk reduction mindset. Clearly, problems exist when doing new, but real problems are not broad, real problems are not like peanut butter and jelly spread evenly across the whole sandwich. Real problems are narrow; real problems are localized, like getting a drip of jelly on your new shirt.

How to get the best of both worlds? How to embrace the risk reduction mindset so products are safe and help engineering folks to try something radically new? To innovate?

We’ve got the risk reduction world covered, so it’s all about enhancing the try-something-new side. To do this we need to combat problem broadening; we need a process for problem narrowing. With problem narrowing, engineers drill down until the problem is defined as the interaction of two elements (the jelly and your shirt), defined in space (the front of your shirt) and time (when the knife drops a dollop on your shirt). Where problem broadening tells us to avoid making peanut butter and jelly sandwiches altogether (those sandwiches will always dirty our shirts), problem narrowing tells use to put something between the knife and the front of your shirt, or to put on your new shirt after you make your sandwich, or to do something creative to keep the jelly away from our shirt.

Problems narrow as knowledge deepens. Work through your fears, try something new, and advance your knowledge. Then define your problems narrowly, and solve them.

Innovate.

We’ve all done Voice of the Customer (VOC) work, where we jump on a plane, visit our largest customers, and ask leading questions. Under the guise of learning it’s mostly a mechanism to justify what we already want to do, to justify the products we know want to launch. (VOC should stand for Validate Our Choices.)

It’s a waste of time to ask customers for the next big thing or get their thoughts on a radical technology. First off, it’s not their job to know the next big thing, it’s ours. The next big thing is bigger than their imagination, never mind what they do today. (That’s why it’s called the next big thing.) And if we wait for customers tell us the next big thing, we’re hosed. (Their time horizon is too short and ours is shorter.) In this case it’s best to declare failure; our competitors figured it out a long time ago (they didn’t wait for the customer) and are weeks from commercialization. We should get busy on the next, next big thing because we’ve already missed this next generation. Next time we’ll silence the voice of the customer (VOC) and listen to the voice of the technology (VOT).

As far as radical technology, if we wait for customers to understand the technology, it’s not radical. Radical means radical, it means game-changing, a change so radical it obsoletes business models and creates unrecognizable, ultra-profitable, new ones. That’s radical. If we don’t start technical work until our customers understand the new technology, it’s no longer radical, and our competitors have already cornered the market. Again, we’ve missed an entire generation. Next time we’ll silence the voice of the customer (VOC) and listen to the voice of the technology (VOT).

Technology has a life force; it has a direction; it knows what it wants to be when it grows up. It has a voice. Independent of customer, it knows where it wants to go and how it will get there. At the highest level it has character traits and preferred paths, a kind of evolutionary inevitability; this is the voice of technology (VOT).

Technology will evolve to complete itself; it will move toward natural periodicity among its elements; it will harmonize itself; it will become more controllable; it will shorten its neural flow paths;  it will do yoga to improve its flexibility; its feet will grow too fast and create adolescent imbalance; it will replicate into multiples selves; it will shrink itself;  it will improve its own DNA. This is VOT.

Technology cannot tell us its lower-level embodiments (we control that), but it does sing hymns of its high-level wants and desires, and we must listen. No need to wait for VOC, it’s time to listen to VOT.

Like a dog whistle, technologists can hear VOT while others cannot. We understand the genetics of technology and we understand its desires (because we understand its physics.) We can look back to its ancestors, see its trajectory of natural evolution, and predict attributes of its offspring. Before everyone else, we see what will be.

Next time, instead of VOC, ask your technologists what the voice of technology is saying, and listen.

With manufacturing change is easy – lean this, six sigma that, more with less year-on-year. With engineering, not so much. Why?

Manufacturing is about cost, waste, efficiency, and yield (how to make it), and engineering is about function (what it does) – fundamental differences but not the why. The consequence of failure is the why. If manufacturing doesn’t deliver, the product is made like last year (with a bit more waste and cost than planned), but the product still sells. With engineering, not so much. If engineering mistakenly designs the Fris out of the Frisbee or the Hula out of the Hoop, no sales. That’s the why.

No function, no sales, no company, this is fear. This is why it feels dangerous to push on engineering; push on engineering and the wheels may fall off. This why the organization treads lightly; this is why the CEO does not push.

As technical leaders we are the ones who push directly on engineers. We stretch them to create novel technology that creates customer value and drive sales. (If, of course, customers value the technology.) We spend our days in the domain of stress, strain, printed circuit boards, programming languages, thermal models, and egos. As technologists, it’s daunting to push effectively on engineering; as non-technologists even more. How can a CEO do it without the subject matter expertise? The answer is one-page thinking.

One-page thinking forces engineers to describe our work in plain English, simple English, simple language, pictures, images. This cuts clutter and cleans our thinking so non-technologists can understand what’s happening, what’s going on, what we’re thinking, and shape us in the direction of customer, of market, of sales. The result is a hybrid of strong technology, strong technical thinking, and strong product, all with a customer focus, a market focus. A winning combination.

There are several rules to one-page thinking, but start with this one:

Use one page.

As CEO, ask your technical leaders (even the VP or SVP kind) to define each of their product development (or technology) projects on one page, but don’t tell them how. (The struggle creates learning.) When they come back with fifteen PowerPoint slides (a nice reduction from fifty), read just the first one, and send them away. When they come back with five, just read the first. They’ll get the idea. But be patient. To use just one page makes things remarkably clear, but it’s remarkably difficult.

Once the new product (or technology) is defined on one page, it’s time to reduce the fear of pushing on engineering – one-page thinking at the problem level. First, ask the technical leaders for a one-page description of each problem that must be overcome (one page per problem and address only the fundamental problems). Next, for each problem ask for baseline data (test data) on the product you make today. (For each problem they’ll likely have to create a robustness surrogate, a test rig to evaluate product performance.) The problem is solved (and the product will function well) when the new one out-performs the old one. The fear is gone.

When your engineers don’t understand, they can’t explain things on one page.  But when they can, you understand.

There are three categories of knowing: we know we know, we don’t know, and we think we know.

When we know we know – we understand fundamentals, we have a model, we have evidence, we can predict. We can build on this knowledge. We’re not often in this state, but it sure feels good when we are. The trick here is to understand the applicability of the knowledge. Change the inputs, change the system, or change the environment and we must question our knowledge. Do the fundamentals still apply?

When we don’t know – no fundamentals, no model, and no predictions. No danger on building on bad knowledge. Life is uncomplicated. Next task: develop the fundamentals; build a model. We’re in this state more often than we admit, and there’s the danger. It’s politically difficult to say “I don’t know.” But it must be said. Otherwise we’re expected to predict the future and to build on the knowledge (that we don’t have).

When we think we know – no fundamentals, no model, and predictions we bet our businesses on. Danger. It feels just as good as when we know we know, but it shouldn’t. Momentum in the wrong direction and we don’t know it. And we’re likely in this state more often than not. But this is a meta-state, an unstable state. The trick is to push on our knowledge so we tip into one of the other two states. Push on our knowledge so we know if we know.

Do you know the fundamentals? Do you have a model? Can you predict?

There is a healthy tension between level of improvement, or level of innovation, and time to market. Marketing wants radical improvement, infinitely short project schedules, and no change to the product. Engineers want to sign up for the minimum level of improvement, project schedules sufficiently long to study everything to death, and want to change everything about the new product. It’s healthy because there is balance – both are pulling equally hard in opposite directions and things end up somewhere in the middle. It’s not a stress-free environment, but it’s not too bad. But, sometimes the tension is unhealthy.

There are two flavors of unhealthy tension. First is when engineering has too much pull; they (we) sandbag on product performance and project timelines and change the design willy-nilly simply because they can (and it’s fun). The results are long project timelines, highly innovative designs that don’t work well, a lack of product robustness, and a boatload of new parts and assemblies. (Product complexity.) Second is when Marketing has too much pull; they ask for radical improvement in product functionality with project timelines too short for the level of innovation, and tightly constrain product changes such that solutions are not within the constraints. The results are long project timelines and un-innovative designs that don’t meet product specifications. (The solutions are outside the constraints.) Both sides are at fault in both scenarios. There are no clean hands.

What are the fundamentals behind all this gamesmanship? For engineering it’s technical risk; for marketing it’s schedule risk. Engineering minimizes what it signs up for in order to reduce technical risk and petitions for long project timelines to reduce it. Marketing minimizes product changes (constraints) to reduce schedule risk and petitions for short project timelines to reduce it. (Product development teams work harder with short schedules.) Something’s got to change. Read the rest of this entry »

Like you, I have been thinking a lot about the recession.  We all want to know how to move ourselves to the other side, where things are somewhat normal (the old normal, not the new one).  Like usual, my mind immediately goes to products.  To me, having the right products is vital to pulling ourselves out of this thing.  There is nothing novel in this thinking;  I think we all agree that products are important.  But, there are two follow-on questions that are important.  First, what makes products “right” to move you quickly to the other side?  Second, do you have the capability to engineer the “right” products?

The first question – what makes products “right” for these times?  Capacity is important to understanding what makes products right.  Capacity utilization is at record lows with most industries suffering from a significant capacity glut.  With decreased sales and idle machines, customers are no longer interested in products that improve productivity of their existing product lines because they can simply run their idle machines more.  And, they are not interested in buying more capacity (your products) at a reduced price.  They will simply run their idle machines more.  You can’t offer an improvement of your same old product that enables customers to make their same old products a bit faster and you can’t offer them your same old products at a lower price.  However, you can sell them products that enable them to capture business they currently do not have.  For example, enable them to manufacture products that their idle machines CANNOT make at all.  To do that means your new products must do something radically different than before; they must have radically improved functionality or radically new features.  This is what makes products right for these times.

On to the second question – do you have the capability to engineer the right products?  Read the rest of this entry »