The smallest section of the Gen AI Leader exam and the one closest to the day job. It asks how an organisation gets from an interest in generative AI to something that changed a number.
The types of solution
Four, and a question will describe a situation that points at one.
Text generation covers drafting, summarising, rewriting, translating, answering and extracting. The broadest category and the one most business problems fall into.
Image generation covers producing and editing visuals, for marketing, product imagery and design exploration.
Code generation covers writing, explaining, translating and testing code, which raises engineering throughput rather than customer facing value.
Personalised user experience covers tailoring what somebody sees to what is known about them, in recommendations, content and interfaces.
What decides the choice
Business requirements first. What outcome are you trying to move, who is affected, what does a wrong answer cost, and what would count as success.
Technical constraints second. Where the data is and whether you may use it, where processing may happen, what latency the experience allows, what it may cost per interaction, and what has to be integrated with.
The cost of a wrong answer is the constraint people underweight. It decides whether a person has to be in the path, and that decision changes the economics of the whole thing far more than the choice of model.
Getting it into an organisation
The sequence Google recommends is unremarkable and mostly ignored.
Start from a business problem rather than the technology. Pick a use case where the outcome is measurable and a wrong answer is survivable. Check the data exists, that you may use it, and that you can reach it. Build the smallest version that answers the question. Measure it against what happened before. Then decide whether to widen, and only then worry about the platform it should sit on permanently.
Two things sit alongside that sequence throughout. Somebody has to own it, and people have to be trained, because a capable system that nobody trusts or knows how to use changes nothing.
Measuring impact
The techniques that matter are ordinary ones.
Against a baseline. Measure the thing before, then after. Handling time, conversion, time to draft, tickets resolved without escalation.
Against a control group. Some teams get it and some do not, which separates the effect of the tool from everything else changing at once.
Quality alongside volume. Faster output that is worse is not an improvement, so pair a throughput measure with a quality one.
Cost per interaction. Token cost, review time and the engineering to keep it running. A system that helps and costs more than it saves is a decision, not a success.
Adoption as a diagnostic, not a result. Usage tells you whether people came. It does not tell you whether anything changed.
The honest final question is the counterfactual. Not whether the output is impressive, but whether it beats what people were doing before at a cost the result justifies.
Practise this
You need fifteen minutes and a complete list of what your organisation has shipped or has in flight, which may take a message to colleagues to assemble.
List every AI feature by name, including the ones demonstrated once and quietly dropped. Against each, write the problem it exists to solve as a sentence somebody outside the team would recognise, and the number it was meant to move. Then mark it P where a named problem came first, and A where the honest history is that the technology came first and a use was found for it.
Feature Problem it solves, in one sentence Number it moves P / A
.......... ................................... .............. P A
.......... ................................... .............. P A
.......... ................................... .............. P A
P somebody named this problem before anyone mentioned AI
A this started from the question of what to do with AI
Count of P ____ Count of A ____
Watch what happens when you try to fill the third column. A feature that started from a problem usually has a number waiting, because whoever noticed the problem was already measuring it, while one that started from the technology tends to produce a blank or a usage figure, and usage records who turned up rather than what changed. The ratio of P to A is a fair estimate of how much of your AI spending is buying an outcome.
It teaches you that the adoption question is largely settled before any model is chosen, in whether a problem or a technology came first.