Apollo.Grid

Because the problem is no longer a shortage of solutions, it is the excess. A management team wanting to solve one concrete problem will find, in half an hour of searching, dozens of products saying more or less the same thing, in the same language, with equally convincing demonstrations.

Without a criterion linking need to capability, the choice ends up being made by market noise: the winner is whoever spent most on marketing, whoever appeared at a conference, or whoever was already a supplier of something else. None of these criteria has any relationship with the problem that needed solving.

By starting from the decision and not from the technology. The useful question is not “which AI solutions exist for finance”, it is “which decision do I need to make better, and what capability does that require”.

That implies three translations nobody performs today. Translating a business problem into a required capability, in language that is not the vendor’s. Translating the products’ promises into that same language, so that they can be compared. And saying, where it is the case, that no solution fits, which is the most useful of the three answers and the one no commercial comparison site will give.

Because the information about what a solution actually does is produced by whoever sells it, and the same capability is described ten different ways depending on the market it addresses. Any map built from vendor material inherits that material’s distortions.

There is also a deeper difficulty: a comparison service that made money from whoever appears on the map would stop being useful the next day. So this project’s funding model is part of the problem to be solved, not a detail to settle at the end.

By testing it with the company’s own cases, and above all the hard ones. A demonstration shows the product in its best scenario; what matters is how it behaves with real data, incomplete and untidy, and with the exceptions that give people trouble today.

Two further questions reveal a great deal. The first is to talk to clients with the same problem, not merely the same sector, because a success story about a different kind of decision says little. The second is to ask the vendor what the solution does not do and what happens when it gets something wrong. The quality of that answer usually says more about the product than the demonstration does.

It is at concept stage: the question and the difficulties are defined, but there is no tested matching method yet, and no decision on the funding model.