The board has asked for our AI strategy for Thursday. Can we bring two real customer problems and the evidence for solving them, rather than a list of features?
I have three roadmap items labelled AI-powered. None of them currently says which customer job improves or how we would measure that.
A prospect asked whether exports use AI. The honest answer is no, but I would like a clearer story about the reliability work we are doing there.
Can we start with a user problem that becomes meaningfully easier? The technology should follow the job, not decide the job for us.
I have listed six candidate jobs, the data they need, the evaluation cost, and what we would do when the model is wrong. I need owners for the top two.
Support would get value from a short account summary with sources. Please do not make us review a creative writing feature before we fix the explanation problem.
Good. Bring two jobs, why this approach helps, how we will evaluate it, and the fallback when it is wrong. That is the strategy discussion.
The week everything needed AI began, as these weeks often do, with a reasonable question and an unreasonable number of stickers.
Nora had a board meeting on Thursday. The board wanted to understand the companyβs AI strategy. Nora wanted the same thing, ideally before the board did. She posted in Slack at 08:47 and then entered another meeting, leaving seven words unattended in an organisation with roadmaps.
By 10:00, three initiatives had been renamed.
Smart Search became AI Search, although the ranking model had been there for two years and felt hurt that nobody had celebrated earlier. Export Studio acquired an βAI-assistedβ future column. Growth proposed an intelligent onboarding companion. Sales added a sparkle to the demo environment, discovered it was a Unicode character, and added two more.
Leon created an icon set. This was not because Leon lacked discipline. It was because icons are how designers process organisational anxiety.
Tom watched a sticker appear on the office toaster and asked whether the toaster had consented to model training.
At noon, Maya opened the roadmap and found that AI had ceased to be a technology. It was now a weather system.
The noun-first strategy
Technology waves create a peculiar inversion. Normally, a team starts with a problem and searches for an effective solution. During a wave, the organisation starts with a solution category and searches the building for eligible problems.
This is not entirely foolish. New capabilities change what is possible. Teams should explore them before the market explains the opportunity more convincingly. Technical curiosity is part of product work.
The trouble begins when exploration is presented as strategy and labels substitute for choices.
βWe need an AI strategyβ can mean at least five things:
- Where can new model capabilities create customer value?
- How will AI change our market or business model?
- Which internal workflows should become more efficient?
- What capabilities, data and governance must we build?
- What story do we need to tell investors before Thursday?
All are legitimate. They do not produce the same roadmap.
Maya asked Victor which question they were answering. Victor admitted the board probably meant all five, which is why executive questions should not be accepted in their original packaging.
They rewrote it: Which customer jobs become materially better with current AI capabilities, and what must be true for us to deliver them responsibly?
The sentence was less exciting. It did, however, contain a customer, a comparative claim and the possibility that an idea might fail.
A use case is not a sparkle
Google PAIRβs design patterns begin with an admirably unfashionable instruction: determine whether AI adds value. Their guidance distinguishes jobs where prediction or natural-language capabilities create a genuinely better experience from cases where rules, transparency or manual control may work better.
That sounds obvious until a roadmap is under social pressure to look current.
The team reviewed six ideas. The intelligent onboarding companion sounded excellent in a headline. In practice, new customers needed predictable setup guidance, and the company already knew the correct sequence for most accounts. A deterministic checklist would be cheaper, easier to explain and more reliable.
Support summarisation looked less glamorous but more useful. Elenaβs team spent hours reconstructing account context across tickets, activity and configuration. A model could draft a summary for an agent to verify, reducing search work without making an unsupervised customer decision.
Another idea proposed generating dashboard narratives. Bea liked the potential but found that metric definitions were inconsistent. AI could produce fluent explanations of contradictory data, creating what Tom called βpremium confusion.β The prerequisite was not a better model. It was metric governance.
This is an underrated AI product skill: identifying the non-AI work hiding inside the AI idea.
An AI use case earns its sparkle
- A specific user job becomes materially better
- The task tolerates probabilistic behaviour
- The team has data, evaluation and operating capability
- Users retain appropriate control and a graceful fallback
- The economics still work after inference and review costs
- Failure is observable before it becomes a customer surprise
The demo is the beginning of the cost
Generative features are unusually easy to demo and unusually easy to misunderstand as finished.
A convincing prototype proves that a model can produce an impressive output under selected conditions. A product must produce useful behaviour across real inputs, permissions, latency, cost, abuse, edge cases and change over time.
Tom added four columns to every proposal:
Evaluation. How would the team measure quality before and after release? βLooks goodβ would not survive a thousand accounts.
Failure. What wrong outputs were possible, and which were merely annoying versus materially harmful?
Control. When should a person review, correct, reject or bypass the system?
Economics. What happened to unit cost when usage grew, context expanded or a more capable model became necessary?
The support-summary idea survived. Agents could inspect drafts before use. The team had historical material and domain experts. Quality could be evaluated against representative cases. Failure would waste time or omit context, but the output would not automatically change an account.
An autonomous renewal-negotiation agent did not survive. Jules mourned it for eleven minutes and then admitted that allowing a probabilistic system to invent commercial terms might complicate the quarter.
NISTβs AI Risk Management Framework organises AI risk work around governing, mapping, measuring and managing. The useful product lesson is that responsibility is not a final legal review attached to a finished feature. Context, measurement, oversight and response belong throughout design and operation.
Nora did not need the board deck to reproduce a framework. She needed it to show that the company could distinguish capability excitement from product judgment.
The strategy becomes a portfolio
By Wednesday, the team had three categories.
Now: support-summary assistance, with human review and a clear evaluation plan.
Explore: natural-language analysis for administrators, gated by work on permissions, semantic definitions and cost.
Enable: shared evaluation tooling, model access patterns, privacy controls and incident monitoring.
Everything else returned to the normal roadmap under its original name.
This was important. A technology strategy should change choices, not merely rename them. If every initiative becomes AI, the portfolio has gained no focus. It has only lost the ability to compare investments honestly.
Jules asked what to tell prospects. Maya suggested the truth: the company was applying AI where it could reduce meaningful work, starting with a supervised support workflow, and was not attaching it to predictable tasks that already had better solutions.
Jules worried this sounded less visionary.
Nora disagreed. βDiscernment is a vision,β she said, which was good enough that Leon placed it in the deck but resisted adding a halo.
The board conversation went well. There were questions about speed, data and differentiation. Nora could answer them because the strategy contained choices. She did not present a map of every place AI might appear. She presented where the company would learn, where it would invest and where it would deliberately wait.
A four-question AI review
For any proposed feature, ask:
- Value: what user job becomes materially better, compared with the best non-AI option?
- Behaviour: which uncertainty does the model introduce, and how will people understand and control it?
- Capability: do we have the data, evaluation, technical and operational systems to make it dependable?
- Exposure: what happens when it is wrong, attacked, expensive or changed by its provider?
The answers do not need to be perfect before exploration. They need to become clearer as commitment grows. A prototype can carry open questions. A public promise cannot carry the same number unnoticed.
On Friday, Tom removed the sticker from the toaster. The adhesive left a star-shaped mark, which Bea photographed for the internal launch channel. Leon kept the icon set in a folder called βfuture weather.β
The support-summary pilot began with eight agents and a weekly failure review.
Nobody called it transformation.
It saved eighteen minutes per complex case in the first test, which was considerably more useful.
My take
An AI strategy is not a list of nouns wearing sparkles. It is a set of choices about where uncertain machine behaviour creates enough value to justify the data, evaluation, control and operating burden around it.
Start with a job. Compare against the boring option. Design the failure path before the launch copy. Excitement is allowed; it just does not get final approval rights.
Questions to take back to your team
- Which proposed AI feature would be better as a rule, search improvement or workflow redesign?
- What user job becomes possible or materially better because the system is probabilistic?
- How will your team evaluate quality before customers discover the failure distribution?
- Where does a person retain control, and what happens when the model is unavailable?
- Which prerequisite are you currently disguising as an AI feature?
Choose one sparkling roadmap item and remove βAI-poweredβ from its title. If the remaining sentence cannot explain who benefits and how, the sticker was doing the strategyβs job.