DiscoveryEvolved from: Jobs-to-be-Done
Jobs-to-be-Done (Agent-Aware)
Model customer progress through the functional, emotional, and social jobs they hire a product to perform. Extended in AI-era practice to include the jobs an agent performs on the customer's behalf, with explicit delegation boundaries.
When to Apply
- Entering a new market or segment where problem framing is unclear
- Evaluating whether an AI capability should be assistive or autonomous
- Reframing a stagnating product around unmet outcomes
AI-Era Notes
Separate the human's job-to-be-done from the agent's job-to-be-delegated. Document escalation triggers where the agent must return control. Capture the trust threshold required before customers delegate irreversible actions.
Common Antipatterns
- Using JTBD as a marketing exercise without evidence
- Assuming AI can perform emotional or social jobs without user consent
Pairs With
Opportunity Solution TreeContinuous Discovery
DiscoveryEvolved from: Continuous Discovery (Torres)
Evidence-Weighted Continuous Discovery
Weekly touchpoints with customers, structured around opportunities and assumptions. Modernized with explicit evidence provenance, AI-assisted synthesis, and human validation of every AI-generated claim.
When to Apply
- Product teams shipping regularly but uncertain about impact
- Enterprise contexts where customer access is gated and precious
- Any environment where AI synthesis of research is being introduced
AI-Era Notes
AI can accelerate transcription, clustering, and pattern surfacing — it cannot replace direct customer contact. Enforce source citations on every AI-derived insight and require human review before an insight influences prioritization.
Common Antipatterns
- Replacing interviews with AI persona simulation
- Losing verbatim quotes and provenance in summarization
- Running discovery without a decision it will inform
Pairs With
Opportunity Solution TreeJTBD
StrategyEvolved from: Opportunity Solution Tree
Opportunity Solution Tree (AI-Branched)
Structure work as outcomes → opportunities → solutions → experiments. Extended with explicit branches for AI-native, agentic, and human-in-the-loop solution paths, each with distinct risk and evaluation requirements.
When to Apply
- Translating a strategic outcome into a portfolio of bets
- Deciding whether a problem is best solved with UI, workflow, or agent
- Communicating trade-offs to executives without over-committing to solutions
AI-Era Notes
Tag each solution branch by autonomy tier and reversibility. AI-native branches inherit additional preconditions: eval set, guardrails, monitoring, and rollback authority.
Common Antipatterns
- Trees that stop at solutions and skip experiments
- Uniform treatment of AI and non-AI branches
Pairs With
Continuous DiscoveryOKRs
MeasurementEvolved from: OKRs
OKRs with Leading Model Metrics
Objectives and key results paired with both business outcomes and model performance indicators — eval scores, hallucination rate, deflection quality, human-override rate — measured alongside adoption and revenue.
When to Apply
- Quarterly planning where AI features materially affect the outcome
- Aligning cross-functional teams on both business and model quality
- Any AI feature where user harm is possible from silent regression
AI-Era Notes
Every AI-affecting objective should carry at least one leading model metric alongside the lagging business metric. Regression in model metrics is a leading indicator of business regression.
Common Antipatterns
- Treating eval scores as vanity metrics divorced from outcomes
- OKRs that measure only shipping activity, not customer or model health
Pairs With
Model Evaluation StandardNorth Star Framework
MeasurementEvolved from: North Star Metric
North Star Framework
A single leading indicator of long-term customer value, supported by input metrics that teams can move. In AI-era practice, includes explicit definition of how AI-generated value is counted or excluded.
When to Apply
- Organizations with fragmented metrics and unclear priorities
- Products where AI outputs may inflate activity without value
- Aligning multiple product lines around a shared measure of success
AI-Era Notes
Define whether AI-assisted actions count toward the metric and how. Undifferentiated counting inflates metrics without reflecting real customer value.
Common Antipatterns
- Choosing a metric that cannot be moved by the team
- Ignoring model-driven noise in the input metrics
PrioritizationEvolved from: RICE / WSJF
Risk-Adjusted RICE
Classic reach × impact × confidence ÷ effort scoring, extended with explicit risk terms for regulatory exposure, model risk, data sensitivity, and reversibility.
When to Apply
- Prioritizing across a mixed portfolio of AI and non-AI initiatives
- Regulated environments where reversibility materially changes cost
- Roadmap trade-offs requiring executive-visible justification
AI-Era Notes
Add a risk multiplier that penalizes low-reversibility, high-blast-radius, or model-dependent work. Shipping an autonomous capability is not equivalent to shipping a UI change.
Common Antipatterns
- False precision in confidence scores
- Prioritizing agent capabilities purely on reach without risk weighting
Pairs With
Opportunity Solution TreeOKRs
DeliveryEvolved from: Product Requirements Document
PRD + Eval Specification
Traditional PRD structure paired with a formal evaluation specification when the feature is model-driven: eval sets, ground truth, guardrails, and post-deployment monitoring criteria.
When to Apply
- Any capability powered by an LLM, model, or autonomous agent
- Regulated products requiring documented acceptance criteria
- Cross-functional work spanning product, engineering, and AI/ML
AI-Era Notes
Acceptance criteria for AI features must be expressed as eval sets, not prose. The eval spec becomes the contract between product intent and model behavior.
Common Antipatterns
- AI PRDs with prose acceptance criteria and no measurable evals
- Eval specs written after the model is already in production
Pairs With
Model Evaluation StandardAgent Autonomy Standard
DeliveryEvolved from: Architecture Decision Records
Architecture & Product Decision Records
Timestamped records of significant decisions with context, alternatives, and rationale. In AI-era practice, includes model, prompt, and dataset selection decisions with their evaluation basis.
When to Apply
- Decisions with long-term architectural or product consequence
- Model, vendor, or dataset selection for AI capabilities
- Any decision that establishes organizational precedent
AI-Era Notes
Model selection is a decision that expires. Every model ADR should include the eval basis for selection and a review trigger for re-evaluation as the model landscape changes.
Common Antipatterns
- ADRs written after the fact to justify a decision
- Missing model version and eval basis in AI-related decisions
Pairs With
PRD + Eval SpecModel Evaluation Standard
DeliveryEvolved from: Dual-Track Agile
Dual-Track Agile with AI Guardrails
Parallel discovery and delivery tracks, with explicit gates for AI-affecting work: eval readiness, guardrail implementation, and monitoring before any delivery track item can ship.
When to Apply
- Teams shipping continuously while validating new opportunities
- Organizations introducing AI features into existing products
- Environments requiring both learning velocity and shipping discipline
AI-Era Notes
Discovery-track AI experiments must never leak into production without crossing delivery-track gates. The evaluation set is the artifact that transitions between tracks.
Common Antipatterns
- Discovery-track prototypes shipped to real customers without evals
- Delivery track blocked waiting for perfect discovery
Pairs With
Continuous DiscoveryPRD + Eval Spec
AI GovernanceEvolved from: Model Evaluation
Model & Agent Evaluation Framework
Structured evaluation of model and agent behavior against curated eval sets covering success cases, safety cases, adversarial cases, and regression cases — with defined thresholds and rollback authority.
When to Apply
- Before production release of any model-driven capability
- Continuously across model, prompt, or context changes
- In response to observed customer harm or regulator inquiry
AI-Era Notes
Evals are not a one-time test; they are a first-class product artifact with version control, ownership, and review cadence equivalent to code.
Common Antipatterns
- Evals maintained by a single individual without redundancy
- No adversarial or safety cases in the eval set
Pairs With
PRD + Eval SpecAgent Autonomy Standard
AI GovernanceEvolved from: Access Control & Permissioning
Agent Autonomy & Boundaries
Classification framework for agent autonomy tiers, tool and data scoping, escalation criteria, and kill-switch procedures — ensuring autonomous action is bounded, observable, and reversible.
When to Apply
- Any agent capable of taking action beyond retrieval
- Customer-facing or regulated workflows involving automation
- Internal agents with access to sensitive data or systems
AI-Era Notes
Autonomy tier is a product decision, not a technical one. It carries governance, liability, and support implications that must be reviewed by legal and executive stakeholders.
Common Antipatterns
- Undocumented tool access granted to agents
- No defined threshold for human escalation
- Missing kill-switch authority or runbook
Pairs With
Model Evaluation FrameworkRisk & Compliance Checklist
AI GovernanceEvolved from: Fairness / Accountability / Transparency
Responsible AI Product Framework
Product-level operationalization of responsible AI principles: fairness testing, transparency artifacts (model cards, system cards), user disclosures, and appeal or override pathways.
When to Apply
- Products making consequential decisions affecting customers
- Regulated environments including healthcare, financial services, employment
- Any deployment requiring model cards or algorithmic accountability disclosures
AI-Era Notes
Model cards and system cards are becoming procurement requirements, not academic artifacts. Treat them as first-class deliverables owned by product.
Common Antipatterns
- Responsible AI relegated to a legal review at the end of the cycle
- Transparency artifacts that are inaccurate or out of date
Pairs With
Model Evaluation FrameworkAgent Autonomy Standard
AI GovernanceEvolved from: Interface Contracts / API Productization
The Tool Contract
Treat every tool, connector, MCP server, and computer-use surface an agent can invoke as a product. Each gets a written contract: purpose, allowed actions, data scope, autonomy ceiling, eval cases, owner, and kill path. Autonomy without a tool contract is an undocumented integration.
When to Apply
- Before wiring an agent to any internal system, SaaS connector, or MCP server
- When computer-use or browser agents can click, send, file, or pay
- When a tool catalog has grown faster than product ownership
AI-Era Notes
A tool grant is a product launch. Adding Slack send, Jira write, Salesforce update, or file-system access is a change of blast radius, not a config toggle. Re-attest the contract on any new tool, new scope, or new model that can call it.
Common Antipatterns
- Granting tools because the demo looked better
- Shared admin credentials used as agent identity
- Tool lists maintained only in engineering config with no product owner
Pairs With
Agent Autonomy & BoundariesModel & Agent Evaluation FrameworkPRD + Eval Specification
AI GovernanceEvolved from: Context Engineering / Information Architecture
The Context Contract
Treat the information environment an agent operates in as a product surface. Every production agent gets a written contract for allowed sources, freshness SLAs, forbidden corpora, memory scope, citation requirements, and a named owner of the context pack. A strong prompt in a weak context still fails.
When to Apply
- Before shipping any retrieval-augmented or multi-agent workflow to production
- When agents can read tickets, email, EMR/EHR notes, CRM records, or private docs
- When hallucination, stale policy, or cross-tenant leakage is a material risk
AI-Era Notes
Prompt engineering is a subset of context engineering. Product owns the context architecture: which sources are in-scope, how they are selected and compressed, how memory persists across turns, and what must be cited. Re-attest the contract when sources, embeddings, chunking, or memory policies change — those are product launches, not infra tweaks.
Common Antipatterns
- Dumping entire corpora into the window and calling it RAG
- Shared memory across tenants, cases, or customers without isolation
- No freshness SLA (agents citing expired policy as current)
- Citation optional for consequential answers
Pairs With
Agent Autonomy & BoundariesThe Tool ContractModel & Agent Evaluation Framework