Skip to main content

Module 1.2: Choosing the Right Problem to Prototype

The most common reason AI prototypes fail is not technical — it is choosing the wrong problem. Teams get excited about AI capabilities and go looking for problems to solve, instead of starting with the problems that matter most to their business.

This lesson gives you a framework for selecting the right problem to prototype. Get this right, and everything else becomes easier.

The Problem Selection Framework

Not every business problem is a good candidate for AI. Use these four filters to narrow your options:

Filter 1: Is There a Clear Business Impact?

Start with problems that have measurable financial or operational impact. Good candidates include:

  • Processes that consume significant staff hours (customer support triage, data entry, document review)
  • Decision points where better predictions would save money (demand forecasting, fraud detection, lead scoring)
  • Customer experiences that could be personalized at scale (recommendations, dynamic pricing, content generation)

Ask yourself: If AI solved this problem perfectly, how much would it be worth per year? If the answer is under €50,000, it is probably not worth the investment. If it is over €200,000, you have a strong business case.

Filter 2: Do You Have the Data?

AI needs data. The quality and availability of your data determines what is possible:

  • Structured data (spreadsheets, databases): Easiest to work with. Good for predictions and classifications.
  • Unstructured data (emails, documents, images): Requires more preprocessing but unlocks powerful use cases with modern LLMs.
  • No data yet: You can still prototype with LLMs using prompt engineering and few-shot learning, but you will need data to evaluate performance.

Ask yourself: Can you get a representative sample of 100-1,000 examples within a week? If yes, you are in good shape. If gathering data requires months of work, consider a different problem first.

Filter 3: Is the Error Tolerance Reasonable?

AI systems make mistakes. Some domains tolerate errors better than others:

  • High tolerance: Content recommendations, email categorization, meeting summaries — a wrong suggestion is annoying, not dangerous.
  • Medium tolerance: Lead scoring, support ticket routing, inventory forecasting — errors cost money but are recoverable.
  • Low tolerance: Medical diagnosis, financial trading, legal compliance — errors can be catastrophic. These require extensive validation before any deployment.

For your first prototype, choose a problem with high or medium error tolerance. You want to learn fast without putting critical operations at risk.

Filter 4: Can You Define Success Clearly?

Before you write a single line of code, define what a successful prototype looks like. Be specific:

  • "The model correctly categorizes support tickets into the right department 85% of the time" — Good.
  • "The AI makes our support better" — Too vague.
  • "The prototype generates product descriptions that our marketing team rates as usable (no major edits needed) for 7 out of 10 products" — Good.

Clear success criteria let you evaluate your prototype objectively and decide whether to invest further or pivot.

Common Problem Categories for First Prototypes

Based on our experience at Emplex, these problem types have the highest success rate for first AI prototypes:

1. Document Processing and Extraction

Extracting structured information from unstructured documents — invoices, contracts, reports. Modern LLMs handle this surprisingly well even without fine-tuning.

Example: A logistics company we worked with wanted to extract shipment details from email confirmations. A two-day prototype using GPT-4 achieved 92% accuracy on their actual emails.

2. Internal Knowledge Retrieval

Building a chatbot or search tool that answers questions from your internal documentation. This is the classic RAG (Retrieval-Augmented Generation) use case.

Example: An insurance company wanted to help agents find policy details faster. A week-long prototype reduced average search time from 4 minutes to 30 seconds.

3. Content Generation with Guardrails

Generating first drafts of repetitive content — product descriptions, reports, email responses — with human review built in.

Example: An e-commerce client needed descriptions for 5,000 products. A prototype generated drafts that required only minor editing for 78% of products, cutting content creation time by 60%.

4. Prediction and Classification

Predicting outcomes or categorizing inputs based on historical data — churn prediction, lead scoring, defect detection.

Example: A SaaS company built a churn prediction prototype in one week that identified at-risk customers with 75% accuracy, allowing proactive retention outreach.

The One-Page Problem Brief

Before starting any prototype, write a one-page problem brief with these sections:

  1. Problem statement: One sentence describing the problem.
  2. Business impact: What is the annual cost of this problem? What would solving it be worth?
  3. Data available: What data do you have? How much? How clean is it?
  4. Success criteria: What does a successful prototype look like? Be specific and measurable.
  5. Error tolerance: What happens when the AI is wrong? How wrong is acceptable?
  6. Timeline: How long should this prototype take? (Aim for 1-2 weeks.)

Key Takeaway

Choosing the right problem is half the battle. Use the four-filter framework — business impact, data availability, error tolerance, and clear success criteria — to select a problem that is both valuable and achievable. Write a one-page problem brief before you touch any code.

In the next module, you will learn how to prepare your data and set up the infrastructure for your prototype.