Feasibility & the scope contract

AI features have a scoping physics all their own: quality is highest where scope is narrowest (the model faces less variety), oversight is cheapest where actions are mildest, and user trust compounds from small kept promises. The scope contract that exploits this physics:

• v1 is the tolerant-workflow version of the vision. The proactive-delivery vision is 'Helper notices and resolves'; the v1 contract is 'Helper notices, and proposes — a resolution the customer one-clicks to accept.' Same value hypothesis, one workflow position safer: the accept-click is the human oversight, built into the UX instead of bolted onto the org. Ship there, earn the data and trust, and let v2's autonomy be a measured decision (the earned-autonomy ladder this course develops in Module 5, as a roadmap).
• Non-goals with teeth: not a wishlist parking lot but explicit refusals with reasons — 'v1 will not handle multi-order issues (identity linkage across orders is where our error map's expensive quadrant lives)'; 'will not message customers who contacted support in the last 24h (collision with human conversations — support team's veto, honored).' Each non-goal names the risk it retires. Non-goals without reasons get 'just quickly added' by week six.
• The scope contract includes the miss behavior (Module 1's lesson, now in writing): when the model's confidence is low, when data is missing, when the customer replies something unexpected — each gets a designed path (stay silent / route to human / fall back to the reactive flow). The percentage of traffic taking each path is a forecast in the PRD, not a surprise in the retro.

The cost model PMs forget (and CFOs remember)

AI features carry a marginal cost per use — tokens, retrieval, the occasional escalation to bigger models — which deterministic features trained PMs to ignore. Unit economics belong in the scope doc: cost per proactive resolution attempted (modeled from prototype token counts × volume forecast), against value per success (ticket avoided ~$4 handling cost + the CSAT/retention effect you'll estimate honestly with ranges). You don't need code to read the token counts: every prototype run shows them — the API console (or the assistant's own usage readout) reports input/output tokens and a dollar cost per call, so the 'cost per attempt' figure is a number you copy off the screen after running your 20 examples, not something engineering has to compute for you. At Harbor Lane's volumes this feature pencils easily — but the discipline of penciling it is what catches the features that don't (the always-on summarizer nobody reads at $3k/month), and the model choice within the feature (fast-cheap for detection, capable for message drafting) is a product decision with a bill attached. If you took the finance or strategy course: yes, same math, smaller units.