Every leadership team has had the meeting. Someone has seen a demo, the board is asking about AI, and there's budget for "something." What happens next decides whether the company builds real capability or spends a year on a pilot that quietly dies. Having been on the receiving end of a lot of those first projects, we've learned that the choice of use case matters more than the choice of model, vendor or framework combined.
Here's the framework we walk clients through before writing a line of code.
Start from a painful, measurable, frequent problem
The best first use case is boring to describe and expensive to live with: a queue someone works down by hand every day, a document that takes an hour to draft and gets drafted a hundred times a week, a question that customers ask constantly and staff answer from the same three sources. Frequency gives you data and quick feedback. Measurability gives you a baseline to beat. Pain gives you a sponsor who will fight for the project when it hits friction — and every project hits friction.
Check the data before you check the model
Ask three questions. Does the information the AI needs actually exist in digital, accessible form? Is it reasonably current and correct? Can you legally and contractually use it for this purpose? A shocking number of promising use cases fail at this step — the knowledge lives in people's heads, the documents are five versions out of date, or the customer data can't leave a system. Discovering this in week one is a cheap pivot. Discovering it in month four is a dead pilot.
Prefer assistance over autonomy for round one
A first project should make a human faster, not replace a decision. "Draft the response for the agent to approve" ships in weeks and builds trust; "answer the customer autonomously" needs the evaluation record that only the first version can generate. The assist-first pattern also lowers the accuracy bar you need on day one — a 90% useful draft is a huge win when a human reviews it, and a serious liability when nobody does. Autonomy is something you earn with data, as we've written about for agents in production.
Score candidates on value, feasibility and risk
Put every candidate on a simple grid. Value: hours saved or revenue touched per month, times frequency. Feasibility: data readiness, integration complexity and how well-bounded the task is. Risk: what happens when the AI is wrong — an awkward draft, or a regulatory incident? The first project should be high on value and feasibility and low on risk. Save the high-risk, high-value cases — credit decisions, clinical judgements, customer-facing autonomy — for when you have the evaluation and governance muscle to carry them.
Scope it to ship in a quarter
If the plan needs more than roughly twelve weeks to put something in front of real users, the scope is too big. Cut the use case down: one team, one document type, one language, one channel. A narrow project that's live and measured beats a broad one that's still in development, every time — because the live one is producing the data, the trust and the internal champions that make the second project easy to approve.
Define success before you start
Agree the metric and the baseline up front: minutes per ticket today versus target, error rate today versus target, adoption rate among the intended users. Decide who owns the AI's output quality after launch — someone has to review the logs, curate the examples and update the prompts, and that's a role, not a task. Projects with a named owner and a numeric target survive their first bad week. Projects without them don't.
The short version
Pick a frequent, painful, measurable problem with data you can actually use. Make the AI assist a human rather than replace one. Score for value, feasibility and low risk. Scope to ship in a quarter, define the metric before you build, and name an owner for what happens after launch. Do that, and your first AI project becomes the foundation for the next ten instead of a cautionary tale.
Weighing up where to start? Book a discovery call — helping teams choose and scope that first project is most of what we do.