Why I won't tell you which platform to buy
in the first meeting

The first meeting almost always contains a version of this question. We're looking at two or three products, which one would you pick? It's a fair question and there's a real answer coming. It isn't coming that day, and I'd rather explain why than give you a confident guess you could have got anywhere.

The evaluation that taught me to slow down

At IBM I ran the cross-platform evaluation of whether to consolidate TRIRIGA and Maximo onto a single platform. Two overlapping enterprise products under one roof after an acquisition, and an org chart that made the merge look obvious. Every instinct in the room said consolidate. I recommended keeping them separate, and that recommendation informed IBM's decision to maintain both product lines.

What decided it wasn't a feature comparison. Both products were capable. What decided it was the data models underneath, the customer commitments already made against each, and what a merge would have cost the roadmap of two things that already worked. None of that was visible from the product surface, and none of it could have been read in a first meeting. That call is written up as the first of the decisions on this site, along with what transfers from it.

What actually determines whether a rollout struggles

In the rollouts I've been close to, the product was almost never the binding constraint. Two other things usually were.

Governance, meaning who is allowed to decide what, and whether that's been agreed or merely assumed. A rollout with an unresolved group and local boundary will struggle on any platform, because the fight it's having isn't a software fight. The platform just becomes where the fight is held.

And data, meaning what you actually have rather than what the current system's screens imply you have. Record counts, duplicate rates, how many fields are populated in practice, whether the identifiers reconcile against the systems you don't plan to replace. That's a week of work to read honestly and it changes the answer more often than any feature does.

Why an early answer is worse than no answer

If I name a product in meeting one, two things happen. The evaluation quietly becomes a justification exercise, because there's now a favourite and everyone knows it. And I've anchored the decision on the only inputs available that early, which are the vendor's materials and my own history. My history is real and I'll draw on it, but it's a description of other companies' constraints, not yours.

There's a commercial version of this too. A consultant who names a platform in the first meeting is easy to hire and easy to be wrong with. I'd rather be the second call than the fast one.

What the first meeting is actually for

Finding out what you're solving, which is not always what the brief says. Establishing where the decision rights sit. Getting an honest read on the calendar, including anything already committed to a board or a customer. Asking what the current system does well, because that's the part a replacement quietly loses and nobody misses until it's gone.

By the end of it I can usually tell you what class of thing you need and what would rule an option out. That's a real answer. It just isn't a product name.

When I will name one

After the data has been looked at rather than described, after the group and local boundary has been written down and agreed by the people it binds, and after the calendar constraint is on the table. That's typically a few weeks, not a few months. Then the recommendation comes with reasons you can check, and with the conditions under which I'd change my mind.

If you need the name faster than that, you probably don't need me. You need a shortlist, and those are cheap.

Sources: The TRIRIGA and Maximo consolidation evaluation is from Bill Thornton's own role history at IBM, recorded in docs/bill-thornton-resume-2026.pdf in this repo and written up as the first entry on the decisions page. Naming those platforms and that employer is permitted under the brand guide's employment-history rule; customers are not named.