Must-Know Concepts

The AI PM Vocabulary Cheat Sheet

Before You Build Any AI Feature — Checklist

• Define your eval criteriaHow will you measure if this is working? What does "good output" look like?
• Map your failure modesWhat happens when the model hallucinates? Who is affected and how?
• Model the unit economicsEstimate token costs at 10k, 100k, 1M requests. Is the margin viable?
• Decide: fine-tune, RAG, or prompt onlyEach has different build time, cost, and accuracy profiles.
• Establish a monitoring baselineWhat metrics will you track in production? Who owns the alert?
• Run a red-team sessionTry to break your feature before users do. Document every failure.
• Write the "not for" statementExplicitly define what this AI feature should NOT be used for.

30-60-90 Day Plans

Path A · Traditional PM Transition

Path B · New Grad Entry

DARE — For Innovation Teams

Intellectual lineage: Eric Ries's Build-Measure-Learn loop (Lean Startup) + MLOps continuous feedback cycles. The core insight: in traditional product management, building was expensive, so you researched first. In AI-native product management, building is nearly free — so the constraint shifts from "can we build it?" to "are we building the right thing?" DARE is a decision system for that environment.

DARE Stage Deep-Dives

D — Decide First

What it replaces: The traditional discovery sprint — 3–6 weeks of user interviews before committing to a direction. In AI-native environments, building is cheap enough that conviction should come first and validation should follow immediately. You're not skipping research; you're sequencing it differently.

• Write your conviction bet in one sentence before opening any research tool. The constraint of one sentence forces precision — vague hypotheses produce vague signal.
• Use AI to synthesize competitive signals and surface contradicting data in under 2 hours. Look specifically for evidence that would kill your hypothesis, not confirm it.
• Set a decision deadline: by end of business today, you either commit to the hypothesis or kill it. Conviction without a deadline is just an opinion.

A — Act Before Ready

What it replaces: The Define and Design phase — wireframes, specs, design reviews, and the endless hand-off loop. In AI-native teams, the PM and engineer co-build a working surface together. Not a mockup. A working prototype deployed to real users.

• Set a 48-hour hard constraint. Whatever exists at hour 48 goes in front of a real user — no extensions, no "just one more thing."
• PM and engineer co-build in the same session using AI tools. The PM drives the UX logic; the engineer wires in the real backend. No hand-off: one synchronous build session.
• Define "real user" before the clock starts. Internal team members who know the goal do not count. A real user has no stake in you being right.

R — Read at Scale

What it replaces: Traditional usability testing and manual data analysis. In the AI-native stack, behavioral telemetry runs automatically, an AI agent synthesizes signal daily, and the PM reviews a summary — not raw data. The insight comes faster and is grounded in real behavior, not self-reported preference.

• Define your behavioral signal before deployment — not after. What specific action confirms your conviction bet? What action would disprove it?
• Deploy to a cohort of at least 20 real users with live telemetry from day one. No delayed data collection setups.
• Let an AI agent synthesize behavioral data daily and flag deviations from your expected signal pattern. Surprises are the signal.

E — Expand or Erase

What it replaces: The traditional staged launch and GA process — beta programs, launch plans, and high-stakes big reveals. In DARE, every deploy is already live. Expand means doubling down on what's working. Erase means killing clean and logging why.

• Define your kill threshold before you launch — a specific metric below which you erase, no negotiation. If you haven't defined it in advance, you'll rationalize staying alive.
• Expand means: double the cohort, increase investment, and write a 3-sentence "expand brief" stating what signal justified the decision.
• Erase means: sunset the prototype within 24 hours, write the kill note for the decision log, and redirect the team to the next bet. A PM who kills fast without ego is more valuable than one who rescues weak ideas.

05 — Own the Outcome

What it replaces: The sprint retrospective — a team ceremony that's often backward-looking, vague, and disconnected from individual PM accountability. Own the Outcome is a personal accountability loop. You document the bet, the signal, and the verdict — and you share it with your engineer.

• After every DARE cycle, write a 3-sentence outcome entry: the bet, the signal, the verdict. Date it. This is your compound interest.
• Review your decision log weekly — look for patterns in where your convictions were accurate and where they were wrong. Calibration improves with deliberate review.
• Share the log with your engineering partner. Transparency about reasoning — not just outcomes — is what builds trust over time.

DARE in Practice — Daily Habits

• Start every week with a written conviction betOne sentence. One hypothesis. What are you trying to prove this week?
• Kill any prototype that hasn't touched a real user in 5 daysInternal polish ≠ progress. Exposure to reality is the only progress metric.
• Maintain a decision log, not a PRDEvery decision: the bet, the signal, the outcome. Reviewed weekly.
• Run a daily demo — not a weekly sprint reviewIf you can build it in a day, you can demo it in a day.
• Run a weekly conviction auditScore your top 3 current bets: which has the strongest signal? Which should you kill?
• Share your decision log with one engineer per weekTransparency about reasoning builds faster trust than any 1:1 ever will.

DARE in the Wild — Linear's AI Issue Triage

ALIGN — For Enterprise Teams

Intellectual lineage: LLMOps lifecycle management + AgentOps governance principles. ALIGN applies enterprise-grade operational discipline to PM execution in mandate-driven environments. The core insight: in enterprise settings, the PM rarely chooses what to build — a business leader does. The PM's job is to translate a vague mandate into a deliverable outcome, navigate every constraint along the way, and close the loop with language the mandate-giver actually understands.

ALIGN Stage Deep-Dives

A — Anchor Intent

Pain it solves: Vague executive mandates that mutate as the build progresses, causing scope explosion. "Use AI to transform customer experience" can mean 47 different things to 12 different stakeholders. An unsigned, unmeasured mandate is a scope disaster waiting to happen.

• Schedule a "mandate excavation" session with the exec before writing a single ticket. Your job is to find the actual outcome they're driving — not the surface request. Ask: "What would have to be true 12 months from now for you to consider this a success?"
• Write the intent brief using the template below — one page, five fields. The "What This Explicitly Does NOT Include" field is the most important and most often skipped.
• Get explicit sign-off: email confirmation is sufficient and creates a paper trail. Verbal agreement is not sign-off.

L — Lay Constraints

Pain it solves: Discovering regulatory or integration blockers mid-build, after significant engineering investment. In enterprise environments, constraints are everywhere — legal, compliance, security, legacy integration, budget approval chains. Finding them in week 8 is expensive. Finding them in week 1 is strategy.

• Map constraints in three categories: hard blockers (will stop the build), soft blockers (add time and cost), and political blockers (require specific people to agree). All three are real constraints.
• Use AI to surface historical similar projects from your organization's delivery record. Every enterprise has a graveyard of initiatives that hit the same walls. Learn from them before you repeat them.
• Publish the constraint map to all stakeholders before sprint planning begins. Surprises found here are cheap. Surprises found in QA are career-defining.

I — Iterate Open

Pain it solves: Scope shifts triggered mid-build by stakeholders who weren't seeing progress and grew anxious. When executives don't see work happening, they fill the vacuum with new requirements. Weekly demos replace that anxiety with transparency — and make scope changes cheap to surface and cheap to redirect.

• Run a live demo every Friday — not a status email, a working demo. Even rough is better than polished slides.
• Make the demo link permanent and always live. Stakeholders should be able to check progress without scheduling a meeting.
• When a stakeholder requests a scope change during a demo, acknowledge it live and add it to the parking lot. Respond within 24 hours with a written decision: absorb, defer to Phase 2, or reject with rationale. Never let a scope request sit unacknowledged for more than 24 hours.

G — Gate Purposefully

Pain it solves: Bureaucratic sign-off processes that consume weeks and add no actual risk management value — committee reviews, approval chains where no one person is accountable, and governance theater that delays launches without improving them. ALIGN gates are fast, accountable, and time-boxed.

• Assign one owner per gate — not a committee. One person with a named email address. Committee ownership is no ownership.
• Define the gate question precisely: "Is the security posture acceptable for a limited-access beta?" — not "does everyone feel good about this?" A precise question gets a clear answer.
• Set a 48-hour SLA on every gate. If the gate owner doesn't respond in 48 hours, the gate passes by default — unless they explicitly request an extension. This forces accountability, not rubber stamps.

N — Normalize + Narrate

Pain it solves: Features ship but don't get adopted; engineering teams can't support what they built; leadership doesn't connect the shipped feature to the business outcome they mandated. Normalize creates institutional memory. Narrate closes the loop with the people who funded the work — in their language, not engineering language.

• Normalization: use AI to auto-generate runbook documentation from commit history, tickets, and sprint notes — on the day of launch, not weeks later. The best documentation is the documentation that actually gets written.
• Narration: write a 1-page Outcome Brief for the exec sponsor using their language — revenue, risk reduction, efficiency — not engineering language (features, endpoints, latency).
• Present the Outcome Brief in the same meeting where the mandate was originally given. Close the loop explicitly. The exec who gave you the mandate deserves to hear that it was delivered.

The Intent Brief Template

ALIGN in the Enterprise — Capital One's AI Credit Feature

DARE vs. ALIGN — Which One Is Yours?

The Trust Equation

Engineers and data scientists extend trust to PMs based on one simple criterion: does this person help me do better work, or do they create friction? Everything below is a variation on that question.

The AI PM ↔ Data Scientist Relationship

The Vibe Coding Collaboration Model

With vibe coding, the PM-engineer relationship is changing from a handoff model to a co-build model. Here's what that looks like in practice:

Prompting as Product Thinking — 5 Rules

• Constrain the output format firstTell the AI what shape the answer should take before asking the question.
• Include the "why" in your promptContext produces better output. "I'm a PM writing for a non-technical exec" changes everything.
• Use negative constraints explicitly"Do not include..." is as important as "Include..."
• Iterate in the open with your engineerShare your prompts with eng. It builds shared language and catches bad assumptions early.
• Document your best prompts as product assetsA great system prompt is a product decision. Version-control it like one.

The AI Stakeholder Landscape

The Agent-Generated Status Update

One of the most powerful applications of ALIGN's Agent monitoring layer is automated stakeholder communication. Here's the template your monitoring agent should generate weekly:

Handling the "Can AI Do That?" Meeting

Every AI PM will face the moment where an executive asks, in a meeting, whether AI can do something that sounds plausible but may be technically wrong, legally risky, or just a bad idea.

• Pre-brief your key stakeholder before every major reviewNo executive should hear a surprise in a meeting. Walk them through it 24 hours before.
• Separate "what AI can do" from "what we should build"Feasibility is an engineering question. Priority is a product question. Own the latter.
• Never let an exec set an AI deadline without a feasibility rangeCommit to a range, not a date. "Q2 to Q3 depending on data availability" beats a promise you can't keep.
• Document all scope decisions in writing within 24 hoursVerbal agreements dissolve. Written ones become your protection when scope creep arrives.

Portfolio Components

The GitHub-Style Portfolio Structure

Building Credibility Without a Title

• Publish one AI product teardown per monthConsistent, public, opinionated analysis builds a reputation faster than any title.
• Contribute to open-source AI tools you useEven documentation improvements. Shows technical fluency and community engagement.
• Do one public DARE cycle on a real product problemDocument it from conviction to signal. Tag the company. People notice.
• Get specific about your domain"AI PM" is too broad. "AI PM focused on developer tools" is a positioning statement.
• Build in public, not in stealthThe act of sharing your process is more credibility-building than the artifact itself.

Resume Positioning

The AI PM Interview Loop

The 10 Questions You Must Nail

• "Tell me about an AI feature you shipped or built."Lead with the eval criteria you set, not the feature. Shows maturity.
• "How do you measure the quality of an AI feature?"Answer with a specific eval framework. Never say "user satisfaction" without a measurement method.
• "What's the biggest risk in the AI product you're most excited about?"Show you can see risk clearly, not just opportunity. This is rare.
• "Walk me through how you'd prioritize AI features on a roadmap."Use a framework: signal quality × implementation cost × strategic fit. Show the trade-offs explicitly.
• "How do you work with data scientists?"Specific story. Show you speak their language — evals, model trade-offs, feasibility ranges.
• "What would you NOT build with AI?"This is a judgment test. Have a strong, defensible answer. Weak answer = no conviction.
• "How do you handle a hallucinating AI feature post-launch?"Incident response mindset: detect, contain, communicate, fix, prevent. Know the order.
• "What's your take on vibe coding's impact on PM?"This is a values question. Don't hedge. Have a real POV. Reference DARE or ALIGN.
• "How would you explain a model's limitations to a non-technical exec?"Practice a 90-second explanation. Use an analogy. Never use jargon.
• "What would you build in your first 30 days?"Answer with a question first: "Can I understand the current signal backlog before I commit?" Shows judgment.