How I Think, View, and Guide Action
The operating philosophy behind every recommendation I make, and why I start with diagnosis instead of tactics.
Short answer
I diagnose the constraint before recommending anything, because most business problems are misdiagnosed symptoms of a single upstream failure.
Key takeaways
- —Most stated problems are symptoms, not causes.
- —A tactic applied to the wrong constraint makes the constraint worse.
- —Diagnosis is a sequence, not an opinion.
- —The cheapest fix is usually the one nobody wants to name.
Every business that calls me arrives with a stated problem. We need more leads. Our close rate dropped. The team is not following the process. In 9 out of 10 conversations, the stated problem is a symptom of something 2 or 3 steps upstream, and the tactic they want to buy would make the real problem harder to see.
That is the whole philosophy. Diagnose first. Everything else is downstream of that.
The stated problem is rarely the buying problem
A contractor tells me he needs more leads. We look at the numbers. He is getting 140 inbound calls a month and answering 61 of them. He does not have a lead problem. He has an answering problem, and buying more leads would have cost him money to expose the same failure at higher volume.
This pattern repeats across every industry I have worked in. The symptom is visible and the cause is boring. Nobody wants to buy the boring fix, so they buy the exciting one, and 90 days later the numbers look the same.
Diagnosis is a sequence
I run the same sequence every time, in order, and I do not skip forward because a later step is more interesting.
- Where does demand actually come from today, and can it be counted?
- What percentage of that demand gets a human response, and how fast?
- What happens to the demand that responds but does not buy?
- What happens to the customers who buy once?
- What does the operator personally have to touch for any of this to work?
The first step that fails is the constraint. Work on it. Ignore the rest until it moves. The reason this feels unsatisfying is that it usually points at something the owner already knows and has been avoiding, which brings up the second principle.
The cheapest fix is the one nobody wants to name
Fixes that cost money are easy to approve because money is impersonal. Fixes that cost a decision are hard, because someone has to admit the current arrangement is not working. Firing the wrong hire, killing the product line that flatters the founder's identity, calling the customers who churned and asking why.
I take the position that the advisor's job is to name it plainly once, explain what it costs to leave it in place, and then help either way. Naming it twice is nagging. Naming it never is malpractice.
Systems beat effort, and evidence beats systems
A system converts a good decision into a repeatable one. That is its only job. Systems built on top of an undiagnosed constraint just repeat the wrong decision faster and with better reporting.
So the order is fixed. Evidence, then diagnosis, then decision, then system. When someone asks me to skip to the system, the answer is that I can build it, and it will not do what they want it to do.
What this means if we work together
I will ask uncomfortable questions before I propose anything. I will show you the number that drove the recommendation. If the honest answer is that you do not need what I sell, that is the answer you will get, because the alternative is a client who spends money and does not grow, and that is a worse outcome for both of us than a short conversation.