AI Playbook
for Software Industry

You are a product manager prioritizing the product roadmap for the next quarter.

Backlog data:
[PASTE: Feature/initiative | Customer impact (1–5) | Strategic alignment (1–5) | Effort estimate (S/M/L/XL) | ARR at risk if not built (churn signal) | ARR unlocked if built (expansion/new logo) | Number of customers requesting | ARR of requesting customers | Dependencies]

Current metrics context:
[PASTE: Current MRR/ARR | Current churn rate % | Current NRR % | Top churn reasons this quarter]

Prioritize using a scoring framework:
1) RICE score for each item: Reach × Impact × Confidence ÷ Effort
   - Reach: customers affected in next quarter
   - Impact: scale 1–3 (1=minimal, 2=medium, 3=massive)
   - Confidence: % confidence in estimates
   - Effort: person-months to complete
2) ARR impact classification — for each item, classify as: churn prevention (protects existing ARR) / expansion enabler (grows NRR) / new logo driver (grows MRR) / operational (no direct ARR impact)
3) Churn-linked items — any feature where customers have cited its absence as a reason they might leave; these are churn-prevention priorities regardless of RICE score
4) Dependencies — flag items that are blocked by other items; sequence accordingly
5) Quick wins — high-impact, low-effort items that should ship early to maintain momentum

Output: Prioritized roadmap. RICE scores. ARR impact classification per item. Total ARR at risk from not building churn-prevention items. Top 10 for next quarter with rationale. Items deferred and why.

You are a product manager analyzing incoming feature requests to inform roadmap decisions.

Request data:
[PASTE: Feature request | Source (customer/sales/CS/internal) | Number of times requested | Customer segment (SMB/mid-market/enterprise) | ARR of requesting customers | Use case description | Any competitor has this?]

Analyze:
1) Request volume by feature — what are the most frequently requested capabilities?
2) ARR-weighted demand — requests from enterprise customers may be fewer in count but higher in revenue impact
3) Segment patterns — is demand concentrated in a specific customer segment? May indicate a segment-specific gap.
4) Competitive parity — features competitors have that we don't; these are table stakes risks
5) Build vs. buy vs. partner — for top requests, is the best answer to build it, buy it, or integrate with a partner?

Output: Feature request analysis. Top requests by volume and ARR weight. Segment demand patterns. Competitive parity gaps. Build/buy/partner recommendation for top 5.

You are a product manager assessing product-market fit signals.

PMF data:
[PASTE: NPS score | "Very disappointed" survey % (Sean Ellis test) | Monthly active users / DAU/MAU ratio | Feature adoption rates | Retention at 30/60/90 days | Organic growth % | Expansion revenue % | Churn rate | Customer support ticket themes]

Assess PMF signals:
1) Sean Ellis test — if >40% of users say they'd be "very disappointed" if the product went away, PMF is likely achieved
2) Retention curve — does retention flatten out (indicates a retained core) or keep declining?
3) Engagement depth — are users using core features regularly, or just logging in?
4) Organic/word-of-mouth growth — are customers referring others without prompting?
5) NPS and expansion — promoters are driving growth; expansion ARR indicates customers are getting increasing value

Output: PMF assessment. Signal strength by category. Overall PMF verdict: strong / moderate / not yet achieved. Recommendations to strengthen PMF if not yet there.

You are a product manager preparing the sprint planning brief.

Sprint data:
[PASTE: Sprint goal | Backlog items under consideration (story | points | priority | ARR impact: churn risk/expansion/new logo/none | dependencies) | Team velocity (last 3 sprints avg) | Any commitments to customers or release dates | Known risks or blockers]

ARR context:
[PASTE: Any backlog items tied to a specific churn risk (customer name and ARR) | Items that unlock a pricing tier or expansion motion | Items committed to a customer as part of their renewal]

Build the sprint brief:
1) Sprint goal — one clear, testable objective that the sprint is designed to achieve
2) Capacity check — team velocity × sprint length; how many story points can realistically be committed?
3) ARR-priority sequencing — items protecting ARR (churn risk) take precedence; items enabling NRR expansion come next; neutral items fill remaining capacity
4) Dependency sequencing — items that must be done before others; sequence accordingly
5) Risk flags — any items with high uncertainty; flag any tied to a renewal or customer commitment

Output: Sprint planning brief. Committed stories with ARR impact labeled. Capacity vs. commitment check. Churn-risk items explicitly called out. Sprint goal statement.

You are a product manager writing user stories for a new feature.

Feature context:
[DESCRIBE: Feature name, the problem it solves, target user persona, key use cases, any acceptance criteria already discussed, technical constraints known]

Write user stories:
1) Format: "As a [specific user persona], I want to [action], so that [benefit/outcome]"
2) Each story should be: Independent / Negotiable / Valuable / Estimable / Small / Testable (INVEST criteria)
3) Include acceptance criteria for each story — specific conditions that must be true for the story to be considered done
4) Break epics into stories — no story should take more than 1 sprint; if it does, decompose further
5) Edge cases — include stories for error states, empty states, and permission variations

Output: User stories with acceptance criteria. Organized by epic if applicable. Stories sized for single-sprint completion. Edge case stories included.

You are a product manager designing the product metrics dashboard.

Business context:
[DESCRIBE: Product type (B2B SaaS / consumer app / marketplace / platform), stage of company (early / growth / scale), current metrics being tracked, key decisions the dashboard should support, stakeholder audience (product team / leadership / board)]

Design the dashboard:
1) North star metric — the single metric that best captures the value customers get from the product; everything else should lead to this
2) Input metrics — leading indicators that drive the north star (activation rate / feature adoption / engagement frequency)
3) Health metrics — lagging indicators of product health (retention / NPS / support ticket volume)
4) Business metrics — revenue impact (MRR / expansion / churn) connected to product performance
5) Alerting — which metrics should trigger an alert if they move significantly in either direction?

Output: Dashboard design. North star metric defined. Input, health, and business metrics. Alert thresholds. Review cadence recommendation.

You are a product manager synthesizing customer interview findings.

Interview data:
[PASTE: Interview # | Customer segment | Current workflow described | Pain points mentioned | Workarounds they use | Features they praised | Features they criticized | Unmet needs expressed | Quotes (anonymized)]

Synthesize findings:
1) Recurring pain points — which problems come up across multiple interviews?
2) Workaround analysis — what hacks or manual processes are customers using? These are product opportunities.
3) Unmet needs — what did customers describe wanting that the product doesn't do today?
4) Segment differences — do different customer segments have meaningfully different needs?
5) Quotes for product briefs — 3–5 verbatim customer quotes that capture the most important findings

Output: Customer interview synthesis. Top 5 findings. Unmet needs list. Segment-specific insights. Quotes for stakeholder communication. Roadmap implications.

You are a product manager preparing for a product or major feature launch.

Launch data:
[DESCRIBE: What is launching, launch date, target customer segments, ARR opportunity (new logo / expansion / churn prevention), pricing changes (if any), key use cases, internal teams involved (sales/CS/marketing/support), any beta testing results, go-to-market strategy]

ARR context:
[PASTE: Expected MRR/ARR impact at 90 days if successful | Churn risk this addresses (ARR amount) | NRR improvement expected | Customers in beta and their ARR]

Build the launch checklist:

Pre-launch (2+ weeks before):
- Feature complete and QA signed off
- Documentation (help articles / release notes) written
- Sales and CS enablement: how does this feature affect renewal conversations and expansion pitches?
- Pricing and billing systems updated (if applicable)
- Marketing assets (email / landing page / social) ready

Launch day:
- Feature flags enabled for target segments
- Monitoring and alerting configured
- Customer communication sent
- Sales and CS notified with talking points linking feature to customer ARR outcomes

Post-launch (first 30 days):
- Usage tracking confirmed
- Customer feedback being collected
- ARR impact measured: any churn prevented, expansion closed, or new logos won citing this feature?
- Success metrics reviewed at day 7 and day 30

Output: Launch checklist by phase. Owner for each item. ARR success metrics defined. Go/no-go criteria. Post-launch ARR impact review schedule.

You are a product manager preparing a competitive analysis.

Competitive data:
[PASTE: Competitor | Target market | Core features | Pricing model | Strengths | Weaknesses | Recent product announcements | Any customer wins or losses to this competitor]

Analyze:
1) Feature parity — where are we at parity, ahead, or behind vs. each competitor?
2) Positioning differentiation — how does each competitor position vs. us? Where do we genuinely differ?
3) Pricing comparison — how does our pricing compare? Are we more/less expensive and why?
4) Win/loss patterns — which competitors do we most often face in deals? Where do we win/lose?
5) Competitive threats — any competitor moves (new features / acquisitions / pricing changes) that require a response?

Output: Competitive analysis. Feature comparison matrix. Positioning differentiation. Win/loss patterns. Recommended product or positioning responses.

You are a product manager running a beta program for a new feature.

Beta program data:
[DESCRIBE: Feature being tested, beta start and end dates, number of beta customers (and how selected), success criteria for the beta, feedback collection method, any known risks in the beta build]

Build the beta program plan:
1) Customer selection — criteria for who is invited to beta; mix of power users and typical users
2) Onboarding — how are beta customers set up and trained? Who is their point of contact?
3) Feedback collection — structured feedback (survey / interview schedule) vs. passive (in-app feedback / usage data)
4) Success criteria — what metrics at beta end will determine whether to proceed, iterate, or kill?
5) Communication — what do beta customers expect? Regular updates; what they get for participating

Output: Beta program plan. Customer selection criteria. Feedback collection schedule. Success criteria. Go/no-go framework for general availability.

You are a product manager working with engineering to assess and prioritize technical debt.

Technical debt data:
[PASTE: Debt item | System/component affected | Impact on development velocity | Impact on reliability/performance | Customer-facing impact | Effort to resolve | Risk if not addressed]

Assess and prioritize:
1) Customer impact — technical debt that is causing outages, slowness, or bugs for customers is highest priority
2) Velocity impact — debt that is significantly slowing down feature development affects the whole roadmap
3) Security and compliance risk — any debt that creates security vulnerabilities or compliance exposure
4) Effort vs. impact — quick wins on high-impact debt items should be addressed first
5) Allocation recommendation — what % of each sprint should be allocated to technical debt vs. new features?

Output: Technical debt priority list. Impact and effort matrix. Recommended sprint allocation % for debt reduction. Items to schedule in upcoming sprints.

You are a CPO writing the annual product vision and strategy document.

Strategic context:
[DESCRIBE: Company mission, current product state, target customer, market opportunity, key strategic themes for the year, any major bets being made, what success looks like in 12 months]

Write the document:
1) Product vision — where is the product going in 3 years? Aspirational and specific.
2) Strategic themes — 3–4 focus areas that will drive product development this year; not a feature list, a direction
3) What we will do — the major bets and initiatives; what they are and why
4) What we will not do — explicit choices to say no to; focus requires trade-offs
5) Success metrics — how will we know if the strategy is working? Measurable outcomes, not outputs

Output: Product vision and strategy document. One-page executive summary + detail for each strategic theme. Suitable for all-hands, board deck, and team alignment.