Is This Tool Solving Your Problem or Someone Else's?
A tool can work exactly as advertised and still be the wrong purchase, because working and solving your problem are separate questions. Every product is built for somebody, and that somebody is a median customer in a segment, assembled from a roadmap. You are not the median. Before evaluating any tool, write your own constraint in a single sentence, in your own words, without using any language from the vendor's website. Then check whose problem the tool actually addresses: yours, the vendor's, the median customer's, or your competitor's. Those are four different problems, and only one of them is worth your money. The AI Alignment Filter™ starts here on purpose, because a search that begins before the constraint is named will make everything look promising.
Introduction
The most expensive purchases I have watched people make were not the ones where the product failed. They were the ones where the product worked perfectly and solved a problem the buyer did not have.
That failure is much harder to see than a broken tool, and it is much more common. Nobody gets to say the vendor misled them. Nothing went wrong. The software does what it said it would do, every day, competently, for a problem that was somebody else's.
And because nothing broke, it never gets canceled. It gets absorbed. It becomes part of the stack, part of the training, part of the onboarding for every new hire, and eighteen months later nobody can remember why it was bought, but everyone assumes there was a reason.
So yesterday's question was what never to hand to a machine. Today's is narrower and more practical. Of the things you could legitimately hand over, is this particular tool addressing your constraint, or somebody else's?
Key Takeaways
• A tool that works as advertised can still be the wrong purchase. Working and solving your problem are separate tests.
• Write your constraint in one sentence before looking at any product, and use none of the vendor's vocabulary in it.
• Every product is designed for a median customer in a segment. Check whether you are near that median on size, complexity, and workflow.
• A demo is assembled from best cases. That is not deception. It is what a demo is.
• The alignment question is whether the tool simplifies or complicates. If it adds a system without removing one, it complicates.
• If the constraint sentence cannot be written, the search is premature, and everything you find will look promising.
Every Tool Is Built for Somebody
No product is built for everyone, and the good ones are honest about it.
Software is designed around an assumed customer: a certain size, a certain complexity, a certain way of working, a certain set of adjacent systems already in place. Every design decision resolves in favor of that assumed customer, because it has to resolve somehow.
That assumed customer is a median. And the further you sit from the median, the more of the product's design works against you rather than for you.
This is why a tool that is genuinely transforming a twelve-location group can be an active burden in a two-operatory practice, and the difference is not that one is better run. The larger organization has a coordination problem that the software was built to solve. The smaller one has a time problem that the software makes slightly worse, because it added a system to a place where the coordination was happening in a room.
So the first question about any tool is not whether it is good. It is who it is good for, and how far that is from you.
The Demo Is Built From the Best Case
A demonstration is not a lie. It is a curated instance, and curation is the whole craft of building one.
The data in the demo is clean, because someone cleaned it. The workflow is the workflow the product handles best, because why would you show the other one? The presenter has run this sequence hundreds of times. Nothing is interrupted. Nobody calls in sick.
None of that is dishonest, and you should not treat it as dishonest. You should treat it as what it is: the upper bound.
The useful move is to ask for the lower bound, and to ask for it without any edge in your voice. What does this look like in a practice that has messy historical data? What is the part customers find hardest in the first ninety days? Which kind of customer has the most trouble with it?
A vendor with a good product answers those questions readily, because they have heard them before and they have real answers. A vendor who treats them as hostile has told you something useful.
Three Problems That Are Not Yours
When a tool is put in front of you, it is solving somebody's problem. Four candidates, and only one of them is a reason to buy.
The vendor's problem. Every software company needs recurring revenue, predictable renewals, and customers who find leaving expensive. Features that serve those needs are legitimate business, and they are not the same as features that serve you. Data that is easy to put in and hard to get out is the clearest example, and it is worth asking about before signing rather than after.
The median customer's problem. Covered above. The product is coherent, well built, and aimed somewhere near the center of a segment you may not sit in.
Your competitor's problem. This one is the most seductive, because it arrives as a reasonable observation. A practice down the road has it. A group you respect has adopted it. That is genuine information about their constraint and almost no information about yours. They may have a bottleneck you do not. They may have made a mistake. You cannot tell from the outside, and the fact that a decision was made by someone competent is not evidence that it was the right decision for them, let alone for you.
Your problem. Which you can only recognize if you wrote it down first.
Write the Sentence First
This is the single most useful discipline in the whole framework, and it takes about a minute.
Before you look at any product, write your constraint in one sentence. In your own words. Using none of the vocabulary from any vendor's website.
Not "we need better patient communication." That is a category, not a constraint. Something closer to: patients who need to reschedule call during lunch when nobody is at the desk, and about a third of them never call back.
Now that is a constraint. It has a who, a when, and a consequence. And notice what it does to the evaluation: it immediately disqualifies several products that would have looked appealing, and it tells you precisely what to ask the remaining ones.
If the sentence cannot be written, the search is premature. That is not a delay; it is the finding. A search that begins before the constraint is named will make everything look promising, because you have given yourself no grounds on which to reject anything.
And be honest about where the sentence came from. If you are writing it after a demo, using the demo's framing, you have not identified a constraint. You have been handed one.
Simplify or Complicate
There is a version of this question that settles a surprising number of cases quickly.
Does this tool make the operation simpler or more complicated?
Not faster. Simpler. Those diverge more often than people expect, because a great deal of speed is purchased with complexity, and complexity has a running cost that does not appear on any invoice.
A tool that replaces two manual steps with one automated step simplifies. A tool that adds an automated step alongside two manual steps that nobody quite trusts yet has complicated, and it will keep complicating until somebody retires the manual steps, which is a decision nobody has scheduled.
This is where the previous months' work connects. If the answer to "what does this replace" is nothing, the tool complicates by definition, however good it is, because your organization is now carrying one more thing.
If it does not replace or compress something, it may be unnecessary.
The Scale Test
One more question, and it is the one people skip because the answer feels obvious until they check.
At your volume, does this pay?
Not at the volume in the case study. Yours. A tool that saves a meaningful amount per transaction is transformative at ten thousand transactions and irrelevant at two hundred, and the per-transaction saving is identical in both cases.
Run the arithmetic with your actual numbers before the conversation, not after. It takes ten minutes, and it changes what you are able to hear in the room, because you walk in knowing the threshold at which this becomes a good idea. Sometimes the finding is that you are well past that threshold and should have bought it a year ago. That is a good outcome from the same ten minutes.
What you cannot do is evaluate a proposal against a number you have not calculated. In that situation, the only available comparison is the vendor's, and theirs was computed on somebody else.
Frequently Asked Questions
What if the constraint is real but small?
Then the tool has to be cheap and nearly free to integrate, because the ceiling on the benefit is low. Small constraints are worth solving. They are not worth solving with a system that takes eight weeks to install and a person to own.
The team is asking for a specific product by name. How should I handle it?
Ask them to write the constraint sentence, not the product name. If several people write similar sentences, you have found something real, and the product they named may or may not be the right answer to it. If the sentences differ, that conversation is more valuable than the purchase.
Is it ever right to buy because a competitor has it?
Occasionally, when patients or customers have begun expecting a capability, and its absence is costing you visibly. That is your constraint, not theirs, and you should be able to state it in those terms. "They have it" is not that.
How do I ask about data portability without sounding adversarial?
Ask it as an operational question, because it is one. How do we get our data out if we ever need to move it, and in what format? Every competent vendor has fielded that question, and the good ones have a straight answer.
What if I get it wrong?
You will, sometimes, and the sunk cost is gone the moment you notice. The only live question is whether the next twelve months of payments buy anything. Deciding that quickly is the skill, not avoiding the mistake.
Final Thoughts
The reason this matters is not the money, although the money is real.
It is that every tool you adopt takes a small permanent share of your team's attention, and attention is the input you have least of and can least replace. Spending it on a well-built solution to somebody else's problem is the quietest way to run an organization that is tired.
So write the sentence first. One line, your words, your constraint.
Everything downstream of that sentence gets easier, including the conversations where you say no.
Complexity is not innovation.