We need a new Dashboard! It is the rallying cry of leaders everywhere.
Leadership is a customer demanding a product. Leadership can be an especially demanding customer. They should be.
Of course, its true that they might need a Dashboard. Also, they might not.
What they actually need is a problem to be solved.
Customer service = doing exactly what someone asks you.
Solving problems = identifying something that’s broken, fixing it, proving that you fixed it, and being personally accountable for the result.
What business are you in…customer service?
Or solving problems?
========================
I will give a two (anonymized) examples from my experience that illustrate the difference between “demanding service” and solving problems. It’s (almost always) as simple as: asking questions and thinking about something before you actually commit to doing something.
Example 1: A market analysis shows that a manufacturing plant’s capacity will fall short by 25% in 2 years. The plant leader directs the organization to add a new manufacturing line.
The thing is, “We don’t have enough equipment” is not a problem statement. Here’s the problem statement: we need 25% more stuff to sell.
Had she brought the requirement (add 25%) instead of the “solution” (new manufacturing line) to the org, many more ideas could have emerged. Can the existing process be optimized? Can we outsource to a contract manufacturer? Can a partner meet the extra demand? Can another site in the company make this stuff? Can we white label someone else’s product?
Example 2: A department develops a homegrown software application. They need to maintain it. No one has time to do the testing. So, they open a headcount for a Software QA specialist.
The thing is “I need to hire someone” is not a problem statement. Here’s the problem statement: We need our software QA’d.
Can they contract it out? Can they automate the testing with scripting and software? Can they reduce the scope of the application, to reduce the scope of the required testing?
Behind every request is a requirement. A problem statement. A broken thing that needs fixing. It can be difficult to uncover sometimes. But it’s there, and uncover it you must, if you want to fix it.
People who wish to appear smart always present the solution instead of stating the problem. This is especially true of people who are actually smart, because they are used to solving problems and being right and having people listen to them.
It takes bravery to admit you have a problem, but have not yet found the best solution.
But if you are the one owning the solution, you had better make sure you know the problem first. Because if you don’t, and the solution doesn’t work, you just created a second problem. And now you own both.
The problem statement is the rust under the paint. It is the termite-ridden pillar wrapped in brand new vinyl siding. It’s the teenager, whose angst is thinly veiled by a smile.
You must peel back the veneer, find the problem statement, and fix it.
Become a fixer of problems.
==========================
At every company I’ve worked, in every role I’ve played, I’ve had to translate feature requests, demands for new equipment, or desires to change business processes into problem statements. Here are three things I have observed as I’ve collected problem statements over the years.
Observation 1] Some problem statements are transient. Other problem statements last forever.
Consider: “We can’t ship product because the packing machine is jammed.” Fixing this problem is 100% within the four walls of a company. Buy a new packaging machine. Fix the existing one. Outsource packaging operations. Resell a competitor’s products. The problem statement disappears.
Now consider: “Our competitors spend much less than we do to deliver an equivalent product.” “Fixing” this problem requires action by the company (of course). But the factors that cause it, characterize it, and drive its evolution live outside the company.
Maybe the price pressure is permanent due to some competitor’s innovation. Maybe it’s not sustainable and the competitor folds and the problem goes away. Maybe a new regulation comes out that adds cost, and destroys margin. Maybe a regulation is repealed or amended that does the opposite .
This second type of problem — the durable type — requires constant monitoring and vigilance. Solving it is not a one time event. In fact: It can’t be solved. It must be managed, optimized, constantly monitored.
These are the ocean currents and winds that guide the ship. You cant control them. But you must understand them. Only then can you harness them, and use them get somewhere.
This kind of problem statement, I call a “Critical Business Question.” (I will call them CBQs to avoid typing that over and over again)
Finding one of these is a big deal, because they can, and should, change how you think about the business unit / function / department.
When you find a whole bunch of these and manage them together, you know what that is? I call that strategy.
What are your company / business unit / department / personal CBQs? Do you have a strategy manage them?
Observation 2] Critical Business Questions (CBQs) are durable and universal.
Think about this CBQ: Is our portfolio of projects delivering our strategy?
How about this: Do we have the right number of resources to run the business?
How about these: How does each activity or project impact our cost of goods/services? How do defects/bugs impact cost of goods/services? How do defects impact customer satisfaction? How does our defect rate / cost of goods / operating margin compare with our competitors? What projects should we be working on? What are we actually working on? What’s the gap? What’s the plan to close it? How are we tracking against that plan? How can we speed up closing the gap?
It doesn’t matter if you make software, Tylenol, gummy bears, microchips, chicken nuggets. It doesn’t matter if you make things, or deliver services, or both. I’m willing to bet most (or all) of these questions apply to you / your department / business unit / P&L.
I know this because they applied when I was working at a startup with 3 people making control systems for navy seals’ boats. They also applied when I designed automated pharmaceutical manufacturing systems, and when I had a small start-up making headphone amplifiers, and when I ran construction crews building industrial production facilities, when i ran my own music recording studio, and when I started my own software company.
They apply to you too.
Observation 3] Direct, explicit management of these questions is (1) not common, and (2) a competitive advantage for a busienss.
And it’s really uncommon below the top tier of management. Where are the critical business questions asked at your company? Are you a part of that conversation? How can you help define them? Answer them? Manage them?
====================
So that’s it: you can choose to be in customer service, or be a problem solver.
It’s easy to slip back in to customer service mode. I do it frequently. “Customer Service” mode is not as good as “Problem Solver” mode, and sometimes it’s actually bad.
Being a problem solver requires skepticism, vigilance, courage. You have to challenge the people that pay your salary.
You have to risk being wrong.
You have to be willing to accept the consequences of being wrong.
But solving problems is the essence of business. It is what creates value…for the company, for customers, for shareholders, for society.
Be a value creator. Go find the problems and solve them.
(And In the next article, I’ll talk about one approach to solving the problems once you’ve found them)
~~~~~~~~~~~~~~~~~~~~~~~~
- Next Read: Your Company’s Strategy Is Not Important. –>
