Shipulski On Design

Archive for the ‘Top Line Growth’ Category

Company leaders deserve to know the truth, but they can no longer take the time to learn it.

Company leaders are pushed too hard to grow the business and can no longer take the time to listen to all perspectives, no longer take the time to process those perspectives, and no longer take the time to make nuanced decisions. Simply put, company leaders are under too much pressure to grow the business.  It’s unhealthy pressure and it’s too severe.  And it’s not good for the company or the people that work there.

What’s best for the company is to take the time to learn the truth.

Getting to the truth moves things forward.  Sure, you may not see things correctly, but when you say it like you see it, everyone’s understanding gets closer to the truth.  And when you do see things clearly and correctly, saying what you see moves the company’s work in a more profitable direction.  There’s nothing worse than spending time and money to do the work only to learn what someone already knew.

What’s best for the company is to tell the truth as you see it.

All of us have good intentions but all of us are doing at least two jobs. And it’s especially difficult for company leaders, whose responsibility is to develop the broadest perspective.  Trouble is, to develop that broad perspective sometime comes at the expense of digging into the details. Perfectly understandable, as that’s the nature of their work. But subject matter experts (SMEs) must take the time to dig into the details because that’s the nature of their work. SMEs have an obligation to think things through, communicate clearly, and stick to their guns.  When asked broad questions, good SMEs go down to bedrock and give detailed answers. And when asked hypotheticals, good SMEs don’t speculate outside their domain of confidence. And when asked why-didn’t-you’s, good SMEs answer with what they did and why they did it.

Regardless of the question, the best SMEs always tell the truth.

SMEs know when the project is behind. And they know the answer that everyone thinks will get the project get back on schedule. And the know the truth as they see it. And when there’s a mismatch between the answer that might get the project back on schedule and the truth as they see it, they must say it like they see it.  Yes, it costs a lot of money when the project is delayed, but telling the truth is the fastest route to commercialization. In the short term, it’s easier to give the answer that everyone thinks will get things back on track. But truth is, it’s not faster because the truth comes out in the end.  You can’t defy the physics and you can’t transcend the fundamentals.  You must respect the truth. The Universe doesn’t care if the truth is inconvenient.  In the end, the Universe makes sure the truth carries the day.

We’re all busy.  And we all have jobs to do. But it’s always the best to take the time to understand the details, respect the physics, and stay true to the fundamentals.

When there’s a tough decision, understand the fundamentals and the decision will find you.

When there’s disagreement, take the time to understand the physics, even the organizational kind. And the right decision will meet you where you are.

When the road gets rocky, ask your best SMEs what to do, and do that.

When it comes to making good decisions, sometimes slower is faster.

Image credit — Dennis Jarvis

Efficiency is a simple measurement – output divided by resources needed to achieve it. How much did you get done and how many people did you need to do it? What was the return on the investment? How much money did you make relative to how much you had to invest? We have efficiency measurements for just about everything. We are an efficiency-based society.

It’s easy to create a metric for efficiency. Figure out the output you can measure and divide it by the resources you think you used to achieve it. While a metric like this is easy to calculate, it likely won’t provide a good answer to what we think is the only question worth asking– how do we increase efficiency?

Problem 1. The resources you think are used to produce the output aren’t the only resources you used to generate the output.  There are many resources that contributed to the output that you did not measure. And not only that, you don’t know how much those resources actually cost.  You can try the tricky trick of fully burdened cost, where the labor rate is loaded with an overhead percentage.  But that’s, well, nothing more than an artifact of a contrived accounting system. You can do some other stuff like calculate the opportunity cost of deploying those resources on other projects. I’m not sure what that will get you, but it won’t get you the actual cost of achieving the output you think you achieved.

Problem 2. We don’t measure what’s important or meaningful.  We measure what’s easy to measure.  And that’s a big problem because you end up beating yourself about the head and shoulders trying to improve something that is easy to measure but not all that meaningful. The biggest problem here is local optimization.  You want something easy to measure so you cull out a small fraction of a larger process and increase the output of that small part of the process.  The thing is, your customer doesn’t care about the efficiency of that small piece of that process.  And, improving that small piece likely doesn’t do anything for the output of the total process.  If more products aren’t leaving the factory, you didn’t do anything.

Problem 3. Productivity isn’t all that important. What’s important is effectiveness.  If you are highly efficient at the wrong thing, you may be efficient, but you’re also ineffective. If you launch a product in a highly efficient way and no one buys it, your efficiency numbers may be off the charts, but your effectiveness numbers are in the toilet.

We have very few metrics on effectiveness.  But here are some questions a good effectiveness metric should help you answer.

• Did we work on the right projects?
• Did we make good decisions?
• Did we put the right people on the projects?
• Did we do what we said we’d do?
• After the project, is the team excited to do a follow-on project?
• Did our customers benefit from our work?
• Do our partners want to work with us again?
• Did we set ourselves up to do our work better next time?
• Did we grow our young talent?
• Did we have fun?
• Do more people like to work at our company?
• Have we developed more trust-based relationships over the last year?
• Have we been more transparent with our workforce this year?

If I had a choice between efficiency and effectiveness, I’d choose effectiveness.

Image credit – Bruce Tuten

A prototype moves us from “That’s not possible.” to “Hey, watch this!”

A prototype moves us from “We don’t do it that way.” to “Well, we do now.”

A prototype moves us from “That’s impossible.” to “As it turns out, it was only almost impossible.”

A prototype turns naysayers into enemies and profits.

A prototype moves us from an argument to a new product development project.

A prototype turns analysis-paralysis into progress.

A prototype turns a skeptical VP into a vicious advocate.

A prototype turns a pet project into top-line growth.

A prototype turns disbelievers into originators of the idea.

A prototype can turn a Digital Strategy into customer value.

A prototype can turn an uncomfortable Board of Directors meeting into a pizza party.

A prototype can save a CEO’s ass.

A prototype can be too early, but mostly they’re too late.

If the wheels fall off your first prototype, you’re doing it right.

If your prototype doesn’t dismantle the Status-Quo, you built the wrong prototype.

A good prototype violates your business model.

A prototype doesn’t care if you see it for what it is because it knows everyone else will.

A prototype turns “I don’t believe you.” into “You don’t have to.”

When you’re told “Don’t make that prototype.” you’re onto something.

A prototype eats not-invented-here for breakfast.

A prototype can overpower the staunchest critic, even the VP flavor.

A prototype moves us from “You don’t know what you’re talking about.” to “Oh, yes I do.”

If the wheels fall off your second prototype, keep going.

A prototype is objective evidence you’re trying to make a difference.

You can argue with a prototype, but you’ll lose.

If there’s a mismatch between the theory and the prototype, believe the prototype.

A prototype doesn’t have to do everything, but it must do one important thing for the first time.

A prototype must be real, but it doesn’t have to be really real.

If your prototype obsoletes your best product, congratulations.

A prototype turns political posturing into reluctant compliance and profits.

A prototype turns “What the hell are you talking about?” into “This.”

A good prototype bestows privilege on the prototyper.

A prototype can beat a CEO in an arm-wrestling match.

A prototype doesn’t care if you like it. It only cares about creating customer value.

If there’s an argument between a well-stated theory and a well-functioning prototype, it’s pretty clear which camp will refine their theory to line up with what they just saw with their own eyes.

A prototype knows it has every right to tell the critics to “Kiss my ass.” but it knows it doesn’t have to.

You can argue with a prototype, but shouldn’t.

A prototype changes thinking without asking for consent.

Image credit — Pedro Ribeiro Simões

Whatever your initiative, start with customer value. Whatever your project, base it on customer value. And whatever your new technology, you guessed it, customer value should be front and center.

Whenever the discussion turns to customer value, expect confusion, disagreement, and, likely, anger. To help things move forward, here’s an operational definition I’ve found helpful:

When they buy it for more than your cost to make it, you have customer value.

And when there’s no way to pull out of the death spiral of disagreement, use this operational definition to avoid (or stop) bad projects:

When no one will buy it, you don’t have customer value and it’s a bad project.

As two words, customer and value don’t seem all that special. But, when you put them together, they become words to live by.  But, also, when you do put them together, things get complicated.  Here’s why.

To provide customer value, you’ve got to know (and name) the customer.  When you asked “Who is the customer?” the wheels fall off. Here are some wrong answers to that tricky question. The Board of Directors is the customer. The shareholders are the customers. The distributor is the customer. The OEM that integrates your product is the customer. And the people that use the product are the customer. Here’s an operational definition that will set you free:

When someone buys it, they are the customer.

When the discussions get sticky, hold onto that definition. Others will try to bait you into thinking differently, but don’t bite. It will be difficult to stand your ground.  And if you feel the group is headed in the wrong direction, try to set things right with this operational definition:

When you’ve found the person who opens their wallet, you’ve found the customer.

Now, let’s talk about value. Isn’t value subjective? Yes, it is.  And the only opinion that matters is the customer’s. And here’s an operational definition to help you create customer value:

When you solve an important customer problem, they find it valuable.

And there you have it.  Putting it all together, here’s the recipe for customer value:

1. Understand who will buy it.
2. Understand their work and identify their biggest problem.
3. Solve their problem and embed it in your offering.
4. Sell it for more than it costs you to make it.

Image credit — Caroline

When the fate of your company rests on a single project, who are the three people you’d tap to drag that pivotal project over the finish line? And to sharpen it further, ask yourself “Who do I want to lead the project that will save the company?” You now have a list of the three most important people in your company.  Or, if you answered the second question, you now have the name of the most important person in your company.

The most important person in your company is the person that drags the most important projects over the finish line.  Full stop.

When the project is on the line, the CEO doesn’t matter; the General Manager doesn’t matter; the Business Leader doesn’t matter.  The person that matters most is the Project Manager.  And the second and third most important people are the two people that the Project Manager relies on.

Don’t believe that? Well, take a bite of this. If the project fails, the product doesn’t sell. And if the product doesn’t sell, the revenue doesn’t come. And if the revenue doesn’t come, it’s game over. Regardless of how hard the CEO pulls, the product doesn’t launch, the revenue doesn’t come, and the company dies.  Regardless of how angry the GM gets, without a product launch, there’s no revenue, and it’s lights out.  And regardless of the Business Leader’s cajoling, the project doesn’t cross the finish line unless the Project Manager makes it happen.

The CEO can’t launch the product. The GM can’t launch the product. The Business Leader can’t launch the product.  Stop for a minute and let that sink in.  Now, go back to those three sentences and read them out loud. No, really, read them out loud.  I’ll wait.

When the wheels fall off a project, the CEO can’t put them back on. Only a special Project Manager can do that.

There are tools for project management, there are degrees in project management, and there are certifications for project management.  But all that is meaningless because project management is alchemy.

Degrees don’t matter. What matters is that you’ve taken over a poorly run project, turned it on its head, and dragged it across the line. What matters is you’ve run a project that was poorly defined, poorly staffed, and poorly funded and brought it home kicking and screaming. What matters is you’ve landed a project successfully when two of three engines were on fire. (Belly landings count.) What matters is that you vehemently dismiss the continuous improvement community on the grounds there can be no best practice for a project that creates something that’s new to the world. What matters is that you can feel the critical path in your chest. What matters is that you’ve sprinted toward the scariest projects and people followed you. And what matters most is they’ll follow you again.

Project Managers have won the hearts and minds of the project team.

The Project manager knows what the team needs and provides it before the team needs it. And when an unplanned need arises, like it always does, the project manager begs, borrows, and steals to secure what the team needs.  And when they can’t get what’s needed, they apologize to the team, re-plan the project, reset the completion date, and deliver the bad news to those that don’t want to hear it.

If the General Manager says the project will be done in three months and the Project Manager thinks otherwise, put your money on the Project Manager.

Project Managers aren’t at the top of the org chart, but we punch above our weight. We’ve earned the trust and respect of most everyone. We aren’t liked by everyone, but we’re trusted by all. And we’re not always understood, but everyone knows our intentions are good. And when we ask for help, people drop what they’re doing and pitch in. In fact, they line up to help. They line up because we’ve gone out of our way to help them over the last decade. And they line up to help because we’ve put it on the table.

Whether it’s IoT, Digital Strategy, Industry 4.0, top-line growth, recurring revenue, new business models, or happier customers, it’s all about the projects. None of this is possible without projects. And the keystone of successful projects?  You guessed it.  Project Managers.

Image credit – Bernard Spragg .NZ

When it comes to strategy and tactics, there are a lot of definitions, a lot of disagreement, and a whole lot of confusion. When is it strategy? When is it tactics? Which is more important? How do they inform each other?

Instead of definitions and disagreement, I want to start with agreement.  Everyone agrees that both strategy AND tactics are required. If you have one without the other, it’s just not the same. It’s like with shoes and socks: Without shoes, your feet get wet; without socks, you get blisters; and when you have both, things go a lot better.  Strategy and tactics work best when they’re done together.

The objective of strategy and tactics is to help everyone take the right action.  Done well, everyone from the board room to the trenches knows how to take action. In that way, here are some questions to ask to help decide if your strategy and tactics are actionable.

What will we do? This gets to the heart of it.  You’ve got to be able to make a list of things that will get done. Real things. Real actions. Don’t be fooled by babble like “We will provide customer value” and “Will grow the company by X%.” Providing customer value may be a good idea, but it’s not actionable. And growing the company by an arbitrary percentage is aspirational, but not actionable.

Why will we do it? This one helps people know what’s powering the work and helps them judge whether their actions are in line with that forcing function. Here’s a powerful answer: Competitors now have products and services that are better than ours, and we can’t have that. This answer conveys the importance of the work and helps everyone put the right amount of energy into their actions. [Note: this question can be asked before the first one.]

Who will do it? Here’s a rule: if no one is freed up to do the new work, the new work won’t get done. Make a list of the teams that will stop their existing projects before they can take action on the new work. Make a list of the new positions that are in the budget to support the strategy and tactics. Make a list of the new companies you’ll partner with. Make a list of all the incremental funding that has been put in the budget to help all the new people complete all these new actions.  If your lists are short or you can make any, you don’t have what it takes to get the work done.  You don’t have a strategy and you don’t have tactics.  You have an unfunded mandate.  Run away.

When will it be done? All actions must have completion dates.  The dates will be set without consideration of the work content, so they’ll be wrong.  Even still, you should have them. And once you have the dates, double all the task durations and push out the dates in your mind.  No need to change the schedule now (you can’t change it anyway) because it will get updated when the work doesn’t get done on time. Now, using your lists of incremental headcount and budget, assign the incremental resources to all the actions with completion dates. Look for actions and budgets as those are objective evidence of the unfunded mandate character of your strategy and tactics. And for actions without completion dates, disregard them because they can never be late.

How will we know it’s done? All actions must call out a definition of success (DOS) that defines when the action has been accomplished. Without a measurable DOS, no one is sure when they’re done so they’ll keep working until you stop them.  And you don’t want that.  You want them to know when they’re done so they can quickly move on to the next action without oversight. If there’s no time to create a DOS, the action isn’t all that important and neither is the completion date.

When the wheels fall off, and they will, how will we update the strategy and tactics? Strategy and tactics are forward-looking and looking forward is rife with uncertainty.  You’ll be wrong.  What actions will you take to see if everything is going as planned? What actions will you take when progress doesn’t meet the plan? What actions will you take when you learn your tactics aren’t working and your strategy needs a band-aid? What will you do? Who will do it? When will it be done? And how will you know it’s done?

Image credit: Eric Minbiole

What it takes to do new work.

Confidence to get it wrong and confidence to do it early and often.

Purposeful misuse of worst practices in a way that makes them the right practices.

Tolerance for not knowing what to do next and tolerance for those uncomfortable with that.

Certainty that they’ll ask for a hard completion date and certainty you won’t hit it.

Knowledge that the context is different and knowledge that everyone still wants to behave like it’s not.

Disdain for best practices.

Discomfort with success because it creates discomfort when it’s time for new work.

Certainty you’ll miss the mark and certainty you’ll laugh about it next week.

Trust in others’ bias to do what worked last time and trust that it’s a recipe for disaster.

Belief that successful business models have half-lives and belief that no one else does.

Trust that others will think nothing will come of the work and trust that they’re likely right.

Image credit — japanexpertna.se

• If you want to have an IoT (Internet of Things) program, you’ve got to connect your products.
• If you want to build trust, give without getting.
• If you need someone with experience in manufacturing automation, hire a pro.
• If the engineering team wants to spend a year playing with a new technology, before the bell rings for recess ask them what solution they’ll provide and then go ask customers how much they’ll pay and how many they’ll buy.
• If you don’t have the resources, you don’t have a project.
• If you know how it will turn out, let someone else do it.
• If you want to make a friend, help them.

• If your products are not connected, you may think you have an IoT program, but you have something else.
• If you don’t have trust, you have just what you earned.
• If you hire a pro in manufacturing automation, listen to them.
• If Marketing has an optimistic sales forecast for the yet-to-be-launched product, go ask customers how much they’ll pay and how many they’ll buy.
• If you don’t have a project manager, you don’t have a project.
• If you know how it will turn out, teach someone else how to do it.
• If a friend needs help, help them.

• If you want to connect your products at a rate faster than you sell them, connect the products you’ve already sold.
• If you haven’t started building trust, you started too late.
• If you want to pull in the delivery date for your new manufacturing automation, instead, tell your customers you’ve pushed out the launch date.
• If the VP knows it’s a great idea, go ask customers how much they’ll pay and how many they’ll buy.
• If you can’t commercialize, you don’t have a project.
• If you know how it will turn out, do something else.
• If a friend asks you twice for help, drop what you’re doing and help them immediately.

• If you can’t figure out how to make money with IoT, it’s because you’re focusing on how to make money at the expense of delivering value to customers.
• If you don’t have trust, you don’t have much
• If you don’t like extreme lead times and exorbitant capital costs, manufacturing automation is not for you.
• If the management team doesn’t like the idea, go ask customers how much they’ll pay and how many they’ll buy.
• If you’re not willing to finish a project, you shouldn’t be willing to start.
• If you know how it will turn out, it’s not innovation.
• If you see a friend that needs help, help them ask you for help.

Image credit — openDemocracy

Two important questions to help you grow your business:

1. Is the problem worth solving?
2. When do you want to learn it’s not worth solving?

No one in your company can tell you if the problem is worth solving, not even the CEO. Only the customer can tell you if the problem is worth solving. If potential customers don’t think they have the problem you want to solve, they won’t pay you if you solve it. And if potential customers do have the problem but it’s not that important, they won’t pay you enough to make your solution profitable.

A problem is worth solving only when customers are willing to pay more than the cost of your solution.

Solving a problem requires a good team and the time and money to run the project. Project teams can be large and projects can run for months or years. And projects require budgets to buy the necessary supplies, tools, and infrastructure. In short, solving problems is expensive business.

It’s pretty clear that it’s far more profitable to learn a problem is not worth solving BEFORE incurring the expense to solve it.  But, that’s not what we do.  In a ready-fire-aim way, we solve the problem of our choosing and try to sell the solution.

If there’s one thing to learn, it’s how to verify the customer is willing to pay for your solution before incurring the cost to create it.

Image credit — Milos Milosevic

All-or-nothing thinking is exciting – we’ll launch a whole new product family all at once and take the market by storm! But it’s also dangerous – if we have one small hiccup, “all” turns into “nothing” in a heartbeat. When you take an all-or-nothing approach, it’s likely you’ll have far too little “all” and far too much “nothing”.

Instead of trying to realize the perfection of “all”, it’s far better to turn nothing into something.  Here’s the math for an all-or-nothing launch of product family launch consisting of four products, where each product will create $1 million in revenue and the probability of launching each product is 0.5 (or 50%).

1 product x $1 million x 0.5 = $500K

2 products x $1 million x 0.5 x 0.5 = $500K

3 products x $1 million x 0.5 x 0.5 x 0.5 = $375K

4 products x $1 million x 0.5 x 0.5 x 0.5 x 0.5 = $250K

In the all-or-nothing scheme, the launch of each product is contingent on all the others.  And if the probability of each launch is 0.5, the launch of the whole product family is like a chain of four links, where each link has a 50% chance of breaking.  When a single link of a chain breaks, there’s no chain. And it’s the same with an all-or-nothing launch – if a single product isn’t ready for launch, there are no product launches.

But the math is worse than that. Assume there’s new technology in all the products and there are five new failure modes that must be overcome.  With all-or-nothing, if a single failure mode of a single product is a problem, there are no launches.

But the math is even more deadly than that. If there are four use models (customer segments that use the product differently) and only one of those use models creates a problem with one of the twenty failure modes (five failure modes times four products) there can be no launches. In that way, if 25% of the customers have one problem with a single failure mode, there are can be no launches.  Taken to an extreme, if one customer has one problem with one product, there can be no launches.

The problem with all-or-nothing is there’s no partial credit – you either launch four products or you launch none. Instead of all-or-nothing, think “secure the launch”. What must we do to secure the launch of a single product? And once that one’s launched, the money starts to flow.  And once we launch the first one, what must we do to secure the launch the second? (More money flows.) And, once we launch the third one…. you get the picture. Don’t try to launch four at once, launch a single product four times in a row. Instead of all-or-nothing, think one-in-a-row, where revenue is achieved after each launch of a single launch.

And there’s another benefit to launching one at a time. The second launch is informed by learning from the first launch.  And the third is informed by the first two. With one-in-a-row, the team gets smarter and each launch gets better.

Where all-or-nothing is glamorous, one-in-a-row is achievable. Where all-or-nothing is exciting, one-in-row is achievable. And where all-or-nothing is highly improbable, one-in-a-row is highly profitable.

Image credit – Mel

If you think you understand what your customers want, you don’t.

If you’re developing a new product for new customers, you know less.

If you’re developing a new technology for a new product for new customers, you know even less.

If you think you know how much growth a new product will deliver, you don’t.

If that new product will serve new customers, you know less.

If that new product will require a new technology, you know even less.

If you have to choose between project A and B, you’ll choose the one that’s most like what you did last time.

If project A will change the game and B will grow sales by 5%, you’ll play the game you played last time.

If project A and B will serve new customers, you’ll change one of them to serve existing customers and do that one.

If you think you know how the market will respond to a new product, it won’t make much of a difference.

If you don’t know how the market will respond, you may be onto something.

If you don’t know which market the product will serve, there’s a chance to create a whole new one.

If you know how the market will respond, do something else.

When we have a choice between certainty and upside, the choice is certain.

When we choose certainty over upside, we forget that the up-starts will choose differently.

When we have a lot to lose, we chose certainty.

And once it’s lost, we start over and choose uncertainty.

Image credit — Alexandra E Rust