Archive for June, 2025
Good Teachers Are Better Than Good
Good teachers change your life. They know what you know and bring you along at a pace that’s right for you, not too slowly that you’re bored and not too quickly that your head spins. And everything they do is about you and your learning. Good teachers prioritize your learning above all else.
Chris Brown taught me Axiomatic Design. He helped me understand that design is more than what a product does. All meetings and discussions with Chris started with the three spaces – Functional Requirements (FRs) what it does, Design Parameters (DPs) what it looks like, and Process Variables (PVs) how to make it. This was the deepest learning of my professional life. To this day, I am colored by it. And the second thing he taught me was how to recognize functional coupling. If you change one input to the design and two outputs change, that’s functional coupling. You can manage functional coupling if you can see it. But if you can’t see it, you’re hosed. Absolutely hosed.
Vicor Fey taught me TRIZ. He helped me understand the staggering power of words to limit and shape our thinking. I will always remember when he passionately expressed in his wonderful accent, “I hate words!” And to this day, I draw pictures of problems and I avoid words. And the second thing he taught me is that a problem always exists between two things, and those things must touch each other. I make people’s lives miserable by asking – Can you draw me a picture of the problem? And, Which two system elements have the problem, and do they touch each other? And the third thing he taught me was to define problems (Yes, Victor, I know I should say conflicts.) in time. This is amazingly powerful. I ask – “Do you want to solve the problem before it happens, while it happens, or after it happens?” Defining the problem in time is magically informative.
Don Clausing taught me Robust Design. He helped me understand that you can’t pass a robustness test. He said, “If you don’t break it, you don’t know how good it is.” He was an ornery old codger, but he was right. Most tests are stopped before the product fails, and that’s wrong. He also said, “You’ve got to test the old design if you want to know if the new one is better.” To this day, I press for A/B testing, where the old design and new design are tested against the same test protocol. This is much harder than it sounds and much more powerful. He taught me to test designs at stress levels higher than the operating stresses. He said, “Test it, break it, and improve it. And when you run out of time, launch it.” And, lastly, he said, “Improve robustness at the expense of predicting it.” He gave zero value to statistics that predict robustness and 100% value to failure mode-based testing of the old design versus the new one.
The people I work with don’t know Chris, Victor, or Don. But they know the principles I learned from them. I’m a taskmaster when it comes to FRs-DPs-PVs. Designs must work well, be clearly defined by a drawing, and be easy to make. And people know there’s no place in my life for functional coupling. My coworkers know to draw a picture of the problem, and it better be done on one page. And they know the problem must be shown to exist between two things that touch. And they know they’ll get the business from me if they don’t declare that they’re solving it before, during, or after. They know that all new designs must have A/B test results, and the new one must work better than the old one. No exceptions.
I am thankful for my teachers. And I am proud to pass on what they gave me.
Image credit — Christof Timmermann
What makes a strategic plan strategic?
X: We need a strategic plan.
Me: Why do you need one of those?
X: Everybody needs a strategic plan.
Me: Okay. That didn’t work. Let me try it another way. What makes a plan strategic?
X: You start with a strategy and you create a plan to make it happen over the next three years.
Me: So, you plan out the next three years?
X: Yes. Or four.
Me: Doesn’t the plan assume you know how the Universe will behave over the next three years?
X: We know our market, we know our customers, we know our technology, and we make a three-year plan.
Me: And what if something changes, like COVID, tariffs, or a new competitor brings to market something that obsoletes your best product?
X: You can’t plan for that.
Me: Exactly.
X: You’re talking in circles! What do you mean?
Me: If your three-year plan can’t plan for unplanned things, what kind of plan is that?
X: I told you. It’s a strategic plan.
Me: Hmm. Let me try that again. What happens when something unexpected arises and your plan needs to change?
X: It’s a strategic plan. Those don’t change.
Me: Arrg. Do you mean the plan should change, but you don’t make the change? Or strategic plans never change?
X: Strategic plans don’t change because they’re strategic. We put a lot of time into creating them.
Me: They don’t change because they take a lot of time and effort to create?
X: Well, yes. We have long planning meetings, and our best people spend a lot of time creating it.
Me: Do you think the Universe cares how long it took you to create your plan?
X: There you go again with the Universe thing.
Me: What I mean by that is there are many factors outside your control. It’s a big world out there. And you can’t plan for everything.
X: What do you mean? We put everything in the strategic plan.
Me: That’s not the type of everything I’m talking about. I’m talking about things outside your control that you cannot possibly know.
X: Are you saying we don’t know what we’re doing?
Me: No, I’m saying you know everything you’re going to do over the next three years. And that’s the problem.
X: You are frustrating. First you tell me it’s impossible to plan for everything, then you tell me we have a problem because we plan for everything. What’s wrong with you?
Me: That’s the right question. There’s a lot wrong with me. I have a good idea that turns out to be wrong, so I change my plan. I think I understand what’s going on, but I learn that I’m wrong, so I change my plan. I have a plan, but something unexpected happens and turns my plan from good to wrong, so I change it, even if the plan is strategic, whatever that means.
Image credit — Geoff Henson
Change the plan or stay the course?
Plans are good, until they’re not. The key is knowing when to stay the course and when to adjust the plan.
The time horizons for strategic plans or corporate initiatives can range from two to five years. To ensure we create the best plans, we assign the work to our best people, we provide them with the best information, and we ask them to use their best judgment. As input, we assess market fundamentals, technology trends, customer segments, our internal talent, our partners, our infrastructure, and our processes. We then set revenue targets and create project plans and resource allocation plans to realize the revenue goals. And then it’s go time.
We initiate the projects, work the plans, and report regularly on the progress. If the progress meets the monthly goal, we keep going. And if the progress doesn’t meet the monthly goal, we keep going. We invested significant time and effort into the plan, and it can be politically difficult, if not bad for your career, to change the plan. It takes confidence and courage to call for a change to a strategic plan or a corporate initiative. But two to five years is a long time, and things can (and do) change over the life of a plan.
A plan is created with the best knowledge available at the time. We assess the environment and use the knowledge to set the financial requirements for the plan. When the environment and requirements change, the plan should change.
Before considering any changes, if we learn that the assumptions used to create the plan are invalid, the plan should change. For example, if the resource allocation is insufficient, the timelines should be extended, resources should be added, or the scope of the work should be reduced. I think changing the plan is responsible management, and I think it’s irresponsible management to stay the course.
The environment can change in many ways. Here are five categories of change: tariffs, competition, internal talent (key people move on), new customer learning, and new technical learning (e.g., more technical risk than anticipated). Significant changes in any of these categories should trigger an assessment of the plan’s viability. This is not a sign of weakness. This is responsible management. And if the change in the environment invalidates the plan’s assumptions, the plan should change.
The specification (revenue targets) for the plans can change. There are at least two flavors of change: an increase in revenue goals or a shorter timeline to achieve revenue goals, which are usually caused by changes to the environment. And when there’s a need for more revenue or to deliver it sooner, the plans should be assessed and changed. Again, I think this is good management practice and not a sign of failure or weakness. When we realize the plan won’t meet the new specification, we should modify the plan.
When we learn the assumptions are wrong, we should change the plan. When the environment changes, we should change the plan. And when the specification changes, we should change the plan.
Image credit — Charlie Day
Fight Dilution!
With new product development projects, there is no partial credit. If you’re less than 100% done, there are zero sales. 90% done, zero sales. 95% done, zero sales. We all understand the concept, but our behavior often contradicts our understanding. You have too many projects, and our focus on efficiency is to blame.
Under the banner of efficiency, we run too many projects in parallel, and our limited resources become spread too thinly over too many projects. Project timelines grow, launch dates are pushed out, and revenue generation is delayed. And because there’s a shortfall in revenue, we start more projects to close the gap. That’s funny.
In short, we’ve morphed Start, Stop, Continue into Start, Start, Start.
Here’s a process to help you stop starting and start finishing.
Open a spreadsheet and list all your projects for the year. At the top of the column, list the projects you’ve completed. Below the completed projects, list your active projects, and below them, list your future (not yet started) projects. Highlight the completed projects and the active projects, and set the print area. Then, select “print on both sides of the page.” When you print the file, the future projects will be printed on the back of the page. This will help you focus on the completed and active projects and block you from trying to start a project before finishing one.
Now, go back to the top of the spreadsheet and select the completed projects and change the font to “strike through.” This will allow you to read the project names and remind yourself of the projects you completed. You can use this list to justify a strong performance rating at your upcoming performance review.
Skip down to the active projects and categorize them as fully staffed or partially staffed. Change the font color to red for the partially staffed projects and move them to the second page with the future projects. Print out the spreadsheet.
The completed projects will be at the top of the page in strike-through font, and the short list of fully staffed projects is listed below them in normal font. On the back of the page, the partially staffed projects are listed in red, and the future projects are listed below them. And now you’re ready to realize the power of the two-sided printout.
Step 1. Ignore the projects on the back of the page (under-staffed and yet to be started projects). They’re still on the do-do list, but they’ll wait patiently on the back of the page until resources are freed up and allocated.
Step 2. Finish the fully staffed projects on the front page.
Step 3. When you finish a project, change the font to “strike-through” and create a list of the freed-up resources.
Step 4. Flip to the back of the page, allocate the freed-up resources to one of the projects, and move the fully staffed project to the front of the page.
Step 5. Proceed to Step 2.
This is a straightforward process, but it requires great discipline.
Here’s a mantra to repeat daily – I will finish a project before I start the next one.
Image credit — iggyshoot