Shipulski On Design

When I want to understand a large system, I make a map.  If the system is an ecosystem, I combine Wardley Maps by Simon Wardley with Wide Lens / Winning The Right Game by Ron Adner.  On Wardley maps, activities and actors are placed on the map, and related elements are connected. On the left are infant and underdeveloped elements, and on the right are fully developed / commodity elements.  It’s like an S-curve that’s been squished flat.

Wide Lens prompts you to consider co-innovation (who needs to innovate for you to be successful) and adoption (who needs to believe your idea is a good one).  Winning The Right Game makes you think through the sequence of attracting partners like a visual time-lapse of the ecosystem’s evolution.  This is a killer combination that demands you put the whole system on one page – all the players/partners, all the activities sorted by maturity, all the interactions, and the evolution of the partner network and maturity of the system elements.  This forces a common understanding of the ecosystem.  There’s no way out.  Did I say it must fit on one page?

When the large system is a technological system, I make a map.  I use the best TRIZ book (Innovation On Demand) by Victor Fey.  A functional analysis is performed on the system using noun-verb pairs that are strung together to represent how the system behaves.  If you want to drive people crazy, this is the process for you.  It requires precise words for each noun (element) and verb (action) pair, and the pairs must hang together in a way that represents the physical system.  There can be only one description of the system, and the fun and games don’t stop until the team converges on a single representation of the system. It’s all good fun until someone loses an eye.

When I want to understand a business/technology/product/service offering that has not been done before (think startup), I use Lean Canvas by Ash Maurya.  The Lean Canvas requires you to think through all elements of the system and forces you to put it on one page. (Do you see a theme here?) Value proposition, existing alternatives, channel to market, customer segments, metrics, revenue, costs, problems, and solutions – all of them on one page.

And then to blow people’s minds, I combine Wardley Maps, Wide Lens, Winning The Right Game, functional analysis of TRIZ, value in action, and Lean Canvas on one page.  And this is what it looks like.

Ash’s Lean Canvas is the backplane.  Ron’s Wide Lens supports 6 (Channel), forcing a broader look than a traditional channel view. Ron’s Winning The Right Game and Simon’s Wardley Map are smashed together to support 2 (Existing Alternatives/Problems).  A map is created for the existing system with system elements (infants on the left, retirees on the right) and partners/players, which are signified by color (red blob).  Then, a second map is created to define the improvements to be made (red circles with arrows toward a more mature state).  Victor’s Functional Analysis/System diagram defines the problematic system, and TRIZ tools, e.g., Separation Principles, are used to solve the problem.

When I want to understand a system (ecosystem or technological system), I make a map.  And when I want to make a good map, I put it on one page.  And when I want to create a new technological system that’s nested in a new business model that’s nested in a new ecosystem, I force myself to put the whole universe on one page.

Image credit – Giuseppe Zeta

I find my way.

I sometimes get caught in other people’s expectations.  Aren’t their wants important too?

I can judge myself negatively even when good things happen.  Wasn’t greatness possible?

I get angry when my expectations don’t control what the Universe does.  Am I alone in this?

But I find my way.

I sometimes prioritize my feelings over others’.  Is that good, bad, neither, or both?

I judge myself positively when good things happen. Maybe I had nothing to do with it?

I am happy when I have no expectations. But shouldn’t I expect that?

And I find my way.

I want what I don’t have.  Who decides when enough is truly enough?

I get what I want, and then I worry about losing it.  But doesn’t everything go away?

I sometimes don’t know what I want.  Maybe I don’t want anything but don’t know it?

And I still find my way.

I love helping people. It’s like helping myself twice.

I love my family.  I get meaning from them.

I love myself even when some parts of me don’t.

I find my way.

Image credit — Jan Mosimann

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

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

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 

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

Design takes responsibility for what it does – the functional or emotional goodness, the data that demonstrates the new one is better than the old one, and for the progress made by customers.

Design takes responsibility for what it’s made of – the materials, their condition, their pre-processing, and their post-processing.

Design takes responsibility for the geometry – the size and shape of the parts and how they fit together.

Design takes responsibility for how it’s made – the manufacturing processes, the automation, the manual assembly, and the variation.

Design takes responsibility for how it’s packaged – the cardboard and protective elements that enable the product to arrive undamaged.

Design takes responsibility for how it’s serviced – the troubleshooting tools, processes, and the real-time data to assess the problem from a remote location.

Design takes responsibility for the recipe – the documentation for all elements so that it can be reproduced.

Design takes responsibility for cost – the rollup of all the elements and activities required by the customer, which must be far less than the price paid by the customer.

Image credit – Pedro

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

Business is about the effective allocation of resources.  Companies win when they do that better than their competitors.  Full stop.  If you believe that, the question is how to allocate resources effectively.  To me, everything starts with a map of the territory – a single-page map of today’s projects, the people you have, and the tools/infrastructure you have.  In short, before you can reallocate resources, map how you allocate them now.

Let the mapping begin.

The first step is to create a one-page summary (a map) of the resources on hand and the projects they work on (how they are allocated).  A simple spreadsheet is the way to go.  At the top, running left to right, list the names of all the people. Give each person their column.  On the left, running top to bottom, list the active projects, one project per row.  For each project, move left to right and ask if the person works on the project.  Put an X in their column if they contribute to the project in any way.  If they work on the project 2% of their time or more, X marks the spot.  You will be reluctant to do this, but the process is more meaningful if you do.

No fancy formats, no extra text, no headings, no footers, just columns of people against rows of projects.  And it MUST fit one page. MUST. Reduce the font size and the margins to fit it on one page. And if that doesn’t work, set the print area and choose the setting that scales the print area to fit on one page.  Put it on 11 by 17 paper if you must, but you must put it on one page.  You’ll have to squint to read the font when you do it right.

When you look at the one-page printout, the first thing you will notice is that you have too many rows because you have too many projects. (And, yes, you should list the quiet projects no one knows about.) The second thing you will notice is that everyone has too many Xs because they work on too many projects.  The third thing is some people have far more Xs than everyone else’s too many Xs.  All the project managers want them on the projects because they are good at getting projects done.

Let the culling begin.

It’s time to stop.  The best way to stop is to set a maximum time threshold to deliver the first dollar of revenue.  Any project that cannot deliver revenue sooner than the threshold should stop.  The threshold method is crude, fast, and effective.  It’s a great way to do the first pass culling.  For those projects that are difficult to stop due to political factors, don’t stop them but, rather, strongly pause them.  Then, use the reallocation process (described later) to move resources to better projects and let the politically charged projects die a slow death.  Good process beats bad projects.

Strike the cancelled projects from the record, eliminate their rows, and reprint the one-page map.  If you have the right number of projects and they’re fully staffed (this is unlikely), execute the projects that made the cut.  If you have too few projects, the next step is to come up with a set of new projects that deliver revenue sooner than the culled projects.  If you still have too many projects (too many people with too many Xs), it’s time to thin the herd again.  Sort the projects by the revenue they will generate over the threshold period plus three years.  The best projects will bubble to the top, and the bad ones will sink to the bottom.

Let the reallocating begin.

Now, delete all the Xs from the spreadsheet so none of the projects are staffed and no one has a project.  Start with the top row (your best project), move left to right, and place an X in the columns until the project is fully staffed.  Allocate the resources to your best project and get after it right now. Because your best project was understaffed, incremental will flow to the project. This will increase the probability you will hit the launch date or even pull it in.

Next, move down one row to your second-best project and repeat the process.  Add Xs left to right until the project is fully staffed.  But this time there’s a constraint – each column can contain only one X.  Because the people are now fully allocated to and actively working on your best project, they cannot work on the second-best project.  With all the Xs in place and your second-best project fully staffed, work the project hard with the reallocated resources.  Pull in the timeline if you can.

Repeat the process project by project until you can no longer fully staff a project.  And here’s where the game gets interesting. Don’t work a project you cannot staff fully.  There.  I said it.  With new product development projects, there is no partial credit. They’re either 100% done or 0% done.  A project that’s 80% done delivers 0% of the revenue.  But it’s worse than that.  Making “progress” on a project that won’t launch because it’s understaffed consumes functional support resources and will slow down your most important projects.  Don’t do that. Don’t run the project. Just don’t.  You’re better off paying the people to stay home so they don’t consume functional resources needed by the more important projects.

Instead of paying the people to stay home, try to add them to the active projects so you can launch those sooner.  In theory, those projects are fully staffed, but old behaviors die hard, and you probably didn’t fully staff the most important projects.  For the people who still don’t have a project (they cannot speed up the projects), train them on the skills/tools they’ll need for the next round of projects.  This will help you do the next projects better and faster.  Or, they could start on more forward-looking projects that don’t consume resources needed by the more urgent projects.

The process to allocate people to the most important projects is the same for resources like infrastructure for reliability testing or product validation.  With the same fully-staff-the-project approach, allocate the infrastructure resources to the most important projects.  Once there is no more infrastructure capacity, don’t run an under-resourced project.  If you run the lesser project, it will consume those precious infrastructure resources and slow down your most important projects.

You likely won’t be able to staff projects such that each person works on a single project.  The concept is more directional than literal.  Working on three projects is better than working on four, and two is better than three.

I did not describe how to estimate the project revenues, how to create new projects that deliver more revenue sooner, or how to create the right mix of projects – short, medium, and long.  But in a first-things-first way, I suggest you start with a singular focus – reallocate resources to your best projects (and, likely, fewer of them), so those projects effectively deliver revenue your company needs.

I think more focus will bring you more effectiveness.

Image credit — Charlie Wales

To be more effective at a meeting, take the time to dissect the meeting agenda and details.

Who called the meeting?  If the CEO calls the meeting, you know your role. And you know your role if a team member calls the meeting.  Knowledge of the organizer helps you understand your role in the meeting.

Who is invited to the meeting?  If you are the only one invited, it’s a one-on-one meeting.  You know there will be dialogue and back-and-forth discussion.  If there are fifty people invited, you know it will be a listening meeting. And if all the company leaders are invited, maybe you should dress up a bit.

What is the sequence of the invitees? Who is first on the invite list?

Who is not invited to the meeting?  This says a lot, but takes a little thought to figure out what it says.

How long is the meeting? A fifteen-minute daily standup meeting is informal but usually requires a detailed update on yesterday’s progress.  An all-day meeting means you’ve got to pace yourself and bring your coffee.

Is lunch served?  The better the lunch, the more important the meeting.  And it’s the same for snacks.

Is the meeting in-person or remote?  In-person meetings are more important and more impactful.

If pre-read material is sent out two days before the meeting, the organizer is on their game.  If the pre-read material is sent out three minutes before the meeting, it’s a different story.

If there’s no agenda, it means the organizer isn’t all that organized.  Skip these meetings if you can.  But if you can’t, bring your laptop and be ready to present your best stuff.  If no one asks you to talk, keep quiet and listen.  If you’re asked to present, present something if you can.  And if you can’t, say you’re not ready because the topic was not included in the agenda.

The best agendas define the topics, the leader of each topic, and the time blocks.

All these details paint a picture of the upcoming meeting and help you know what to expect.  When you know what to expect will enable you to hear the things that aren’t said and the discussions that don’t happen.

When the group avoids talking about the charged topic or the uncomfortable situation, you’ll recognize it.  And because you know who called the meeting, the attendees, and the meeting context, you’ll help the group discuss what needs to be discussed.  You’ll know when to ask a seemingly innocent question to help the group migrate to the right discussion.  And you’ll know when it’s okay to put your hand up and tell the group they’re avoiding an important topic that should be discussed.

Anyone can follow the agenda, but it takes preparation, insight, awareness, and courage to help the group address the important but uncomfortable things not on the agenda.

Image credit — Joachim Dobler