Shipulski On Design

Archive for the ‘Fundementals’ Category

When the cost of the experiment is small, the downside of its potential failure is also small.

Small improvements cost little and can be implemented quickly.

Small improvements make a difference.

If the transformational improvement never sees the light of day because it costs too much to implement, its realized value is less than the smallest improvement that was implemented.

When a small experiment does not go as planned, the learning can be significant (and fast).

Small experiments are funded by small investments that don’t require approval.  Don’t seek approval. Run the experiment.

The second small improvement stands on the shoulders of the first one

If the improvement is never implemented, it’s not an improvement.

Small improvements can be tested under the radar.  When they work well, give the credit to someone who deserves it. When they go poorly, try something else.

Like ants, small improvements gang up to make a real difference.

Once a small improvement is implemented, it stays implemented.  Like a one-way ratchet, there’s no backsliding.

Small improvements add up over time, but only if you bring them to life.

When it comes to improvements, small is beautiful.

Image credit — Jim Roberts – Papa I’m only a little sparrow

Companies make progress through projects.

Projects have objectives that are defined by the company’s growth or improvement objectives.

Projects have quantifiable goals that are, hopefully, time-bound.

Projects require resources, and those resources limit the number of projects that are completed.

Projects are run with the resources allocated, not with the resources we want to allocate.

Projects have timelines that are governed by the work content, novelty, and resources.

Project timelines cannot violate the governing constraints of work content, novelty, and resources.

Projects have project managers, or they’re not projects.

Projects can be accelerated by eliminating waiting.  To find the waiting, look for the work queued up in front of the bottleneck resources.  Those resources are usually resources that support multiple projects (shared resources).  When it comes to waiting, shared resources are almost always the culprit.

Projects have a critical path.  A one-day delay (waiting) on the critical path delays project completion by a day.  That’s how you know it’s the critical path.

If you don’t know the project’s critical path, you don’t know much.

When it comes to projects, effectiveness is far more important than efficiency, yet we fixate on efficiency.  Would you rather run the wrong project efficiently (ineffective) or run the right project inefficiently (effective)?

Regardless of the business you’re in, it’s all about the projects.

Image credit — State Library of South Australia

When you start something, by definition, you will end it.

All good things come to an end.  So do all bad things. That’s how it goes with things.

All new things start with the end of old things. That’s how things are.

What does it say when a phase of your life comes to an end?

Doesn’t the start of a new phase demand the end of an existing one?

When something ends, do you curse it or celebrate it, do both, or neither?  And how do you decide?

If you stay with the old thing too long, what does that say?  And how do you know it was too long?

Can you know it will be too long before you stay too long?

If you leave too soon, can you know that before you leave?

The follow-on results of a decision do not determine the quality of a decision.

There is no right decision to make.

Make the decision and then make it right.

Image credit — Karissa Burnett

When the ocean gets tired from holding its water up to make high tide, it lets go and relaxes into low tide.  The ocean takes direction from the moon who knows it can’t always be high tide.  This is The Way.

When the earth gets tired from heating up the northern hemisphere it wobbles on its axis and relaxes its northern territories into cooler weather.  And the reduced energy demand in the north frees up energy for the earth to focus on heating up its southern hemisphere.  Taking direction from the  sun, the earth knows it cannot always be hot in the north or the south.  And it know it doesn’t have enough energy to make it hot in the north and south at the same time. And it knows it can’t be lazy all year and let it be cold in both hemisheres year round. It’s natural for winter to follow summer and for the hemispheres to be out of phase.  The earth and sun know this.  It’s natural for them.

Bears have their fun in spring summer and fall.  They are all-in on eating, taking care of young bears, and making new ones.  After three seasons of fun and games, bears know they need to hunker down and rest for the winter.  That is how it is with bears and how it will always be. It is natural bear behavior. And it works.

When you work out hard, your body knows it needs to rest the next day.  It knows it needs to recover from the elevated stress of the workout so it gives you feedback that it’s important to do less the following day. There’s nothing wrong with that.  In fact, there’s everything right with that.   It’s natural and it works.

And there are natural rest cycles at work,  After a full week of planning meetings, people need to downshift into work that is less taxing and gives their bodies time to process the plans.  This is not weakness, it’s natural.

And there are even natural hibernation cycles at work in the form of vacations and holidays.  Like with bears, our bodies need (and deserve) deep rest.  And just bears don’t check their email when hibernating, neither should we.  Taking time for deep rest is not irresponsible or wasteful, it’s natural

Without a trough there can be no crest.  And without rest there can be no high performance.  This, too, is natural.

Image credit — Geoff Henson

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)

Are you working on important problems?

Or are you seeking out important problems?

Or are you connecting with people who work on important problems?

I ask because I think working on important problems is important.

Are you working with people who build you up?

Do you separate from those who do the opposite?

Are you building up others?

Do you call out those who do the opposite?

Are you seeking out people who deserve rebuilding?

Do you suppress the unbuilding that creates the need for rebuilding?

I ask because I think building builds character.

Does your work matter?

What do you do when it doesn’t?

To whom does your work matter?

What do you do if you don’t know?

Do you seek out work that matters?

What do you do to block yourself from seeking out work that matters?

How do you decide if your work matters?

What do you do when you are unsure?

I ask because I think it matters.

Who is important to you?

How can you spend more time with them?

Who is not important to you?

How can you spend less time with them?

I ask because I think that’s important.

What do you think is most important?

What deserves more attention?

Who deserves to know?

When will you tell them?

I ask because I think this adds meaning to our lives.

Image credit – Dr. Matthias Ripp – Any Questions?

The CEO doesn’t decide if it’s good enough.  The VP of Marketing doesn’t decide if it’s good enough.  The VP of Engineering doesn’t decide if it’s good enough. The customer decides if it’s good enough.

If the product isn’t selling, the price may be okay, but the performance may not be good. In this case, it’s time to add some sizzle.  And who decides if the sizzle is sufficient?  You guessed it – the customer.  And if you add the sizzle and they buy more, the sizzle was the problem.  If they don’t buy more, it wasn’t the sizzle.

If the product isn’t selling, the performance may be okay, but the price may be too high.  In this case, it’s time to pull some cost out of the product and reduce the price.  Maybe a better way is to test a lower price with customers.  If they buy more, it’s worth doing the work to pull out the cost.  If they don’t buy at the lower price, the price isn’t the problem.  You still have some work to do.

If the product isn’t selling, both the performance and the price may be the problem.  It’s time to add some sizzle and lower the price.  But there’s no need to do the work until you test the hypothesis.  Make a one-page sales tool with the new sizzle and price.  If they like it, make it so.  If they don’t like it, make another sales tool with some different sizzle and a different price.  Repeat the process until the customer likes the new offering.  Then, make it so.

If the product isn’t selling, it’s possible the sales channel isn’t making enough money when they sell your product.  To test this, go on several sales calls with them.  If they are unwilling to bring you on the sales calls, it’s a good sign that there’s not enough money in it for them.  There are three ways to move forward.  Reduce the price to the channel partner.  If they sell more, you’re off to the races if, of course, there is enough margin in the product to support the reduced price.  Make it easier for them to sell your product so they spend less time and effort and make more profit.  Sell through a different channel.

When your product isn’t selling, figure out why it isn’t selling.  And because there are many possible reasons your product isn’t selling, it’s best to create a hypothesis and test it.  Your job is not to solve the problem; rather, your job is to figure out what the problem is and to decide whether it’s worth solving.

If you create a one-page sales tool with a lower price and customers still don’t want to buy it, don’t bother to design out the cost or reduce the price.  If you create a one-page sales tool with a new DVP and the customers still don’t want to buy it, don’t do the work to develop that new DVP.  If you test a reduced price to the channel and they sell a few more systems, don’t reduce the price because it’s not worth it.

Once you have objective evidence that you know what the problem is and it’s worth solving, do the work to solve it and implement the solution.  If you don’t have objective evidence that you know what the problem is, it’s not yet time to solve it.

There’s nothing worse than solving the wrong problem.  And the customer decides if the problem is worth solving.

Image credit — Geoff Henson

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)

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

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