From a broad AI idea to a first launch: how we plan an AI product

Most AI product conversations start the same way. Someone senior has seen what a language model can do, the team has a demo that impressed a few people, and the brief we receive is a sentence like "we want to use AI across operations." It is an honest starting point. It is also not a product.

This post is about how we get from that sentence to a first launch. It is written from the projects where we got it wrong first, because the pattern of getting it wrong is remarkably consistent, and the fix is mostly discipline rather than cleverness.

The mistake we kept making early on

Our first few AI engagements began with the model. We would pick a provider, wire up a prompt, show something that answered questions about the client's documents, and then try to work backwards to a product. It produced fast demos and slow launches. The demo never told us who would use the thing every day, what decision it changed, or what happened when it was wrong.

On one engagement for an operations team, we spent three weeks tuning retrieval quality for a knowledge assistant before anyone asked which questions the team actually needed answered. When we finally sat with the people doing the work, the top request was not answering questions at all. It was drafting a specific weekly report from four systems. The assistant we had built was accurate and unused.

The order matters: workflow first, data second, model last. Every time we reversed it, the launch slipped.

Start from the workflow and the decision

Now the first artefact on every AI engagement is a workflow map. Not an architecture diagram, a map of what people do: the trigger that starts the work, the inputs they gather, the decision they make, the output they produce, and who owns the result. For each step we ask what a good outcome looks like and what it costs when it goes wrong.

Three questions do most of the work here:

• What decision changes? If the AI feature does not change a decision or remove a task, it is a curiosity.
• What is the cost of delay? A task that blocks ten people for an hour a day is worth automating. A task that annoys one person monthly is not.
• Who reviews the output? If nobody can check the AI's work, we are not ready to ship it in that workflow.

Map the users and the data honestly

The second artefact is a data map, and this is where most ambitious ideas shrink to something buildable. We list every data source the workflow touches, who is allowed to see it, how fresh it needs to be, and how clean it is today. In practice, the data is never as connected as the brief implied. Customer records live in a CRM, the contracts in a document system, the exceptions in a spreadsheet that one person maintains.

That is fine. It just means the first release is bounded by the data we can reach reliably, not by what the model could theoretically do. We write those boundaries down, because they become the permissions model later and the source of most security questions.

Choose the smallest release that proves value

With the workflow and data mapped, we pick a first release from a short menu. The choice depends on where the value is and how much trust exists.

• An assistant when people spend time finding and reading things.
• An automation queue when there is a repetitive decision with a clear rule and a reviewer.
• A dashboard with AI summaries when leaders need visibility more than action.
• A retrieval flow inside an existing tool when adoption of a new interface is the risk.
• An embedded feature in a product the client already ships, when the value is for their customers.

The rule we hold ourselves to: the first release should be explainable in one sentence, usable by one identifiable group, and measurable by one number that group already cares about.

Security is a planning question, not a launch checklist

We used to treat security as something to handle before go-live. That created two problems. Architecture decisions had already been made that were hard to secure, and the client's security team met the project for the first time with a week to go.

Now security goes into the plan at the data-map stage. Which data leaves the client's environment, and to which provider? Does the model provider retain prompts? Who can invoke the feature, and can they ask it about data they could not otherwise see? Is there an audit trail of what the AI produced and who accepted it? Answering those early usually changes the design in small ways that are cheap at planning time and expensive after.

What the plan looks like when it is done

By the end of planning, the client has a short document with the workflow map, the data map with access rules, the chosen first release and why, the evaluation criteria we will use to call it working, and the named owner who will support it after launch. It is deliberately unglamorous. It is also the reason the launch usually happens.

A checklist you can use

1. Write the workflow as trigger, inputs, decision, output, owner.
2. List every data source with access rules and freshness.
3. Pick the first release from the menu and defend it in one sentence.
4. Define how you will know it works before you build it.
5. Decide what leaves your environment and who is allowed to ask what.
6. Name the person who owns it after launch.

If you can complete those six lines, you have a product. If you cannot, the AI part is not the problem yet.