Shipulski On Design

Archive for the ‘Product Development’ Category

Hands-on versus hands-off – as a leader it’s a fundamental choice.  And for me the single most important guiding principle is – do what it takes to maintain or strengthen the team’s personal ownership of the work.

If things are going well, keep your hands off.  This reinforces the team’s ownership and your trust in them.  But it’s not hands-off in and ignore them sense; it’s hands-off in a don’t tell them what to do sense. Walk around, touch base and check in to show interest in the work and avoid interrogation-based methods that undermine your confidence in them.  This is not to say a hands-off leader only superficially knows what’s going on, it should only look like the leader has a superficial understanding.

The hands-off approach requires a deep understanding of the work and the people doing it.  The hands-off leader must make the time to know the GPS coordinates of the project and then do reconnaissance work to identify the positions of the quagmires and quicksand that lay ahead.  The hands-off leader waits patiently just in front of the obstacles and makes no course correction if the team can successfully navigate the gauntlet.  But when the team is about to sink to their waists, leader gently nudges so they skirt the dangerous territory.

Unless, of course, the team needs some learning.  And in that case, the leader lets the team march it’s project into the mud.  If they need just a bit of learning the leader lets them get a little muddy; and if the team needs deep learning, the leader lets them sink to their necks.  Either way, the leader is waiting under cover as they approach the impending snafu and is right beside them to pull them out.  But to the team, the hands-off leader is not out in front scouting the new territory.  To them, the hands-off leader doesn’t pay all that much attention.  To the team, it’s just a coincidence the leader happens to attend the project meeting at a pivotal time and they don’t even recognize when the leader subtly plants the idea that lets the team pull themselves out of the mud.

If after three or four near-drowning incidents the team does not learn or change it’s behavior, it’s time for the hands-off approach to look and feel more hands-on.  The leader calls a special meeting where the team presents the status of the project and grounds the project in the now.  Then, with everyone on the same page the leader facilitates a process where the next bit of work is defined in excruciating detail.  What is the next learning objective? What is the test plan?  What will be measured? How will it be measured?  How will the data be presented?  If the tests go as planned, what will you know?  What won’t you know?  How will you use the knowledge to inform the next experiments? When will we get together to review the test results and your go-forward recommendations?

By intent, this tightening down does not go unnoticed.  The next bit of work is well defined and everyone is clear how and when the work will be completed and when the team will report back with the results.  The leader reverts back to hands-off until the band gets back together to review the results where it’s back to hands-on.  It’s the leader’s judgement on how many rounds of hands-on roulette the team needs, but the fun continues until the team’s behavior changes or the project ends in success.

For me, leadership is always hands-on, but it’s hands-on that looks like hands-off.  This way the team gets the right guidance and maintains ownership.  And as long as things are going well this is a good way to go.  But sometimes the team needs to know you are right there in the trenches with them, and then it’s time for hands-on to look like hands-on.  Either way, its vital the team knows they own the project.

There are no schools that teach this.  The only way to learn is to jump in with both feet and take an active role in the most important projects.

Image credit – Kerri Lee Smith

When it’s time for a tough decision, it’s time to use data.  The idea is the data removes biases and opinions so the decision is grounded in the fundamentals.  But using the right data the right way takes a lot of disciple and care.

The most straightforward decision is a decision between two things – an either or – and here’s how it goes.

The first step is to agree on the test protocols and measure systems used to create the data.  To eliminate biases, this is done before any testing.  The test protocols are the actual procedural steps to run the tests and are revision controlled documents.  The measurement systems are also fully defined.  This includes the make and model of the machine/hardware, full definition of the fixtures and supporting equipment, and a measurement protocol (the steps to do the measurements).

The next step is to create the charts and graphs used to present the data. (Again, this is done before any testing.) The simplest and best is the bar chart – with one bar for A and one bar for B.  But for all formats, the axes are labeled (including units), the test protocol is referenced (with its document number and revision letter), and the title is created.  The title defines the type of test, important shared elements of the tested configurations and important input conditions.   The title helps make sure the tested configurations are the same in the ways they should be.  And to be doubly sure they’re the same, once the graph is populated with the actual test data, a small image of the tested configurations can be added next to each bar.

The configurations under test change over time, and it’s important to maintain linkage between the test data and the tested configuration.  This can be accomplished with descriptive titles and formal revision numbers of the test configurations.  When you choose design concept A over concept B but unknowingly use data from the wrong revisions it’s still a data-driven decision, it’s just wrong one.

But the most important problem to guard against is a mismatch between the tested configuration and the configuration used to create the cost estimate.  To increase profit, test results want to increase and costs wants to decrease, and this natural pressure can create divergence between the tested and costed configurations. Test results predict how the configuration under test will perform in the field.  The cost estimate predicts how much the costed configuration will cost.  Though there’s strong desire to have the performance of one configuration and the cost of another, things don’t work that way.  When you launch you’ll get the performance of AND cost of the configuration you launched.  You might as well choose the configuration to launch using performance data and cost as a matched pair.

All this detail may feel like overkill, but it’s not because the consequences of getting it wrong can decimate profitability. Here’s why:

Profit = (price – cost) x volume.

Test results predict goodness, and goodness defines what the customer will pay (price) and how many they’ll buy (volume).  And cost is cost.  And when it comes to profit, if you make the right decision with the wrong data, the wheels fall off.

Image credit – alabaster crow photographic

Here’s something a little different – a crossword puzzle to test your knowledge on products, technology, and innovation. Complete the puzzle using the image  below, or download it (and answer key) using the green arrows below, and take your time with it over the Thanksgiving holiday.

[wpdm_file id=5]

[wpdm_file id=4]

Our threshold for uncertainty is too low.

Early in projects, even before the first prototype is up and running, you know what the product must do, what it will cost, and, most problematic, when you’ll be done. Independent of work content, level of newness, and workloads, there’s no uncertainty in your launch date. It’s etched in stone and the consequences are devastating.

A zero tolerance policy on uncertainty forces irrational behavior. As soon as possible, engineering gets something running in the lab, and then doesn’t want to change it because there’s no time. The prototype is almost impossible to build and is hypersensitive to normal process variation, but these issues are not addressed because there’s no time.  Everyone agrees it’s important to fix it, and agrees to fix it after launch, but that never happens because the next project is already late before it starts. And the death cycle repeats project after project.

The root cause of this mess is the mistaken porting of manufacturing’s zero uncertainly mindset into design. The thinking goes like this – lean and Six Sigma have achieved magical success in manufacturing by eliminating uncertainty, so let’s do it in product design and achieve similar results. This is a fundamental mistake as the domains are fundamentally different.

In manufacturing the same product is made day-in and day-out – no uncertainty; in product design no two product development efforts are the same and there’s lots of stuff that’s done for the first time – uncertainty by definition. In manufacturing there’s a revision controlled engineering drawing that defines the right answer (the geometry and the material) – make it like the picture and it’s all good; in product design the material is chosen from many candidates and the geometry is created from scratch – the picture is created from nothing. By definition there’s more inherent uncertainty in product design, and to tighten the screws and fix the launch date at the start is inappropriate.

Design engineers must feel like there’s enough time to try new things because new products that provide new functionality require new technologies, new materials, and new geometries. With new comes inherent uncertainty, but there are ways to manage it.

To hold the timeline, give on the specification and cost. Design as fast as you can until you run out of time then launch. The product won’t work as well as you’d like and it will cost more than you’d like, but you’ll hit the schedule. A good way to do this is to de-feature a subassembly to reduce design time, and possibly reduce cost. Or, reuse a proven subassembly to reduce design time – take a hit in cost, but hit the timeline. The general idea – hold schedule but flex on performance and cost.

It feels like sacrilege to admit that something’s got to give, but it’s the truth. You’ve seen how it goes when you edict (in no uncertain terms) that the timeline will be met and there’ll be no give on performance and cost. It hasn’t worked, and it won’t – the inherent uncertainty of product design won’t let it.

Accept the uncertainty; be one with it; and manage it. It’s the only way.

Countries want their companies to create wealth and jobs, and to do it they want them to design products, make those products within their borders, and sell the products for more than the cost to make them. It’s a simple and sustainable recipe which makes for a highly competitive landscape, and it’s this competition that fuels innovation.

When companies do innovation they convert ideas into products which they make (jobs) and sell (wealth). But for innovation, not any old idea will do; innovation is about ideas that create novel and useful functionality. And standing squarely between ideas and commercialization are tough problems that must be solved. Solve them and products do new things (or do them better), become smaller, lighter, or faster, and people buy them (wealth).

But here’s the part to remember – problems are the precursor to innovation.

Before there can be an innovation you must have a problem. Before you develop new materials, you must have problems with your existing ones; before your new products do things better, you must have a problem with today’s; before your products are miniaturized, your existing ones must be too big. But problems aren’t acknowledged for their high station.

There are problems with problems – there’s an atmosphere of negativity around them, and you don’t like to admit you have them. And there’s power in problems – implicit in them are the need for change and consequence for inaction. But problems can be more powerful if you link them tightly and explicitly to innovation. If you do, problem solving becomes a far more popular sport, which, in turn, improves your problem solving ability.

But the best thing you can do to improve your problem solving is to spend more time doing problem definition. But for innovation not any old problem definition will. Innovation requires level 5 problem definition where you take the time to define problems narrowly and deeply, to define them between just two things, to define when and where problems occur, to define them with sketches and cartoons to eliminate words, and to dig for physical mechanisms.

With the deep dive of level 5 you avoid digging in the wrong dirt and solving the wrong problem because it pinpoints the problem in space and time and explicitly calls out its mechanism. Level 5 problem definition doesn’t define the problem, it defines the solution.

It’s not glamorous, it’s not popular, and it’s difficult, but this deep, mechanism-based problem definition, where the problem is confined tightly in space and time, is the most important thing you can do to improve innovation.

With level 5 problem definition you can transform your company’s profitability and your country’s economy. It does not get any more relevant than that.

There’s a natural tendency to simplify, to reduce, to narrow. In the name of problem solving, it’s narrow the scope, break it into small bites, and don’t worry about the subtle complexities. And for a lot of situations that works. But after years of fixing things one bite at a time, there are fewer and fewer situations that fit the divide and conquer approach. (Actually, they’re still there, but their return on investment is super low.) And after years of serial discretization, what are left are situations that cannot be broken up, that cut across interfaces, that make up a continuum. What are left are big problems and big situations that have huge payoff if solved, but are interconnected.

Whether it’s cross-discipline, cross-organization, cross-cultural, or cross-best practice, the fundamental of these big kahunas is they cross interfaces. And that’s why they’ve never been attacked, and that’s why they’ve never been solved. But with payoffs so big, it’s time to take on connectedness.

For me, the most severe example of connectedness is woven around the product. To commercialize a product there are countless business process that cut across almost every interface. Here are a few: innovation, technology development, product development, robustness testing, product documentation, manufacturing engineering, marketing, sales, and service. Each of these processes is led by one organization and cuts across many; each cut across expertise-specialization interfaces; each requires information and knowledge from the other; and each new product development project must cooperate with all the others. They cannot be separated or broken into bits. Change one with intent and change the others with unintended consequences. No doubt – they’re connected.

Green thinking is much overdue, but with it comes connectedness squared. With pre-green product commercialization, the product flowed to the end user and that was about it. But with environmental movement there’s a whole new return path of interconnected business processes. Green thinking has turned the product life cycle into the circle of life – the product leaves, it lives it’s life, and it always comes back home.

And with this return path of connectedness, how the product goes together in manufacturing must be defined in conjunction with how it will be disassembled and recycled. Stress analysis must be coordinated with packaging design, regulations of banned substances, and material reuse of retired product. Marketing literature must be co-produced with regulatory strategy and recycling technologies. It’s connected more than ever.

But the bad news is the good news. Yes, things are more interwoven and the spider web is more tangled. But the upside – companies that can manage the complexity will have a significant advantage. Those that can navigate within connectedness will win.

The first step is to admit there’s a problem, and before connectedness can be managed, it must be recognized. And before it can become competitive advantage, it must be embraced.

Product costs, without product thinking, drop 2% per year. With product thinking, product costs fall by 50%, and while your competitors’ profit margins drift downward, yours are too high to track by conventional methods. And your company is known for unending increases in stock price and long term investment in all the things that secure the future.

The supply chain, without product thinking, improves 3% per year. With product thinking, longest lead processes are eliminated, poorest yield processes are a thing of the past, problem suppliers are gone, and your distributers associate your brand with uninterrupted supply and on time delivery.

Product robustness, without product thinking, is the same year-on-year. Re-injecting long forgotten product thinking to simplify the product, product robustness jumps to unattainable levels and warranty costs plummet. And your brand is known for products that simply don’t break.

Rolled throughput yield is stalled at 90%. With product thinking, the product is simplified, opportunities for defects are reduced, and throughput skyrockets due to improved RTY. And your brand is known as a good value – providing good, repeatable functionality at a good price.

Lean, without product thinking has delivered wonderful results, but the low hanging fruit is gone and lean is moving into the back office. With product thinking, the design is changed and value-added work is eliminated along with its associated non-value added work (which is about 8 times bigger); manufacturing monuments with their long changeover times are ripped out and sold to your competitors; work from two factories is consolidated into one; new work is taken on to fill the emptied factories; and profit per square foot triples. And your brand is known for best-in-class quality, unbeatable on time delivery, world class performance, and pioneering the next generation of lean.

The sales argument is low price and good payment terms. With product thinking, the argument starts with product performance and ends with product reliability. The sales team is energized, and your brand is linked with solid products that just plain work.

The marketing approach is stickers and new packaging. With product thinking, it’s based on competitive advantage explained in terms of head-to-head performance data and a richer feature set. And your brand stands for winning technology and killer products.

Product thinking isn’t for everyone. But for those that try – your brand will thank you.

Engineering is more important than manufacturing – without engineering there is nothing to make, and engineering is more important than marketing – without it there is nothing to market.

If I could choose my competitive advantage, it would be an unreasonably strong engineering team.

Ideas have no value unless they’re morphed into winning products, and that’s what engineering does. Technology has no value unless it’s twisted into killer products. Guess who does that?

We have fully built out methodologies for marketing, finance, and general management, each with all the necessary logic and matching toolsets, and manufacturing has lean. But there is no such thing for engineering. Stress analysis or thermal modeling? Built a prototype or do more thinking? Plastic or aluminum? Use an existing technology or invent a new one? What new technology should be invented? Launch the new product as it stands or improve product robustness? How is product robustness improved? Will the new product meet the specification? How will you know? Will it hit the cost target? Will it be manufacturable? Good luck scripting all that.

A comprehensive, step-by-step program for engineering is not possible.

Lean says process drives process, but that’s not right. The product dictates to the factory, and engineers dictate the product. The factory looks as it does because the product demands it, and the product looks as it does because engineers said so.

I’d rather have a product that is difficult to make but works great rather than one that jumps together but works poorly.

And what of innovation? The rhetoric says everyone innovates, but that’s just a nice story that helps everyone feel good. Some innovations are more equal than others. The most important innovations create the killer products, and the most important innovators are the ones that create them – the engineers.

Engineering as a cost center is a race to the bottom; engineering as a market creator will set you free.

The only question: How are you going to create a magical engineering team that changes the game?

Know what’s new in the new design. To do that, ask for a reuse analysis and divvy up newness into three buckets – new to your company, new to your industry, new to world. If the buckets are too big, jettison some newness, and if there’s something in the new-to-world bucket, be careful.

Create test protocols (how you’ll test) and minimum acceptance criteria (specification limits) before doing design work. It’s a great way to create clarity.

Build first – build the crudest possible prototype to expose the unfamiliar, and use the learning to shape the next prototypes and to focus analyses. Do this until you run out of time.

Cost and function are joined at the hip, so measure engineering on both.

Have a healthy dissatisfaction for success. Recognize success, yes, but also recognize it’s fleeting. Someone will obsolete your success, and it should be you.

To get an engineering team to believe in themselves, you must believe in them. To believe in them, you must believe in yourself.

As a subject matter expert (SME), you have more power than you think, and certainly more than you demonstrate.

As an SME, you have special knowledge. Looking back, you know what worked, what didn’t, and why; looking forward, you know what should work, what shouldn’t, and why.  There’s power in your special knowledge, but you underestimate it and don’t use it to move the needle.

As an SME, without your special knowledge there are no new products, no new technologies, and no new markets. Without it, it’s same-old, same-old until the competition outguns you. It’s time you realize your importance and behave that way.

As an SME, when you and your SME friends gang together, your company must listen. Your gang knows it all. From the system-level stuff to the most detailed detail, you know it. Remember, you invented the technology that powers your products. It’s time you behave that way.

As an SME, with your power comes responsibility – you have an obligation to use your power for good. Figure out what the technology wants, and do that; do the sustainable thing; do the thing that creates jobs; do what’s good for the economy; sit yourself in the future, look back, and do what you think is right.

As an SME, I’m calling you out. I trust you, now it’s time to trust yourself. And it’s time for you to behave that way.

If I was a company, the first thing I’d do is invest in my engineering teams. But not for the reasons we normally associate with engineering. Not for more function and features, not for product robustness, not technology, and not patents. I would invest in engineering for increased profits.

When it comes to their engineering divisions, other companies think minimization – fewest heads, lowest wages, least expensive tools. Not me. I’m all about maximization – smartest, best trained, and the best tools. That’s how I like to maximize profits. To me, investing in my engineering teams gives me the highest return on my investment.

Engineers create the products I sell to my customers. I’ve found when my best engineers sit down and think for a while they come up with magical ideas that translate into super-performing products, products with features that differentiate me from my cousin companies, and products that flat-out don’t break. My sales teams love to sell them (Sure, I pay a lot in bonuses, but it’s worth it.), my marketing teams love to market them, and my factory folks build them with a smile.

Over my life I’ve developed some simple truisms that I live by: When I sell more products, I make more profits; when my products allow a differentiated marketing message, I sell more and make more profits; and when my product jumps together, my quality is better, and, you guessed it, I make more profits. All these are good reasons to invest in engineering, but it’s not my reason. All this increased sales stuff is good, but it’s not great. It’s not my real reason to invest in engineering. It’s not my secret.

When I was younger I vowed to take my secret to the grave, but now that I’ve matured (and filled up several banks with money), I think it’s okay to share it. So, here goes.

My real reason to invest in engineering is material cost reduction. Yes, material cost reduction. My materials budget is one of my largest line items and I help my engineers reduce it with reckless abandon (and the right tools, time, training, and teacher.) I’ve asked my lean folks to reduce material cost, but they’ve not been able to dent it. Sure, they’ve done a super job with inventory reduction (I get a one-time carrying cost reduction.), but no material cost reduction from my lean projects. I’ve also asked my six sigma organization to reduce material costs, but they, too, have not made a dent. They’ve improved my product quality, but that doesn’t translate into piles of money like material cost reduction.

Now, I know what you’re thinking: Why, Mrs. Company, are you wasting engineering’s time with cost? Cost is manufacturing’s responsibility – they should reduce it, not engineering. Plain and simple – that’s not what I believe, and neither do my engineers. They know they create cost to enable function, good material cost – worth every penny. But they also know all other cost is bad. And since they know they design in cost, they know they’re the ones that must design it out. And they’re good at it. With the right tools, time, and training, they typically reduce material costs by 50%. Do the math –material cost for your highest volume product times 50% – year-on-year. Piles of money.

I’ve learned over the years increasing sales is difficult and takes a lot of work. I’ve also learned I can make lots of money reducing material costs without increasing sales. In fact, even during the recent downturn, through my material cost reductions I made more money than ever. I have my design engineers to thank for that.

Company-to-company, I know things have been tough for us over the last years, and money is still tight. But if you have a little extra stashed away, I urge you to invest in your engineering organization. It makes for great profits.