Applied GenAI Curriculum for AI PMs · Core Sequence

Unit 11 — Data Curation: The Unsexy Blocker

Data quality, coverage, and quantity — why "we need better data" is the most common true diagnosis, what "better" concretely means, and how to budget annotation realistically.

Why the blocker is usually data

When an AI feature stalls, "we need better data" is the most common diagnosis — and it's usually true. The problem is that "better" is vague, so the conversation goes nowhere. This unit makes "better" concrete. The right data makes a model more capable and safer; poor data actively increases bias and hallucination and wastes resources. Your job here isn't to curate data — it's to know what to ask when data is the thing standing between you and launch, and to budget the annotation work honestly instead of hand-waving it.

The cooking analogy Training is cooking; data is the ingredients. Quality = are the ingredients fresh (not spoiled)? Coverage = is the mix right (not too much or too little of anything)? Quantity = do you have enough? All three matter, and more of one doesn't fix a deficit in another.

Quality

fresh ingredients

Each example is good — relevant, consistent, correct.

Coverage

the right mix

The data spans the range of problems and phrasings you'll actually see.

Quantity

enough of it

Enough examples to learn — the amount depends heavily on the case.

1. Quality — what "good data" concretely means

The headline finding: a small amount of high-quality data beats a large amount of noisy data. Carefully curated instruction sets in the low thousands have matched or beaten datasets hundreds of times larger. "High quality" isn't a vibe — it's six checkable traits:

Relevant

Fits the task — a 19th-century legal corpus is wrong for today's law, right for legal history.

Aligned with requirements

Matches what the task needs — factual if it needs facts, concise if it needs brevity, with justifications if asked. (Not just "correct" — a correct answer may not be what's wanted.)

Consistent

Two annotators on the same example shouldn't diverge; inconsistency confuses the model. A clear guideline is what makes this possible.

Correctly formatted

Follows the expected format — strip HTML tags, trailing spaces, stray newlines, inconsistent casing.

Sufficiently unique

Duplicates introduce bias and contamination; how much duplication is tolerable depends on the use case.

Compliant

Respects internal and external policy — e.g. no PII if you're not permitted to train on it.

Curation isn't only about adding good data — it's also removing data to unlearn bad behavior. If a chatbot keeps tacking on unsolicited rewrites, the fix is to find and delete the training examples that model that habit, then add examples that don't.

2. Coverage — the diversity you'll actually see

Training data should span the range of problems, and phrasings, real users bring. Coverage is really diversity: if some users write long detailed prompts and others terse ones, include both; if queries often have typos, include typos; if you support several programming languages, cover them.

The diversity axes differ by application — a French→English tool needs no language diversity but benefits from diverse topics and styles; a global product bot needs linguistic and cultural diversity. And the best proof point: a model trained on data that's both high-quality and diverse beats the same model trained on data that's only one or the other. Two cautions — more heterogeneous data can sometimes hurt, and the right mix is the one that reflects real usage (or is found by experiment).

3. Quantity — how much, really

"How much data do I need?" is like "how much money do I need" — it varies enormously (models can learn from a single example; some finetunes use millions). Four factors set the answer:

Quality & diversity	Better, more diverse data needs less of it.
Finetuning technique	Full finetuning wants far more data (tens of thousands+); lightweight methods work with a few hundred to a few thousand.
Task complexity	Sentiment classification needs far less than QA over financial filings.
Base model strength	The closer the base model already is, the fewer examples to close the gap.

Diminishing returns. The first 1,000 examples might add 10 points; the next 1,000, only 5. Train on 25% / 50% / 100% subsets and plot the slope to estimate how much more data buys.

The practical move: start tiny Before committing budget to a big dataset, try a small, well-crafted set (~50 examples). Clear improvement suggests more data will help further; no improvement at all means a bigger set rarely will (though check hyperparameters and prompts before concluding). This small-first probe is how you de-risk a data investment cheaply — and it's the honest answer to "how much annotation should we fund?"

4. Acquisition & annotation — where the real cost lives

The single best data source is your own application data — it's perfectly relevant and matches the distribution you care about, which is nearly impossible to get elsewhere. Building a data flywheel that turns user activity and feedback into continual improvement is a durable advantage (and ties back to the moat in Unit 03). Before creating data, check public dataset marketplaces — but never fully trust them: inspect, validate, and always check the license (even a commercially-licensed set may contain sub-sources that aren't).

Real curation is mix-and-match: start from an existing set, prune low-quality instructions and responses, hand-write the missing responses, spot a thin topic, generate synthetic examples from templates, annotate those… and loop back when guidelines turn out wrong or annotations turn out incorrect. It is iterative and slow.

The part everyone underestimates: annotation guidelines The hardest part of annotation usually isn't labeling — it's writing a clear guideline. What does a good response look like? Can it be correct yet unhelpful? What separates a 3 from a 4? Teams routinely report this as one of the toughest parts of the whole pipeline, and it's alarmingly common to abandon careful annotation halfway and hope the model figures it out. The good news: these are the same guidelines you built for evaluation in Unit 09 — another reason that investment pays off twice.

Budgeting annotation, concretely Data quantity is bounded by what you can afford, not just what you need: a $10,000 annotation budget at $2/example caps you at 5,000 examples — and data spend competes with compute spend. When a team says "we need more data," the real question is: how many examples, at what per-example annotation cost, and does the performance-gain slope justify it? That's a fundable plan, not a wish.

What "good" looks like after this unit

You can now:

Translate "we need better data" into the three concrete axes — quality, coverage, quantity — and the six quality traits.
Recognize that curation includes removing data to unlearn bad behavior, not just adding good data.
Reason about how much data via the four factors, the diminishing-returns curve, and the small-first probe.
Name application data / the data flywheel as the best source, and check licenses on everything else.
Budget annotation realistically — cost per example, total budget, and the guideline work that's the real bottleneck.

The tempting shortcut — "we'll just generate the training data" — is its own topic with its own risks, held for DEPTH Unit 20 (synthetic data & distillation).