Background

Product context fragments across teams, tools and planning cycles. Decisions then depend on whoever remembers the history. Product 360 connects the evidence, plans and operating routines needed to manage a product across its full life, with visible owners and review dates.

Key takeaways

1. Define your scope with neighboring PMs. Cover customers, capabilities, teams and revenue. Resolve ownership disputes before building documents that assume different boundaries.

2. Organize the nine dimensions into Direction, Delivery and Durability. Check customer, strategy, business, build, measure, go-to-market, operations, lifecycle and leadership for missing evidence.

3. Start with the twelve-artifact spine and one index. Give every artifact an owner, audience, purpose and last-reviewed date. Mark gaps explicitly.

4. Separate durable artifacts, reviewed at strategic changes, from living artifacts, reviewed on a cadence, and event artifacts, archived after a decision.

5. Audit links between strategy, roadmap, pricing and positioning. Resolve contradictions through an explicit decision, and update the affected artifacts together so teams work from consistent choices.

6. Schedule weekly metrics, monthly roadmap and quarterly business reviews. Record decisions, alternatives, approvers and reasons. Adjust rituals that produce no useful decisions.

7. Use approved AI tools to draft and compare sources. Verify claims and numbers. For AI products, add evaluations, cost models, model registers and risk assessments.

Background

A product can work technically and still fail because the problem, customer or buying process was misunderstood. Enterprise products add buyers, reviewers and procurement to the user relationship. Discovery must explain each role’s needs and identify which assumptions deserve a test first.

Key takeaways

1. Write customer, problem and solution hypotheses separately. Add a buying-process hypothesis. For each, name the evidence that would change your view and the smallest useful test.

2. Map assumptions by desirability, feasibility, viability and adoptability. Test important assumptions with little evidence first, including security approval and procurement constraints.

3. Use switch interviews to identify push, pull, anxiety and habit. Write job stories around situations and desired progress. Use outcome scoring when prioritizing unmet needs at scale.

4. Include end users, champions, economic buyers, technical evaluators and procurement in the persona set. Label proto-personas as hypotheses and record research evidence and review dates.

5. Connect buying and usage journeys at first value. Interview about specific past behavior. Treat commitments of time, reputation or money as stronger evidence than compliments.

6. Keep weekly customer contact and trace insights to source quotes. Use AI for preparation and synthesis. Label synthetic responses as hypotheses and validate them with real customers.

Background

Teams often maintain a vision and quarterly goals without connecting them. A release can meet its deadline while customer behavior stays unchanged. Product goals need a clear path from the intended customer change to measurable inputs that individual teams can influence and own.

Key takeaways

1. Describe the lasting customer change in a short vision. Test it against Pichler’s qualities: inspiring, shared, ethical, concise, ambitious and enduring. Let strategy change beneath it.

2. Expand the statement into a vision board and narrative. Use the internal FAQ to expose feasibility, security, procurement, cost and revenue questions before committing.

3. Map the customer’s value stream, capabilities, segments and business model. Resolve ownership gaps and overlaps before assigning one team to each metric-tree input.

4. Choose a North Star that counts customer value. Define the population, event, period and source. Add three to five inputs and test their historical relationships.

5. Write key results as who does what by how much, with sourced baselines. Label OKRs committed or aspirational. Keep delivery dates in the delivery plan.

6. Check confidence weekly and review inputs monthly. For AI products, track evaluation quality, wrong actions, trust and cost per outcome. Record thresholds and responses when guardrails fail.

Background

Enterprise roadmaps absorb requests from customers, sales, partners and executives. Without a stated challenge and investment policy, each request competes on urgency or influence. Prioritization and roadmap communication need an explicit strategy, with choices that survive the next escalation and evidence that can change them.

Key takeaways

1. Write Rumelt’s diagnosis, guiding policy and coherent actions. Use Playing to Win to choose markets, customers, channels, capabilities and management systems. State three requests you will refuse.

2. Turn strategic choices into testable hypotheses. Use Biddle’s delight, hard-to-copy and margin-enhancing lenses, then pair each strategy with a proxy metric and tactics.

3. Choose a scoring method for its context and biases. In B2B, express reach in accounts or annual recurring revenue. Show evidence quality and cost of delay.

4. Separate raw requests, customer opportunities and ordered delivery work. Give requests visible status. Keep the delivery backlog short, archive stale items and publish a capacity split.

5. Use now, next and later to express confidence. Date commitments after discovery and engineering estimates. Keep bets undated and exploration free of delivery promises.

6. Generate audience views and changelogs from one roadmap. For AI work, use outcome goals, capability thresholds on your evaluations, and capacity for model migration. Track external deadlines to sources.

Background

A realistic prototype can expose usability and trust problems before delivery. It can also look ready while ignoring security, reliability and operational work. Product teams need an explicit risk question, a suitable test and a clear record of the decisions that production must implement.

Key takeaways

1. Name the risk: value, usability, feasibility or viability. State the participant, situation and observable behavior. Label what the prototype ignores before presenting it to stakeholders.

2. Choose the lowest useful fidelity. Adjust content, visuals and interactivity separately. Expert users need credible domain content. Engineers own prototypes that touch real data or traffic.

3. Match the method to uncertainty. Use concierge work to test value, Wizard of Oz to test an automated experience, and historical-case hybrids to test AI output quality.

4. Recruit three to five participants per distinct role per qualitative round. Write realistic tasks without interface clues. Pre-register proceed, iterate and stop signals. Retest after fixing severe findings.

5. Staff from net capacity after support, on-call and migrations. Name team types, interaction modes, appetite and the binding constraint. Add applied AI expertise for evaluation risks.

6. Use a PR/FAQ for the investment choice. Begin the PRD with one page, then add tested journeys, acceptance criteria, permissions, reliability, rollout and decisions. AI features need failure states, evaluations and cost limits.

Background

Post-launch behavior tests the assumptions discovery could only explore. Enterprise analytics needs account-level identity, suitable usage windows and methods that work with small samples. AI features also require ongoing quality checks because accepted answers can be wrong and model changes can alter behavior.

Key takeaways

1. Write launch questions and criteria before release. Map each question to metrics, events and properties. Use consistent event names, account identifiers, actor type and documented privacy rules.

2. Define activation as first customer value. Build account-level funnels across roles. Read retention in cohorts, using meaningful actions and windows matched to how often customers need the product.

3. Combine product-market-fit survey responses by persona with retention curves. Report respondent counts and investigate disagreement between stated enthusiasm and actual usage.

4. Before an experiment, specify the Overall Evaluation Criterion, guardrails, unit, sample size, duration and stopping rule. Check sample ratio mismatch and data quality before reading effects.

5. Calculate the minimum detectable effect. When volume or safety prevents randomization, choose a suitable rollout or observational method and state the assumption limiting its causal interpretation.

6. Pair AI acceptance with reversions, downstream outcomes or expert-graded samples. Track versions, latency and cost per task. Review production errors, record assumption verdicts and assign the next dated tests.

Background

Product execution connects customer intent to engineering decisions under constraints. Enterprise work adds permission boundaries, reliability obligations and contractual dates. Coding agents can increase change volume while leaving review capacity constrained. Clear ownership, small release slices and shared quality rules make the work easier to plan and verify.

Key takeaways

1. Agree ownership of the problem, outcome, order, solution, estimates and quality. Use refinement to resolve tradeoffs. Keep evidence available to engineers making implementation choices.

2. Map the full journey across users, administrators and approvers. Build the smallest end-to-end walking skeleton first. Write stories as card, conversation and confirmation.

3. Use observable Given-When-Then criteria. Include tenancy, permissions, errors and audit behavior. Keep readiness criteria short and require completed acceptance checks before work counts as done.

4. Plan net capacity after leave, on-call and support. Reserve unplanned work and review capacity from history. Forecast dates as ranges with confidence and scope levers.

5. Separate defect severity from business priority. Set release bug bars and internal service levels. Rank debt by interest and how often the affected code changes.

6. Separate deployment from release with flags. Define rollout stages, exit criteria, rollback and kill-switch ownership. For AI, add evaluation thresholds, cost limits, staged model changes and human code review.

Background

Technical product choices become customer promises: compatibility, access, reliability, cost and recovery. These promises can be expensive to reverse. Product managers need enough fluency to identify the tradeoffs, involve technical specialists early and judge experiment evidence without delegating the product decision to an analysis tool.

Key takeaways

1. Define who consumes the capability: a user, developer, internal team or agent. Assess value, usability, feasibility, viability and adoptability before choosing the discovery and delivery approach.

2. Run a pre-mortem with engineering, security, support and commercial partners. Use product fit, economics, process failures and feature-factory symptoms as prompts. Assign top risks owners and early signals.

3. Read designs for goals, alternatives, interfaces, security, residency, cost and reversibility. Understand the system diagram and data entities. Preserve major decisions in architecture decision records.

4. Treat APIs and MCP servers as product promises. Define compatibility, versions, scopes, limits, service objectives and revocation. Make human accountability and permitted agent actions explicit.

5. Before experiments, specify the hypothesis, primary measure, guardrails, randomization unit and stopping rule. Check assignment ratios first. Read effect sizes and confidence intervals, then planned segments.

6. Give the AI harness the plan and metric definitions. Demand exclusion counts and validity checks. Reconcile headline numbers independently. For AI features, establish evaluation quality before testing customer value.

Background

Growth strategy depends on acquisition costs, customer value and the path from interest to revenue. Enterprise buying crosses people, systems and long time periods. Blended metrics and incomplete tracking can direct investment toward the wrong segment, while product bottlenecks prevent new demand from converting.

Key takeaways

1. Define customer acquisition cost, lifetime value and payback with owners, sources and periods. Report each by segment and motion. Include partner economics and update payback when margin changes.

2. Define product-qualified leads and accounts through experienced value. Check whether those behaviors predict conversion. Measure activation and time to value through trials and proofs of value.

3. Map each journey stage’s entry rule, persona, conversion, time, source and observability. Include peer conversations and AI-assistant research, then estimate these through interviews and self-reported attribution.

4. Audit attribution rules for selection bias, missing touches, double counting and person-versus-account errors. Use credited conversions for optimization with clear causal limits.

5. Combine marketing mix modeling for allocation, attribution for campaign tuning and experiments for incrementality. Pre-agree sample size and decision rules. Report wide intervals honestly at low B2B volume.

6. Improve the binding product constraint before buying more demand. Audit AI answers about your product. Verify AI-generated calculations, definitions and joins, and state what evidence would reverse the investment decision.

Background

The installed base can expand while parts of it deteriorate. Renewal dates delay the financial signal, multiple people shape each account’s decision, and a few large customers can dominate averages. Retention analysis needs segment-level behavior, economics and customer evidence to reveal where investment will help.

Key takeaways

1. Agree churn, activity, cohort-start and revenue definitions with finance and customer success. Analyze contract and usage survival separately. Keep current customers as censored observations that are still active.

2. Read cohorts by age, start period and calendar events. Segment before attributing higher tenure retention to stickiness. Customer differences can create a sorting effect without individual loyalty improving.

3. Report net revenue retention, gross revenue retention and logo retention together. Reconcile expansion, contraction and churn to finance. Read other companies’ definitions before using benchmarks.

4. Compare lifetime value by segment and channel using contribution margin after inference and service costs. Weight by survival, cap expansion and report ranges, sensitivities and payback.

5. Back-test health scores against renewals. Remove signals that arrive after the decision to leave. Run randomized retention pilots to identify accounts whose behavior the intervention can change.

6. Link voice-of-customer themes to account revenue and retention. Validate AI coding against human labels, including theme shares, negation and sarcasm. Keep source quotes and use approved systems for customer text.

Background

Customer findings can disappear between research and delivery. Requirements can also shape behavior without anyone examining why. Enterprise buying adds multiple decision-makers and veto holders. Insight work must connect evidence to an explanation, a product decision and a measurable result while preserving user choice.

Key takeaways

1. Write insights with who, observed behavior, evidence, explanation, tension, implication and confidence. Test that each is non-obvious, explains behavior, has evidence and implies action.

2. Map every buying-group role’s job, fear, proof needs and veto. Treat risk reduction, reversibility, security evidence and internal business-case materials as product decisions.

3. Use behavioral effects with their evidence status attached. Measure local outcomes. Give every default an owner, customer rationale and measure, distinguishing preference from default persistence.

4. Review influence against four tests: user benefit, defensible disclosure, symmetric choices and truthful information. Obtain appropriate legal review for billing, consent, data and relevant markets.

5. Link requirements to insight IDs or named drivers. Give every high-confidence insight a build, defer or reject decision. Add acceptance criteria, success measures and feedback to confidence.

6. For AI, design calibrated trust with visible evidence and correction paths. Measure wrong acceptance alongside acceptance. Relaunch for real perception changes, with clear existing-customer plans and baselines set before launch.

Background

Delivery methods shape feedback, capacity and coordination. A company-wide method can fit some teams while obstructing others. Enterprise commitments still require credible forecasts and service expectations. As coding agents increase implementation capacity, review and verification can become the work states that most constrain delivery.

Key takeaways

1. Classify recent work by uncertainty, planned versus unplanned demand, dominant risk and external commitments. Choose a method per team with a rationale and a trigger for review.

2. Use Scrum for regular inspection, Kanban for interrupt-driven flow and appetite-bounded cycles for fixed-time bets. Keep discovery and delivery concurrent within the same team.

3. Share North Star, quarterly outcomes, customer-facing completion criteria and reviews across teams. If PM and Product Owner responsibilities split, give backlog decisions direct customer evidence.

4. Track work in progress, throughput, item age and cycle time. Set service level expectations from history. Show waiting in review and verification as explicit states.

5. Use RICE with one relevant reach unit, evidence-based confidence and effort through safe adoption. Check deadline-sensitive work with cost of delay and document overrides.

6. Remove avoidable dependencies before adding coordination frameworks. For coding agents, use smaller batches, review limits, protected tests and evaluation gates. Put permissions, human review and cost checks in the working agreement.

Background

A buyer needs a credible reason to pay more for a better outcome than their current alternative provides. Product investment must also earn an acceptable return for the supplier. AI increases the importance of including variable costs, oversight and uncertain benefits in both value calculations.

Key takeaways

1. Build a value proposition canvas for each buying-group role, including partners. Rank measurable jobs, pains and gains. Link each capability to the need it addresses and record evidence strength.

2. Estimate economic value to the customer from the real, discounted alternative. Add differentiated benefits and subtract switching, training, oversight and failure costs. Use customer inputs and risk adjustments.

3. Use fully loaded cost as the floor, the competitive alternative as reference and customer value as the ceiling. Choose the share captured according to strategy, uncertainty and lifecycle.

4. Ask finance for the discount rate. Review net present value across scenarios, the realistic do-nothing baseline and assumptions that change the result. Stage investment around evidence gates.

5. Make customer ROI tools editable, sourced and clear about modeled results. Include full ownership costs and compare the same value drivers with actual results after the sale.

6. Define billable AI outcomes, exclusions, disputes and credits before setting price. Test margin at expected usage. Use clear terms, genuine options, pilots and spend controls to reduce buyer uncertainty.

Background

Investment requests depend on market size, competitive alternatives and financial returns. Each can look credible while resting on weak assumptions. A useful case makes the inputs traceable and shows which uncertainties could change the funding decision.

Key takeaways

1. Calculate total, serviceable and obtainable markets separately. Count accounts and annual value by segment. Check the result against top-down or job-based estimates and explain disagreements.

2. Derive obtainable market from sales and partner capacity, ramp, win rates, contract value and expansion over a stated period. Define segments by trigger, job and buying motion.

3. Map direct rivals, indirect rivals, substitutes and doing nothing. Use buyer-chosen landscape axes. Keep competitor profiles and battlecards sourced, dated and assigned to an owner.

4. Use Porter’s Five Forces to explain pricing power and margin. For AI products, examine model-provider power, inference costs and customers’ ability to assemble substitutes.

5. Build a sourced assumptions register with finance. Compare three scenarios, rank sensitivity, use comparable past projects and set milestone-based kill criteria for the largest uncertainties.

6. Have AI collect, draft and monitor evidence. Check every consequential number and competitor claim on a primary source. Use approved tools for customer and commercial data.

Background

Partners, developers and customers may already create value around your core product. That ecosystem needs deliberate incentives and governance. At the same time, marketplaces and AI hosts control distribution and rules your product depends on. Platform strategy addresses both relationships.

Key takeaways

1. Map owners, providers, producers and consumers. Write the core interaction as producer, value unit, filter and consumer action. Use it to guide platform design.

2. Test every network-effect claim by type, mechanism and evidence. Separate cross-side effects, data-enabled learning, scale and switching costs. Measure where benefits plateau.

3. Find the smallest viable atomic network and the hardest participants to attract. Solve their problem, build early complements where necessary and expand from a working network.

4. Give builders both technical access and a reason to invest. Define rewards, certification, enforcement, appeals, versioning and deprecation notice before opening each stage.

5. Map every marketplace, suite, cloud and AI host. Record fees, benefits, change rights, envelopment risk and an exit or multihoming plan with an accountable owner.

6. Choose host, complement or both for each agent ecosystem. Track interaction failure, engagement, match quality and harmful effects. Verify AI-assisted assessments against customer and builder evidence.

Background

Price determines which customers can buy, how they use the product and whether growth earns a margin. Agents complicate that relationship because work can increase while seats decline, and every task can incur inference cost. Packaging and billing therefore require product decisions.

Key takeaways

1. Interview economic buyers about current costs, valued capabilities, payment units, budget source and predictability. Triangulate structured pricing research with actual deals and customer commitments.

2. Score value metrics for value alignment, adoption, flexibility, growth, metering, budgetability and dispute risk. Combine a base fee with variable pricing where one unit cannot satisfy them.

3. Build each tier for a named segment with purchase-driving features. Move narrow needs into add-ons. Keep essential safety and compliance controls available wherever the capability requires them.

4. Calculate break-even volume before changing price. Set a baseline, leading and lagging indicators, guardrails, confounders and kill criteria. Review outcomes at 30, 90 and 180 days.

5. Track the pocket price waterfall, including free inference. Set approval rules and exchange discounts for commitments. Protect unit rates and review effective prices with finance and sales.

6. Define billable outcomes, exclusions, verification, evaluation windows, audit trails and disputes. Specify harm credits, alerts, caps and overages. Shadow-bill existing customers before migration.

Background

A product can create value while competitors steadily erode its returns. Features, model access and growing datasets may offer benefits without lasting barriers. Defensibility requires examining why a capable rival cannot reproduce the advantage and whether that protection is strengthening.

Key takeaways

1. Assess Helmer’s seven Powers: scale, networks, counter-positioning, switching costs, branding, cornered resources and process power. Mark each present, emerging or absent with evidence for benefit and barrier.

2. Use Porter’s activity-system lens. Look for reinforcing choices across workflow, data, pricing, channels and trust that a rival would need to copy together.

3. Test disruption precisely: an initially worse, cheaper or simpler entrant serves low-end buyers or nonconsumers, improves toward mainstream needs and uses an unattractive incumbent business model.

4. Test AI advantages for exclusive context, hard-to-obtain outcome labels, workflow depth, trust and learning processes. Separate these from shared model access and easily matched integration breadth.

5. When a feature becomes a commodity, choose a response: own a larger outcome, bundle, reprice, open the complement, or harvest and retire. Record the tradeoff and migration implications.

6. Choose one or two barriers to deepen. Put the work and measures on the roadmap. Review widening or narrowing annually and validate sourced competitive signals monthly.

Background

Connected tools can return numbers quickly, yet vague questions leave crucial choices to the model. Product decisions require explicit options, reliable definitions and evidence that could change the plan. Good analysis begins with the choice and ends with an accountable decision.

Key takeaways

1. Name the options, decision maker and deadline. Identify whether the decision is reversible. Use a full memo for consequential commitments and a lighter process for bounded tests.

2. For each question, write the answer that would change your choice. Select evidence and precision accordingly. Remove analysis whose possible results all lead to the same action.

3. Define population, time window, metric and comparison. Supply governed definitions or write a metric card. Require the harness to return filters, assumptions and record counts.

4. Replace cumulative totals with rates, cohorts and account-level distributions. Add a guardrail to every target. Combine quantitative evidence with conversations with customers behind the numbers.

5. Check at least one result against a trusted source. For AI autonomy, examine wrong acceptance, severity and cost per task alongside adoption and evaluation results.

6. Record confidence, dissent, assumptions, tradeoffs and kill criteria when deciding. Review the process using information available then, separately from whether the eventual result was favorable.

Background

Enterprise product evidence spans systems with different purposes, owners and account structures. Reports become inconsistent when each tool recomputes its own metrics. A source map, governed definitions and a focused report set make both human and AI analysis easier to trust.

Key takeaways

1. Inventory telemetry, CRM, billing, support, surveys, calls, reviews, market data, finance and AI traces. Record purpose, limits, grain, freshness, owner and known traps for each source.

2. Assign ownership of account mappings across tenants, subsidiaries, partners and billing entities. Document failures and exclusions before using cross-source comparisons to make decisions.

3. Create a report catalog with questions, cadence, audience, owner and decision. Start with a few useful reports. Archive duplicate dashboards with pointers to their governed replacements.

4. Run the weekly review from controllable inputs to outputs and financials. Show every metric, discuss exceptional movement and log unknown causes for follow-up rather than improvising explanations.

5. Give each metric a definition, version, owner and steward. Mark definition changes on charts. Finance should co-own metrics used for revenue, billing or cross-functional financial reporting.

6. For AI products, combine capability and regression evaluations, production failure analysis and cost per successful outcome. Require source provenance, freshness checks and account-level reconciliation before consequential decisions.

Background

An AI harness can retrieve and analyze data before anyone checks the business meaning. Wrong windows, definitions, joins and access scopes can produce convincing errors. A repeatable process makes analysis safer, reproducible and useful for decisions rather than merely faster to produce.

Key takeaways

1. Write the decision, audience, deadline and analysis question first. Specify population, dates, time zone, grain and metric definitions. Choose a prompt pattern suited to the question.

2. Use approved workspaces and connectors with minimal read-only scopes. Classify and aggregate data. Separate analysis of private data and untrusted text from outbound, send and write capabilities.

3. Give the harness a short context pack: product summary, governed metrics, canonical prior values, segments, sources and dated tracking changes. Retrieve detailed context when the task needs it.

4. Explore through live connectors, then preserve the exact method, filters, timestamp or frozen dataset for a decision. Governed metrics reduce ambiguity compared with raw tables.

5. Reconcile headline numbers independently. Check windows, grain, denominators and account mix. Trace sample records and rerun in a fresh session. Require data-owner approval for consequential financial numbers.

6. Brief charts explicitly and lead reports with the answer. Separate facts from interpretation. Log the choice, confidence, threshold, owner and review date with the verified evidence attached.

Background

Established companies face constant pressure to spend on the core. Innovation bets need an explicit corporate purpose, protected resources and accountable sponsorship to survive that pressure. Different kinds and stages of bets also need different evidence, goals and funding decisions.

Key takeaways

1. Quote the corporate goal and write an innovation thesis naming the customer, innovation type, intended outcome and funding band. Screen candidates for reality, ability to win and worthwhile returns.

2. Use Doblin’s ten types to explore profit model, network, process, service and channel opportunities alongside features. Examine customers you overserve and defensible assets you can reuse.

3. Classify distance from the core with the ambition matrix and maturity with three horizons. Choose a justified spend mix. Treat 70-20-10 as a reference point.

4. Name a champion whose goals the bet serves. Agree participation, coalition-building, decision rights and kill criteria before work starts. Define the partnership with the core business.

5. Pair outcome goals with leading indicators, guardrails and learning goals. Early bets should prove assumptions. Use revenue and growth measures as evidence earns the right to scale.

6. Keep an owned risk register with signals and stop or pivot triggers. For AI bets, include inference economics, evaluation quality, security and trust. Review evidence at every funding gate.

Background

A new venture searches for a viable business model. Execution metrics and confident plans can hide that uncertainty. Lean Startup, customer development and design thinking help teams replace assumptions with evidence before committing to a full product and repeatable sales motion.

Key takeaways

1. Plan Build-Measure-Learn backward: learning need, measurement, minimum build. Choose an MVP by the risk, from a fake door or concierge service to a paid pilot.

2. Write the hypothesis, method, measure and success threshold before running the test. Record costs, time and evidence strength. Complete a learning card afterward, including the next action.

3. Test desirability, feasibility, viability and enterprise adoptability. Interview users, champions, buyers and security reviewers separately. Look for repeatable purchases and approvals beyond one enthusiastic partner.

4. Use design thinking and the first Double Diamond to understand the problem. Use sprints and prototypes for solution risks. Tie workshops to customers, thresholds and a decision maker.

5. Measure actionable leading indicators by cohort and schedule a continue, pivot or stop review. A pivot changes a fundamental hypothesis while retaining what the evidence already established.

6. Use AI for experiment drafts, facades and synthesis. Label prototypes, protect customer data and test with real people. Measure hypothesis-to-decision time, quality and cost per successful AI outcome.

Background

Innovation programs produce little value when their mechanism does not fit the unresolved question or nobody can absorb the result. Product teams need a deliberate choice among internal experiments, external partnerships and ownership changes, with follow-through planned before work begins.

Key takeaways

1. Write the bet as a question. Identify whether feasibility, adoption, availability, capability or business-model uncertainty blocks it. Classify its horizon and distance from the core.

2. Compare the fourteen mechanisms by cost, speed, control, customer impact and reversibility. Use hackathons for feasibility, design partners for workflow learning and venture client pilots for external fit.

3. Run build, partner and buy questions in order: internal resource relevance, contractibility, alliance needs and deep integration. Acquire only when the earlier paths cannot meet the need.

4. Plan the landing before the event or pilot. Get a receiving PM and engineering owner, follow-on budget, success thresholds and a decision date. Involve legal, procurement and security early.

5. Choose representative design partners, agree commitments both ways and require needs across several partners. Judge AI hackathons on shared evaluations. Give successful pilots a defined contract path.

6. Treat model providers as strategic partners. Compare company, team and technology deals, including their effect on customers. Use AI for scouting and drafting, then verify evidence and confidential-data handling.

Background

Pilots can work while the organization remains unable to sell, fund, secure or support them at scale. Core incentives and routines often explain the gap. Implementation therefore requires stakeholder agreements, an appropriate team boundary and explicit criteria for funding and transfer.

Key takeaways

1. Map stakeholder power, interest, stance, gains, losses and evidence that would change their view. Confirm important stances in conversation and build a coalition across affected functions.

2. Split work by routine fit. Shared staff handle compatible tasks. A dedicated team handles conflicting work under a focused leader. Document borrowed assets, access rights and reciprocal commitments.

3. Identify blocking policies and request bounded exceptions with scope, guardrails and end conditions. Schedule evidence-based wins before decision points and maintain an objections log.

4. Review innovation separately from core performance. Release funding against evidence at early gates and business viability later. Write state-and-date kill criteria against the riskiest assumption before funding.

5. Test scale using representative customers, normal attention, support readiness, economics and legal requirements. Name the transfer path and receiving owner. AI readiness includes evaluations, controls and dated cost assumptions.

6. Pitch the next decision with learning, a precise ask, reversibility and the scale path. Transfer an exit report, open assumptions and metrics. Keep reviewing those metrics for two or three quarters.

Background

Buyers need a clear frame for understanding a product, evidence for its value and an offer they can purchase. Positioning, messaging and commercial readiness often drift apart. AI terminology and unsupported performance claims can deepen that confusion and create substantiation risk.

Key takeaways

1. Work Dunford’s components in order: competitive alternatives, differentiated capabilities, value, best-fit customers and category. Use won deals and customer evidence. Treat pre-launch positioning as a testable thesis.

2. Decide whether to lead an existing category, a subsegment or a new category. Fund the education a new category requires. Write the positioning statement after completing the analysis.

3. Build a message house with an umbrella promise, value pillars, proof and adoption foundations. Adapt it to each buying role. Product and marketing share the positioning decision.

4. Define SKUs, editions, bundles, charge units, terms, eligibility and entitlements. Walk quoting, contracting, billing and revenue recognition with the responsible teams before announcing availability.

5. Give objective claims an approved evidence record with matching population, scope and date. Product owns factual evidence, marketing wording and legal review of sufficiency.

6. Position AI on the customer job and outcome. State autonomy boundaries and capability status where the claim appears. Tie performance numbers to evaluations or production metrics with explicit denominators.

Background

A launch joins engineering delivery with promises made by sales, marketing, billing, support, security and legal. Failures often occur between those functions. Different changes deserve different levels of coordination, while AI behavior and upstream model changes create continuing release obligations.

Key takeaways

1. Propose a tier using customer, commercial and trust impact. Assign a proportional artifact set, review path and decider. Treat production agent actions as major trust exposure.

2. Publish stage definitions from design partners through preview, limited availability and general availability. Match customer terms, eligibility, support commitments, pricing, product labels and sales language.

3. Give each function an owner, readiness definition and evidence link. Test quoting, invoices, documentation, support, controls and capacity against the announcement plan before the review.

4. Hold go/no-go early enough to change scope or timing. Log go, conditional go or no-go, including accepted risks, owners, conditions and resolution dates.

5. Compare the original PR/FAQ with the shipped scope. Keep announcements and FAQs consistent. Record adoption, business and guardrail targets before launch. Report reach separately.

6. For AI, govern autonomy separately from availability. Include behavior review, disclosure and transparency notes. Treat model swaps as releases, run production evaluations and review results at 30 and 90 days.

Background

A flagship event turns product claims into public expectations. Marketing owns production, while the PM owns capability claims, readiness, demonstrations and customer evidence. AI demonstrations add variable outputs, action permissions and disclosure requirements to the usual staging and network risks.

Key takeaways

1. Match events to their purpose. Reserve keynote time for tier 1 launches, with breakouts, webinars and release notes handling the remaining announcement and education work.

2. Sign the readiness table before creative work starts. Use generally available, public preview, private preview and roadmap labels consistently in slides, releases and briefings.

3. Sequence internal enablement, analyst briefings, press embargoes and public announcements. Give every spokesperson approved answers and identify the facts that remain confidential.

4. Structure the keynote around Duarte’s current and possible worlds. Serve users, buyers, analysts and press with one memorable beat and approved customer proof.

5. Open demos with the result. Isolate and reset the environment, pin dependencies, rehearse audience load, and assign an abandon trigger and fallback to every beat.

6. Run repeated AI rehearsal evals against a preset threshold. Show approvals and uncertainty, and disclose staged, recorded, edited or human-assisted segments on screen.

7. Measure activation, business impact and attributable margin. Compare matched attending and non-attending accounts, state uncertainty, and track mistaken capability expectations for 90 days.

Background

Enterprise customers learn, deploy and adopt through sellers, partners and customer success teams. Product claims must remain accurate across those handoffs. The field also supplies evidence about buying decisions, adoption barriers and retention that should shape the product roadmap.

Key takeaways

1. Assign ownership across PM, product marketing, enablement, sales and customer success. Give each enablement asset an owner, review date and an accuracy check before distribution.

2. Build discovery and objection guides for each buying role. Acknowledge valid objections, source competitive claims, and base ROI estimates on customer inputs with conservative assumptions.

3. Enable each partner type separately. MSPs need multi-tenant operations, per-customer billing and workable margins alongside training, certification, sandboxes and a route into triage.

4. Carry the Desired Outcome from the sales handoff into onboarding. Define first value, simplify the path to it, and review cohort progress at 30, 60 and 90 days.

5. Validate health scores against renewals and contractions. Read gross and net revenue retention together by segment and cohort, with churn reasons and expansion triggers.

6. Deduplicate requests into customer problems and link them to opportunities. Triage weekly, interview where context is missing, and notify requesters at decision and at release.

7. Use AI to search calls and draft assets in approved tools. Keep source excerpts attached, check proposed merges, and give every published asset a human owner.

Background

Growing product organizations often develop inconsistent metrics, fragmented feedback and expensive planning cycles. Product operations supplies shared evidence and operating infrastructure so teams can make decisions reliably. It serves product teams and leaders while preserving their ownership of product choices.

Key takeaways

1. Start with one senior, credible person and the most painful pillar. Use unreliable metrics, a shared planning calendar and excessive reporting as signals for investment.

2. Write a charter with customers, services, response times and scope boundaries. Keep roadmap content, research judgments, priorities, pricing and customer commitments with accountable PMs and leaders.

3. Give each leadership metric one definition, owner and system of record. Route customer evidence from every channel into a shared repository with consistent tags.

4. Assign each ritual its owner, preparation, decision and record. Separate quarterly results reviews from forward planning, and overlay fiscal, budget, board and event dates.

5. Pre-assign decision rights and process weight. Use DACI for one-off choices, RAPID for bounded vetoes and RACI for recurring work. Keep reversible decisions with teams.

6. Standardize tool ownership, read-only connector defaults and shared template skills. Grant writes for named, logged use cases, and apply data-class rules to models and connectors.

7. Review AI capability and regression results separately. Track consistency for autonomous actions and cost per successful outcome distributions, then report operational measures against baselines.

Background

Product reviews allocate resources and expose risks, but accumulated meetings and conflicting records can slow decisions. AI-generated packs increase the volume of available material while leaving verification with people. Governance needs clear forums, accountable owners and records that connect evidence to action.

Key takeaways

1. Audit recurring forums against their last three sessions. Merge, shrink or retire those that changed no decision, resource allocation or metric-owner action. Count preparation time too.

2. Run weekly reviews around controllable inputs and exceptions. Accept evidenced explanations or explicit investigations with owners and dates. Treat routine variation as routine.

3. Use monthly and quarterly narratives to compare results with plan. Surface changed assumptions and recommended corrections, while keeping results reviews distinct from forward planning.

4. Assign portfolio postures: invest, maintain, harvest or divest. Record the evidence that would change each posture and price dependencies before exiting a platform component.

5. Log options, evidence, one approver, door type, reversal trigger and revisit date. Delegate reversible choices and use heavier review for difficult-to-reverse commitments and bounded vetoes.

6. Give risks a cause-event-consequence statement, owner, early indicator and escalation threshold. Test objective escalation triggers and explicit handoffs before an incident occurs.

7. Verify AI review packs against source systems and refresh dates. Reconcile headline numbers, sample citations and keep unconfirmed causal claims as hypotheses for named human owners.

Background

Offerings, modules, APIs and model dependencies age at different rates. Enterprise customers build around them, and contracts constrain their retirement. Lifecycle management connects investment choices with customer migration, while provider schedules can force changes before your own commitments expire.

Key takeaways

1. Inventory offerings and technical surfaces with owners, stability labels, affected customers and dependency dates. Assess stages separately, recording evidence, confidence and the signal that would change the call.

2. Assign invest, sustain, harvest or retire postures. Compare revenue share with engineering capacity and check whether declining offerings consume resources needed for the next growth curve.

3. Set gates for major commitments and retirement milestones. Agree mandatory criteria, scored criteria, decision rules and gatekeepers before proposals arrive for review.

4. Write the sunset memo before announcing dates. Compare options, quantify ARR exposure and migration costs, review contracts with legal, and set measurable reversal criteria.

5. Build a feature-parity map, migration tools, parallel runs and account tracking. Pre-brief partners and top accounts, then monitor progress by ARR and account count.

6. Publish deprecation rules tied to stability labels. Send human and machine-readable notices, monitor deprecated API use, and retain evidence of data return and deletion.

7. Maintain a model register by feature, channel and region. Set deadlines ahead of provider retirement, test replacements on your evals, canary with rollback and verify every customer-facing commitment.

Background

AI features produce variable outputs, consume inference resources and can act on customer systems. Traditional functional requirements need additional quality, economics and control decisions. The PM works with engineering and domain experts to define acceptable outcomes, failure responses and release evidence.

Key takeaways

1. Write the cost of false positives, false negatives and harmful actions. Use that asymmetry to decide whether AI fits and where uncertainty or refusal is the correct result.

2. Choose a workflow before an open-ended agent when it meets the need. Set autonomy per action class, map reversibility and constrain tool permissions and task budgets.

3. Read real traces and build a failure taxonomy. Start with 20–50 representative tasks, binary criteria and model judges validated against held-out human labels.

4. Separate capability from regression evals. Measure repeated-run consistency for autonomous work, grade the end state and add production failures to the suite.

5. Keep customer purpose, economics and risks in the PRD. Add quality thresholds, data rules, latency budgets, cost per task, margin floor, fallbacks and staged-release controls.

6. Design calibrated trust through sources, uncertainty, correction, undo and escalation. Audit approvals for rubber-stamping and disclose AI where users interact with it.

7. Roll out through shadow, assisted and supervised stages before allowlisted autonomy. Monitor quality, latency, task cost and user corrections, and rerun regression tests after model or prompt changes.

Background

PMs often use AI to accelerate documents while customer evidence remains unread. Recurring workflows can extend its value to discovery, analysis and critique. That requires product context, permissioned sources, testable prompts and checks that catch fluent but unsupported outputs.

Key takeaways

1. Map recurring activities, needed sources, AI roles, verification checks and human steps. Start with discovery synthesis, one recurring report and a drafting task, then measure cycle time and quality.

2. Create a dated one-to-two-page context brief with product, personas, strategy, metrics, pricing and decision rights. Reference full documents for retrieval and mark confidentiality classes.

3. Give recurring prompts owners, success criteria, test inputs and known failure modes. Share the library and promote stable, frequently used prompts into team skills.

4. Climb from one-off prompts through saved prompts, projects, skills and schedules to gated agents. Advance only when checks work and a named person reviews the output.

5. Trace numbers to sources and dates, quotes to verbatim source passages and commitments to the brief. Review material drafts against that brief in a fresh session.

6. Use approved tools and narrowly scoped connectors. Enforce mandatory action boundaries with permissions, and treat retrieved messages and documents as untrusted task data.

7. Keep strategy calls, prioritization, promises and relationship moments with accountable people. Review failures monthly, update context and checks, and reward openly shared improvements.

Background

Responsible AI affects product behavior, enterprise procurement and incident response. Principles need controls that teams can test and customers can inspect. Applicable law depends on the system, use, market and organizational role, so product evidence must support specialist legal and privacy review.

Key takeaways

1. Inventory AI use cases separately, including models, data and actions. Record provider/deployer roles, possible risk areas and transparency duties, then have counsel confirm legal applicability.

2. Translate fairness, transparency, accountability, privacy, safety and security into questions, requirements and tests. Attach owners, evidence artifacts and review gates to each significant risk.

3. Use NIST’s Govern, Map, Measure and Manage functions to organize work. Cross-reference product impact assessments with required privacy or rights assessments and management-system records.

4. Give agents least-privilege tools, scoped connectors, approval gates and tested stop controls. Red-team relevant injection, privilege, poisoning and cascading-action risks before beta.

5. Maintain a product system card with models, data flows, permissions, autonomy, eval performance and limits. Derive questionnaire answers from a canonical bank with owners and review dates.

6. Prepare AI incident severities, handoffs, customer communications and notification clocks with specialists. Rehearse a tabletop and convert confirmed failures into eval cases and backlog work.

7. Review material changes to models, tools, data, markets and autonomy. Verify current regulatory sources and every AI-drafted customer claim, keeping classification and compliance conclusions with counsel.

Background

PMs influence decisions through documents that travel beyond the meeting. A proposal must make the ask and reasoning clear to busy readers with different stakes. AI drafting lowers production effort while increasing the importance of evidence, judgment and accountable authorship.

Key takeaways

1. Narrow the objective to one action, decider, deadline and scope. Check that a yes or no makes the next step clear, then separate independent requests.

2. Map readers by authority, knowledge, goals, concerns and reading context. Confirm consequential assumptions about stakeholders through conversation and define references an outsider would miss.

3. Build a pyramid with one governing thought and logically grouped support. Use Situation, Complication, Question and Answer when a real problem needs context, and lead email with the ask.

4. Choose document length by the decision. Use a one-page proposal for most choices, a fuller narrative for complex tradeoffs and a PR/FAQ to test a new customer proposition.

5. Include the status quo, rejected options, costs and reversal conditions. Record dissent and rationale after the decision, with process weight matched to reversibility.

6. Use concrete examples and honest persuasion. Keep deadlines real, quotes sourced and research caveats visible. Test the argument with a reader outside the work.

7. Give AI your evidence, outline, audience and voice samples. Retain the ask and recommendation, verify every factual claim, rewrite key judgment sections and disclose material AI assistance.

Background

Product decisions often depend on brief executive or customer meetings. A presentation must make the ask clear before attention or time runs out. It needs audience-specific evidence, visible uncertainty and preparation for questions that can alter the decision.

Key takeaways

1. Write the audience, decision maker, objective and one-sentence Big Idea before production. Define what listeners should know, feel and do, then test the opening with an outsider.

2. Choose the medium by purpose. Use a pre-read for complex tradeoffs, visuals for teaching and demonstrations, and written updates for routine status. Prepare three- and five-minute versions.

3. Storyboard full-sentence action titles. Lead with the ask and recommendation, group supporting arguments and keep optional detail in an appendix available for questions.

4. Make charts support their titles. State source, period, denominator, sample and uncertainty. Separate observed findings from recommended actions, and explain probability terms with a stated scale.

5. Prepare hard questions with one-sentence answers and evidence. Respond to interruptions directly, acknowledge unknowns and assign dated follow-ups. Rehearse aloud and test technical setup.

6. For AI results, distinguish offline evals from customer outcomes. Show failures, controls and ranges alongside successes, and disclose prepared or recorded demos and human approvals.

7. Use AI to draft slides, check claims and simulate skeptics. Verify numbers yourself, use approved tools, and close the meeting with decisions, owners and dates followed by a written record.

Background

Principal PMs depend on people across sales, finance, security, leadership and customer organizations. Each function has its own goals, constraints and decision authority. Product leadership adds responsibility for developing PMs and creating team conditions that support candid learning and accountable outcomes.

Key takeaways

1. Map internal and external stakeholders separately by power, interest and evidenced stance. Add desired positions, dates and engagement plans, especially for gatekeepers who can block late.

2. Understand each person’s metrics and pressures before asking for help. Offer useful evidence, task support, visibility or direction that advances their goal alongside the product outcome.

3. Settle decision rights before discussing options. Name one approver, make genuine vetoes explicit, consult key contributors privately and log the choice, reasons and dissent.

4. Turn feature requests into customer problems and use consistent prioritization criteria. Explain no, conditional yes or deferral in writing, with alternatives and a review condition.

5. Agree an upward rhythm of outcomes, decisions, risks and asks. Bring bad news early, supply recommendations and escalate unresolved peer disagreements jointly with a decision deadline.

6. Define scope, impact, autonomy and competencies by level, with credible individual-contributor and management paths. Hire using work evidence and coach one real problem through Goal, Reality, Options and Will.

7. Create team charters with outcome measures, roles and working agreements. Make regressions and failed hypotheses safe to report, and test AI-era working changes before reorganizing around them.

Background

A new product owner inherits documents that disagree or describe stale conditions. The first 90 days need a shared view built while decisions continue. A Product 360 connects verified evidence, explicit choices and artifact ownership to a cadence that keeps them current.

Key takeaways

1. Use days 1–30 to agree scope, inventory evidence, map stakeholders and open the decision log. Verify facts and settle one overdue decision with a clear owner and supporting evidence.

2. Separate facts found, facts missing and decisions missing. Cite names and dates, preserve source conflicts and leave gaps visible until an accountable person resolves them.

3. Grill one dimension per session with recommendations and seven tests: specificity, evidence, falsifiability, tradeoff, consistency, ownership and decision relevance. Log agreed, overridden and open answers.

4. Use live questioning for evolving judgments and written questionnaires for stakeholder responses. Review recommendations before returning the file: untouched answers count as accepted. Confirm the readback before generating artifacts.

5. Build the spine in dependency order during days 31–60. Generate from approved logs in fresh sessions and assign each artifact an owner, source trail and review date.

6. Audit source accuracy and cross-artifact consistency. Turn clear errors into fixes and genuine conflicts into decisions with deciders and dates. Approve the gap list, logs and audit as human gates.

7. Run at least four verified weekly reviews before day ninety. Score maturity, choose the weakest dimension for next quarter and schedule quarterly or annual re-grills as appropriate.