Practical AI strategy memo

The company, the question, and the boundary of this memo.

The subject is a mid-market financial services company with ~60 engineers, a stable customer base of roughly two thousand enterprise accounts, and three primary product lines. The CEO is wary of hype but also worried about being left behind. Both feelings are appropriate.

We were asked to characterize the company's current AI usage, identify the use cases with the highest expected value, distinguish opportunities that are real from those that are fashionable, recommend a sequence of investments, and be specific about what we would not do.

How we gathered evidence.

• Surveyed every engineering team about current AI usage in development workflows.
• Interviewed eleven engineers, six product managers, the head of customer success, the head of operations, the COO, and the CEO.
• Sat in on three customer support shifts and two onboarding calls.
• Reviewed twelve months of customer support tickets to identify recurring patterns.
• Audited the data the company holds — customer interaction history, operational telemetry, financial records (compliance-permitting).
• Surveyed the AI landscape relevant to this domain, biased toward tools that have been in production at comparable companies for at least six months.

We deliberately discounted vendor pitches and proof-of-concept demos. We asked: what is shipping, working, and not regressing?

What we observed.

A. The team is already using AI well at the individual level.

85% of engineers use an AI coding assistant daily; an internal estimate puts productivity gains at 15–25% for boilerplate-heavy work. This is happening without formal endorsement, which is fine — but it means there is no aggregated learning. The biggest gains are in test writing, refactoring, and getting unstuck on unfamiliar parts of the codebase. Limited gains in design-level or system-level work, which is normal.

B. The product surface has obvious AI opportunities — but they are not the obvious ones.

The most-discussed use case in internal meetings — "an AI agent that handles customer questions" — is the lowest-value opportunity we identified. Customer questions in this domain are roughly 70% account-specific (account access, billing, configuration), and a generic LLM has nothing to add. Higher-value, less-discussed: AI-assisted data reconciliation across customer-provided inputs (a current three-FTE manual task). Higher-value, less-discussed: anomaly surfacing in operational telemetry (currently no one looks at it until a customer complains).

C. Customer-facing AI features have unusual risk in this domain.

Financial services customers are conservative; visible "AI" branding actively reduces trust in this segment. Customers will pay more for features that happen to use AI than for features marketed as AI. The most successful AI features at peer companies are invisible: better search, better recommendations, better summaries.

D. The company's data is its most underused asset.

Twelve years of customer interactions, transactions, and operational data. Currently used primarily for individual queries; not aggregated, not embedded, not retrievable. A basic semantic search layer over support history would, in our estimate, halve the time-to-resolution on tier-2 support tickets. This is achievable in a quarter with one engineer.

E. There is no AI strategy because there is no one whose job is AI strategy.

AI conversations happen in three places — engineering, product, and exec — and rarely converge. No one tracks AI investments across the company. No one is responsible for evaluating tools, vendors, or build-versus-buy decisions. This is the normal state for companies the subject's size. It is not a failure. But it is the first thing to fix.

Quiet wins, not moonshots.

The company does not need a moonshot. It needs three to five well-chosen, internally-facing AI investments that compound. The CEO's wariness of hype is correct. The most expensive AI mistakes we have seen in comparable companies have been customer-facing initiatives with vague ROI and high failure risk. The most successful have been quiet, internal improvements with measurable savings or revenue uplift.

There is also an organizational question. AI tools, like any new technology, do not adopt themselves. There is no AI strategy here because no one owns it.

What we would do, in priority order.

1. Name an AI strategy owner.

Single most important recommendation. One person, part-time, with explicit charter to make build-versus-buy decisions, prioritize investments, and report on outcomes quarterly. Likely a senior engineer or a principal product manager. Reporting to the CTO.

2. Build the semantic search layer over support history.

Lowest-risk, highest-conviction opportunity. One engineer, one quarter, measurable impact on support cycle time. Use this as the team's first internal AI shipping exercise — and as proof, internally, that AI investments can be small and concrete.

3. Invest in the data reconciliation use case.

Currently a three-FTE manual task. With careful design, an AI-assisted workflow could halve that effort within six months. This requires deeper investment, but has the clearest ROI of any opportunity we identified.

4. Establish an AI tooling budget with a quarterly review.

Do not buy ten tools. Buy two, evaluate them rigorously, and consolidate. The current "every team chooses their own" pattern is fine until it isn't; get ahead of the tooling sprawl before it costs you.

5. Do not build a customer-facing AI agent. Not this year.

The opportunity cost is real and the failure risk is high. Revisit this in twelve months, with the benefit of having shipped internal AI features successfully first. This is the recommendation most likely to be ignored, and the one we are most confident about.

A sequenced plan.

Weeks 1–2.

Name the AI strategy owner. Charter is one page. Reports to the CTO. Reviewed by the executive team quarterly.

Weeks 3–4.

Scope the semantic search project. Assign one engineer. Identify the success metric — we suggest median tier-2 ticket resolution time (currently 4.2 hours).

Weeks 5–8.

Ship v1 of internal semantic search. Begin scoping the data reconciliation work in parallel; this is a quarter or more of effort.

Weeks 9–12.

Measure semantic search impact. Publish the first quarterly AI investment review. Use it to decide the next investment.

We expect the semantic search work alone to pay back the engagement fee within two quarters. The data reconciliation work, if pursued, will pay back many multiples within a year. We are available to support the AI strategy owner through their first quarter.