Principle 01
Lead with the problem. The tool is the conclusion.
Most organizations start with the technology and reverse-engineer a justification. That order produces expensive answers to questions nobody asked.
What I mean
A tool decision should be the last thing you make, not the first. Before anyone names a vendor, model, or platform, the problem should be written down in a form specific enough that you could tell whether it had been solved. If the problem statement changes depending on which tool is in the room, it was never a problem statement.
Why it matters
Technology-first initiatives fail quietly. They ship, get announced, and then slowly stop being used, because nothing in anyone's actual working day got easier. Problem-first initiatives are harder to start and much harder to kill, because the people who feel the problem become the ones defending the solution.
What it looks like in practice
- 01Write the problem as a sentence with a subject, a cost, and a measurable state of resolved.
- 02Ask what happens if we do nothing. If the answer is 'not much,' stop there: that is a real result.
- 03Delay vendor conversations until the evaluation criteria exist. Criteria written after a demo are a rationalization.
- 04Name the decision being asked for. 'Explore AI' is not a decision. 'Should support triage run autonomously above 0.9 confidence' is.
From my work
The request was an AI chatbot to deflect tickets. Written as a problem, it became: the product creates twenty recurring confusions per day and support absorbs the cost invisibly. That sentence produced a different, much better roadmap than the chatbot brief did.
Turning Consumer Support Into a ProductContact
Let's get into it.
Ambiguous problem, AI adoption that stalled, an operating model that stopped scaling, a support function that should be a product. That is the conversation I want.