Shipulski On Design

Posts Tagged ‘Competitiveness’

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

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

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 

When your idea is new, it (and you) will be misunderstood.  I urge you to see the misunderstanding as a vote of confidence.  Keep going.

When your position contradicts the mainstream, say it anyway.  They’ll appreciate your honesty and courage if you work at a good company.  If you work at a bad company, they’ll probably try to run you out of town.  Either way, you’ll know what kind of company you’re working for.

Change is difficult when the Status Quo has been successful for a long time.  Success will block your new idea because there’s no need for it.  Working on your new idea pulls resources away from the Status Quo’s initiatives, and the Status Quo will have none of that.  Don’t take its wrath personally.  That’s how the Status Quo goes about its business.

When your new idea is young, it is too fragile to be justified in an ROI sense.  Shelter it from the Accounting Police.

Your new idea isn’t right.  It starts the journey as one thing, and as the journey progresses, it will transform into something better.  This is how it goes with new ideas.

Without a new idea, you’ll do what you did last time. That’s no way to live.

If no one complains, your idea isn’t new.  You missed the mark.

If some complain but none are threatened, it’s not new enough. Try harder.

Image credit – denisben

We all want to increase top-line revenue by selling more.  But we’ve been selling our existing products into the same old applications for a long time now, and we’ve reached a hard limit – when we add more effort, we get little in return.  Developing an entirely new product will take a long time, so we will try to sell our existing products into new applications.  We will have to change our product slightly to make it work in the new applications, but we can do that quickly.  We have a good plan.

We search the globe for these new applications and find a winner.  It’s a new application in which our product has a technological advantage over the existing products.  The new value is clear to the customer, and they want to get rid of their existing products and replace them with our flagship product. Our product requires minimal changes, which we’ve already implemented.  Our product is ready to sell!  Let’s go!  Let’s get after it.  Not so fast.

As it turns out, the customers don’t know how to use our product, they don’t know how to install it, and they don’t have a way to buy the consumables and maintenance parts.  Before we can sell, we must figure out a way to get the products installed, to train the operators, to find a way to sell the wear parts and consumables, and to service the product.  As it turns out, with this new application, there are a lot of missing elements to the go-to-market system.

When selling into new applications, it’s not all about the product.  It’s all about the partners. It’s about finding and developing partners familiar with the industry, the application, and the customers.  But it’s tricky.  You are unfamiliar with the application and don’t know how to find these partners.  Once you identify them, they are unfamiliar with your product, how it’s installed, how it’s operated, and how it’s serviced.

It takes time and effort to educate, train, and develop a new partner.  They may know the customer, but they don’t know the ins and outs of your product.  And they need to educate, train, and develop you.  You may know your product, but you don’t know the customers and the ins and outs of the application.

These new applications can create incremental revenue for you and your new partners, and that’s exciting.  But at the early stages of development, these new applications require more time and investment than we’re used to.  The profitability equation will take some time to realize its full potential.  And to realize that full potential, be sure to create a go-to-market model that is profitable for your partner.  An unprofitable partner can’t afford to be a good partner.  And you need good partners.

Image credit — TMAB2003

Before you can make improvements, you must identify improvement opportunities.

Before you can identify improvement opportunities, you must look for them.

Before you can look for improvement opportunities, you must believe improvement is possible.

Before believing improvement is possible, you must admit there’s a need for improvement.

Before you can admit the need for improvement, you must recognize the need for improvement.

Before you can recognize the need for improvement, you must feel dissatisfied with how things are.

Before you can feel dissatisfied with how things are, you must compare how things are for you relative to how things are for others (e.g., competitors, coworkers).

Before you can compare things for yourself relative to others, you must be aware of how things are for others and how they are for you.

Before you can be aware of how things are, you must be calm, curious, and mindful.

Before you can be calm, curious, and mindful, you must be well-rested and well-fed.  And you must feel safe.

What choices do you make to be well-rested? How do you feel about that?

What choices do you make to be well-fed? How do you feel about that?

What choices do you make to feel safe? How do you feel about that?

Image credit — Philip McErlean

Improvement is progress.  Improvement is always measured against a baseline, so the first thing to do is to establish the baseline, the thing you make today, the thing you want to improve.  Create an environment to test what you make today, create the test fixtures, define the inputs, create the measurement systems, and write a formal test protocol.  Now you have what it takes to quantify an improvement objectively.  Test the existing product to define the baseline.  No, you haven’t improved anything, but you’ve done the right first thing.

Improving the right thing to make progress.  If the problem invalidates the business model, stop what you’re doing and solve it right away because you don’t have a business if you don’t solve it. Any other activity isn’t progress, it’s dilution.  Say no to everything else and solve it.  This is how rapid progress is made.  If the customer won’t buy the product if the problem isn’t solved, solve it.  Don’t argue about priorities, don’t use shared resources, don’t try to be efficient.  Be effective.  Do one thing.  Solve it.  This type of discipline reduces time to market.  No surprises here.

Avoiding improvement of the wrong thing to make progress.  For lesser problems, declare them nuisances and permit yourself to solve them later.   Nuisances don’t have to be solved immediately (if at all) so you can double down on the most important problems (speed, speed, speed).  Demoting problems to nuisances is probably the most effective way to accelerate progress.  Deciding what you won’t do frees up resources and emotional bandwidth to make rapid progress on things that matter.

Work the critical path to make progress. Know what work is on the critical path and what is not.  For work on the critical path, add resources.  Pull resources from non-critical path work and add them to the critical path until adding more slows things down.

Eliminate waiting to make progress.  There can be no progress while you wait.  Wait for a tool, no progress.  Wait for a part from a supplier, no progress.  Wait for raw material, no progress.  Wait for a shared resource, no progress.  Buy the right tools and keep them at the workstations to make progress.  Pay the supplier for priority service levels to make progress.  Buy inventory of raw materials to make progress.  Ensure shared resources are wildly underutilized so they’re available to make progress whenever you need to.  Think fire stations, fire trucks, and firefighters.

Help the team make progress. As a leader, jump right in and help the team know what progress looks like.  Praise the crudeness of their prototypes to help them make them cruder (and faster) next time.  Give them permission to make assumptions and use their judgment because that’s where speed comes from.  And when you see “activity” call it by name so they can recognize it for themselves, and teach them how to turn their effort into progress.

Be relentless and respectful to make progress. Apply constant pressure, but make it sustainable and fun.

Image credit — Clint Mason

Efficient – How do we do more projects with fewer people?

Effective – Let’s choose the right project.

Would you rather do more projects that miss the mark or fewer that excite the customer?

Efficient – How do we finish the project faster?

Effective – Let’s fully staff the project.

Would you rather burn out the project team or deliver on what the customer wants?

Efficient – How do we reduce product cost by 5%?

Effective – Let’s make customers’ lives easier.

Would you rather reduce the cost or delight the customer?

Efficient – How can we go faster?

Effective – Let’s get it right.

Would you rather go fast and break things or get it right for the customer?

Efficient – How many projects can we run in parallel?

Effective – Let’s fully staff the most important projects.

Would you rather get halfway through four projects or complete two?

Efficient – How do we make progress on as many tasks as possible?

Effective – Let’s work on the critical path.

Would you rather work on things that don’t matter or nail the things that do?

Efficient – How can we complete the most tasks?

Effective – Let’s work on the hardest thing first.

Would you rather learn the whole thing won’t work before or after you waste time on the irrelevant?

If there’s a choice between efficiency and effectiveness, I choose effectiveness.

Image credit — Antarctica Bound

COPYRIGHT GEOFF HENSON

If you’ve done it before, let someone else do it.

If you’ve done it before, teach someone else to do it.

If you’ve done it before, do it in a tenth of the time.

Do it differently just because you can.

Do it backward. That will make you smile.

Do it with your eyes closed.  That will make a statement.

Do its natural extension. That could be fun.

Do the opposite.  Then do its opposite.  You’ll learn more.

Do what they should have asked for. Life is short.

Do what scares them. It’s sure to create new design space.

Do what obsoletes your most profitable offering. Wouldn’t you rather be the one to do it?

Do what scares you.  That’s sure to be the most interesting of all.

Image credit — Geoff Henson

We all have to-do lists. We add things and we check them off.  This list grows and shrinks.  We judge ourselves negatively when we check off fewer than expected and positively when we check off more than that.  But what’s the right number of completed tasks for us to feel good? How many completed tasks is enough?

If you complete one task per week that saves $5000, is that enough? Is it enough to complete fifty tasks per year?  If you create the conditions that make possible a new product line that delivers $1B over three years, but you do that only once every five years, is that enough? Is it enough to do just that one right thing over five years? What does it look like to others when you complete one exceptionally meaningful task every five years? I think it looks like most of the time you are doing very little.

Sometimes you complete small things and sometimes you don’t.  And sometimes you learn what doesn’t work and that’s the completed task.  And sometimes there are long stretches where nothing is accomplished until you create something magical. Counting tasks is no way to go through life.

But counting and measuring is all the rage.  Look at your yearly goals.  Do ten of these.  Run six of those. Complete twelve of the other.  Why do we think we can predict what we should do next year?  Even sillier, do we really believe we know how many of these, those, and the others we will be able to get done next year?  C’mon.  Really?

What if all this counting prevents us from imagining the future? And what if our unhealthy fascination with measuring blocks us from creating it?

If it’s all about the measurable, there’s no room for the Magical.

Why not make some room for the Magical?

Image credit — Philip McErlean