Applied GenAI Curriculum for AI PMs · Core Sequence
A feasibility screen you run before a single engineer-hour is spent: why you're building, what success means, how you'll get there, and how you'll keep it alive.
Units 01 and 02 were about how the technology behaves. This one steps back to the business question that should precede any of it: should you build this at all? It lands right after non-determinism (Unit 02) on purpose — you can't set honest expectations with stakeholders until you understand that the output won't always be the same or always be right. "It's easy to build a cool demo with foundation models. It's hard to create a profitable product." This unit is the screen that separates the two before you spend real money.
Building an AI feature, like most business decisions, is a response to risk or opportunity. Before scoping anything, place your motivation on this ladder — it determines urgency and whether you should build in-house at all:
| Motivation | What it means for you |
|---|---|
| Existential threat | AI-native competitors could make you obsolete. Highest priority — and a reason to build in-house rather than hand the capability to a competitor. Common in document processing, financial analysis, insurance, and creative work. |
| Profit / productivity upside | The most common driver. Cheaper acquisition, better retention, faster support, lead-gen. Here you likely have plenty of buy options that beat building. |
| Don't-get-left-behind | Unsure where AI fits yet, but exploring is prudent if you can afford it (cue Kodak, Blockbuster, BlackBerry). Fits R&D, not a product commitment. |
How central AI is to the feature sets its quality bar. Three axes to classify any AI feature:
| Critical vs. complementary | Does the app still work without AI? Face ID is AI; Gmail works without Smart Compose. The more critical AI is, the more accurate and reliable it must be — people forgive mistakes more when AI isn't core. |
| Reactive vs. proactive | Reactive responds to a user request (chatbot) and usually must be fast. Proactive shows up uninvited (traffic alerts) — latency matters less, but the quality bar is higher because low-quality proactive features feel intrusive. |
| Dynamic vs. static | Dynamic updates continually from feedback (per-user personalization, memory); static updates periodically with a shared model. Determines your maintenance and infra shape. |
Then pin down the human-in-the-loop question: does AI support a human, decide directly, or both? A support chatbot could (a) suggest responses agents reference, (b) handle only simple requests and route the rest, or (c) answer everything unaided. A useful way to stage that automation over time:
Human involvement is mandatory. AI only generates suggestions.
AI interacts directly with internal employees.
Increased automation, potentially including direct interaction with external users.
The role of humans moves as quality proves out. Start AI as a suggester; if agents accept, say, 95% of its suggestions verbatim on simple requests, graduate those requests to direct AI handling. The acceptance rate is your promotion signal.
The low barrier that lets you build also lets competitors build. Two threats specific to building on top of foundation models: (1) the platform can subsume you — a PDF-parsing app dies the day the base model parses PDFs well; (2) a giant can replicate a thin feature "with three engineers in two weeks." Three moats exist — technology, data, distribution — but with shared foundation models, tech converges and distribution favors incumbents. That leaves data as the realistic moat: get to market first, accumulate usage data, and let it compound into product improvements. (Calendly could've been a Google Calendar feature; Mailchimp a Gmail feature — first-mover usage data is how the small player wins.)
Once you've decided to build, define success before building. The most important metric is business impact, not model quality. For a support chatbot: what % of messages should it automate? How much more volume can you handle? How much faster do you respond? How much labor is saved? And because answering more messages doesn't mean happier users, track satisfaction alongside throughput.
| Quality | How good the responses are (the eval thread, Units 06–09, makes this concrete). |
| Latency | TTFT (time to first token), TPOT (time per output token), total latency. "Acceptable" is relative — if humans currently answer in a median hour, anything faster may be plenty. |
| Cost | Cost per inference request. |
| Other | Interpretability, fairness, and similar, as the use case demands. |
If you can't name the exact metrics yet, that's fine — later units supply them. What matters now is committing to having a threshold.
With goals set, plan backward from where you actually start: evaluate off-the-shelf models first. If your goal is automating 60% of tickets and a stock model already does 30%, your remaining effort is far smaller than starting from zero. Expect goals to shift after evaluation — you may learn the cost to reach the threshold exceeds the return, and rightly kill the project. That is a successful outcome of this unit, not a failure.
The last-mile challenge — initial success is misleading:
A good demo does not promise a good product. "The journey from 0 to 60 is easy; progressing from 60 to 100 becomes exceedingly challenging." One team hit 80% of the target experience in a month — then needed four more months to pass 95%, most of it spent on kinks and hallucinations.
Planning doesn't stop at launch. AI products carry an extra burden: the field moves at a "bullet train" pace, and even good changes cause friction. A few forms the churn takes:
| Shifting economics | Build in-house because it's cheaper, then providers halve prices in three months and in-house becomes the expensive option. Every tech investment needs an ongoing cost-benefit check. |
| Model swaps | APIs are converging, so swapping models is easier — but each model has quirks, so prompts, data, and workflows need retuning. Painful without versioning and evaluation infrastructure in place. |
| Regulation | Hard to adapt to. GDPR compliance was estimated at $9B across businesses; compute access can change overnight with new export laws. |
| IP risk | Potentially fatal. If your product is built on a model trained on others' data, can you be sure you own your output's IP? IP-heavy firms (e.g. game studios) hesitate for exactly this reason. |
You don't need answers to all of these now — you need to have asked them before committing, so maintenance isn't a surprise line item a year in.
If a question has no answer, that's your signal to keep screening — or to pass. Killing an idea here is cheap; killing it after six months of engineering is not.