When a company contacts us, they rarely say “we need a diagnosis.” What they say is “we need a chatbot” or “we want to automate X process” or “we need an app with AI.” They arrive with the solution already decided. What they want is for us to build it.
And our response, invariably, is: “Great. But first let us understand the problem.”
That’s not always well received.
Why diagnosis is unpopular
There are three reasons companies avoid paying for a diagnosis:
1. It seems unnecessary. If they already know what they want, why spend time and money having someone tell them if they’re right? The answer is that 60% of the time, what they think they need isn’t what they actually need. But they only discover that when the project is 3 months in and the results don’t add up.
2. It’s intangible. A chatbot can be touched, shown, demonstrated. A diagnosis is a document. It’s harder to sell, harder to budget, and harder to justify in a procurement committee.
3. It might say no. An honest diagnosis might conclude that the company isn’t ready for what it wants to do. And nobody wants to pay to be told they’re not ready.
What a good diagnosis actually does
A diagnosis isn’t a bureaucratic audit or a 100-page report nobody reads. It’s a concrete evaluation of three things:
Current state. How does the process work today? How much does it cost? Where does it lose time, money, or quality? What data is generated and in what condition? This is gathered through interviews, direct observation, and analysis of existing data. Not with generic surveys.
Technical feasibility. Is what the client wants to do technically possible with their current data, infrastructure, and constraints? What gaps need to be closed first? How much does closing them cost? This part requires real implementation experience, not just theoretical knowledge.
Prioritized recommendation. Not a list of 20 opportunities. A clear recommendation: do this first, with this scope, with this budget, and expect these results. If the diagnosis ends with “there are many opportunities,” it failed. It has to end with “do this.”
The medical metaphor (which works because it’s exact)
A patient walks into a doctor’s office and says “I need knee surgery.” The doctor doesn’t schedule the surgery. They run an exam. Maybe the knee resolves with physical therapy. Maybe the pain is coming from the hip, not the knee. Maybe surgery is needed, but not the one the patient had in mind.
Operating without diagnosing is medical negligence. In technology, we do it all the time and call it “agility.”
The cost of not diagnosing
We’ve seen (and sometimes been called to rescue) projects that started without a diagnosis:
-
An $80,000 chatbot nobody used because the real problem was that internal documentation was a mess. They didn’t need AI. They needed a good wiki.
-
A demand prediction project that took 6 months to discover the historical data was useless. A 3-week diagnosis would have revealed it.
-
A process automation that faithfully replicated an inefficient process. They automated doing things wrong, faster.
In every case, the cost of not diagnosing was orders of magnitude greater than the cost of the diagnosis.
Our model
At Redstone Labs, diagnosis isn’t a phase we sell for the sake of selling. It’s a quality filter. It allows us to:
- Understand the real problem, not the symptom the client identified
- Calibrate expectations before committing resources
- Design the right solution from the start, not mid-project
- Say no when appropriate, and explain why
A typical diagnosis takes between 2 and 4 weeks. It includes stakeholder interviews, analysis of existing data and systems, and a recommendation document with estimated costs and timeline.
Is it an additional cost? Yes. Does it pay for itself? Always. Whether by avoiding an unnecessary project, reducing scope to what truly matters, or discovering something nobody was seeing.
The best investment in technology isn’t the tool you buy. It’s the clarity with which you define what you need. Everything else is built on that.