How to Scope an AI Feature Without a Data Science Team

The most common objection we hear from product teams when we suggest building an AI feature is: 'We don't have a data science team.' This concern is understandable and almost always misplaced.

In 2024, a huge proportion of what used to require custom ML models can now be done with well-prompted foundation models accessed via API. The question isn't whether you have a data science team. It's whether you have a clear enough hypothesis to know what you're actually trying to build.

Start with the problem, not the capability

Before you scope anything, write down the user problem in one sentence. Not 'we want to add AI to our dashboard.' A specific problem: 'Our users spend 25 minutes every morning manually reviewing data to identify anomalies. We want to surface those anomalies automatically so they can start their day with insights, not work.'

That sentence tells you almost everything: what the AI needs to do (detect anomalies), what data it needs (time-series metrics), what success looks like (25 minutes saved per user per day), and what failure looks like (false positives that erode trust).

The API-first approach

For most AI features, the fastest path to validation is API-first: use a foundation model (GPT-4, Claude, Gemini) via API, wrap it in a thin product layer, and test with real users before you make any infrastructure decisions.

• Don't train a custom model until you've validated that the feature solves a real problem
• Don't fine-tune until you've proven the base model isn't good enough
• Don't build a vector database until you know the retrieval pattern you need
• Don't optimise for cost until you know how the feature will actually be used

"Every week you spend on infrastructure before validation is a week you're building for a hypothesis you haven't tested. Use the API. Test the hypothesis. Then invest."

Cost modelling: the step everyone skips

AI features have a cost structure that traditional software doesn't: inference costs at scale. Before you commit to building, model the unit economics. How many API calls will this feature make per user per day? What does that cost at your current pricing tier? What does it cost at 10x your current user base?

We've seen products where the AI feature was technically brilliant and economically untenable — the inference cost was higher than the average revenue per user. That's a product you can't ship at scale, no matter how good the AI is.

The validation test

Before you build anything production-quality, answer these five questions. If you can't, you're not ready to build:

• What does the user do today without this feature? (The baseline)
• What will the user do differently if this feature works perfectly? (The outcome)
• What does 'good enough' look like? (The acceptance bar — not 100% accuracy)
• What happens when the AI gets it wrong? (The failure mode)
• What data does the model need to do this, and do we have it? (The data question)

These questions aren't bureaucracy. They're the difference between building a product and building a prototype that never ships.