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.
Red flags vs. normal, workable risk
Not every identified risk should stop a feature — most risk is normal and workable, and treating every uncertainty as a blocker would stall the entire roadmap. The skill is telling apart a genuine stop-the-feature red flag from a risk that just needs a mitigation plan in the PRD.
Red flags that should stop a feature before a PRD gets written:
- The data the feature fundamentally depends on doesn't exist and can't be created within a reasonable timeframe or budget (the opening scenario)
- The latency budget is architecturally impossible with any known approach (a sub-200ms hard requirement for a task that needs a multi-step reasoning chain no matter how it's built)
- A required integration depends on a system or vendor that has explicitly refused access, or that legal/security has flagged as a hard blocker, not just a slow approval
Normal, workable risk that belongs in the PRD as a mitigation, not a roadmap-killer:
- The data exists but needs cleaning or relabeling — real work, but scopeable and estimable
- Latency is tight but achievable with a specific technical approach (a smaller model, caching, streaming partial responses) — this becomes a design constraint, not a blocker
- An integration is possible but requires coordination with another team's roadmap — this becomes a dependency to sequence around, not a reason to cancel
The distinguishing question for any risk: is there a knowable, estimable path to resolving it, even if that path is expensive or slow? If yes, it's a mitigation to plan for. If the honest answer from the technical partner is "there's no known way to close this gap" or "we've already tried and been told no," that's the red flag that should stop the feature before more time is invested.
An ML lead tells a PM: "The model we'd need for this feature would require every response in under 500 milliseconds, but the approach needs to retrieve from a database, run two sequential model calls, and do a verification pass — realistically that's 2-4 seconds no matter how we optimize it, and there's no way to restructure this into a single call without losing the verification step the feature depends on." Is this a red flag or a normal, workable risk?
The distinguishing test from the lesson is whether there's a knowable, estimable path to resolving the risk. Here, the technical partner has explicitly said there is no way to hit the latency requirement without cutting a capability (verification) the feature depends on -- that's not "tight but achievable with a specific approach," it's a stated architectural conflict with no known resolution as scoped. This is exactly the red-flag pattern: the feature as currently defined should be stopped or fundamentally rescoped (e.g., relaxing the latency requirement, or redesigning to drop or defer the verification step) before a PRD commits a roadmap slot to it. Throwing more budget at it doesn't resolve a stated "no known way," and the PM doesn't need architecture expertise to recognize that answer as a stop signal.
A PM asks a data lead about a proposed "flag emails likely to result in a customer escalation" feature. The data lead says: "We don't have a labeled dataset of past emails tagged as 'led to escalation' or not, but our support platform does log which tickets got escalated, and we could join that against the original email thread with about two weeks of data engineering work to build a labeled set." Is this a red flag or a normal, workable risk?
The distinguishing test is whether there's a knowable, estimable path to resolving the gap. Here, the data doesn't exist in its needed labeled form yet, but the data lead has identified a concrete, time-boxed way to create it (joining two existing data sources, ~2 weeks of work) -- that's exactly the "workable risk" pattern, not the red-flag pattern from the earlier root-cause-categorizer example where no such path existed. The PM's job is to make sure this two-week data engineering step is explicitly sequenced into the roadmap before the feature's other work begins, not to treat the current absence of labels as an automatic stop.
Running the triage and scoring the result
A feasibility and risk triage doesn't need to be a heavyweight process — the opening scenario's problem wasn't a lack of process, it was skipping the conversation entirely. A structured 30-45 minute conversation with an ML/engineering lead, walking through the three feasibility signals plus the red-flag test, produces enough signal to make a "yes, write the PRD," "yes, but with these mitigations scoped in," or "no, not as currently defined" call — and documenting that triage (not just having the conversation) is what makes the decision defensible later, the same way the TCO and model-selection matrices from earlier lessons made those decisions auditable rather than a matter of trust.