Phase 2: Discovery & AI Product Strategy · 130 min · Opportunity Solution Tree · RICE Framework · Python
The Problem
Every lesson in this phase built one piece of a real AI product decision: sizing an opportunity with jobs-to-be-done, choosing a sourcing path with a TCO comparison, selecting a model with a weighted matrix, triaging feasibility before committing a roadmap slot, and sequencing the bet with RICE and staged rollout. In a real company, none of these happen as separate, disconnected exercises — they happen as one continuous thread of reasoning that starts with "here's a problem worth solving" and ends with "here's what we're building, how, and in what order," documented in a single artifact an executive sponsor and an engineering lead can both read and trust.
That artifact is an opportunity assessment memo, and it's also one of the highest-leverage things you can put in a portfolio when you're trying to break into AI product management. The research behind this course found that project-led portfolios outperform resume-led ones for candidates transitioning into the role, and that a real, defended opportunity assessment — the kind that shows judgment, not just vocabulary — is exactly the evidence a hiring panel is looking for when they ask "walk me through how you'd evaluate this AI opportunity" in a product-sense interview.
This project asks you to do the real thing, once, completely, on a product or company of your choosing — not a toy exercise, and not five separate homework assignments. Pick something you know well enough to reason about honestly: your current employer, a company whose product you use regularly, or one you've researched enough to make credible assumptions. The specificity matters more than the size of the company. A sharply-reasoned assessment for a mid-size SaaS product beats a vague one for a famous brand.
Why this one feature matters for the rest of the course
Here is the structural decision that makes this project different from a standalone assignment: the opportunity you choose and size here is the exact feature you will carry through the rest of this course. The PRD project in Phase 4 turns this opportunity into a full AI product requirements document. The evaluation plan project in Phase 5 builds a scoring rubric for this same feature. The responsible AI review project in Phase 7 assesses risk and fairness for this same feature. The final capstone case study in Phase 9 assembles all four of these into one portfolio piece, alongside a mock interview presentation.
This means the choice you make in this project is not low-stakes. Pick an opportunity that's rich enough to sustain four more rounds of real work — something with genuine complexity in the build-vs-buy decision, a real feasibility risk worth triaging, and a business case substantial enough that a PRD, an eval plan, and a responsible-AI review would each have real content to say, not a thin restatement of this memo. A trivial opportunity ("add an AI-powered dark mode toggle") won't hold up across five projects. An opportunity with a real data dependency, a real precision/recall tradeoff, and a real cost-at-scale question will.
Choose the feature you're building for the next four projects, not just this one
Spend real time on this choice before you start scoring. Ask: does this opportunity have a genuine build-vs-buy tension (not an obvious "just call the API" case), a feasibility risk worth triaging (not a slam dunk), and stakes high enough that a responsible-AI review later in the course would have something substantive to assess? If the honest answer to any of those is no, pick a different opportunity now — reworking this choice in Phase 4 because the original one turned out too thin costs far more time than getting it right here.
What the memo needs to contain
The memo assembles five components, each one a direct application of a lesson from this phase:
- The opportunity, sized. A jobs-to-be-done statement, plus the frequency/pain-intensity/workaround-cost scoring from Lesson 1's framework, adjusted for AI fit. This section has to answer "why this, why now" with numbers, not just a compelling narrative.
- Build vs. buy vs. fine-tune recommendation. A real total cost of ownership comparison across at least two sourcing options (a frontier API path and at least one alternative — self-hosted, managed SaaS, or a different sourcing structure), following Lesson 2's TCO framework, with a stated recommendation and reasoning.
- Model selection. A weighted scoring matrix across at least three candidate models, using Lesson 3's cost/latency/quality/context-window framework, with weights justified by this specific feature's actual requirements — not a generic weighting copied from a lesson example.
- Feasibility and risk triage. A documented triage across data readiness, latency constraints, and integration risk, following Lesson 4's red-flag test, with an honest verdict — proceed, proceed with named mitigations, or a real discussion of what would need to change if triage surfaced a stop-level blocker.
- Roadmap sequencing. A RICE score (with the AI-specific confidence discount from Lesson 5) placing this opportunity in context against at least one or two other opportunities you considered and didn't choose, plus a crawl/walk/run staged rollout plan with explicit validation questions and progression bars per stage.
The memo closes with a one-paragraph executive summary that a time-constrained sponsor could read alone and still understand the recommendation — this is the same "can a non-technical stakeholder trust this without reading the whole thing" bar that a real launch-review memo has to clear.
A candidate is assembling their opportunity assessment memo and has strong, well-reasoned sections for opportunity sizing and model selection, but the feasibility and risk triage section just says "engineering thinks this is doable." What's wrong with this, and what would fix it?
Lesson 4 was explicit that "is this feasible?" is a bad, unanswerable question, and a vague "engineering thinks this is doable" is exactly that kind of non-answer restated. A real feasibility section has to work through the three specific signals -- data readiness, latency constraints, integration risk -- with concrete answers to each, and apply the red-flag test (is there a knowable, estimable path to resolving any identified risk) to reach a defensible verdict. Getting a more senior sign-off doesn't fix a documentation gap; specificity does, and it's exactly the kind of gap an engineering lead reviewing this memo would immediately flag.
Why this format, specifically
A memo — not a slide deck, not a one-pager — is the deliverable because the four projects that follow it in this course all need to reference back to the reasoning here, not just the conclusion. A PRD in Phase 4 that says "we're using Model X because it won the selection matrix in the opportunity assessment" only works if the opportunity assessment's matrix is legible enough to actually check. This is the same principle from Lesson 3's model-selection matrix — the artifact itself, not just the bottom-line recommendation, is what makes a decision auditable and revisable months later when circumstances change.
A reviewer reading this project's memo says: "I can see your final model recommendation, but I can't tell why you weighted quality so much higher than cost for this particular feature." What does this feedback indicate about the memo, and how should it be addressed?
This is precisely the gap Lesson 3 warned against: a bare weighted total without visible reasoning forces a reader to either trust it blindly or redo the analysis. The fix isn't a new framework, it's completing the existing one -- each weight in the matrix needs a specific, feature-grounded justification (why does this particular feature's low volume and high stakes justify weighting quality over cost, for example), so a reader (technical or not) can audit the reasoning, not just the number. A memo missing this is incomplete regardless of who reviews it.