Phase 2: Discovery & AI Product Strategy · 45 min · NIST AI RMF · Python

Feasibility & Risk Triage

The cheapest way to kill a bad AI feature is a 30-minute triage conversation before the PRD, not a canceled sprint after it.

Hiring signal: The interview loop research behind this course found evaluators specifically test how a candidate partners with data science across the model lifecycle and evaluates feasibility under uncertainty — a PM who can run a structured, non-technical feasibility triage with an ML lead before committing a roadmap slot is demonstrating exactly that signal, not just describing it.

What you will learn

Run a structured feasibility triage covering data readiness, latency constraints, and integration risk without requiring deep technical expertise
Frame feasibility questions an ML or engineering lead can answer quickly and concretely, instead of vague open-ended questions
Identify red flags that should stop a feature before a PRD gets written, distinguishing them from normal, workable risk
Score a feature's overall feasibility and risk level and justify the score with specific evidence, not a gut feeling
Explain the difference between a feasibility blocker and a risk to monitor, and route each appropriately

The Problem

A PM pitches "automatically categorize every inbound support ticket by root cause, so we can spot emerging product issues in real time." Leadership loves it. It goes on the roadmap. Six weeks into the build, the ML engineer flags that the "root cause" categories the PM wants don't actually exist anywhere in the historical data — support agents have never consistently tagged tickets that way, so there's no labeled training set, and even manually creating one would take a full-time labeler two months before any model work could start. The feature gets pulled from the roadmap, the sprint's work gets shelved, and the PM has to explain to leadership why a feature they championed just evaporated after six weeks of visible engineering time.

The information that killed this feature — no existing labels, no fast way to create them — was knowable on day one. It didn't require the PM to understand model architecture. It required asking a specific, answerable question of the right person before committing a roadmap slot: "does the data this feature needs already exist, and if not, how would we get it?" That single question, asked in a 30-minute conversation with an ML lead before the PRD was written, would have surfaced the exact blocker that six weeks of engineering time eventually surfaced anyway, at a much higher cost.

This lesson is that 30-minute conversation, structured. A PM doesn't need to be technical to run a real feasibility and risk triage — they need to know which questions to ask, how to phrase them so an ML or engineering lead can answer quickly and concretely, and which answers are red flags versus normal, workable risk.

Three Feasibility Signals a Non-Technical PM Can Actually Assess

Data readiness. Does the data this feature needs already exist, in a usable form, at sufficient volume? This is the single highest-leverage question to ask first, because a data gap is often the slowest and most expensive thing to fix — as the opening scenario shows, "we don't have labels" can turn a six-week feature into a six-month one. The right question to an ML/data lead isn't "is the data good" (too vague to answer quickly) — it's specific: "does a labeled example of [the exact thing the feature needs to predict/generate] already exist, and how many do we have?"

Latency constraints. Does this feature have a hard response-time requirement, and does anything about the proposed approach put that requirement at risk? A live user-facing feature (chat, autocomplete) has a much tighter latency bar than a nightly batch job, and an approach that requires multiple model calls chained together (retrieval, then generation, then a verification pass) adds up latency fast. The right question: "walk me through every model or API call this feature would need to make per user action, and what's the latency budget for the whole chain."

Integration risk. Does this feature need to connect to systems that are hard to integrate with — legacy systems with no API, systems owned by another team with their own roadmap, or third-party systems with rate limits or unclear data-sharing terms? Integration risk is often invisible in a product spec because it doesn't show up until an engineer actually tries to wire the systems together. The right question: "which systems, teams, or vendors outside our own does this feature depend on, and have we actually confirmed access, not just assumed it?"

None of these three questions requires the PM to evaluate model architecture or write code. They require knowing what to ask and who to ask it of — which is precisely the technical fluency this course has been building without ever asking a PM to become an engineer.

Phrase feasibility questions so an ML/eng lead can answer in one sitting
"Is this feasible?" is a bad question — it's too broad for anyone to answer quickly, and it invites either a reflexive "sure, probably" or a reflexive "that's really hard," neither of which is useful. A good feasibility question is specific and checkable in the room: "does labeled data for X exist, and roughly how much," "what's the latency budget and how many model calls does this chain need," "which external systems does this touch and have we confirmed access." Bring these three questions into every feasibility conversation and you'll get answers you can actually act on, instead of a vibe.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers Red Flags vs. Normal, Workable Risk, Running the Triage and Scoring the Result, Build It, What to Practice — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.

Key terms in this lesson

Latency