Buy the problem, not the platform

There is a specific failure pattern in mid-market and public-sector technology buying, and it is almost always the same sequence. Someone sees a demo. The demo is good, because demos are built to be good. A requirements document is then produced that describes, with impressive specificity, the capabilities of the system that was demonstrated. The evaluation that follows is technically fair and substantively rigged, because the criteria were derived from one of the candidates.

Eighteen months later the organization is running a platform that does several things brilliantly, none of which turned out to be the constraint, and the original problem is still there wearing a new interface.

Requirements are a description of your problem, not of a product

A usable requirement describes something that must be true about your operation after the purchase. It does not name a feature. “Field technicians must be able to close a work order without returning to the office” is a requirement. “Mobile app with offline sync” is a product description that happens to be one solution to it — and by writing it that way, you have eliminated every alternative before evaluating any of them.

The discipline is simple and uncomfortable: write the requirements before you look at anything, and write them in terms of your own operation. If you cannot state what must become true without naming a technology, you have not defined the problem yet.

Rank them, honestly

Every requirements list we are handed is flat, and every flat list is a fiction. Some of those requirements would kill the deal if unmet. Most would be mildly annoying. A few were added because someone in a meeting said “it should probably also…” and nobody wanted to argue.

Sort them into three groups and put a name next to each: must-have, valuable, and nice. Then apply the test that matters — if a candidate fails this requirement, do we walk away? If the answer is no, it is not a must-have, and it should not be weighted like one. This exercise routinely reduces a thirty-item must-have list to five or six genuine ones, at which point the field of viable options usually widens considerably and the price conversation changes.

Model the total cost, not the subscription

The quoted figure is the beginning of the cost, and everyone in the room knows it. What gets left out with some consistency:

• Implementation and data migration — frequently exceeding the first year of licensing, and quoted late in the process when the decision is emotionally settled.
• Integration work to connect the platform to systems you are keeping, including whatever it costs to maintain those connections when either side updates.
• Internal time — your staff’s hours during configuration, testing, and the period where they run two systems in parallel. This is real money and it is never in the vendor’s model.
• Training and productivity dip in the first quarter after cutover.
• Exit cost — what it takes to get your data out in a usable form if this decision turns out to be wrong. Ask about this before you sign, when the answer is still commercially motivated.
• Growth pricing — what the per-seat or per-transaction rate does at two and three times your current volume, contractually, not verbally.

A cheaper platform with expensive integration is not the cheaper platform. This is arithmetic, but it only works if someone does it before the decision rather than after.

Check who is advising you

A large share of the technology advice available to organizations of this size is delivered by parties compensated by the vendor being recommended. Resellers, partners, and referral arrangements are a legitimate and open part of the industry, and plenty of people working inside them give sound advice.

But you should know which conversation you are in. The question is not rude and the answer is not complicated: does your compensation change depending on which option we choose? Ask it directly. An honest partner will tell you plainly, and the answer tells you exactly how to weight the recommendation that follows.

Reference calls the vendor did not arrange

Vendor-supplied references are selected, prepared, and occasionally compensated. They are not worthless — they will tell you the platform works — but they will not tell you what the implementation was like or what broke in month four.

Find your own. Industry associations, peer networks, and professional communities will produce someone running the platform who has no relationship with the vendor’s marketing team. Ask them two questions: what surprised you during implementation, and what would you do differently. The answers to those two questions are worth more than the entire evaluation matrix.

The short version

• Write requirements in terms of your operation, before any demo.
• Rank them and defend the must-haves.
• Model total cost over three years, including your own people’s time and the cost of leaving.
• Ask every advisor how they are paid.
• Find your own references.

None of this is sophisticated. It is a discipline, and its entire difficulty is that it has to happen before anyone is excited — which is exactly when nobody wants to do it.