Use-case selection
The feasibility triad — value, error tolerance, data — plus prototype-prompting: the AI PM's superpower of testing the risky assumption in an afternoon for free.
AI discovery adds one genuinely new instrument to the PM toolkit and one new axis to prioritization. The axis first — every candidate use case scored on the feasibility triad:
- Value density: how often does the moment occur × how much does it matter each time? High-frequency/low-stakes (draft assistance) and low-frequency/high-stakes (fraud flags) can both clear the bar; low-frequency/low-stakes never does, no matter how good the demo feels.
- Error tolerance of the workflow — not of the model: does a human review naturally (drafts)? does the workflow verify downstream (suggestions a user picks from)? or does the output act directly (sends, charges, blocks)? The same model quality is shippable in the first workflow and negligent in the third. PMs who scope AI features into tolerant workflow positions ship years earlier than PMs who wait for intolerant positions to become safe.
- Data & grounding reality: what does the feature need to know, and does that exist somewhere accessible, current, and permitted? The proactive-delivery feature needs carrier tracking data (exists, current) + order-customer linkage (exists — resolved identity, in fact; Harbor Lane's data-foundations work paying product dividends) + delay-pattern history (exists, unlabeled — a cost, not a blocker). Features whose data column reads 'we'd need to start collecting' are next-year features wearing this-quarter costumes.
Prototype-prompting: test the risky assumption for the price of an afternoon
The new instrument: for most AI features, the riskiest assumption — 'can a model actually do this well enough?' — is testable by a PM, in a chat window, before any engineering. Assemble 15-20 real examples of the input (real delayed-order data, real customer context — sanitized per policy), write the feature's core prompt yourself (AI Foundations skills suffice; Prompt Engineering skills shine), and look at the outputs against your quality sketch. An afternoon of this yields one of three findings, each worth weeks: clearly works (discovery proceeds to the harder questions), clearly doesn't (killed for free — the highest-ROI outcome in product management), or works with caveats (the caveats become your spec's edge cases and your eval set's seed — you've started Module 3 by accident). No other product discipline lets the PM personally retire the core technical risk this cheaply; not using it is malpractice.
'Write the core prompt yourself' is the step no-code PMs skip because it sounds like engineering — it isn't. Here is exactly what Dana pastes into a chat window for the proactive-delivery-resolution feature: a role, the delivery-exception context, the task, the constraints (the non-goals and the miss behavior), and a fixed output format. This is the feature's core logic, in English:
You are Harbor Helper, Harbor Lane's support assistant. A customer's order has hit a delivery exception (delay, misroute, or failed delivery) that our systems detected before the customer contacted us. Your job: decide whether to proactively message this customer, and if so, draft the message plus one resolution they can accept in one click. Context you're given: - Order + item summary, order value, customer tenure - The exception: type, carrier status, days late vs. promised - Whether the customer has contacted support in the last 24h Task: Return a decision and, if messaging, a draft. Constraints: - Do NOT message if the customer contacted support in the last 24h (a human owns that conversation). - Do NOT message for delays under 1 day past the promised date. - Offer exactly ONE resolution the customer can one-click accept (reship, refund, or expedited replacement) — pick the one that fits the exception. - Voice: warm, brief, no groveling, no over-promising a date we don't control. - If confidence is low or data is missing, choose action = STAY_SILENT and say why. Output format (exactly this): ACTION: MESSAGE | STAY_SILENT | ROUTE_TO_HUMAN REASON: <one line> MESSAGE: <the customer-facing draft, or n/a> RESOLUTION: <the one-click offer, or n/a>
Notice what's here: every scope-contract non-goal ('don't message in the last 24h') and every miss path (STAY_SILENT / ROUTE_TO_HUMAN) is a line the PM writes. The prompt is where the spec becomes testable — and it's plain English, not code.
Now run it on real-shaped inputs and read the outputs against your quality sketch. Three of Dana's 20:
- Input: Order #4471, $58, 3-year customer; carrier shows package stuck at a hub, 2 days late; no recent support contact. → Expected:
ACTION: MESSAGE/ a warm two-line note acknowledging the stuck package /RESOLUTION:expedited replacement. (The clean case — this is what 'works' looks like.) - Input: Order #4490, $210, first-time customer; failed delivery, 1 day late; customer called support 3 hours ago. → Expected:
ACTION: STAY_SILENT/REASON:recent human contact — non-goal honored. (If the model messages here, you've found a real bug before a single line was built.) - Input: Order #4502, $12, delay of 6 hours, still within the promised window. → Expected:
ACTION: STAY_SILENT/REASON:under the 1-day threshold, no exception to surface. (The 'don't cry wolf' case — the one PMs forget to test until it spams a customer in production.)
Your 20 hand-picked examples are cleaner, more typical, and more charitable than production traffic — the same pilot-to-scale discount the strategy course applies to ROI applies to your prototype's quality impression. Prototype findings are directional evidence for proceed/kill, never quality claims for ship. The gap between 'worked on my 20' and 'works at p95' is exactly what Module 3's evals exist to measure — and forgetting that is how PMs end up promising eval scores their feature will never see.