Twelve questions to ask before anyone builds your AI product

Most AI products that fail do not fail in the build. They fail before it, in decisions nobody made, or after it, in the gap between a convincing demo and something the business can actually run. I have written about why that happens in why AI pilots stall before production.

These are the questions that catch those problems early. Ask them of your own team, and of any partner you are thinking of hiring.

The problem

1. What problem are we solving, and for whom? Stated plainly enough that you can say no to things. "Use AI in customer service" is a direction. "Cut the time to answer delivery questions from a day to an hour" is a problem.

2. Does AI genuinely change the answer? Sometimes the best solution is a better form, a clearer process or a report. AI earns its place when the work involves language, judgment or messy inputs that rules cannot handle.

3. What will this project not do? Write the boundaries down in the first week. Most scope creep, and most disappointment, comes from things everyone assumed were included.

Success

4. What number should it move, and how will we measure it? Hours saved, error rate, response time, conversion. Agree the measure, and how you will get the baseline, before anything is built.

5. How will we know if the AI's output is good enough? Collect real examples of good and bad results before you start, and test against them. Without that, quality is a matter of opinion and every model change is a gamble.

The data and the systems

6. Is our data ready, and will you tell us if it is not? Good data that you cannot reach is not ready. Neither is data nobody owns. A good partner tells you this early, even when it shrinks the project.

7. How does this connect to the systems we already run? Integration is where timelines go to die. Map what connects to what, and who controls each system, before committing to dates.

8. Where does our data go, and who processes it? Know which vendors and models see your data, where it is stored, and whether it is used for training. Set the boundaries first and design inside them.

Delivery and ownership

9. Will the person who scopes it also build it? Every handoff loses context. If a different team builds what someone else scoped, budget time for that handoff, or avoid it.

10. What is the path from demo to production? Ask for it explicitly: hosting, monitoring, who gets alerted when it misbehaves, and what happens when a model is retired. A demo that has none of this is a prototype, not a product.

11. Who owns the code, models and configuration when it is delivered? It should be you, in writing, and it should cover more than the application code: prompts, configuration, evaluation data and deployment scripts too.

12. What does it cost to run, and who keeps it working? AI products have running costs that grow with use: model usage, hosting, monitoring. Get an estimate at expected volume, and name who maintains it after launch.

What good answers sound like

You do not need perfect answers to all twelve before starting. You need honest ones. Be wary of a partner who has a confident answer to everything in the first meeting, cannot show you something they have shipped, or treats questions 10 to 12 as details for later.

Our product strategy sprint answers these questions in a week, ending in a spec for the first thin slice you could build next. If you would rather we built it too, that is what Ship One Thing is for.