Product Manager Toolkit

When your AI feature could be exploited (prompt injection, data exfiltration, jailbreaks, harmful content, fraud), especially if it connects to tools, sensitive data, or enterprise systems.

When you’re launching a production AI feature and need an “on-call plan” for safety, quality, or data incidents.

When an AI feature touches sensitive data, high-stakes decisions, or could be misused.

When users might overtrust AI outputs and you must set expectations (confidence, sources, limitations).

When failures would harm trust and you need clear behavior for refusal, fallback, and escalation.

When the model is not reliable enough to fully automate and a human must approve or correct outputs.

When you suspect the model may hallucinate, jailbreak, or produce unsafe outputs—and you need to test it before launch.

Management philosophy developed by Toyota that focuses on eliminating waste and improving efficiency in manufacturing. It is based on two main principles: Just-in-Time production, which means producing only what is neede

When you’re about to move from “prototype” to “production” (and again right before launch) to prevent shipping an AI feature that isn’t safe, measurable, or economically viable.

When you’re considering an AI feature and you’re not 100% sure you have the right data (or a viable plan to get it).

When you’re considering an AI feature and don’t know if you have the right data (or any usable data) to build it.

When you must compare models/prompt approaches and need a defensible way to decide what ships.

When you must choose a model/prompt approach and need a repeatable, defensible way to compare options.

When quality is subjective and you need a stable test set to prevent “it feels better” arguments.

When you’re choosing between vendors/models and need to balance quality, cost, latency, privacy, and lock-in.

When you’re launching or sharing an AI capability and need to document intended use, limits, and risks.

When an AI feature is live (or about to go live) and you need to detect quality decay, drift, or abuse fast.

When you’re changing prompts/models/tools and need to ensure you didn’t quietly break performance.

When requirements are being interpreted differently by PM/Eng/QA and you need testable clarity.

When you’re building an AI feature for real and need full alignment on requirements, risks, and evaluation.

When users might overtrust the AI, or when inconsistent UI behavior (confidence, citations, refusals) would damage trust and adoption.

When the user journey is complex or multi-role and misunderstandings are causing bad requirements.

When your team lacks a shared process and work is getting stuck in handoffs or unclear stages.

When you want to run experiments without chaos—clear hypotheses, guardrails, and decision rules.

When engineering needs precise behavior, edge cases, and constraints beyond the PRD.

When you need primary customer evidence (not opinions) to validate needs, workflows, or pricing.

When scope is ballooning and you need the smallest version that can validate value.

When your team jumps to features too fast and you need to map problems → opportunities → solutions.

When you need quick alignment for a small bet before writing a full PRD.

When you’re pricing/packaging an AI feature or approaching launch and need to ensure margins won’t get destroyed by inference/tooling costs.

When you have a product/feature ready and need a plan to drive adoption in the target segment.

When a launch involves multiple teams and you need readiness, comms, and support aligned.

When users sign up but don’t reach “aha”—you need a path to value.

When you’re monetizing and need tiering that matches value + controls AI cost-to-serve.

When churn is rising or repeat usage is low and you need systematic retention levers.

When sales is involved and needs crisp positioning + objections + proof to sell confidently.

When regulation, privacy, policy, or macro trends could block/enable your product.

When you’re entering a market and need to understand competitive pressure and “why margins will/won’t get crushed.”

When you’re setting pricing/tiers and don’t know what customers will pay or what value metric fits.

When you need to justify that the opportunity is big enough to invest in (or to prioritize vs other bets).

When you’re deciding if growth is profitable—or you suspect the product can’t scale economically.

When launch is done but users aren’t “getting value” fast enough (activation is weak)

When you’re running tests and want to prevent moving goalposts after results show up.

When experimenting or shipping AI and you need to prevent harm, trust loss, or cost blowups.

When engineers ask “what do you want tracked?” and you need an event-level plan.

When teams disagree on what drives success or you need to diagnose why metrics moved.

When outcomes take time and you need early signals you’re on track.

When UX quality and trust matter as much as growth (common for AI assistants/copilots).

When you need quarterly alignment on outcomes and ownership across teams.

When you’re about to ship and want measurement/instrumentation ready on day one.

When a decision is blocked and you need a clear path to get it decided at the right level.

When leaders need status and decisions—fast, metrics-driven, and with clear asks.

When you need a recurring forum to review outcomes, reset bets, and make decisions.

When ownership is unclear and decisions/work keep stalling.

After a launch, incident, or miss—when you must learn and prevent repeats.

—

When alignment is fragile and you need to manage influence, incentives, and resistance.

When you have more work than capacity and need a consistent way to rank backlog items.

When you’re betting on something uncertain and need to test what could kill the idea early.

When deciding whether to integrate a vendor/model or build your own capability.

When you must choose between initiatives and need to justify ROI with costs + uncertainty.

When decisions keep getting revisited and you need a single source of truth for “what we decided and why.”

When stakeholders can’t agree on scope and you need to force “must vs nice-to-have” decisions.

When you have more work than capacity and need a consistent way to rank backlog items.

When stakeholders ask for AI and you need to determine if AI is actually the right solution.

When you’re locking the next quarter’s priorities and assigning owners, outcomes, and kill criteria.

When you need to communicate direction without committing to fake dates.

When your industry is highly competitive with shrinking margins, and you seek to create new market spaces where competition is irrelevant.

When launching a new business, refining an existing model, or exploring new market opportunities.

When you need a defensible differentiation and people keep saying “Competitor X already does this.”

Use this framework when you need to evaluate or shape a strategy for a business, product, or initiative and want to separate real strategy from vague goals, slogans, or ambition statements. It is especially useful before

When user needs are unclear, or users describe goals in messy, inconsistent ways.

When you’re trying to decide “which customer segment do we serve first?” (and you can’t justify it).

When success is being debated or you have too many metrics and no single “win condition.”

When you need exec buy-in and want to pressure-test clarity before spending engineering time.

When people are proposing solutions but you can’t clearly state the problem, who has it, and why it matters.

When you’re starting a new product/pivot and stakeholders are asking “what are we building and why?”

When you’re planning the next quarter/half and must choose 3–5 bets with clear tradeoffs and metrics.

When you need to clarify “why would anyone choose us?” or messaging feels feature-y and weak.