Claude Prompt Library

Claude Prompts That Make You Decide Faster

100 copy-paste prompts

100 Claude prompts for the decisions you keep putting off — pricing, hiring, scope, pivots, partnerships. Stress-test plans, kill commitments, reframe decisions you're sleeping on.

In short: This page contains 100 copy-paste ready prompts, organized into 5 categories with a description and pro tip for each. The first 15 prompts are free instantly — no signup needed. Hand-curated and tested by the AI Academy team.

By Louis Corneloup · Founder, Techpresso
Last updated ·Hand-curated & tested by the AI Academy team

Stop & Kill Decisions

19 prompts

The Stop-Doing Audit

1/100

<task>Tell me what to stop doing based on the last 90 days of company activity.</task> <context> - Notes, meeting summaries, plans, OKRs: [paste 90 days of artifacts] - Goal for the next quarter: [describe] - Resources I have: [headcount, hours, budget] </context> <output> 1. 3 commitments to kill — for each: what it is, weekly cost of keeping it (hours / dollars / opportunity), why it doesn't serve the goal, and the single sentence I'd use to announce killing it. 2. 2 patterns I'd missed (in customer calls, churn, hiring, etc.) — evidence + implication. 3. 1 thing that looks killable but isn't — explain the hidden value. 4. Confidence (low / med / high) on each recommendation. </output>

Identifies 3 commitments to kill from 90 days of notes, with cost-of-keeping calculation.

💡

Pro tip: This is Claude's best decision prompt because it forces evidence-based killing, not vibes. Always include the "1 thing that looks killable but isn't" — it stops you from cutting load-bearing work.

Cost-of-Keeping Calculator

2/100

<task>Calculate the true cost of keeping [project / commitment / process].</task> <commitment> - What: [describe] - Origin: [why it started] - Current state: [active / dormant / on autopilot] </commitment> <inputs> - Direct hours/week: [estimate] - People involved: [list] - Meetings it generates: [estimate] - Tools / subscriptions: [list] - Mental overhead (decisions, context switches): [describe] </inputs> <output> 1. Direct cost: hours × loaded rate + tools (annualized). 2. Opportunity cost: what those hours would produce if redirected. 3. Mental tax: decision count, switching cost, calendar fragmentation. 4. Total annualized cost in dollars and FTE-equivalents. 5. The "kill threshold" — what'd have to change for the value to exceed this cost. 6. Recommendation: keep / pause / kill, with one-line reasoning. </output>

Calculates direct + opportunity + mental cost of a commitment and recommends keep/pause/kill.

💡

Pro tip: Most "kill it" decisions stall on "but we already paid for it." Loaded cost beats sunk cost in conversation — Claude calculates this without the emotional weight.

Project Sunset Decision

3/100

<task>Decide whether to sunset [project] now or push through one more quarter.</task> <project> - Name: [describe] - Original thesis: [what we believed when we started] - Current state: [milestones hit / missed] - Resources committed to date: [hours / dollars] - Resources required to finish: [estimate] </project> <output> 1. Has the original thesis been validated, disproven, or remained unknown? Cite evidence. 2. Would we start this project today knowing what we know now? Yes/no + reasoning. 3. Probability of success if we push one more quarter (rough estimate with assumptions). 4. Sunk-cost honesty check: how much of "let's keep going" is rational vs commitment bias? 5. Sunset plan: how to wind down without losing what's been learned. 6. Recommendation + the strongest counter-argument to that recommendation. </output>

Decides project sunset using thesis validation, fresh-start test, and sunk-cost honesty check.

💡

Pro tip: The "would we start this today?" question is the single best decision unlock. Force Claude to answer yes/no — vague answers mean you're not done thinking.

Feature Kill Decision

4/100

<task>Decide whether to kill [feature] from the product.</task> <feature> - What it does: [describe] - Built: [date] - Active users in last 30d: [number / %] - Maintenance cost: [bugs, support tickets, infra] </feature> <output> 1. Who is the smallest user segment that still relies on this? Can we live without them? 2. Maintenance cost over the last 6 months (engineering hours + support). 3. Migration path: where do current users go if we kill it? 4. Sunset comms plan: announcement → grace period → removal. 5. Risk of keeping it: opportunity cost + cognitive load on the team. 6. Recommendation: kill / hide / deprecate / keep, with reasoning. </output>

Decides whether to kill a feature based on usage, maintenance cost, and migration paths.

💡

Pro tip: Most "kill the feature" debates ignore the 2% of users who scream. Force the migration path into the analysis — if you can't describe it, you're not ready to kill yet.

Meeting Audit

5/100

<task>Audit my recurring meetings and tell me which to kill.</task> <meetings>[paste calendar export or list: name, frequency, attendees, last 4 weeks of stated purpose]</meetings> <my_role>[founder / IC / manager — what I'm optimizing for]</my_role> <output> For each meeting: 1. Purpose check: is it status, decision, generative, or social? 2. Could the value be captured async (doc, Loom, Slack)? 3. Attendee count vs. decision-makers — who could leave? 4. Cadence check: weekly that should be biweekly, monthly that should be ad-hoc? 5. Kill / shrink / keep recommendation with reasoning. Then: ranked kill list (highest hours saved first) and a single one-line message I can send to cancel each. </output>

Audits recurring meetings and ranks kill candidates by hours saved.

💡

Pro tip: The "could this be async?" question kills 30% of recurring meetings on first pass. Status updates almost always can; generative meetings almost never can.

Customer Segment Exit

6/100

<task>Decide whether to stop serving [customer segment].</task> <segment> - Description: [who they are] - % of revenue: [number] - Acquisition cost: [estimate] - Support burden: [tickets / hours] - Strategic fit with where we're going: [describe] </segment> <output> 1. True contribution margin (revenue minus CAC, support, custom work). 2. Strategic fit: are they buying what we want to sell more of? 3. What we'd learn from keeping them vs reinvesting that energy. 4. Migration / sunset plan if we exit (refunds, alternatives, comms). 5. Reputation / referral risk of exit — quantify. 6. Recommendation: keep, deprioritize, sunset, or fire — with one-line reasoning. </output>

Decides whether to exit a customer segment using margin, fit, and reputation risk.

💡

Pro tip: Customer segments you should exit usually feel like "loyal customers." Loyalty doesn't make them profitable or strategic. Margin + fit beat tenure.

Channel Sunset Decision

7/100

<task>Decide whether to stop investing in [acquisition channel].</task> <channel> - Channel: [SEO / paid / partnerships / cold outbound / events] - Last 90 days: spend, leads, customers, CAC, LTV ratio - Compared to next-best channel: [data] - Team time required: [hours/week] </channel> <output> 1. Channel ROI vs alternatives — hard numbers. 2. Is performance trending up, flat, or down? What's driving it? 3. Channel saturation: are we at the productivity ceiling? 4. Switching cost: what we lose if we pause (relationships, SEO equity, momentum). 5. Reallocation: where the freed hours and dollars would produce more. 6. Recommendation: kill / pause 90d / shrink / keep — with reasoning. </output>

Decides whether to sunset an acquisition channel using ROI vs alternatives.

💡

Pro tip: Channel sunsets are usually delayed by 6 months because nobody owns the kill decision. Run this monthly on your weakest channel — kill it when it underperforms 3x in a row.

Tool & Subscription Audit

8/100

<task>Audit our SaaS stack and identify what to cut.</task> <stack>[paste tool list: name, monthly cost, seats, primary user, last login if known]</stack> <output> 1. Tools used by <30% of seats — candidates for seat reduction. 2. Tools with no logins in 30 days — candidates for cancellation. 3. Tools with overlap (e.g., two PM tools, two design tools) — consolidation candidates. 4. Tools where switching cost > savings — keep. 5. Annual savings if we executed all recommendations. 6. The riskiest cancellation (where convenience cost might exceed dollar savings) — flag. </output>

Audits SaaS stack and identifies seat cuts, cancellations, and consolidation opportunities.

💡

Pro tip: The "annual renewal sneaks up" pattern wastes 15-20% of SaaS budgets. Run this 60 days before any major renewal — gives time to negotiate or migrate.

Process Elimination

9/100

<task>Find a process to eliminate (not improve — eliminate).</task> <processes>[list current recurring processes: name, who does it, time spent, output, who consumes the output]</processes> <output> For each process: 1. Who reads / uses the output? (be specific — if "nobody specifically," flag it) 2. What decision does it inform? 3. Has any decision actually been changed by this output in the last 90 days? 4. What would break if we stopped doing it? 5. Eliminate / automate / keep — recommendation. Then: top 3 processes to kill this week, ranked by hours saved. </output>

Eliminates rather than improves processes by checking whether outputs change any decisions.

💡

Pro tip: Most "improve the process" discussions should be "kill the process" discussions. Forcing "what decision did this change?" reveals dead reports nobody reads.

Reporting Kill List

10/100

<task>Identify reports and dashboards we should stop producing.</task> <reports>[list: name, frequency, audience, time to produce, last meaningful action taken from it]</reports> <output> 1. Reports that haven't driven a decision in the last 90 days — candidates to kill. 2. Reports where the audience is "everyone" (= nobody owns them) — kill or assign owner. 3. Reports duplicating data from another source — consolidation candidates. 4. The "vanity report" — flag the one most likely to be feel-good, not decision-driving. 5. Recommended kill list with one-line messages to send each audience. </output>

Identifies vanity reports and dashboards that no longer drive decisions.

💡

Pro tip: Reports calcify. The "we've always sent this" report rarely gets read. Ask Claude to be ruthless — soft recommendations let dead reports survive.

Vendor Relationship Sunset

11/100

<task>Decide whether to end the relationship with [vendor].</task> <vendor> - Service: [describe] - Annual cost: [amount] - Tenure: [years] - Recent issues: [list] - Internal owner: [name] </vendor> <output> 1. Performance vs SLA / expectations over last 12 months. 2. Switching cost: migration time, data export, retraining team. 3. Alternatives: 3 specific replacements with rough cost + capability comparison. 4. Negotiation leverage if we'd rather stay (price reduction, scope shift). 5. Off-ramp plan if we exit: 30/60/90 day milestones. 6. Recommendation: renegotiate, switch, or stay — with reasoning. </output>

Decides vendor relationship end with switching cost, alternatives, and renegotiation analysis.

💡

Pro tip: Vendor relationships hit a "comfortable inertia" point around year 3. That's exactly when their pricing creeps up and their service flattens. Audit at year 3, not year 5.

Initiative Postmortem

12/100

<task>Run a postmortem on [completed initiative] to extract what to stop doing in future ones.</task> <initiative> - What it was: [describe] - Goal: [original] - Result: [actual] - Duration: [length] - People involved: [list] </initiative> <output> 1. What worked — keep doing. 2. What partially worked — modify. 3. What didn't work — stop doing in the next initiative. 4. The unspoken thing nobody wants to say — name it. 5. What we'd start doing differently from day 1 next time. 6. 3 specific commitments to change for the next initiative. </output>

Postmortem that extracts what to stop doing, including the unspoken thing nobody wants to say.

💡

Pro tip: The "unspoken thing" prompt is the single most valuable postmortem question. Claude will name it without team-political risk — that's the unique value here.

Sunk-Cost Reality Check

13/100

<task>Help me distinguish sunk cost from forward investment in [situation].</task> <situation> - What we've already invested: [time, money, reputation, relationships] - What we'd need to invest more: [estimate] - What we'd capture if we finish: [describe] - What we'd capture if we redirect: [describe] </situation> <output> 1. Sunk-cost component: what's already spent and unrecoverable. 2. Forward-cost component: what we'd need to commit to finish. 3. Forward-value if we finish vs forward-value if we redirect — apples to apples. 4. The cognitive bias check: which of these biases is most likely operating — commitment bias, loss aversion, social proof, identity protection? 5. What I'd recommend to a friend in the same situation (often more honest than self-advice). 6. Decision recommendation with confidence level. </output>

Separates sunk cost from forward investment and surfaces the operating cognitive bias.

💡

Pro tip: The "what would I recommend to a friend?" reframe is the cleanest debias technique. Most founders are 2x more honest about a friend's situation than their own.

Headcount Cut Decision

14/100

<task>Decide whether to reduce headcount and by how much.</task> <context> - Runway: [months] - Current burn: [monthly] - Revenue trajectory: [last 6 months trend] - Team: [count by function] - Recent hiring vs results: [describe] </context> <output> 1. Cash position scenarios: 0% cut, 10%, 20%, 30% — runway impact. 2. Output scenarios: what we can still ship with each headcount level. 3. Single biggest skill gap exposed by each cut size. 4. Severance + closeout cost — net cash savings per scenario. 5. Cultural / morale cost of cuts at each level. 6. Recommendation with the strongest counter-argument to it. </output>

Headcount-cut decision with runway scenarios, output impact, and counter-argument.

💡

Pro tip: The "ship what?" question forces realistic scenarios. Founders who skip this end up cutting too deep and unable to deliver, or too shallow and burning anyway.

Office Lease Decision

15/100

<task>Decide whether to renew / downsize / exit office lease.</task> <context> - Current lease: [size, cost, end date] - Avg in-office attendance: [%] - Team distribution: [local vs remote] - Cultural value of office: [be honest] - Hybrid commitments made: [if any] </context> <output> 1. True cost per in-office seat (rent ÷ avg daily attendance). 2. Alternative scenarios: full remote, smaller office, co-working — annual savings. 3. Cultural / hiring impact of each scenario. 4. Reversibility: can we re-enter the lease market in 12 months if we exit? 5. Team-side reaction: who'd be upset, who'd be relieved. 6. Recommendation with the 12-month reversibility lens. </output>

Office lease decision using cost-per-occupied-seat and reversibility analysis.

💡

Pro tip: The "cost per occupied seat" frame is brutal — most underused offices are 3-5x more expensive per person than they look on the lease line.

Content Pillar Kill

16/100

<task>Decide which content pillar to stop creating for.</task> <pillars>[list current content pillars: topic, frequency, traffic, conversions, time investment]</pillars> <output> 1. Conversion-weighted ROI per pillar (not just traffic — actual customers). 2. Topical authority: where are we already known vs where are we trying to break in? 3. Time-to-payoff: how long to next dollar from each pillar? 4. Compounding fit: which pillars build into each other? 5. Recommendation: 2 to kill, 1 to double down on, with reasoning. </output>

Decides which content pillar to kill using conversion-weighted ROI and topical authority.

💡

Pro tip: Most content strategies have 1 pillar doing 80% of the work and 4 pillars existing out of inertia. Force ranking forces honesty.

Product Line End-of-Life

17/100

<task>Decide end-of-life timing for [product line].</task> <product> - Product: [describe] - Revenue: [current monthly] - Trajectory: [last 12 months] - Maintenance cost: [engineering + support hours] - Customers: [count + key accounts] </product> <output> 1. Revenue runway: at current trajectory, when does this go to zero? 2. Cost to maintain through end-of-life vs immediate sunset. 3. Customer migration paths (to us, to competitor, to nothing). 4. EOL announcement timing: 6mo, 12mo, 18mo notice — pros/cons of each. 5. Final-year revenue we'd capture vs cost of capturing it. 6. Recommended EOL date + comms plan. </output>

Plans product end-of-life with revenue runway, customer migration, and announcement timing.

💡

Pro tip: The biggest EOL mistake is announcing too late (customers feel betrayed) or too early (revenue evaporates before maintenance cost drops). 9-12 months is the typical sweet spot for B2B SaaS.

Partnership Wind-Down

18/100

<task>Decide whether and how to wind down [partnership].</task> <partnership> - Partner: [name] - Type: [reseller / integration / co-marketing / strategic] - Original goal: [describe] - Current performance: [vs goal] - Relationship history: [any tensions] </partnership> <output> 1. Mutual value scorecard: what each side has actually delivered vs promised. 2. Strategic fit: does the partnership still serve where each side is going? 3. Wind-down approaches: graceful exit, dormant pause, scope reduction, hard end. 4. Contractual obligations / off-ramps available. 5. Comms plan to preserve relationship for future opportunities. 6. Recommended approach with the version of the conversation I'd start. </output>

Plans partnership wind-down with mutual scorecard and relationship-preserving comms.

💡

Pro tip: Partnerships rarely "fail" — they drift. The fastest wind-down is honest acknowledgment: "this isn't producing for either of us." Direct beats slow drift.

Saying No to an Opportunity

19/100

<task>Help me decide whether to say no to [opportunity that looks attractive].</task> <opportunity> - What it is: [describe] - What it'd require: [time, money, attention, reputation] - Why it looks attractive: [be specific] - What I'd be implicitly choosing not to do if I say yes: [list] </opportunity> <output> 1. Strategic fit (1-10) — does this advance the main thing or just look impressive? 2. Opportunity cost (specific things you'd stop doing or do less of). 3. The "would I pursue this if it weren't being offered to me?" test — yes/no with reasoning. 4. The version of yes that protects the main thing (smaller scope, deferred, delegated). 5. The reframing that makes "no" feel obvious in retrospect. 6. Recommendation with the exact wording I'd use to decline (if applicable). </output>

Decides whether to say no to attractive opportunities using opportunity-cost framing.

💡

Pro tip: The "would I pursue this if it weren't offered?" test is the cleanest filter. If you wouldn't go find it, you probably shouldn't accept it just because it found you.

XML tags are just the start. Learn the full Claude workflow.

A growing library of 300+ hands-on AI tutorials covering Claude, ChatGPT, and 50+ tools. New tutorials added every week.

Start 7-Day Free Trial

Pricing Decisions

20 prompts

Price Increase Decision

20/100

<task>Decide whether and how much to raise prices.</task> <context> - Current pricing: [describe tiers] - Last increase: [date + amount] - Customer feedback signals: [recent quotes if any] - Competitor pricing: [data] - Cost trajectory: [margin trend] </context> <output> 1. Justification check: what value increase justifies a price increase customer-side? 2. Three price-increase scenarios: 10%, 20%, 30% — projected churn at each, projected revenue at each. 3. Grandfather decision: keep existing customers at old price or migrate them? 4. Comms strategy: who hears first, what framing, what timing. 5. Risk: churn cliff, sales-cycle drag, public reaction. 6. Recommended increase + 90-day rollout plan. </output>

Decides price increase amount with churn scenarios, grandfather choice, and rollout plan.

💡

Pro tip: Price increases under 20% with 60+ days notice rarely trigger meaningful churn. The bigger risk is sales cycles stalling — flag that explicitly in the rollout plan.

Price Decrease Decision

21/100

<task>Decide whether to lower prices.</task> <context> - Current price: [amount] - Conversion rate: [%] - Win/loss reasons in last 90 days: [list] - Margin: [current] - Competitor pricing: [comparable products] </context> <output> 1. Is price the actual blocker (per win/loss data) or are we projecting? 2. Demand elasticity estimate: at -20% price, conversion lift needed to break even. 3. Brand/perception risk of lowering price. 4. Alternative: keep price, add value vs cut price (which moves the needle more?). 5. Annual margin impact at each scenario. 6. Recommendation with the strongest counter-argument. </output>

Decides price decrease using elasticity, win/loss data, and brand-risk analysis.

💡

Pro tip: Lowering price almost never solves a positioning problem — it makes it worse. Force the "is price actually the blocker?" question first.

Packaging & Tier Restructure

22/100

<task>Restructure pricing tiers.</task> <current> - Tier 1: [name, price, features] - Tier 2: [name, price, features] - Tier 3: [name, price, features] - Distribution: [% customers in each] - Top requested features: [list] </current> <output> 1. Tier-by-tier diagnosis: who's in each, why, where they upgrade/downgrade. 2. Feature gating analysis: what gates work (drive upgrades) vs what gates annoy (drive churn). 3. New tier proposal: 3 tiers with prices, features, target persona for each. 4. Migration path for existing customers (grandfather, opt-in, force-migrate). 5. Pricing-page narrative: what message each tier sends. 6. Risks + the test we'd run before full rollout. </output>

Restructures pricing tiers with feature-gating analysis and migration paths.

💡

Pro tip: Three tiers with clear personas per tier convert better than five tiers covering edge cases. Force "who is this tier for?" — if you can't answer in one sentence, the tier shouldn't exist.

Discount Strategy Decision

23/100

<task>Decide our discount strategy.</task> <context> - Current discount practice: [describe] - Most common discount request: [%] - Win rate with vs without discount: [data] - Avg ACV impact: [data] - Sales rep autonomy: [current rules] </context> <output> 1. Strategic position on discounts: never / rarely / situationally / always negotiate. 2. Approved discount ladder: % bands tied to commitment (annual prepay, multi-year, etc.). 3. Sales rep authority: when to escalate, when to walk. 4. Discount-killer alternatives: trials, extra seats, services, deferred start. 5. Margin impact of each scenario at current win rate. 6. Recommendation + the 90-day measurement plan. </output>

Decides discount strategy with approved ladders, escalation rules, and non-price alternatives.

💡

Pro tip: Discounts are usually a habit, not a strategy. The discount ladder ("you get X% if you commit to Y") trades discount for commitment — much higher LTV.

Free Tier Decision

24/100

<task>Decide whether to add, kill, or modify our free tier.</task> <context> - Current state: [free tier exists / doesn't] - Free → paid conversion: [%] - Free user support cost: [hours/month] - Free tier strategic role: [acquisition / awareness / data] - Competitor free tiers: [describe] </context> <output> 1. Free tier ROI: cost to serve vs paid conversions generated. 2. Strategic role check: is it actually driving the role we claim? 3. Three options: kill free / shrink free / keep free / expand free — projected impact each. 4. Top-of-funnel alternative if we kill free (trial, freemium-of-features, demo). 5. Migration plan if we modify or kill. 6. Recommendation with 90-day signal we'd measure. </output>

Decides free-tier strategy using ROI, strategic role, and migration planning.

💡

Pro tip: Free tiers calcify. They usually start strategic and end as overhead. The "is it driving the role we claim?" check separates strategic free tiers from legacy free tiers.

Enterprise Custom Pricing

25/100

<task>Decide pricing for [specific enterprise deal].</task> <deal> - Prospect: [company] - Stated budget: [if shared] - Use case: [describe] - Stakeholders: [count] - Competition: [other vendors] - Strategic logo value: [yes/no/why] </deal> <output> 1. Anchor price: what we'd charge a typical company this size. 2. Strategic adjustments: logo discount, multi-year discount, expansion-bet discount. 3. Walk-away price: minimum we'd take. 4. Above-anchor scenarios: what'd justify pricing above the anchor. 5. Negotiation moves: what we give if they push (deeper discount vs more value). 6. Recommended opening price + the three concession ladder. </output>

Builds enterprise custom pricing with anchor, walk-away, and concession ladder.

💡

Pro tip: The biggest enterprise pricing mistake is starting at "what they'll pay." Start at the anchor, justify it, then concede in structured trades — never just lower.

Annual vs Monthly Push

26/100

<task>Decide how aggressively to push annual contracts vs monthly.</task> <context> - Current annual %: [%] - Annual discount currently offered: [%] - Cash position: [months runway] - Churn rate monthly vs annual: [data] - Sales cycle implications: [annual slower?] </context> <output> 1. LTV impact: monthly vs annual customer lifetime value (with churn factored). 2. Cash impact: annual prepay vs monthly streaming at current growth. 3. Sales-cycle drag of pushing annual (objections, longer close). 4. Discount calibration: discount % that maximizes annual conversion without margin loss. 5. Comms / packaging: how the offer is shown on pricing page. 6. Recommendation: hard push annual / nudge / customer choice. </output>

Decides annual-contract push intensity with LTV, cash, and discount calibration.

💡

Pro tip: Annual customers are 2-3x more valuable in LTV but 30-50% slower to close. Cash position dictates the answer — short runway = push annual hard with a meaningful discount.

Geographic Pricing

27/100

<task>Decide whether and how to introduce geographic pricing.</task> <context> - Current pricing: [single global] - Geographic mix: [% by region] - Purchasing-power differences in target markets: [data] - Risk of arbitrage (people gaming via VPN): [low / med / high for our product] - Competitor practice: [describe] </context> <output> 1. Markets where current price is a meaningful blocker (be specific). 2. PPP-adjusted pricing proposal for top 3 underpenetrated markets. 3. Arbitrage protection: payment-method gating, address verification, etc. 4. Existing-customer policy if they relocate. 5. Revenue impact: new sales vs cannibalization. 6. Recommended rollout: which markets first, what timeline. </output>

Decides geographic pricing with PPP analysis, arbitrage protection, and rollout plan.

💡

Pro tip: Geographic pricing works for B2C and falters for B2B (companies have global procurement that'll flag the price gap). Lead with the arbitrage risk — it kills more rollouts than the pricing math.

Add-On & Upsell Decision

28/100

<task>Decide which add-ons to introduce.</task> <context> - Current product: [describe] - Top customer requests not in core: [list] - Top reasons for churn or downgrade: [list] - Team capacity to build: [hours] </context> <output> 1. Add-on candidate list ranked by: revenue potential × adoption likelihood × build cost. 2. Bundle vs separate decision per candidate. 3. Adoption funnel: how customers discover and try the add-on. 4. Margin: which add-ons are high-margin (digital, automated) vs low (services). 5. Risk: do any add-ons signal core product gaps that should be fixed instead? 6. Recommendation: top 2 to ship next quarter, top 1 to kill before starting. </output>

Decides add-on roadmap using revenue × adoption × build cost ranking.

💡

Pro tip: Add-ons that fix a missing-feature complaint signal the feature should be in core, not add-on. Force the "is this an add-on or a core gap?" check.

Sunset Old Pricing Plan

29/100

<task>Decide how to sunset [old pricing plan] while keeping legacy customers.</task> <plan> - Plan name: [describe] - Customers on it: [count + % of total] - Revenue from it: [amount] - Why it's being sunset: [strategic reason] </plan> <output> 1. Migration paths: nearest new plan, custom landing, or grandfather forever. 2. Communication timing: notice period, framing, who gets what message. 3. Special-case handling: high-value legacy accounts, multi-year prepays. 4. Sales / support enablement: scripts, FAQ, escalation criteria. 5. Revenue scenarios: best case, expected, worst case under each migration path. 6. Recommended approach + the 90-day execution plan. </output>

Sunsets old pricing plan with migration paths, comms timing, and special-case handling.

💡

Pro tip: Customers tolerate sunset migrations when they understand why and feel they have time. 90 days notice + 1 phone call to top accounts handles 80% of upset.

Founding Member Pricing

30/100

<task>Decide whether to offer founding-member pricing.</task> <context> - Stage: [pre-launch / early / scaling] - Current pricing plan: [if any] - Distribution channel for founding members: [waitlist, network, social] - Desired commitment from them: [feedback, case studies, testimonials] </context> <output> 1. Strategic role of founding-member pricing (loyalty, social proof, feedback, cash). 2. Pricing options: lifetime discount, locked-in price, free year, lump-sum lifetime. 3. Cap: how many founding members and why that number. 4. Obligation: what we commit to vs what they commit to (feedback cadence, case studies). 5. Cost over time: revenue we forgo vs value we capture. 6. Recommendation + exact offer language. </output>

Decides founding-member pricing with strategic role, cap, and mutual obligations.

💡

Pro tip: Founding-member offers work when both sides give something. One-sided discounts attract bargain hunters; mutual commitment attracts champions.

Grandfather Existing Customers

31/100

<task>Decide whether to grandfather existing customers at old pricing or migrate them.</task> <context> - Old price: [amount] - New price: [amount + when introduced] - Active customers on old price: [count + revenue] - Goodwill considerations: [recent issues if any] - Cash impact of migrating: [estimate] </context> <output> 1. Grandfather-forever vs migrate-with-notice vs hybrid (partial increase) — financial impact each. 2. Customer reaction modeling: who'd churn vs accept under each path. 3. Loyalty / fairness narrative: how each path lands with the customer base. 4. Operational cost: maintaining old pricing infrastructure forever. 5. Sales-side implication: do current discounts to new prospects undermine the grandfather? 6. Recommendation + the comms wording. </output>

Decides grandfather vs migrate with financial, fairness, and operational analysis.

💡

Pro tip: Grandfathering feels generous but creates SKU sprawl. The cleanest path is migrate-with-notice; the kindest path is grandfather. Pick based on cash and customer relationship strength.

Bundle vs Unbundle Decision

32/100

<task>Decide whether to bundle or unbundle [product / set of features].</task> <context> - Current packaging: [bundled / unbundled / hybrid] - Customer purchase patterns: [data] - Stage of market: [early adopter / mainstream / mature] - Competitor packaging: [describe] </context> <output> 1. Bundle case: simpler buying, higher ACV, harder to compare. 2. Unbundle case: lower entry price, easier expansion, modular adoption. 3. Market-stage match: early markets often bundle; mature markets often unbundle (or rebundle). 4. Pricing power: which path captures more value at our stage? 5. Comms / positioning shift required for the new packaging. 6. Recommendation + the 90-day test plan. </output>

Decides bundle vs unbundle using market stage, pricing power, and customer patterns.

💡

Pro tip: Markets cycle: bundle → unbundle → rebundle. Where you sit on the cycle dictates the answer. Force Claude to identify the cycle stage first.

Usage-Based vs Flat

33/100

<task>Decide whether to switch to usage-based pricing.</task> <context> - Current model: [flat / per seat / hybrid] - Variable cost per unit (compute, API, etc): [data] - Customer usage distribution: [P50, P90, P99] - Customer feedback on current model: [signals] - Cash predictability requirement: [investor expectations] </context> <output> 1. Margin variability under usage-based vs flat — model scenarios. 2. Customer-acquisition impact: easier entry vs harder forecasting for them. 3. Predictability hit: revenue forecastability decreases — quantify. 4. Hybrid models: base + usage, credits, committed-spend with overage. 5. Migration plan for existing customers (forced vs optional). 6. Recommendation with the riskiest assumption flagged. </output>

Decides usage-based pricing transition with margin, predictability, and hybrid options.

💡

Pro tip: Pure usage-based pricing kills enterprise procurement (they need budget predictability). Hybrid (committed base + overage) captures both — it's the most boring answer and usually right.

Lifetime Deal Decision

34/100

<task>Decide whether to offer a lifetime deal.</task> <context> - Product type: [recurring / one-time-ish] - Current MRR per customer: [average] - Cash runway: [months] - Distribution channel for LTD: [AppSumo, own audience, partnership] - Strategic stage: [need cash now / building long-term LTV] </context> <output> 1. Cash now vs revenue forever — break-even months calculation. 2. Customer-base composition risk: LTD buyers behave differently than recurring (more support, less loyal). 3. Pricing: LTD price that's break-even at year 2 vs year 3 vs year 5. 4. Cap: limited slots, sunset date, tiered. 5. Brand / positioning risk of being "the LTD product." 6. Recommendation: yes/no + structure if yes. </output>

Decides lifetime deal with cash-now vs LTV math and brand-risk analysis.

💡

Pro tip: LTDs are emergency cash with long-term cost. They work for short cash runways with sustainable margins; they wreck SaaS economics if abused.

Negotiation Floor & Ceiling

35/100

<task>Set negotiation floor and ceiling for [type of deal].</task> <context> - Typical deal size: [data] - Margin profile: [data] - Strategic value of close rate vs price: [describe] - Authority structure: [who can approve what] </context> <output> 1. List price (anchor). 2. Standard discount band: 0-15% (rep authority). 3. Manager escalation band: 15-25% (with justification). 4. Exec escalation band: 25-35% (rare, strategic only). 5. Walk-away floor: below this, decline the deal. 6. What we ask for in return at each discount level (commitment, term, expansion). </output>

Sets negotiation floor/ceiling with discount bands and what to ask for in return.

💡

Pro tip: Every discount should buy something — annual prepay, multi-year, case study, expansion. "Free discount" trains buyers to ask again next renewal.

Refund Policy Decision

36/100

<task>Decide our refund policy.</task> <context> - Current policy: [describe] - Refund rate: [%] - Top refund reasons: [list] - Customer service load from refunds: [hours/week] - Competitor policies: [describe] </context> <output> 1. Liberal vs strict refund — what each says about brand confidence. 2. 30-day money-back vs no-questions-asked vs case-by-case — abuse risk each. 3. Refund vs credit vs alternative compensation analysis. 4. Trial-first alternative: would a longer free trial reduce refund volume? 5. Annual revenue impact at each policy. 6. Recommendation + the exact policy language. </output>

Decides refund policy with abuse risk, trial alternative, and revenue impact.

💡

Pro tip: Liberal refund policies usually reduce churn complaints more than they cost in actual refunds. The math almost always favors generosity — flag if it doesn't.

Cancellation Win-Back Pricing

37/100

<task>Decide cancellation win-back offer.</task> <context> - Cancellation rate: [%] - Top cancellation reasons: [list] - Customer LTV vs CAC ratio: [data] - Current win-back attempts: [describe] </context> <output> 1. Win-back offer ladder: discount, pause, downgrade, custom — when to use each. 2. Triggers: which cancellation reasons get which offer. 3. Cost / benefit per offer: revenue retained vs concession given. 4. Brand risk: aggressive win-back can feel desperate. 5. Limit: cap on win-back attempts per customer per year. 6. Recommendation + scripts for the top 3 cancellation reasons. </output>

Builds cancellation win-back offer ladder with triggers and brand-risk balance.

💡

Pro tip: Win-back offers work best when they're calibrated to the cancellation reason. "Too expensive" → discount; "missing feature" → roadmap commit; "team change" → pause. Generic offers feel cheap.

Black Friday & Promo Decision

38/100

<task>Decide whether to run a Black Friday / seasonal promo.</task> <context> - Past promo performance: [if any] - Brand positioning: [premium / accessible / discount-friendly] - Customer expectations: [trained to wait for promos?] - Margin headroom: [%] - Team capacity for promo execution: [hours] </context> <output> 1. Strategic role of the promo: new acquisition / win-back / cash injection / cultural moment. 2. Promo structure options: % off, BOGO, gift, free trial extension, bundle. 3. Risk of training customers to wait: quantify if past data exists. 4. Margin impact: gross profit per new customer acquired through promo. 5. Comms plan: pre-launch tease, launch, last-call. 6. Recommendation + the kill criteria if performance is weak by day 2. </output>

Decides promo with strategic role, training-risk, and kill criteria.

💡

Pro tip: Promos work or don't in the first 48 hours. Set kill criteria upfront — if conversions are <50% of target by day 2, pull the promo before it trains expectations.

Competitive Repricing Reaction

39/100

<task>Decide how to react to [competitor] changing their pricing.</task> <context> - Competitor: [name] - Change: [their new pricing vs old] - Their positioning shift implied: [describe] - Our overlap: [shared customers / similar product] - Customer feedback on the change: [if any] </context> <output> 1. Did they raise (validates market) or lower (creates pressure)? 2. Match / hold / counter-position — three reaction options analyzed. 3. Customer-side: who'll defect either direction and why. 4. Sales enablement update: talking points for prospects asking about it. 5. Public response: silent vs subtle vs direct counter. 6. Recommendation + the 30-day measurement plan. </output>

Reacts to competitor pricing with match/hold/counter analysis and customer-defection modeling.

💡

Pro tip: Pricing matches usually lose — you race to the bottom on their schedule. Counter-positioning ("we're different and here's why") outlasts most price wars.

Hiring & People Decisions

19 prompts

When to Hire vs Outsource

40/100

<task>Decide whether to hire FTE or contract out [function].</task> <context> - Function: [describe] - Estimated hours/week needed: [number] - Specialized vs commodity skill: [describe] - Current team capacity: [if any] - Cash position: [runway] - 12-month forecast for the work: [growing / stable / one-time] </context> <output> 1. Total cost: FTE fully-loaded vs contractor (don't forget hidden FTE costs). 2. Output quality / consistency under each model. 3. IP / continuity risk of contractor. 4. Speed-to-productive: how fast each can deliver. 5. Reversibility: easier to end a contractor relationship than fire an FTE. 6. Recommendation + the 6-month review trigger to revisit. </output>

Decides FTE vs contractor with cost, continuity, and reversibility analysis.

💡

Pro tip: Contractor first, FTE when work is steady and strategic is the default for early-stage. Reverse the default if the work is core IP — never outsource the core.

First Hire in a New Function

41/100

<task>Design the first hire for [function] we don't have yet.</task> <context> - Function: [marketing / sales / product / etc.] - Current state: [founder-led / contractor / nothing] - 12-month goal for the function: [describe] - Team they'd work with: [list] - Reporting line: [direct to founder?] </context> <output> 1. Generalist vs specialist for the first hire — why. 2. Seniority decision: someone who can build alone vs someone who needs scaffolding. 3. Top 3 must-have skills + top 2 nice-to-haves. 4. Compensation band benchmark (with location adjustment if remote). 5. 90-day expected output to validate fit. 6. Red flags to screen for in interviews (function-specific). </output>

Designs first hire with generalist/specialist call, seniority, and 90-day fit criteria.

💡

Pro tip: First hire in a new function should be a player-coach — senior enough to set strategy, hands-on enough to actually do the work alone for 9-12 months.

Senior vs Junior Hire

42/100

<task>Decide whether to hire senior or junior for [role].</task> <context> - Role: [describe] - Existing team structure: [who they'd work with] - Mentorship capacity available: [hours/week] - Budget: [comp range] - Urgency: [need them productive in X weeks] </context> <output> 1. Senior pros: speed to productive, lower management overhead, hiring brand signal. 2. Junior pros: lower cost, longer tenure, growth path, culture-shaping. 3. Mentorship reality check: is there actually capacity to develop a junior? 4. Org-shape consequence: too many seniors = no growth path; too many juniors = bottlenecked seniors. 5. Recommendation + the alternative scenario (what changes if budget shifts). </output>

Decides senior vs junior hire with mentorship reality check and org-shape consequence.

💡

Pro tip: The "is there actually capacity to develop a junior?" reality check kills most well-intentioned junior hires. If existing seniors are at capacity, the junior will not get mentored — they'll get neglected.

Compensation Floor & Ceiling

43/100

<task>Set compensation band for [role].</task> <context> - Role: [title + level] - Location flexibility: [remote / hub-based] - Top 2 competitors for this talent: [companies they'd consider] - Internal equity reference points: [comp of comparable role] - Cash vs equity philosophy: [our stance] </context> <output> 1. Market data: 25th, 50th, 75th percentile from public sources (Levels, Pave, Glassdoor estimates). 2. Internal equity check: where does this sit vs other roles at same level? 3. Floor: minimum we'd offer + why. 4. Anchor: opening offer. 5. Ceiling: above this, requires founder approval. 6. Equity grant + vesting if applicable. </output>

Sets compensation band with market data, internal equity, and floor/anchor/ceiling.

💡

Pro tip: Internal equity matters more than market data for retention. New hire making more than tenured peer at same level is the single biggest avoidable culture wound.

Performance Improvement vs Let Go

44/100

<task>Decide whether [team member] is salvageable or should be let go.</task> <context> - Person: [role, tenure] - Specific performance issues: [list with examples] - Their strengths: [be specific] - Manager feedback / coaching given: [history] - Team impact: [morale, output, blocking others] </context> <output> 1. Skill issue vs will issue vs fit issue — diagnose. 2. PIP viability: are the gaps coachable in 60-90 days? 3. Cost of keeping (their salary + team drag + manager time). 4. Cost of replacing (recruit, ramp, severance). 5. Team-side honesty: what would the team think if we kept them / let them go? 6. Recommendation + the conversation plan. </output>

Decides PIP vs let-go with skill/will/fit diagnosis and team-side honesty check.

💡

Pro tip: The "what would the team think?" check exposes most stalled fire decisions. Teams know who isn't working out 60 days before management does — keeping them costs respect.

Promotion Decision

45/100

<task>Decide whether to promote [team member] to [next level].</task> <context> - Person: [role, tenure] - Performance against current level: [reviews / wins / metrics] - Evidence of next-level operation: [specific examples] - Comparable peers at the next level: [for calibration] - Team-impact of promotion (positive / negative): [describe] </context> <output> 1. Operating at next level NOW (not "potential") — yes / partial / no, with evidence. 2. Promotion gaps that need closing first — list with timelines. 3. Comp adjustment required at next level. 4. Team-side reaction: who'd be upset, who'd be inspired. 5. Risk of NOT promoting (flight risk, motivation, signal to team). 6. Recommendation + comms plan. </output>

Decides promotion using "operating at next level NOW" test and flight-risk balance.

💡

Pro tip: The "operating at next level NOW" test prevents most premature promotions. Promotion reward past performance; the new level is a new job, not an extension of the current one.

Team Structure Reorg

46/100

<task>Reorganize [team / org] structure.</task> <context> - Current structure: [describe] - Pain points: [decision speed, accountability, communication] - Strategic priorities for next 12 months: [list] - Team size: [current + planned hires] </context> <output> 1. Diagnosis of structural pain: who's blocked by what? 2. 2-3 alternative structures with pros/cons each. 3. Reporting line changes required. 4. Title / role changes (any demotions disguised as moves?). 5. Comms sequence: who hears first, what gets shared when. 6. Recommended structure + the 30-60-90 day rollout. </output>

Reorganizes team structure with structural-pain diagnosis and rollout sequence.

💡

Pro tip: Most reorgs hide a fire decision (someone gets a "new role" that's actually a demotion). Call it out — clean reorgs solve structural problems; political reorgs create new ones.

Remote vs In-Office Hire

47/100

<task>Decide remote vs in-office for [role].</task> <context> - Role: [describe] - Team's current distribution: [remote / hybrid / in-office] - Role-specific collaboration needs: [describe] - Talent pool size at each option: [local vs national vs global] - Comp differential by geography: [estimate] </context> <output> 1. Talent pool size: local vs national vs global — order of magnitude. 2. Role's collaboration profile: lone-wolf / pair / heavy meeting. 3. Comp implications under each model. 4. Onboarding considerations: remote ramps slower without structure. 5. Manager-side capacity to manage remote. 6. Recommendation + the dealbreaker that'd flip it. </output>

Decides remote vs in-office with talent-pool size and collaboration-profile analysis.

💡

Pro tip: For specialized roles, remote 10x's the talent pool. For pair-heavy roles (sales, design), remote works only with deliberate collaboration infrastructure.

Internal vs External Hire

48/100

<task>Decide whether to fill [role] internally or externally.</task> <context> - Role: [describe] - Internal candidates: [list with current roles] - External market: [easy / hard to recruit] - Role's strategic newness: [continuity vs change?] </context> <output> 1. Internal candidate readiness: are they at level now, or 6 months away? 2. External hire upside: fresh perspective, broader experience. 3. Internal hire upside: continuity, retention signal, culture fit. 4. Risk of passing over an internal candidate (motivation, attrition). 5. Hybrid: external hire with internal stretch role created. 6. Recommendation + comms plan. </output>

Decides internal vs external hire with readiness, pass-over risk, and hybrid options.

💡

Pro tip: Promoting internal sends a powerful signal to the team — but only if the person is actually ready. A stretch promotion that fails costs more than an external hire.

Equity Grant Decision

49/100

<task>Decide equity grant for [hire / promotion].</task> <context> - Role: [level + function] - Stage of company: [seed / Series A / B / later] - Cash comp offered: [amount] - Internal equity reference points: [comparable existing grants] - Their previous equity expectations: [if known] </context> <output> 1. Stage-adjusted equity range for this level (e.g., seed eng level 3: 0.1-0.3%). 2. Internal equity check: where does this sit vs peers? 3. Cliff / vest schedule (standard 4-year, 1-year cliff vs alternatives). 4. Refresh schedule: when next grant comes. 5. Cash-vs-equity trade: are they more cash-motivated or upside-motivated? 6. Recommendation + offer language. </output>

Decides equity grant with stage-adjusted range and internal equity check.

💡

Pro tip: Equity grants below 0.1% rarely motivate; above 1% rarely make economic sense outside founding team. Internal equity matters more than market — discovery destroys trust.

Counteroffer Decision

50/100

<task>Decide whether to counter-offer [departing team member].</task> <context> - Person: [role, tenure, performance] - Their stated reason for leaving: [if known] - Their new offer: [amount + role + company if known] - Strategic value to us: [be honest] - Counter-offer history at our company: [any precedent?] </context> <output> 1. Is the actual motivator money or something else? (Money usually masks the real reason.) 2. Counter math: cost of counter vs cost of replacement and ramp. 3. Counter-offers fail 70% of the time within 12 months — apply to this case. 4. Precedent risk: counter-offering one teaches others to fish. 5. Goodwill exit alternative: structured handoff, recommendations, alumni network. 6. Recommendation + the conversation. </output>

Decides counter-offer with motivator-diagnosis and precedent-risk analysis.

💡

Pro tip: Counter-offers almost always fail because money isn't the actual issue — it's management, growth, or culture wearing a money mask. Address the real issue or let them go.

Manager Hire Decision

51/100

<task>Decide whether to hire a manager for [team].</task> <context> - Team size: [count] - Current manager: [founder-led / IC-leading / nobody] - Team's pain points: [communication, prioritization, growth] - Strategic priorities the team owns: [list] </context> <output> 1. Team size threshold check: typically managers needed at 5-7 direct reports. 2. Founder bandwidth check: hours/week currently spent managing this team. 3. IC-promotion alternative: can someone on the team grow into the role? 4. External manager hire vs internal promotion — pros/cons each. 5. Risk: bad managers do more damage than no manager. Hiring bar. 6. Recommendation + the 90-day fit milestones. </output>

Decides manager hire with team-size threshold and founder-bandwidth audit.

💡

Pro tip: Hiring a manager too early creates middle-management layers in a small team; too late burns the founder out and team performance flatlines. 5-7 reports is the typical inflection.

Replace vs Restructure After Departure

52/100

<task>Decide whether to replace [departing role] or restructure work.</task> <context> - Departing role: [describe] - Their actual outputs in last 6 months: [list] - Team capacity if work redistributed: [estimate] - Strategic importance of the function: [be honest] </context> <output> 1. Output audit: which outputs were valuable, which were vestigial? 2. Redistribution map: who could absorb what (with capacity check). 3. Replacement option: same role / different role / not refilled. 4. Cost: hire cost + manager time vs redistribution overhead. 5. Risk: under-resourcing creates burnout 90 days later. 6. Recommendation + the 60-day re-evaluation criteria. </output>

Decides replace vs restructure after a departure with output audit and redistribution map.

💡

Pro tip: Departures expose role vestiges. Force the output audit — half of what someone did may turn out to be unneeded once they're gone.

Layoff Selection Criteria

53/100

<task>Define layoff selection criteria for [headcount reduction].</task> <context> - Cut size: [number / %] - Strategic priorities post-cut: [what must keep functioning] - Team distribution: [function and seniority breakdown] - Tenure / performance data: [available] - Legal jurisdiction: [WARN Act, etc.] </context> <output> 1. Strategic-need filter: which functions / roles must remain intact. 2. Performance filter: where lower-quartile performers exist. 3. Redundancy filter: where role overlap exists. 4. Criteria documented: explicit, defensible, applied consistently. 5. Legal review checklist: protected classes, WARN Act, severance norms. 6. Final selection framework + the executive sign-off process. </output>

Defines layoff selection criteria with strategic, performance, and legal filters.

💡

Pro tip: Layoff criteria must be documented before names are picked. Reverse order (pick names, then justify) creates legal and cultural exposure.

Severance Package Decision

54/100

<task>Decide severance package for [layoff / single termination].</task> <context> - Type: [layoff / performance / mutual] - Person / group: [describe] - Tenure: [data] - Geographic / legal jurisdiction: [list] - Budget for severance: [if any] </context> <output> 1. Statutory minimum by jurisdiction. 2. Industry / stage norms (e.g., early-stage SaaS: 2-4 weeks per year tenure). 3. Goodwill premium: extra weeks for layoff vs performance. 4. Benefits continuation: COBRA, equipment, references, alumni. 5. Release / non-disparagement: scope and risks. 6. Recommended package + total cost. </output>

Builds severance package with statutory, industry-norm, and goodwill components.

💡

Pro tip: Severance is the last cultural message you send a departing employee — and their network. Statutory-minimum severance saves money and costs talent-brand reputation for years.

Founding Team Equity Split

55/100

<task>Decide founding-team equity split.</task> <context> - Founders: [list with roles] - Idea origin: [who] - Capital contributed: [if any] - Time commitment so far: [full-time / part-time per founder] - Future time commitment: [planned] </context> <output> 1. Equal split vs role-weighted vs contribution-weighted — pros/cons each. 2. Vesting: standard 4-year cliff vs alternatives (especially with prior work). 3. Reverse vesting / leaver provisions: bad-leaver, good-leaver scope. 4. Pre-formation work credit (idea, IP, prototype). 5. Future-dilution expectations: who's OK with which dilution path. 6. Recommended split + the conversation to have before signing. </output>

Decides founding equity split with vesting, leaver provisions, and conversation prep.

💡

Pro tip: Founding splits should be argued out and put in writing before any product is built. Almost equal-but-not-quite splits cause more disputes than clean unequal ones.

Co-Founder Conflict Resolution

56/100

<task>Help me decide how to resolve [co-founder conflict].</task> <context> - Conflict: [describe] - History: [recurring vs one-off] - Stakes: [low / company-existential] - Each founder's stated position: [list] - Each founder's underlying interest (often different from position): [if known] </context> <output> 1. Position vs interest analysis: what does each side actually want? 2. Decision rights: whose call is this by function / by stake? 3. Options menu: 4-5 ways to resolve, ranked by mutual acceptability. 4. The conversation: how to start it without it spiraling. 5. Worst-case planning: if this isn't resolvable, what does separation look like? 6. Recommended next step (sometimes that's a 3rd-party mediator, not an answer). </output>

Resolves co-founder conflict using position vs interest, decision rights, and options menu.

💡

Pro tip: Most co-founder fights are interest fights wearing position clothing. "I want X" usually means "I'm afraid of Y" — name the fear and the fight gets simpler.

Performance Review Tier Allocation

57/100

<task>Allocate performance review tiers across the team.</task> <context> - Team: [count + roles] - Performance signals: [outputs, peer feedback, manager feedback] - Last cycle's distribution: [if any] - Compensation budget for raises: [%] - Calibration goals: [forced ranking, no-forced-ranking, hybrid] </context> <output> 1. Tier definitions: top-performer, strong, meets, below — what each looks like. 2. Distribution: forced curve vs natural distribution — pros / cons. 3. Calibration: cross-team comparison to prevent inflation. 4. Edge cases: new hires, parental leave returners, role-change mid-cycle. 5. Raise / bonus / equity refresh implications per tier. 6. Recommended distribution + manager conversation guide. </output>

Allocates performance review tiers with calibration, edge cases, and manager guide.

💡

Pro tip: Performance tier inflation creeps in every cycle — managers want to give their reports the top tier. Cross-team calibration is the only counter; without it, "Exceeds Expectations" becomes meaningless.

Job Description Trade-Off

58/100

<task>Refine job description for [role] by deciding which requirements are must-have vs nice-to-have.</task> <context> - Role: [title] - Initial JD: [paste] - Talent pool reality: how rare each requirement is in the market. - Strategic must-do outputs: [what they actually need to deliver] </context> <output> 1. Must-haves (3-5 max): non-negotiable, would fail without. 2. Nice-to-haves: helpful but not required. 3. Disqualifiers: filters in screening. 4. The "kitchen sink" items in the original JD that probably aren't needed. 5. Diversity-of-pool check: does the JD as written exclude qualified candidates? 6. Rewritten JD + the candidate persona. </output>

Refines job description by separating must-haves from nice-to-haves and exposing kitchen-sink bloat.

💡

Pro tip: Most job descriptions have 12 must-haves and find nobody. Cutting to 3-5 must-haves opens the pool 3-5x. Force ranking is the unlock.

These prompts give you the what. Tutorials give you the why.

Learn when to use extended thinking, how to build Claude Projects, and workflows that compound. 300+ tutorials and growing.

Try AI Academy Free

Scope & Strategy Decisions

20 prompts

Quarterly Plan Stress-Test

59/100

<task>Stress-test my Q[X] plan and surface the assumptions it depends on.</task> <plan> - Goals: [list] - Key initiatives: [list] - Resources committed: [hours, headcount, dollars] - Success criteria: [how we'll know] </plan> <output> 1. The 4-5 assumptions this plan depends on (often unstated). 2. Each assumption ranked by fragility (most likely to break first). 3. Leading indicators that'd tell us an assumption is breaking — 60 days before it's obvious. 4. Pre-mortem: imagine this plan failed. What's the most likely failure path? 5. Top 3 things to validate in the first 30 days. 6. The hardest part of the plan nobody's talking about. </output>

Stress-tests a plan and ranks its assumptions by fragility.

💡

Pro tip: The "what nobody's talking about" prompt is Claude's superpower here — it surfaces the elephant before the quarter is half over. Run this on day 1 of every quarter.

Pivot Decision

60/100

<task>Help me decide whether to pivot [direction].</task> <context> - Current product / market: [describe] - Pivot proposal: [where we'd go] - Evidence for pivot: [what's not working in current state] - Evidence against pivot: [what is working] - Pivot cost: [time, money, team, reputation] </context> <output> 1. What's actually broken in current state — is it product, market, distribution, timing? 2. Is the pivot solving the actual problem or projecting hope onto something new? 3. Pivot specificity: pivot WHAT — product, customer, business model, channel? 4. Reversibility: how much of current state we'd lose vs preserve. 5. 90-day pivot validation milestones. 6. Recommendation + the strongest counter-argument. </output>

Decides pivot direction with what-is-broken diagnosis and reversibility analysis.

💡

Pro tip: Many pivots solve the wrong problem. The "WHAT are you pivoting?" specificity check prevents vague "let's try something new" pivots — pivot product, customer, channel, or model, not all four.

Focus Decision

61/100

<task>Help me decide which one bet to focus on.</task> <context> - Options on the table: [list] - Evidence for each: [what we know] - Resources we have: [time, headcount, cash] - Win conditions: [what success looks like for each] </context> <output> 1. Each option scored on: market size, conviction, time-to-evidence, fit with team. 2. Mutually exclusive vs sequencable: can we do A then B, or is it really either/or? 3. The cost of NOT picking each one (regret cost). 4. The cost of picking each one (commitment cost). 5. The bet that maximizes information vs the bet that maximizes outcome. 6. Recommendation + the kill criteria for the chosen bet. </output>

Decides focus among competing bets with regret-cost vs commitment-cost analysis.

💡

Pro tip: The "information vs outcome" frame is the cleanest focus decision. Early-stage, pick the bet that maximizes information (you learn fast). Later-stage, pick the bet that maximizes outcome (you bet big).

Roadmap Sequencing

62/100

<task>Sequence roadmap items for the next 6 months.</task> <context> - Items on the table: [list with rough effort] - Strategic priorities: [list] - Customer commitments: [if any] - Team capacity: [data] - Compounding items vs one-off items: [if categorized] </context> <output> 1. Dependencies: which items unblock or accelerate others? 2. Risk-adjusted value per item. 3. Compounding sequence vs one-off sequence — which order builds momentum? 4. Customer-commitment fixed dates (can't reschedule). 5. Capacity allocation: % of team time per item. 6. Recommended 6-month sequence + 30/60/90 day milestones. </output>

Sequences roadmap with dependencies, compounding value, and capacity allocation.

💡

Pro tip: Roadmap sequencing fails when items are treated equally. Compounding items (where one unlocks the next) belong first; one-offs go in the gaps.

Build vs Buy Decision

63/100

<task>Decide whether to build or buy [capability].</task> <context> - Capability: [describe] - Build cost estimate: [time + dollars] - Available products to buy: [list with pricing] - Strategic differentiation: is this core or context? - Team's interest in building: [be honest] </context> <output> 1. Core vs context check: is this in our differentiation, or just necessary plumbing? 2. Total cost of ownership: build (with maintenance) vs buy (with subscription compounding). 3. Time-to-value: when does each option produce. 4. Vendor risk: lock-in, pricing power, ecosystem health. 5. Reversibility: easier to buy then build than build then buy. 6. Recommendation with the 18-month review point. </output>

Decides build vs buy with core-vs-context check and total-cost-of-ownership.

💡

Pro tip: Build the core, buy the context. The "would we win because we built this?" question separates differentiation from infrastructure. If no, buy.

Build vs Partner

64/100

<task>Decide whether to build [capability] or partner with someone who has it.</task> <context> - Capability: [describe] - Potential partners: [list] - Build cost: [estimate] - Strategic value of owning it: [describe] - Customer adoption needs: [describe] </context> <output> 1. What customers need vs what we need: do customers care WHO delivers? 2. Margin / unit economics under each path. 3. Partnership lock-in risk: what happens if partner changes strategy. 4. Time-to-market under each path. 5. Capability staying current: who's better at keeping it competitive — us or them? 6. Recommendation + partnership terms or build sequence. </output>

Decides build vs partner with customer perception, lock-in risk, and capability-staying-current analysis.

💡

Pro tip: Partner-first lets you ship faster and learn customer demand before committing to a build. Build-first lets you control margin and customer experience. Stage of company often dictates.

Geographic Expansion Decision

65/100

<task>Decide whether to expand to [geography].</task> <context> - Current geo: [primary market] - Target geo: [describe] - Why now: [signal that triggered the question] - Local capability needs: [language, support, payments, legal] - Investment required: [estimate] </context> <output> 1. Demand evidence in target geo (organic signal vs hope). 2. Local capability gaps: language, payments, support, legal, sales motion. 3. Light vs full expansion: try-it-with-existing-product vs localized-product. 4. Investment + 18-month financial outlook. 5. Distraction cost: focus pulled from core geo. 6. Recommendation + the 90-day validation experiment. </output>

Decides geographic expansion with demand evidence, capability gaps, and validation experiment.

💡

Pro tip: Most geographic expansions fail on distraction cost, not market opportunity. The light-expansion validation experiment (sell existing product to existing customers asking from that geo) beats premature full localization.

Vertical vs Horizontal Expansion

66/100

<task>Decide whether to expand vertically or horizontally.</task> <context> - Current product: [describe] - Current customer: [describe ICP] - Vertical expansion option: deeper for current ICP — [describe] - Horizontal expansion option: same product, new ICP — [describe] - Evidence pulling each direction: [list] </context> <output> 1. Pull strength: which direction is the market asking for, with evidence? 2. Capability fit: which direction matches what we already know? 3. Compounding: which direction creates lock-in or expansion revenue? 4. Risk: which direction breaks our current customer story? 5. Sequencing: can we do one then the other? 6. Recommendation + the leading indicator we'd watch for 90 days. </output>

Decides vertical vs horizontal expansion with pull-strength, compounding, and sequencing analysis.

💡

Pro tip: Vertical expansion (deeper for same ICP) usually compounds; horizontal expansion (new ICP) usually doesn't. Default to vertical unless the current ICP is exhausted.

Open Source vs Proprietary

67/100

<task>Decide whether to open-source [component / product].</task> <context> - What's being considered: [describe] - Strategic role: [acquisition / community / standard-setting / hiring] - Business model implications: [how we monetize if open-sourced] - Competitive risk: [who'd benefit] - Team capacity to maintain open-source community: [hours/week] </context> <output> 1. Strategic role: is open source actually serving what we claim it serves? 2. Business model fit: open core, dual-license, services, sponsored development — which? 3. Competitive risk: who benefits more from open source — us or competitors? 4. Maintenance reality: open source isn't free — community management cost. 5. License choice: MIT / Apache / GPL / source-available — implications. 6. Recommendation + the success metric for year 1. </output>

Decides open source vs proprietary with strategic role, business model, and license choice.

💡

Pro tip: Open-sourcing as a marketing tactic almost always fails — you take on maintenance for no clear return. Open-source works when the community participation creates a moat or a standard.

Free vs Paid Feature Decision

68/100

<task>Decide whether [feature] should be free or paid.</task> <context> - Feature: [describe] - Cost to build/maintain: [data] - Customer value: [how much pain it solves] - Strategic role: acquisition vs expansion vs retention - Current free/paid split philosophy: [describe] </context> <output> 1. Feature's strategic role: hook (free) / value (paid) / retention (free). 2. WTP signal: would customers pay separately? 3. Adoption ceiling: does paid gating prevent the network effects we need? 4. Pricing tier fit: which existing tier should it be in? 5. Cannibalization risk: does it weaken anything paid we already offer? 6. Recommendation + the rollout test. </output>

Decides free vs paid feature with strategic role, WTP, and adoption-ceiling analysis.

💡

Pro tip: Free vs paid is really a "what role does this feature play?" question. Hook features must be free; value-extraction features should be paid; muddle in between confuses both.

Launch Sequencing

69/100

<task>Sequence the launch of [feature / product / campaign].</task> <context> - Launch elements: [product, marketing, sales, PR, partnerships] - Strategic goals: [awareness, signups, revenue, narrative] - Dependencies: [what must happen before what] - Risk tolerance: [bold launch vs phased] </context> <output> 1. Risk-adjusted launch model: stealth → soft → public, vs big-bang. 2. Pre-launch sequence: alpha, beta, waitlist, design partners. 3. Launch day: PR, social, email, sales enablement, customer comms. 4. Post-launch: 7-day, 30-day, 90-day milestones. 5. Kill criteria: what'd make us pull / pause the launch. 6. Recommended sequence + the single biggest risk in it. </output>

Sequences launch with risk-adjusted model, pre/launch/post phases, and kill criteria.

💡

Pro tip: Big-bang launches make great press but bury most early-stage products under attention they can't serve. Phased launches catch issues before scale exposes them.

Market Timing Decision

70/100

<task>Decide whether to launch [thing] now or wait.</task> <context> - Thing: [describe] - Readiness: [where it is vs ideal] - Market signals: [what's happening externally] - Competitor activity: [imminent or quiet] - Cost of waiting: [opportunity, runway, momentum] - Cost of launching now: [unfinished, missing features] </context> <output> 1. Market window: is it opening or closing? Evidence. 2. Readiness threshold: what'd be unacceptable to launch without? 3. First-mover vs fast-follower trade-offs. 4. Internal momentum: launch-now energy vs polish-more morale. 5. Reversibility: can we launch now and fix later, or is this one-shot? 6. Recommendation + the 30-day go/no-go criteria. </output>

Decides market timing with window analysis, readiness threshold, and first-mover trade-offs.

💡

Pro tip: Most "wait until it's perfect" stalls cost more than the launch flaws would have. Reversibility matters more than polish — if you can fix in flight, launch.

Niche vs Broaden Decision

71/100

<task>Decide whether to niche down further or broaden out.</task> <context> - Current positioning: [describe ICP] - Wins / losses by segment: [data] - Distribution channel fit by segment: [data] - Competitive density by segment: [data] - Strategic ambition: [niche dominance vs broad reach] </context> <output> 1. Niche-down case: deeper differentiation, lower CAC, faster reference building. 2. Broaden case: bigger TAM, more dependencies, harder positioning. 3. Where wins are coming from now: signal of where to lean. 4. Where losses are coming from: signal of where you're not yet winning. 5. The unbreakable promise you'd make to the niche (or broad market). 6. Recommendation + 12-month leading indicator to watch. </output>

Decides niche down vs broaden with win/loss signal and promise-strength check.

💡

Pro tip: When in doubt, niche down. Niches are where references compound and CAC stays low. Broadening early kills both. The smallest viable audience is usually still bigger than it looks.

Brand Repositioning Decision

72/100

<task>Decide whether to reposition the brand.</task> <context> - Current positioning: [describe] - Why it's being questioned: [signals] - Proposed positioning: [if any] - Brand equity built: [years, customer recognition, search volume] - Switching cost: [internal effort + external relearning] </context> <output> 1. Is the current positioning broken, or is the messaging just stale? 2. What customers think we are vs what we think we are — gap analysis. 3. Repositioning options: tweak / refresh / hard reset. 4. Risk: alienating existing customers vs being invisible to new ones. 5. Transition plan: rename, redesign, relaunch — sequencing. 6. Recommendation + 90-day measurement plan. </output>

Decides brand repositioning with broken-vs-stale diagnosis and risk analysis.

💡

Pro tip: Most "we need to reposition" requests are messaging problems, not positioning problems. Force the gap analysis — if customers describe you well, the positioning isn't broken.

Naming Decision

73/100

<task>Decide a name for [product / feature / company].</task> <context> - What it is: [describe] - Audience: [describe] - Brand context: [parent brand if any] - Constraints: [domain availability, trademark, search competition] - 3-5 candidate names: [list] </context> <output> 1. Each candidate scored on: pronounceability, memorability, distinctiveness, scaleability. 2. Trademark / domain availability check. 3. Search competition: who else owns this term in SEO. 4. International concerns: meaning in other languages. 5. 10-year scalability: does the name limit what the product can become? 6. Recommendation + a fallback if first choice has issues. </output>

Decides naming with scoring, trademark, search competition, and scalability check.

💡

Pro tip: The "10-year scalability" check kills cute but limiting names. "Productivity app for dentists" is a great product description and a terrible name once you expand to doctors.

Domain Acquisition Decision

74/100

<task>Decide whether to buy [premium domain] for [amount].</task> <context> - Domain: [name] - Asking price: [amount] - Alternative domains we own / could use: [list] - Strategic value: [SEO, brand, defensive] - Current usage by seller: [parked, monetized, used] </context> <output> 1. Domain value categories: brand match, SEO authority, defensive, vanity. 2. Comparable sales for similar domains in this category. 3. ROI math: how much revenue / brand value over 5 years justifies the spend? 4. Alternatives: settle for .co / .ai / different name at much lower cost. 5. Negotiation: ceiling, opening offer, walk-away. 6. Recommendation: buy / negotiate down / pass. </output>

Decides domain acquisition with value-category, ROI math, and alternatives.

💡

Pro tip: Premium domain prices are anchor games. Most buyers pay 2-3x rational value because they've fallen in love with the name. Force the ROI math before negotiating.

Public Launch vs Stealth

75/100

<task>Decide between public launch and continued stealth.</task> <context> - Where we are: [stage, traction] - Public launch upside: [PR, hiring, fundraising, customers] - Stealth upside: [no competitor pressure, slow learning, no PR exposure] - Team's energy / public-readiness: [be honest] - Competitive risk if visible: [low / high] </context> <output> 1. What does going public BUY us right now — be specific. 2. What does going public COST us — competitor attention, hiring expectations, PR drag. 3. Halfway: tier-1 customers know, public doesn't (semi-stealth). 4. The forcing function: what'd make us go public regardless (fundraise, hiring, customer demand). 5. Comms plan if public, stealth-preservation if not. 6. Recommendation + the trigger event. </output>

Decides public launch vs stealth with explicit cost/benefit and semi-stealth option.

💡

Pro tip: Stealth past Series A signals avoidance or weakness. Most companies launch publicly because they need to hire — that's the right reason. "Not ready" is usually fear, not strategy.

Founder Title & Role Decision

76/100

<task>Decide founder's title and role as the company scales.</task> <context> - Current title: [CEO / co-founder / etc.] - Current scope: [what they actually do] - Company stage: [seed / Series A / B / later] - Team composition: [executive team in place?] - Founder's strengths / weaknesses: [be honest] </context> <output> 1. CEO vs CPO vs CTO vs Chairman — what each title means at this stage. 2. Role narrowing: which areas should the founder hand off and to whom. 3. Energy match: where founder produces 10x value vs 1x value. 4. Title signaling: external vs internal implications of each option. 5. Successor / second-in-command: who covers what. 6. Recommendation + the 90-day handoff plan. </output>

Decides founder role/title with energy match and successor planning.

💡

Pro tip: Founder titles often outlast their useful scope. The "where do you produce 10x value?" question separates strategic founder work from work the founder happens to be doing.

Quitting a Strategy

77/100

<task>Help me decide whether to quit [strategy / approach].</task> <context> - Strategy: [describe] - Time committed: [months / years] - Results vs goals: [data] - What we'd lose by quitting: [list] - What we'd gain by quitting: [list] </context> <output> 1. Quitting is hard because it codes as failure — separate quitting from failure. 2. Stage of strategy: should it have worked by now? What's the typical timeline? 3. Doubling-down alternative: what'd it take to actually make this work — is it within reach? 4. The 80% test: if you'd told yourself at the start "this would happen," would you have started? 5. Quit-cost: pride, reputation, sunk effort. 6. Recommendation + the language for explaining the quit. </output>

Decides whether to quit a strategy with the 80% test and quit-cost framing.

💡

Pro tip: The "would I have started knowing this would happen?" test (variant of fresh-start) is the cleanest quit decision. If no, the right question isn't whether to quit but how.

Re-org Decision

78/100

<task>Decide whether to re-org [team / company].</task> <context> - Current state: [structural pains] - Proposed re-org: [if any] - Reasons floated for re-org: [list] - Last re-org: [when, what changed, what worked / didn't] </context> <output> 1. Is the actual problem structural, or are we using re-org to avoid people decisions? 2. Re-org cost: 3-6 months of disruption, attrition risk, lost context. 3. Alternative: fix process, fix manager, fix one role — without org redesign. 4. Re-org payoff: what does the new structure unlock that current doesn't. 5. Comms / sequence / 90-day stability metric. 6. Recommendation + the rules for what NOT to also change while re-orging. </output>

Decides re-org with structural-vs-people-problem diagnosis and disruption cost.

💡

Pro tip: Most re-orgs hide people problems. The "is this structural or people?" check is brutal — re-organizing to avoid firing one person costs the whole team 3 months of disruption.

Partnerships & External Decisions

20 prompts

Partnership Yes/No

79/100

<task>Decide whether to enter [partnership].</task> <partnership> - Partner: [name] - Type: [referral / co-marketing / integration / reseller / strategic] - Proposed structure: [describe] - Their expected value to us: [describe] - Our expected value to them: [describe] </partnership> <output> 1. Strategic fit: does this advance our north star or distract? 2. Asymmetric value: are we getting equal value or are we doing more? 3. Lock-in / exclusivity terms: dangerous or fine? 4. Operating cost: hours/month to actually deliver our side. 5. Reversibility / off-ramp: can we exit cleanly if it underperforms? 6. Recommendation + the 90-day milestone to evaluate. </output>

Decides partnership with asymmetric-value, lock-in risk, and reversibility analysis.

💡

Pro tip: Partnerships fail when the value isn't equal. The "are we doing more?" question kills most asymmetric deals before the wedding is over.

Integration Partner Selection

80/100

<task>Decide which [type of] integration partner to prioritize building with.</task> <options>[list candidates with: user overlap, technical fit, strategic alignment, partnership program quality]</options> <output> 1. Each option scored on: user overlap, partnership program leverage, technical effort, strategic alignment. 2. Distribution leverage: which partner's marketing actually moves the needle for us? 3. Engineering cost: which integration is reasonable vs swamping us? 4. Mutual incentive: which partner cares about us, vs which we'd be one of 100 to? 5. Sequencing: 1 deep, 3 shallow — or 1 deep first? 6. Recommendation + the success criteria for the first integration. </output>

Selects integration partner with leverage, effort, and mutual-incentive scoring.

💡

Pro tip: Most integration partnerships fail on mutual incentive. Big platforms have 1000 integration partners — you're one of many. Start where you matter to them.

Reseller / Channel Partner Decision

81/100

<task>Decide whether to set up a reseller / channel partner program.</task> <context> - Current sales motion: [direct, hybrid] - Margin structure: [room for partner cut?] - Strategic geo / vertical fit for partners: [describe] - Team capacity for partner management: [hours] </context> <output> 1. Strategic fit: are channels the natural distribution for our product? 2. Margin math: what % can we give partners and still make it work? 3. Channel conflict: where direct sales and channel collide on accounts. 4. Partner enablement requirements: training, certification, support. 5. Pilot model: 2-3 partners first vs full open program. 6. Recommendation + the 6-month go/no-go criteria. </output>

Decides reseller program with margin math, channel-conflict, and pilot scope.

💡

Pro tip: Reseller programs need 30%+ margin available to give partners — most early-stage SaaS doesn't have that. Force the margin math first.

Acquisition Offer Evaluation

82/100

<task>Evaluate [acquisition offer] for our company.</task> <offer> - Acquirer: [company] - Offer: [structure: cash, stock, earnout] - Total enterprise value: [amount] - Strategic rationale (theirs): [describe] - Timeline / urgency: [their pacing] </offer> <output> 1. Value comparison: offer vs realistic 3-year independent value. 2. Strategic fit: do we believe their thesis for us under the new umbrella? 3. Lock-up / earnout / retention risk: how much of the value depends on staying. 4. Team-side: who'd thrive vs who'd leave post-acquisition. 5. Negotiation leverage: what we can push on (price, structure, autonomy). 6. Recommendation + the 4 alternative outcomes (counter, walk, accept, multi-bid). </output>

Evaluates acquisition offer with independent-value comparison and earnout risk.

💡

Pro tip: Most acquisition decisions fail by under-weighting earnout / lock-up risk — half the headline value never lands. Compare cash-at-close to independent 3-year value, not headline to headline.

Acquihire Decision

83/100

<task>Decide whether to accept [acquihire offer] vs continue independent.</task> <context> - Stage: [pre-revenue / early revenue / etc.] - Runway: [months] - Team morale / energy: [be honest] - Offer: [team retention + small premium typically] - Independent path: realistic chance of bigger outcome </context> <output> 1. Independent-path probability honestly assessed. 2. Acquihire outcome for: founders, team, investors. 3. Team future: do they get good roles or get shelved at the acquirer? 4. Personal: founder reputation, network, future-fundraise implications. 5. Walk-away option viability. 6. Recommendation + the negotiating points if proceeding. </output>

Decides acquihire with independent-path probability and team-future check.

💡

Pro tip: Acquihires often hide failed-company guilt under a label of success. They're sometimes the right move, but the team future check (where do your people actually land?) matters more than the headline.

Investor Selection

84/100

<task>Decide which investor / term sheet to take.</task> <options>[list term sheets with: valuation, partner, fund stage, value-add reputation, terms]</options> <output> 1. Each option scored on: valuation, partner quality, fund stage, follow-on capacity, network value, terms cleanliness. 2. The 10-year-relationship view: which partner do we want on this cap table for a decade. 3. Term gotchas: liquidation preference, anti-dilution, board composition, info rights. 4. Speed-to-close: which can move fastest if speed matters. 5. Reference checks: what 3 founders they've backed say about working with them. 6. Recommendation + the negotiation moves before signing. </output>

Selects investor with partner-quality, term gotchas, and 10-year-view scoring.

💡

Pro tip: Valuation is the most-cited but least-important factor in term sheet selection. Partner quality, fund stage match, and term cleanliness beat 20% higher valuation almost every time.

Fundraise vs Bootstrap

85/100

<task>Decide whether to fundraise or bootstrap from here.</task> <context> - Current state: [revenue, growth, runway] - Capital needs: [what we'd actually use money for] - Path-without-capital: [what we can build from cash flow] - Founder ownership preference: [how much dilution acceptable] - Market opportunity: [winner-take-most vs fragmented] </context> <output> 1. Use of funds: what exactly capital would buy that bootstrap can't. 2. Bootstrap path: realistic ramp at current capital efficiency. 3. Market dynamics: does this market reward fast-and-funded or slow-and-profitable? 4. Dilution math: % given vs % we'd retain in either path at year 5. 5. Founder energy: fundraise mode is expensive in attention. 6. Recommendation + the trigger that'd flip the answer. </output>

Decides fundraise vs bootstrap with use-of-funds clarity and dilution math.

💡

Pro tip: Bootstrap-vs-fundraise often comes down to market dynamics. Winner-take-most markets reward fast and funded; fragmented markets reward slow and profitable. Pick the right game first.

Raise Now vs Wait

86/100

<task>Decide whether to raise the next round now or wait.</task> <context> - Current runway: [months] - Current traction: [data] - Traction we'd have in 6 months: [forecast] - Market sentiment for our category: [hot / cooling / cold] - Founder appetite for fundraising right now: [be honest] </context> <output> 1. Runway buffer: never raise with less than 9 months left. 2. Traction inflection: what number we'd hit in 6 months that changes our raise narrative. 3. Market timing: macro / category sentiment in 6 months — better or worse. 4. Opportunity cost: 3-4 months of founder time on fundraise vs on traction. 5. Valuation: where would we land now vs in 6 months at projected metrics. 6. Recommendation + the milestone that changes the answer. </output>

Decides raise timing with runway buffer, traction inflection, and market sentiment.

💡

Pro tip: The 9-month runway rule is non-negotiable — never start a raise with less than 9 months. You'll close around the 4-month mark and you can't afford a single slip.

Down Round Decision

87/100

<task>Decide whether to take a down round vs alternatives.</task> <context> - Last round: [valuation] - This round options: [down round terms] - Alternatives: [bridge, convertible, structured, no raise] - Runway: [months] - Cap table sensitivity: [employee / common shareholder impact] </context> <output> 1. Down round structure: clean (just lower valuation) vs structured (with preferences). 2. Cap table impact: employee dilution, common-stock impact, ratchets. 3. Bridge alternative: convertible note with discount, no valuation set today. 4. No-raise path: cut burn, extend runway. 5. Signal: down rounds are loud but survivable; structured rounds are quieter and worse. 6. Recommendation + the comms plan. </output>

Decides down round vs alternatives with cap-table impact and signal analysis.

💡

Pro tip: A clean down round is almost always better than a structured round at flat valuation. Investors and acquirers can read structure — they can't reverse it.

Acquisition Target Evaluation

88/100

<task>Evaluate [target company] as an acquisition.</task> <target> - Company: [name] - What they do: [describe] - Strategic rationale: [why we'd buy] - Estimated cost: [range] - Integration complexity: [low / med / high] </target> <output> 1. Build-vs-buy comparison: what would this cost us to build instead? 2. Strategic fit: revenue accretion vs capability addition vs talent addition. 3. Integration plan: tech stack, team, customer base, brand. 4. Risk: integration failure rate by acquisition type. 5. Cultural fit honesty check. 6. Recommendation + the diligence priorities before LOI. </output>

Evaluates acquisition target with build-vs-buy, integration plan, and culture check.

💡

Pro tip: Most acquisitions fail on culture, not strategy. The cultural fit honesty check pre-LOI saves millions. If you wouldn't hire 80% of their leadership team into your existing org, don't buy them.

Customer Account: Hold or Drop

89/100

<task>Decide whether to keep or drop [problem account].</task> <account> - Customer: [name + size] - Issue history: [list] - Revenue: [annual] - Support load: [hours/month] - Strategic value: [logo, reference, expansion potential] </account> <output> 1. Margin reality: revenue minus support load minus management time. 2. Strategic value: is the logo worth the headache? 3. Behavior trend: are issues escalating or resolving? 4. Internal team morale: who's impacted, and how badly? 5. Fire path: terms of disengagement, transition support, comms. 6. Recommendation + the conversation if firing. </output>

Decides whether to fire a problem customer with margin reality and team-morale check.

💡

Pro tip: Firing customers is rare but powerful. The biggest impact is internal — the team's relief and renewed energy compounds. Calculate that, not just the margin.

Public Statement Decision

90/100

<task>Decide whether to make a public statement on [issue / controversy].</task> <context> - Issue: [describe] - Our actual position: [be honest] - Stakeholders: [who'd see it — customers, team, investors] - Risk of staying silent: [list] - Risk of speaking: [list] </context> <output> 1. Our actual stake in the issue: relevant / adjacent / opportunistic. 2. Stakeholder mapping: who needs us to speak vs who'd be alienated. 3. Statement options: silent / brief / detailed / activist. 4. Internal alignment check: would our team feel represented? 5. Long-term consistency: if we speak now, does that commit us to speaking on similar future issues? 6. Recommendation + draft statement if proceeding. </output>

Decides public statement on controversy with stake check and consistency analysis.

💡

Pro tip: Speaking publicly on an issue commits you to speaking on every similar future issue. The consistency check is the cleanest test — if you wouldn't speak on the next 3, don't speak now.

Press & PR Response Decision

91/100

<task>Decide how to respond to [press inquiry / story / coverage].</task> <situation> - Outlet: [name] - Topic: [their angle] - Their deadline: [time] - Our exposure: [reputation, customer, competitive] - Past relationship with this outlet: [if any] </situation> <output> 1. The story will run with or without us — what comment matters? 2. On-record vs background vs no-comment — pros / cons each. 3. Talking points: 3 things we want in the story. 4. Hostile-question prep: what we won't say. 5. Crisis vs opportunity: this can amplify or contain. 6. Recommendation + statement / on-record quote if proceeding. </output>

Decides press response with on-record/background/no-comment options and hostile-question prep.

💡

Pro tip: No-comment is rarely the right call — the story runs anyway, and now you look defensive. A short on-record statement that controls the framing is almost always better.

Legal Escalation Decision

92/100

<task>Decide whether to escalate [legal dispute] vs settle.</task> <situation> - Issue: [describe] - Counterparty: [who, with what resources] - Our position: [strong / mixed / weak] - Settlement on table: [if any] - Strategic cost of fight: [time, distraction, public exposure] </situation> <output> 1. Legal merit: how strong is our case, honestly? 2. Cost / time of full litigation vs settlement. 3. Reputation / precedent: does settling teach others to try this? 4. Counterparty's resolve: are they bluffing or committed? 5. Settlement structure that protects us most. 6. Recommendation + the term they'd never accept (so we know we're starting realistically). </output>

Decides litigation vs settlement with merit, cost, and precedent analysis.

💡

Pro tip: Most litigation costs more than the settlement avoided. Settle when reasonable; fight only when precedent matters more than money. Reputation rarely matters enough to fight.

Patent & IP Decision

93/100

<task>Decide whether to file patent / protect IP on [innovation].</task> <context> - Innovation: [describe] - Patentability assessment: [from counsel if available] - Strategic role: defensive vs offensive - Cost of patent: [filing + prosecution + maintenance] - Competitive density: [how fast could this be replicated?] </context> <output> 1. Trade secret vs patent: is this better kept private or registered? 2. Patent's defensive value: blocking competitors. 3. Patent's offensive value: licensing or litigation revenue. 4. Cost over 20 years: filing + prosecution + maintenance globally. 5. Disclosure cost: patents publish — does that help competitors? 6. Recommendation + the territory strategy. </output>

Decides patent vs trade secret with defensive/offensive value and disclosure cost.

💡

Pro tip: Software patents are rarely worth it for startups — they cost $20K+ to file, take years to grant, and rarely block determined competitors. Trade secrets often beat patents for software.

Conference & Event Sponsorship

94/100

<task>Decide whether to sponsor [conference / event].</task> <event> - Event: [name] - Audience: [size + persona match] - Cost: [sponsorship + travel + opportunity] - Past sponsorships' ROI: [if any data] - Strategic alternatives: [own event, content marketing, ads] </event> <output> 1. ICP match: how many actual buyers will be there? 2. Activation: what we'd do beyond the logo (talk, dinner, demos). 3. Pipeline math: opportunities needed to break even. 4. Brand / awareness lift if direct pipeline isn't the goal. 5. Opportunity cost: same dollars in other channels. 6. Recommendation + the activation plan if proceeding. </output>

Decides conference sponsorship with ICP-match, activation plan, and pipeline math.

💡

Pro tip: Conference sponsorships fail when the logo is the activation. Booth + speaker + dinner + targeted outreach = sponsorship paying back; logo only = donation.

Endorsement & Partnership Brand Risk

95/100

<task>Decide whether to accept [endorsement / partnership opportunity] from a brand-risk perspective.</task> <partner> - Partner: [who] - Reach: [audience size, demographics] - Past controversies / brand baggage: [list] - Audience overlap with our ICP: [%] - Value being offered (or asked): [describe] </partner> <output> 1. Brand alignment audit: do their values match what we publicly stand for? 2. Risk register: 3-5 things that could go sideways from this association. 3. Reversibility: can we unwind if their next controversy is bad? 4. Audience reaction modeling: who'd love it, who'd be offended. 5. Contract protections: morality clause, termination rights. 6. Recommendation + the kill criteria. </output>

Decides endorsement deal with brand-alignment audit and risk register.

💡

Pro tip: Brand partnerships fail more often through partner controversy than through poor reach. Morality clauses and termination rights protect you — make them non-negotiable.

Co-Marketing Deal Evaluation

96/100

<task>Evaluate [co-marketing deal] with [partner].</task> <deal> - Partner: [name] - Activity: [webinar / report / event / content] - Audience overlap: [%] - Effort each side: [estimated hours] - Distribution promises: [their commitment] </deal> <output> 1. Audience match: is their audience actually our ICP, or just a big number? 2. Effort symmetry: are we doing 50% or 80% of the work? 3. Distribution discipline: will they actually push to their list? 4. Output value: what we keep after the co-marketing ends (content, leads, brand). 5. Reputational fit: do we want our brand near theirs? 6. Recommendation + the leverage we should ask for. </output>

Evaluates co-marketing deal with audience match, effort symmetry, and output value.

💡

Pro tip: Co-marketing fails on effort symmetry — one side does the work, the other slaps their logo on. Write the effort split into the partnership document upfront.

Distribution Deal Decision

97/100

<task>Decide whether to take [distribution deal] on offered terms.</task> <deal> - Distributor: [who] - Volume promise: [estimated] - Margin to distributor: [%] - Exclusivity terms: [any] - Term length: [years] </deal> <output> 1. Volume realism: is the promise based on data or hope? 2. Margin math: can we afford their cut and still grow? 3. Exclusivity damage: what other channels does this lock out? 4. Term length: how long are we committing? 5. Channel conflict with direct sales: where does it bite? 6. Recommendation + the negotiation moves. </output>

Decides distribution deal with volume realism, margin math, and exclusivity damage.

💡

Pro tip: Distribution deals with exclusivity are bets — you win big if it works, you're trapped if it doesn't. Never sign exclusivity longer than your ability to absorb the failure.

Exit Timing Decision

98/100

<task>Decide whether to start an exit process now.</task> <context> - Current state: [revenue, growth, market position] - Market for exits in our category: [hot / cool] - Founder readiness: [be honest] - Investor pressure: [if any] - Best case independent path: [3-year forecast] </context> <output> 1. Market timing: are buyers paying premium multiples for our category now? 2. Independent path: what'd we be worth in 3 years if we stayed. 3. Founder energy: do you have another 3 years of this in you? 4. Investor / cap table alignment: what does the cap table need. 5. Process: who'd lead it, what'd timeline look like. 6. Recommendation + the trigger event that'd flip the answer. </output>

Decides exit timing with market multiples, independent-path forecast, and founder energy.

💡

Pro tip: Exit timing is mostly founder energy and market multiples. Independent-path math matters but rarely changes the answer — if you're tired, you're selling; if multiples are sky-high, you're considering.

Frequently Asked Questions

Claude's extended thinking and structured reasoning are designed for exactly this — multi-criteria analysis, stress-testing assumptions, surfacing counter-arguments. The XML-tagged prompts force structure that Claude was trained to parse, producing more rigorous analysis than free-form chat.
Opus for high-stakes decisions (pricing strategy, hiring, pivots, acquisitions). Sonnet for everyday decisions (which meeting to kill, which feature to deprioritize). Cost is meaningful for Opus; quality is meaningful for Opus too.
Yes — every prompt uses placeholder variables ([describe], [list], etc.). Replace with sanitized inputs (round numbers, role descriptions instead of names) for sensitive scenarios. Claude doesn't train on your conversation by default in the API or paid plans.
Explicitly ask for a recommendation in the output structure, including a confidence level (low/med/high). When Claude hedges, follow up with "Pick one. Explain why this is more likely right than the alternative." It will commit when forced.
No — they accelerate them. Use Claude to clarify your own thinking, surface assumptions, and stress-test before bringing decisions to your team. The team conversation is faster and sharper when you arrive prepared instead of half-formed.
Save your company context (mission, ICP, key metrics, current strategy) as a Claude Project system prompt. Then every decision prompt runs against that context automatically. Reduces re-explaining and dramatically improves output relevance.

Prompts are the starting line. Tutorials are the finish.

A growing library of 300+ hands-on tutorials on ChatGPT, Claude, Midjourney, and 50+ AI tools. New tutorials added every week.

7-day free trial. Cancel anytime.