Shipulski On Design

Archive for the ‘Seeing Things As They Are’ Category

Good new product development projects deliver value to customers.  Bad ones create value for your company, not for customers.  Can you discern between custom value and company value?  What do you do when there’s an abundance of company value and a shortfall of customer value?  Do you run the project anyway or pull the emergency brake as soon as possible?

Customers decide if the new product has value.  That’s a rule. No one likes that rule, but it’s still a rule. The loudest voice doesn’t decide; it only drowns out the customer’s voice.

Having too many projects is worse than having too few.  With too few, you finish projects quickly because shared resources are not overutilized.  With too many, shared resources are overbooked, their service times blossom, and projects are late.   Would you rather start two projects and finish two or start seven and finish none? That’s how it goes with projects.

Three enemies of new product development: waiting, waiting, waiting.  Waiting that extends the critical path is the worst flavor of all.   Can you tell when the waiting is on the critical path?  If you calculate the cost of delay, it’s possible to spend money to eliminate waiting that’s on the critical path and make more money for your company.  H/T to Don Rienertsen.

For projects, effectiveness is more important than efficiency.  Yes, you read that correctly.  Would you rather efficiently run the wrong project (low effectiveness) or run the right project inefficiently?  Do you spend more mental energy on efficiency or effectiveness? (You don’t have to say your answer out loud.)

I think post-mortems of projects have no value.  The next project will be different, and the learning will not be applicable or forgotten altogether.  However, I think pre-mortems are powerful and can improve the effectiveness of a project BEFORE it is started.  I suggest you try it on your next project.

Strategy is realized through projects. Projects generate growth.  Cost savings come to life through projects.  I think building a deeper understanding of your projects is the most important thing you can do.

Image credit — Mike Keeling (one too many head on collisions)

You know you know, but you don’t.

You think you know, but you don’t.

You’re pretty sure you don’t know.

You know you don’t know, you think it’s not a problem that you don’t, but it is a problem.

You know you don’t know, you think it’s a problem that you don’t, but it isn’t a problem.

You don’t know, you don’t know that you don’t need to know yet, and you try.

You don’t know, you know you don’t need to know yet, and you wait.

You don’t know, you can’t know, you don’t know you can’t, and you try.

You don’t know, you can’t know, you know you can’t, and you wait.

Some skills you may want to develop….

To know when you know and when you don’t, ask yourself if you know and listen to the response.

To know if it’s a problem that you don’t know or if it isn’t, ask yourself, “Is it a problem that I don’t know?”  If it isn’t, let it go.  If it is, get after it.

To know if it’s not time to know or if it is, ask yourself, “Do I have to know this right now?” If it’s not time, wait.  If it is time, let the learning begin.  Trying to know before you need to is a big waste of time.

To know if you can’t know or if you can, ask yourself, “Can I know this?” and listen for the answer. Trying to learn when you can’t is the biggest waste of time.

Image credit — Dennis Skley

Create something that isn’t.

Build something that turns ‘didn’t’ into ‘does’.

Work on your cants.

Help people.

Make a prototype.

Use all the pieces, but use them in different ways.

Make it worse and then do the opposite. (H/T to VF)

Finish one before starting another.

Turn a ‘must not’ into a ‘hey, watch this!’

Do less with far less (post 1, post 2).

Bundle the old and new items together, and vice versa.

See cannot as a call to arms.

Say no to good projects and yes to the amazing ones.

Use half the pieces.

See quitting as fast finishing.

Ask for help.

Repeat.

Image credit Victor Sassen (confusion)

Growing a company is challenging.  Here are some common difficulties and associated approaches to improve effectiveness.

No – The way we work is artisanal.

Yes – We know how to do the work innately.

It’s perfectly fine if the knowledge lives in the people.

Would you rather the knowledge resides in the people, or not know at all?

You know how to do the work.  Celebrate that.

No – We don’t know how to scale.

Yes – We know how to do the work, and that’s the most difficult part.

It doesn’t make sense to scale before you’ve done it for the first time.

Socks then shoes, not shoes then socks.

If you can’t do it once, you can’t scale it.  That’s a rule.

Give yourselves a break.  You can learn how to scale it up.

No – We don’t know how to create the right organizational structure.

Yes – We get the work done, despite our informal structure.

Your team grew up together, and they know how to work together.

Imagine how good you’ll be with a little organizational structure!

There is no “right” organizational structure.  Add what you need where you need it.

Don’t be so hard on yourselves.  Remember, you’re getting the work done.

No – We don’t have formal production lines.

Yes – Our volumes are such that it’s best to keep the machines in functional clusters.

It’s not time for you to have production lines.  You’re doing it right.

When production volume increases, it will be time for production lines.

Go get the business so you can justify the production lines.

No – We have too many projects.  It was easier when we had a couple of small projects.

Yes – We have a ton of projects that could take off!

Celebrate the upside.  This is what growth feels like.

When the projects hit big, you’ll have the cash for the people and resources you need.

Would you rather the projects take off or fall flat?

Be afraid, celebrate the upside, and go get the projects.

No – We need everything.

Yes – Our people, processes, and systems are young AND we’re getting it done!

Assess the work, define what you need, take the right first bite, and see how it goes.

Reassess the work, define the next right bite, put it in place, and see how it goes.

Repeat.

This is The Way.

Attitude matters.  Language matters.  Approach matters. People matter.

Image credit — Eric Huybrechts (Temple of Janus)

Sometimes when I have a good idea, my body recognizes it before my mind does.  I believe my body has been doing this since I was young, but only over the last five years have I developed sufficient body awareness to recognize the sensation my body generates.  And now that I know the sensation is a signal, I know my body knows more than I do.

My body’s signaling system is usually triggered during a conversation with someone I trust.  While they are speaking to me, one or two of their words help my body flip the “knowing switch” and send its signal. Sometimes I stop listening and wait for the idea to come to my awareness.  Sometimes I say out loud, “My body thinks there’s something important in what you said.” Sometimes the signal and idea come as a pair, and I tell my friend about the idea after they finish their sentence.  All this takes some time for my coworkers and friends to understand and become comfortable.

My body can also send signals when it recognizes wrong paths or approaches that will cause conflict or confusion.  It’s a colder sensation than the one described above, and the coldness distinguishes it as a signal of potential wrongness, conflict, or confusion. Like above, it’s usually triggered during a conversation where a coworker’s words help my body flip its knowing switch and send the cold sensation.  Sometimes I stop listening and wait for the knowing to arrive.  Sometimes I acknowledge I just received a knowing signal. And sometimes I tell my friend about the knowing as soon as there’s an opening.  This, too, takes time for others to understand and become comfortable.

For my body to be able to do this for me, it must be well-rested, well-exercised, and grounded.  To do this, my body must be standing on emotional bedrock.

I think I’m more effective because I can connect with my body’s signals.  I can become aware of better ideas, I can become aware of skillful approaches, and I can become aware of ways to protect my friends from conflict and confusion.

Bessel van der Kolk says The Body Keeps The Score, and I agree. And with deep calm and awareness, I think the body can do much more.

Image credit — darkday

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 

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