Problem Statement Analysis

Overview

Most wasted AI engineering effort starts before any model is chosen: the problem was never defined. Problem statement analysis turns a fuzzy ask into inputs, outputs, constraints, and one measurable success criterion — the smallest honest spec you can build against.

When to Use

• Stakeholder says "we need an AI chatbot" without defining what success looks like
• A ticket describes a solution ("use RAG") before the underlying need is clear
• You are about to pick models, vector DBs, or agents without a written target
• Skip when acceptance criteria already exist and were validated with real users

Quick Reference

Implementation

1. Capture the raw ask — paste the email, ticket, or meeting note verbatim.
2. Restate in one paragraph — who is the user, what do they provide, what should the system return, under what limits (latency, cost, privacy).
3. List constraints — budget, compliance, data residency, existing stack, timeline, team capacity.
4. Define one success criterion — e.g. "80% of support tier-1 questions answered with citation to help docs" or "JD fit score within 10 points of recruiter label on 50 held-out cases."
5. Name the smallest system — the minimum pipeline that could satisfy the criterion; defer everything else.
6. Send back for confirmation — if they disagree with the restatement, you found the real work early.

On This Portfolio

Before building the public assistant, I scoped: visitors ask about my work → answers must cite published knowledge only → refuse when corpus has no support. That single constraint ruled out open-ended generation and shaped RAG + publish gates in admin.

Red Flags

Common Mistakes

• Jumping to architecture before success criteria exist
• Treating the stakeholder's favorite solution as the requirement
• Defining success only as "model quality" without a user or business outcome

Related Skills

• RAG vs fine-tuning decision
• Scoping MVP vs production system
• Failure mode mapping before build