---
name: problem-statement-analysis
description: Use when a request is vague, open-ended, or arrives as a business ask rather than a technical spec.
---

# 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

| Signal | Action |
|---|---|
| Vague ask | Restate as input → output → constraints in one paragraph |
| No metric | Ask what "working" means in numbers or observable behavior |
| Solution-first request | Separate the proposed solution from the actual problem |
| Multiple stakeholders | Write the restatement and get explicit sign-off before build |

## 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

| Thought | Reality |
|---|---|
| "I'll discover the spec while building" | You will ship the wrong thing efficiently |
| "They asked for RAG, so we build RAG" | RAG may not be the problem — maybe routing or UX is |
| "Too small to need scoping" | Small projects hide the riskiest assumptions |

## 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