Archive for the ‘Top Line Growth’ Category

Wrong Questions to Ask When Doing Technology Development

I know you’re trying to do something that has never been done before, but when will you be done? I don’t know.  We’ll run the next experiment then decide what to do next.  If it works, we’ll do more of that.  And if it doesn’t, we’ll do less of that. That’s all we know right now.

I know you’re trying to create something that is new to our industry, but how many will we sell? I don’t know. Initial interviews with customers made it clear that this is an important customer problem. So, we’re trying to figure out if the technology can provide a viable solution.  That’s all we know right now.

No one is asking for that obscure technology. Why are you wasting time working on that?  Well, the voice of the technology and the S-curve analyses suggest the technology wants to move in this direction, so we’re investing this solution space.  It might work and it might not.  That’s all we know right now.

Why aren’t you using best practices? If it hasn’t been done before, there can be no best practice.  We prefer to use good practice or emergent practice.

There doesn’t seem like there’s been much progress.  Why aren’t you running more experiments? We don’t know which experiments to run, so we’re taking some time to think about what to do next.

Will it work?  I don’t know.

That new technology may obsolete our most profitable product line.  Shouldn’t you stop work on that? No. If we don’t obsolete our best work, someone else will. Wouldn’t it be better if we did the obsoleting?

How many more people do you need to accelerate the technology development work? None.  Small teams are better.

Sure, it’s a cool technology, but how much will it cost?  We haven’t earned the right to think about the cost.  We’re still trying to make it work.

So, what’s your solution? We don’t know yet.  We’re still trying to formulate the customer problem.

You said you’d be done two months ago.  Why aren’t you done yet? I never said we’d be done two months ago. You asked me for a completion date and I could not tell you when we’d be done.  You didn’t like that answer so I suggested that you choose your favorite date and put that into your spreadsheet. We were never going to hit that date, and we didn’t.

We’ve got a tight timeline.  Why are you going home at 5:00? We’ve been working on this technology for the last two years.  This is a marathon.  We’re mentally exhausted.  See you tomorrow.

If you don’t work harder, we’ll get someone else to do the technology development work.  What do you think about that? You are confusing activity with progress.  We are doing the right analyses and the right thinking and we’re working hard.  But if you’d rather have someone else lead this work, so would I.

We need a patented solution.  Will your solution be patentable? I don’t know because we don’t yet have a solution. And when we do have a solution, we still won’t know because it takes a year or three for the Patent Office to make that decision.

So, you’re telling me this might not work?  Yes. That’s what I’m telling you.

So, you don’t know when you’ll be done with the technology work, you don’t know how much the technology will cost, you don’t know if it will be patentable, or who will buy it? That’s about right.

Image credit — Virtual EyeSee

Two Sides of the Equation

If you want new behavior, you must embrace conflict.

If you can’t tolerate the conflict, you’ll do what you did last time.

If your point of view angers half and empowers everyone else, you made a difference.

If your point of view meets with 100% agreement, you wasted everyone’s time.

If your role is to create something from nothing, you’ve got to let others do the standard work.

If your role is to do standard work, you’ve got to let others create things from scratch.

If you want to get more done in the long term, you’ve got to make time to grow people.

If you want to get more done in the short term, you can’t spend time growing people.

If you do novel work, you can’t know when you’ll be done.

If you are asked for a completion date, I hope you’re not expected to do novel work.

If you’re in business, you’re in the people business.

If you’re not in the people business, you’ll soon be out of business.

If you call someone on their behavior and they thank you, you were thanked by a pro.

If you call someone on their behavior and they call you out for doing it, you were gaslit.

If you can’t justify doing the right project, reduce the scope, and do it under the radar.

If you can’t prevent the start of an unjust project, find a way to work on something else.

If you are given a fixed timeline and fixed resources, flex the schedule.

If you are given a fixed timeline, resources, and schedule, you’ll be late.

If you get into trouble, ask your Trust Network for help.

If you have no Trust Network, you’re in trouble.

If you have a problem, tell the truth and call it a problem.

If you can’t tell the truth, you have a big problem.

If you are called on your behavior, own it.

If you own your behavior, no one can call you on it.

Image credit – Mary Trebilco

No Time for the Truth

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

Effectiveness at the Expense of Efficiency

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

The Power of Prototypes

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

Want to succeed? Learn how to deliver customer value.

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

The Most Important People in Your Company

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

Strategy, Tactics, and Action

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

 

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

28 Things I Learned the Hard Way

  • 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 Questions to Grow Your Business

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

Mike Shipulski Mike Shipulski
Subscribe via Email

Enter your email address:

Delivered by FeedBurner

Archives