When to use: Before customer interviews. Stops you going in with assumptions.
You are a product discovery coach trained in Jobs-to-Be-Done theory. Before you give me anything, ask me these questions one at a time and wait for my answer to each:
1. What product or feature are we exploring?
2. Who is the user you are trying to understand?
3. What outcome are they trying to achieve?
4. What do you currently assume is their biggest frustration?
After I answer all four, generate a set of 10 customer interview questions designed to uncover the job they are hiring the product to do. For each question, explain why it helps surface a real job rather than a stated preference.
-
💡
Pro Tip:
After generating questions, ask AI: Flag any questions that lead the witness or assume the answer.
-
📎
Add Context:
Paste a real support ticket or user complaint before running this prompt for more targeted questions.
When to use: When you have a product goal but too many ideas competing for space on the roadmap.
I am building an Opportunity Solution Tree for my product. Here is my context:
Product: [describe the product in 2-3 sentences]
Desired outcome: [what measurable user or business outcome are we trying to move]
Known user pain points: [list 3-5 things users complain about or struggle with]
Build a structured OST with:
- One clear desired outcome at the top
- 3-5 opportunity nodes (user needs or pain points)
- 2-3 solution ideas under each opportunity
- 1 key assumption to test for each solution before building it
Format this as a clear text tree structure I can copy into a whiteboard tool.
-
⚠️
Watch For:
AI will generate plausible-sounding opportunities. Challenge each one by asking: Is there evidence this is a real pain, or is it a hypothesis?
When to use: Before starting a new feature or product initiative. Forces you to surface hidden bets.
I am about to build: [describe the feature or product in plain language]
Act as a product strategist. Extract every assumption embedded in this idea across four categories:
1. Desirability (Do users want this?)
2. Viability (Will this work as a business?)
3. Feasibility (Can we build it?)
4. Usability (Can users figure it out?)
For each assumption, score it on:
- Importance to success (High / Medium / Low)
- Current evidence level (Strong / Weak / None)
Then identify the top 3 riskiest assumptions (high importance + weak or no evidence) and suggest the cheapest way to test each one before investing in a full build.
-
💡
Follow Up:
Which of these tests can I run in under a week with no engineers?
-
🔁
Iterate:
After running tests, paste results back and ask: How does this evidence change our risk ranking?
When to use: When your team cannot agree on what they are building or why it matters.
Ask me four questions to understand my product before writing anything:
1. Who is the target customer and what is the most important problem they face?
2. What does success look like for them after using this product?
3. What makes this product different from what already exists?
4. What would a user lose if this product disappeared tomorrow?
After I answer, write 3 versions of a product vision statement (one sentence each) using the structure: For [customer], who [problem], [product name] is a [category] that [key benefit], unlike [alternative].
Also explain the trade-off in focus between each version.
-
💡
Test Your Vision:
After picking one, ask: What would a sceptical engineer say is wrong with this vision? Use that to pressure-test it.
When to use: When you need to hand off a feature to engineering with enough context to avoid back-and-forth.
Feature: [feature name and one-sentence summary]
User: [who is this for and what are they trying to do]
Problem: [what friction or gap does this solve]
Constraints: [timeline, technical limits, or scope restrictions]
Write a concise PRD with these sections only:
1. Problem statement (2-3 sentences, no fluff)
2. Success metrics (3 measurable KPIs with baseline and target)
3. User stories (format: As a [user], I want to [action] so that [outcome])
4. Out of scope (what we are explicitly NOT building in this version)
5. Open questions (what needs a decision before engineering starts)
Do not pad. If a section needs only two bullet points, write two bullet points.
-
⚠️
Watch For:
AI tends to write vague success metrics like improve satisfaction. Push it: Make every metric specific and measurable with a number.
-
🔁
Refine:
Share with your lead engineer and ask them to flag the top 3 things they would need clarified before starting work.
When to use: Before positioning a product or entering a market. Saves weeks of spreadsheet-building.
My product: [one paragraph description of what it does and who it is for]
Competitors to analyze: [list 3-5 competitors, or say identify the main ones]
Key dimensions I care about: [e.g. pricing model, target customer, key feature set, distribution channel]
Build a structured competitive analysis table covering those dimensions. Then write a short paragraph (150 words max) identifying:
- Where there is an obvious gap no competitor is filling
- Which competitor is most dangerous to us and why
- One thing each competitor does better than us right now
Be direct. Do not soften the analysis.
-
📌
Note:
Replace the orange text with your own context.
When to use: When your team has different mental models of who they are building for.
Before creating a persona, ask me:
1. What real user interviews, surveys, or support data do I have?
2. What behaviors have I actually observed, not assumed?
3. What is the one job they are trying to get done?
After I answer, create a one-page persona that separates:
- What we know (backed by evidence I provided)
- What we assume (clearly marked as hypotheses)
Include: Name, role, primary goal, key frustrations, how they currently solve the problem without us, and the one metric that would tell us we have made their life better.
Flag any section where I gave you no evidence, so I know where my assumptions are hiding.
-
⚠️
Important:
A persona built on assumptions is a fictional character. If you cannot answer the first question with real data, run 5 user interviews first, then come back to this prompt.
When to use: When something feels wrong with your product direction but you cannot name what it is.
Current situation: [describe what your product does, who it serves, and what the main business goal is right now in 3-5 sentences]
What is not working: [be honest: slow growth, wrong customers, team confusion, unclear priorities, all of the above]
Act as a product strategist using Rumelt's Good Strategy framework. Diagnose the situation using:
1. Diagnosis: What is the core challenge (not the symptom)?
2. Guiding Policy: What approach will address the challenge?
3. Coherent Actions: What 3-5 concrete moves would make this strategy real?
Do not prescribe generic advice. If you need more information to give a real diagnosis, ask one focused question before proceeding.
-
📌
Note:
Replace the orange text with your own context.
When to use: When you have a business idea and need to stress-test it on one page before investing further.
My idea: [describe your product idea in plain language: what it does, who it helps, how you make money]
Build a Lean Canvas for this idea using Ash Maurya's 9-block framework:
1. Problem (top 3 problems you solve)
2. Customer Segments (who has this problem most urgently)
3. Unique Value Proposition (why you, why now)
4. Solution (top 3 features of your MVP)
5. Channels (how you reach customers)
6. Revenue Streams (how you make money)
7. Cost Structure (what costs most to run this)
8. Key Metrics (how you measure progress)
9. Unfair Advantage (what competitors cannot easily copy)
After completing the canvas, identify the single riskiest block: the one that, if wrong, kills the whole idea. Suggest one experiment to test it this week without building anything.
-
💡
Reality Check:
After generating, ask: Which assumptions in this canvas am I most emotionally attached to? Those are exactly the ones you need to test first.
When to use: When growth is stalled and you cannot tell if the problem is the product or how you are talking about it.
Ask me these four diagnostic questions before making any assessment:
1. What is your current monthly active user count and 30-day retention rate?
2. Of users who churned in the last 90 days, what reason did most of them give?
3. How are most new users currently finding you?
4. What percentage of users who try the product come back more than twice?
After I answer, tell me whether I have a product problem, a marketing problem, or both. Give me the 3 most important actions to take in the next 30 days. Be direct. Do not hedge.
-
📌
Note:
Replace the orange text with your own context.
When to use: Before signing a contract with a development agency. Or when your current agency feels off.
Here is the situation with my development agency: [describe what they are building, how they communicate, what deliverables you have received so far, and what concerns you - be specific]
Analyze this situation as an experienced Technical Product Manager who has worked with dozens of outsourced teams. Tell me:
1. Which of these signals are red flags that indicate a problem with accountability or delivery culture?
2. Which signals are normal friction that happens in all software projects?
3. What three questions should I ask them in our next meeting to get clear answers about delivery health?
4. If I had to make a go/no-go decision on this engagement in the next 30 days, what would you advise?
Do not be diplomatically vague. I need a direct read.
-
📌
Note:
Replace the orange text with your own context.
When to use: When your MVP has grown into a full product and you have not shipped anything yet.
What I am trying to build: [describe the full vision of your product]
Features I have listed so far: [paste your current feature list or backlog items]
Target user: [who is the first person who will pay for or use this]
The one job they need done: [what is the single outcome they cannot get today]
Apply the principle of ruthless MVP scoping. From my feature list, categorize every item as:
- Must ship (nothing works without this)
- Nice to have (adds value but not blocking the core job)
- Cut entirely (solves a problem my MVP user does not have yet)
Then tell me what the smallest possible thing is that I could ship in the next 4-6 weeks that proves one person gets real value from this product. Be brutal with scope.
-
⚠️
Warning:
Founders resist this. If you feel defensive about items AI suggested cutting, ask yourself: Am I keeping this because users need it, or because I like it?
When to use: After validating your MVP. Before spending on ads or hiring sales.
Product: [what it does in one sentence]
Target customer: [who they are and where they hang out online and offline]
Price point: [what you plan to charge or how you plan to monetize]
Budget for first 90 days: [your actual budget, be honest even if it is small]
Build a 90-day go-to-market plan using only channels that match my budget and target customer. Structure it as:
- Days 1-30: Validation and first 10 customers (what I should be doing before spending anything)
- Days 31-60: First repeatable acquisition test
- Days 61-90: Double down on what worked, cut what did not
For each phase, give me one primary activity, what I am trying to learn, and what success looks like. Do not give me a plan that requires a marketing team or large budget I do not have.
-
📌
Note:
Replace the orange text with your own context.
When to use: After a product failure, missed metric, or team breakdown you do not fully understand.
The problem I observed: [describe the outcome that went wrong, be specific about what happened, when, and who was affected]
Run a structured Five Whys analysis on this problem. At each level:
- State the why
- Identify what evidence would confirm or refute this as the real cause
- Flag if you are making an assumption that needs verification
After five levels, state:
1. The probable root cause
2. Whether it is a people problem, process problem, or system/tool problem
3. The lowest-cost fix that addresses the root, not the symptom
4. What monitoring I should put in place so I see this early next time
-
📌
Note:
Replace the orange text with your own context.
When to use: When you know your product works but people are not buying. Often a framing problem, not a product problem.
My product: [what it does and who buys it]
Current price or pricing model: [what you charge and how]
What the buyer gets: [list every deliverable, feature, or outcome they receive]
The most common reason people do not buy: [what objection kills the sale most often]
Reframe my offer using the value equation: maximize perceived dream outcome and likelihood of success, minimize perceived time to result and effort required. Rewrite my offer description to:
1. Lead with the dream outcome, not the features
2. Increase perceived likelihood that this works for them specifically
3. Reduce the perceived risk of buying
4. Name and neutralize the top objection inside the offer itself
Then suggest whether my current price is working against the perceived value, and what change (if any) would help.
-
📌
Note:
Replace the orange text with your own context.
When to use: Before a call with a potential customer. Stops you pitching before you understand.
About my prospect: [their role, company size, industry, and how they found us or why they agreed to this call]
What I am selling: [one sentence on the product and the problem it solves]
What I want from this call: [qualify them, understand their problem, close a trial, or something else]
Give me a discovery call script with:
1. An opening (build rapport, set agenda, not a pitch)
2. Five questions that help me understand if they have the problem I solve, in their words
3. A transition into showing how we help (only if the problem is confirmed)
4. A clear next step to close the call with, not I'll send you some info
Also flag the moment when I should stop asking and start listening, because most founders pitch too early.
-
📌
Note:
Replace the orange text with your own context.
When to use: When you have 10+ items competing for the next sprint and no clear winner.
Here is my backlog of items to prioritize:
[paste your list of features, bugs, or initiatives here, one per line]
Our main product goal right now: [one sentence on the metric or outcome we are trying to move]
Score each item using the RICE framework:
- Reach: How many users does this affect per quarter?
- Impact: How much does it move our goal? (3=massive, 2=significant, 1=minimal, 0.5=low)
- Confidence: How sure are we of R and I? (100%, 80%, 50%)
- Effort: Estimated person-weeks to ship
Calculate RICE score = (Reach x Impact x Confidence) / Effort
Present the result as a ranked table. Highlight the top 3 items and explain why they scored highest. Also flag any item where Confidence is below 60%, meaning we should validate before building.
-
📌
Note:
Replace the orange text with your own context.
When to use: When stakeholders keep asking for a roadmap and you have not been able to produce one that everyone agrees with.
Before building a roadmap, ask me:
1. What is the product's goal for the next 6 months in one sentence?
2. What requests or initiatives are currently competing for attention?
3. Which stakeholders have the most conflicting opinions?
4. What resource constraints should I know about (team size, timeline pressure)?
After I answer, organize my inputs into a Now/Next/Later roadmap (outcome-based, not feature-based). For each item:
- State the outcome it achieves, not just the feature name
- Note which stakeholder cares most about it
- Flag dependencies between items
Also write a two-sentence rationale I can use with leadership to explain why things ended up in the order they did.
-
📌
Note:
Replace the orange text with your own context.
When to use: When a stakeholder or executive pushes a feature that should not be on the roadmap right now.
The request: [describe the feature being asked for and who is asking]
Why I need to push back: [what would it cost in time, focus, or opportunity if we build this now]
Our current priority: [what the team is actually focused on and why]
Write a professional response that says no without damaging the relationship. The response should:
1. Acknowledge what the request is trying to achieve (not the feature itself)
2. Explain the trade-off clearly without being defensive
3. Offer a specific alternative: defer to a date, reduce scope, or suggest a faster workaround
4. Close the loop so the conversation has a clear next step
Keep it under 150 words. No corporate softening. Make it sound like it came from a human who respects the person asking.
-
📌
Note:
Replace the orange text with your own context.
When to use: When your team ships constantly but user metrics are not moving.
Here is a list of features we shipped in the last quarter:
[list the features or releases, with a brief note on what each one did]
Our north star metric: [what metric matters most: DAU, retention, revenue, NPS, etc.]
What happened to that metric this quarter: [went up, flat, went down, by how much if you know]
Act as a product auditor. For each feature I shipped:
1. Assess whether there was a clear user outcome being targeted before it was built
2. Flag items that look like they were shipped for activity, not impact
3. Identify which 2-3 features most likely had a meaningful effect on the north star metric
Then give me an honest verdict: are we a feature factory, and if so, what is the one structural change that would most help us shift to outcome-driven delivery?
-
📌
Note:
Replace the orange text with your own context.
When to use: When your user stories are vague, dev-written, or written in solution language instead of user language.
Feature area: [what part of the product this covers]
User type: [who uses this part of the product]
What they are trying to accomplish: [the outcome, not the button clicks]
Write 5 user stories in this format:
As a [specific user type], I want to [action] so that [outcome I care about].
For each story:
- Add 3 acceptance criteria (testable, not vague)
- Add one edge case or failure scenario worth handling
- Flag if any story is too large to complete in a single sprint and suggest how to split it
Then review the set and tell me if any stories are actually solution specifications written backwards as user stories, a common trap.
-
📌
Note:
Replace the orange text with your own context.
When to use: At the start of a quarter when you need goals that actually connect daily work to company strategy.
Company-level goal this quarter: [what is the business trying to achieve]
My team's area of ownership: [what part of the product or experience does your team own]
Biggest user problem we are currently aware of: [in plain language, not technical terms]
Write one Objective and 3 Key Results for my product team this quarter. Follow these rules:
- Objective: qualitative, motivating, directional, not a task
- Key Results: measurable, outcome-focused (not output), achievable with stretch
For each Key Result, add:
- Baseline (where we are now)
- Target (what 100% success looks like)
- Leading indicator (what we can track weekly to know we are on track)
Then tell me which Key Result is hardest to influence directly and why. Most teams write KRs they cannot actually move.
-
📌
Note:
Replace the orange text with your own context.
When to use: When you need to argue for fast-tracking a feature. Most PMs under-estimate the cost of waiting.
Feature: [what it is]
Business value if shipped: [revenue impact, churn reduction, or conversion improvement, use numbers if you have them]
Current estimated delay: [how long until this would be built under current priorities]
What happens if we delay: [lose customers, miss window, competitor ships first, or something else]
Help me quantify the cost of delay for this feature. If I have numbers, use them. If I do not, help me estimate by asking what is likely true. Build a simple argument for either accelerating this feature or parking it, based purely on what delay actually costs versus the effort to ship sooner.
Then write one paragraph I can use in a prioritization meeting to make this case without sounding like I am just pushing my personal favourite feature.
-
📌
Note:
Replace the orange text with your own context.
When to use: When your retros are repetitive, feel performative, or always produce the same action items nobody follows up on.
What happened this sprint:
- What we shipped: [completed items]
- What we did not finish: [carried-over items and rough reason why]
- Incidents or blockers: [any fires, delays, or surprises]
- Team mood (honest assessment): [energized, frustrated, confused, burned out]
Design a 60-minute retrospective agenda for a team of 5-8 people. For this sprint specifically:
1. Choose a retrospective format that fits the team mood I described (not the same format every time)
2. Write the exact questions or prompts the facilitator should use
3. Suggest how to convert discussion into 1-2 concrete, assigned action items, not vague intentions
4. Include one thing that should be celebrated before we dive into problems
Do not use the phrase what went well, what could be improved. That format produces the same conversation every time.
-
📌
Note:
Replace the orange text with your own context.
When to use: When your team is delivery-heavy with frequent requests and fixed sprints feel like they are creating more overhead than value.
About our team: [team size, what we build, how often we get interrupt-driven work versus planned work]
Current pain with Scrum: [what specifically is not working: too many unplanned items, sprint goals never achieved, etc.]
Help us evaluate whether Kanban is the right move and, if it is, how to make the transition. Specifically:
1. Is our pain actually a Scrum-fit problem, or a process discipline problem that Kanban would not fix?
2. If Kanban is right: give me a 3-step transition plan with what to stop, what to keep, and what to introduce
3. What WIP limits should we start with based on our team size?
4. What does success look like in 60 days if the transition goes well?
Do not recommend the transition if the evidence I provided does not support it.
-
📌
Note:
Replace the orange text with your own context.
When to use: Before sprint planning when you want to set a realistic commitment rather than an optimistic one.
Team size: [number of developers, designers, and QA]
Sprint length: [1 or 2 weeks]
Known absences or commitments this sprint: [leave, hiring interviews, company all-hands, etc.]
Average velocity last 3 sprints: [story points or number of items completed]
Items we are considering for this sprint: [paste your candidate backlog items with estimated effort]
Calculate available capacity for this sprint (accounting for absences and 20% unplanned work buffer). Then:
1. Tell me how much the team can realistically commit to this sprint
2. If the candidate list exceeds capacity, rank which items to drop and which to keep based on stated priority
3. Suggest a sprint goal in one sentence that captures the theme of what we are trying to achieve
4. Flag any item in the candidate list that does not yet have a clear definition of done
-
📌
Note:
Replace the orange text with your own context.
When to use: When done means different things to different people on the team and it is causing rework or production bugs.
Our product type: [web app, mobile app, API, internal tool, etc.]
Our biggest quality issues historically: [bugs in production, missing edge cases, accessibility gaps, poor documentation, etc.]
Current team setup: [do we have QA? do developers self-test? is there a staging environment?]
Write a Definition of Done for our team. Include criteria across:
- Code quality (reviews, standards)
- Testing (what types, by whom)
- Documentation (what is required before something is truly done)
- Deployment (what environment and who can verify it)
- UX/accessibility (minimum bar)
- Stakeholder acceptance (who needs to sign off)
Format it as a checklist the developer can run through before marking anything done. Keep it short enough that people will actually use it, no more than 12 items.
-
📌
Note:
Replace the orange text with your own context.
When to use: When a blocker has been sitting unresolved for more than two days and you need to decide whether to intervene.
The blocker: [describe what is blocking the team: technical dependency, a missing decision, a person not responding, etc.]
How long it has been blocked: [in days]
Who owns resolving it: [developer, another team, external vendor, or unclear]
Impact on sprint goal: [is it blocking one story or the whole sprint?]
Help me decide:
1. Should I escalate this or give the team more time to resolve it?
2. If I escalate: who do I escalate to, what do I say, and what outcome am I asking for?
3. Is there a workaround that unblocks the team without resolving the underlying issue?
4. What should change in our process so this type of blocker is caught earlier next time?
Be direct about whether I am under- or over-managing based on the situation I described.
-
📌
Note:
Replace the orange text with your own context.
When to use: When you worry that losing one person would break your delivery. It usually means you have a system problem, not a people problem.
About our team: [team size, roles, how long you have been working together]
What breaks if our most critical person is absent: [be honest and specific: what knowledge, skills, or access lives only with one person]
How long delivery would stall: [hours, days, the whole sprint]
Help me build a 30-day plan to reduce our bus factor. Specifically:
1. Identify what types of single points of failure exist (knowledge, access, process, code ownership)
2. Suggest the 3 highest-priority knowledge transfer or redundancy actions
3. Recommend a documentation or pairing practice that fits into how we already work
4. Give me a simple way to measure progress: how will I know in 30 days that we are less fragile?
Do not recommend a wiki as the solution. Most team wikis go stale and nobody reads them.
-
📌
Note:
Replace the orange text with your own context.
When to use: When you need to get non-technical stakeholders to agree to slow down feature shipping and invest in paying down technical debt.
Technical debt situation: [describe the problem in plain English: what is slow, brittle, or risky in the codebase and what it costs us in delivery speed or incidents]
Audience: [who you need to convince: CEO, investors, non-technical co-founder, or board]
Help me make the business case for technical debt investment to a non-technical audience. Structure it as:
1. The symptom they already see (in business terms, not engineering terms)
2. The underlying cause (technical debt explanation without jargon)
3. What it is currently costing us (speed, risk, talent, or money)
4. What we are asking for (time, budget, or feature slowdown)
5. What they get in return and by when
Then write a one-paragraph version I can use in a 5-minute leadership update. No jargon. No passive voice.
-
📌
Note:
Replace the orange text with your own context.
When to use: When your 1-on-1s are status updates rather than growth and trust-building conversations.
About the person: [their role, how long they have been on the team, and what their current biggest challenge or project is]
What I know about their current state: [motivated, struggling, underperforming, coasting, new, or something else]
Last time we met: [what we discussed and what was agreed]
Build a 30-minute 1-on-1 agenda that prioritizes their growth and wellbeing over project status. Include:
1. Opening question that is not about work deliverables
2. A check-in on the action items from last time
3. One question specific to their current challenge that shows I was paying attention
4. Time for them to raise anything I do not know about
5. Closing: one thing they commit to before next time, one thing I commit to
Also suggest the one thing I should avoid asking in this specific 1-on-1 based on the context I gave you.
-
📌
Note:
Replace the orange text with your own context.
When to use: When you have been avoiding a difficult conversation and the problem is getting worse, not better.
The behavior or performance issue: [describe what is happening specifically, not personality, but observable behavior or output]
The impact: [what is actually being affected: team trust, project delivery, a specific stakeholder, etc.]
My relationship with this person: [direct report, peer, or someone I work with closely but do not manage]
What I have tried so far: [nothing yet, hinted at it, discussed informally, formal warning]
Write a feedback script I can use in the next conversation. It should:
1. Open by naming the specific behavior, not a character judgment
2. State the concrete impact on the team or work
3. Ask a question before telling them what to change: they may have context I do not
4. Offer what support I am willing to provide
5. Be clear about what needs to change and by when
Keep it under 200 words. Feedback delivered with care and directness is not unkind. Coach me out of any softening language that dilutes the message.
-
📌
Note:
Replace the orange text with your own context.
When to use: Before writing a job description. Most JDs describe the perfect candidate rather than the actual job.
Before generating anything, ask me:
1. What specific problem will this hire solve in the next 6 months?
2. What does failure in this role look like at the 90-day mark?
3. What is the most common misconception about what this role actually involves?
4. What does the best person we have ever hired have in common?
After I answer, write:
- A 5-bullet role description (what they will actually do, not a wish list)
- 3 screening questions for the first call that reveal how they think, not just what they have done
- The one non-negotiable (a hard filter that eliminates the wrong candidate fast)
- A 90-day success milestone so everyone agrees what good looks like
-
📌
Note:
Replace the orange text with your own context.
When to use: When you manage a team with different performance levels and you are applying the same management approach to everyone.
My team members and how I would honestly describe them:
[For each person: Name/Role | Skill level in their core function (High/Med/Low) | Current motivation or willingness (High/Med/Low) | One-sentence context]
Map each team member onto the Skill-Will Matrix and recommend a specific management approach for each quadrant:
- High skill, high will: What to stop doing (you are probably micromanaging)
- High skill, low will: What to investigate (burnout? wrong role? misaligned incentives?)
- Low skill, high will: What structure and coaching they need
- Low skill, low will: What conversation needs to happen and when
Do not give me generic quadrant advice. Tailor it to each person I described. Also tell me: am I managing the team the way they need to be managed, or the way I am most comfortable managing?
-
📌
Note:
Replace the orange text with your own context.
When to use: When something is clearly wrong on the team but you cannot name what it is. Usually a trust or accountability issue.
Symptoms I am observing: [describe what you are seeing: people not speaking up in meetings, blame shifting, missed commitments, low energy, politics, silo behavior, etc.]
Team context: [how long has the team been together, any recent changes like a new manager, reorganization, or difficult project]
Using Lencioni's Five Dysfunctions of a Team as a diagnostic lens, identify which dysfunction is most likely at the root of what I described:
1. Absence of trust
2. Fear of conflict
3. Lack of commitment
4. Avoidance of accountability
5. Inattention to results
Explain why you believe this is the root (not a symptom), and give me three concrete interventions in order of priority. The first intervention should be something I can do in the next two weeks. No generic team-building suggestions.
-
📌
Note:
Replace the orange text with your own context.
When to use: When you have just been promoted to manager or joined a team as a new leader. The first 30 days set everything that follows.
About me: [previous role, what brought me to this management position, any concerns I have about the transition]
About the team: [team size, how long they have been together, what they are currently working on, any known issues or tensions]
What I know about why the previous manager left or changed: [if you know]
Build a 30-day plan for my transition as manager. Structure it as:
- Days 1-10: Listen and observe (what to learn before making any changes)
- Days 11-20: Build trust (specific actions, not platitudes)
- Days 21-30: Make one meaningful move (the smallest change that signals my leadership style)
Also tell me: what is the biggest mistake new managers make in the first 30 days? And what specific traps should I avoid based on the context I gave you?
-
📌
Note:
Replace the orange text with your own context.
When to use: When you are not sure whether you are over-controlling your team or under-involved at the wrong moments.
Recent decisions I made:
[list 5-7 recent decisions you were involved in: what the decision was, who made it, and how it turned out]
How my team would describe my decision-making style: [your honest guess: do they see you as hands-on, hands-off, unclear, or something else]
Analyze the decisions I listed. For each one, assess:
- Was this the right person to make this decision?
- What would have happened if I had delegated it to someone closer to the problem?
- What would have happened if I had made it more quickly or more slowly?
Then give me a simple decision filter: a set of 3 questions I can ask myself before taking or delegating any decision in the future.
Be direct if my pattern suggests I am either bottlenecking decisions or abdicating responsibility when my involvement was actually needed.
-
📌
Note:
Replace the orange text with your own context.
When to use: When your team tracks 20 metrics and cannot agree on which one actually matters most.
My product: [what it does and how users get value from it]
Business model: [subscription, transactional, freemium, marketplace, etc.]
Current metrics we track: [list all the metrics your team currently measures]
Help me find my North Star Metric. A good NSM:
- Captures the core value delivered to users (not just revenue)
- Moves in the same direction as long-term business success
- Is specific enough that the whole team can influence it
From my current metrics, identify:
1. Which one best fits these criteria and why
2. Which metrics are vanity metrics I should stop prioritizing
3. What 3-4 input metrics drive the NSM (the leading indicators my team can directly influence)
4. One metric that might be hiding a retention problem even if growth looks healthy
Explain your reasoning for the NSM choice. I need to defend it to the team.
-
📌
Note:
Replace the orange text with your own context.
When to use: When users sign up but do not come back. Scaling acquisition will only amplify this problem.
Retention data: [Day 1, Day 7, Day 30 retention rates if you have them. If not, describe what you observe about when users drop off]
Activation step: [what does a user need to do to experience the core value for the first time?]
What churned users say: [exit survey data, support tickets, or your honest guess]
Diagnose my retention problem and identify which of these is most likely:
1. Activation failure (users never hit the aha moment)
2. Value gap (the core value is not compelling enough to come back for)
3. Habit failure (the product is not integrated into the user's workflow)
4. Competition (they found something better)
For the most likely root cause, give me three specific experiments to run in the next 30 days. Each experiment should have a clear hypothesis, what we change, and what a positive result looks like.
-
📌
Note:
Replace the orange text with your own context.
When to use: When you know you have a growth problem but not where in the funnel it actually lives.
Fill in what you know (approximate numbers are fine):
- Acquisition: Monthly visitors or leads: [number and main channel]
- Activation: % who take the first key action: [e.g. 20% complete signup]
- Retention: % active after 30 days: [number or honest guess]
- Referral: Do users recommend us? [NPS score, referral rate, or anecdotal evidence]
- Revenue: Conversion to paid, average revenue per user: [numbers or rough estimate]
Run a pirate metrics audit on my funnel. Tell me:
1. Which stage is leaking the most relative to benchmarks for my business model
2. The priority order for fixing each stage (which fix has the highest leverage)
3. One specific test I can run at the leakiest stage without engineering resources
4. What metric I should be obsessing over this month and why
If my numbers suggest I should not be spending on acquisition yet, say so directly.
-
📌
Note:
Replace the orange text with your own context.
When to use: Before scaling. Most startups scale before PMF and wonder why growth is expensive and fragile.
Ask me these diagnostic questions one at a time:
1. If your product disappeared tomorrow, what percentage of current users would be very disappointed? (Sean Ellis benchmark: 40%+ = PMF signal)
2. Which customer segment uses your product most intensely and comes back without prompting?
3. Is there a group of users who would pay more than you currently charge? Who are they?
4. Where is your best retention coming from and why?
After I answer all four, give me an honest PMF verdict:
- Strong signal, ready to scale
- Weak signal, need to narrow focus to a specific segment
- No signal, go back to discovery
Then tell me the single most important thing to do next based on where I sit.
-
📌
Note:
Replace the orange text with your own context.
When to use: When your team cannot connect their daily work to the business outcome they are supposed to drive.
Business outcome we care about: [e.g. Monthly Recurring Revenue, Daily Active Users, Net Revenue Retention]
Product area my team owns: [e.g. onboarding, search, notifications, billing]
Team size: [number of people]
Build a metrics tree that shows how my team's work connects to the business outcome. Structure it as:
Level 1: The business outcome (lagging indicator)
Level 2: 2-3 product metrics that drive it (intermediate indicators)
Level 3: 3-5 team-level activity metrics that drive Level 2 (leading indicators the team can directly influence)
For each metric at Level 3, add:
- How to measure it (what event or data point to track)
- What healthy looks like vs. what at risk looks like
- One change the team could make tomorrow that would move it positively
Format this so I can share it with my team without them needing a data background to understand it.
-
📌
Note:
Replace the orange text with your own context.
When to use: When growth feels like it depends entirely on paid acquisition and you want to build something more durable.
My product: [what it does and who uses it]
How users currently find us: [channels: organic, paid, word of mouth, sales, etc.]
What happens after a user gets value from the product: [do they share it, invite others, create content, come back more often, or just use it alone?]
Identify whether there is a natural growth loop embedded in my product that I am not fully leveraging. Growth loops to consider:
- Viral loop (users invite or share)
- Content loop (users create content that attracts new users)
- Data loop (more users make the product smarter, attracting more users)
- Community loop (users connect with each other, increasing switching cost)
Tell me which loop is most realistic given my product and user behavior. Then give me a specific experiment to activate or strengthen it. If no loop exists naturally, tell me honestly rather than forcing one.
-
📌
Note:
Replace the orange text with your own context.
When to use: When churn is your biggest problem and you do not yet know if it is price, product, fit, or onboarding.
Churn rate: [monthly or annual churn percentage]
When most churn happens: [Day 7, end of trial, Month 3, renewal time, etc.]
What churned users say: [reasons given, or we do not ask if you do not have this data]
What your best retained users have in common: [any pattern you have noticed]
Diagnose the most likely type of churn I am facing:
- Early churn (never got value, activation or onboarding problem)
- Mid-term churn (got value, then stopped needing it, fit problem)
- Involuntary churn (payment failure, pricing, or plan confusion)
- Competitive churn (left for an alternative)
For the most likely type, write a 3-step intervention plan with:
- What to fix in the product
- What to do operationally (outreach, in-app messaging, support)
- How to measure whether the intervention is working
If I told you we do not ask for churn reasons, make that the first thing you tell me to fix.
-
📌
Note:
Replace the orange text with your own context.
When to use: When you need to brief a senior leader or board in under 5 minutes, in writing or verbally.
What I need to communicate: [full context of what is happening, include the messy details here]
Audience: [who I am presenting to and what they care about most]
Decision needed (if any): [what I need from them, or no decision needed, this is informational]
Restructure my communication using the Pyramid Principle:
1. Lead with the conclusion or recommendation (not the background)
2. Three supporting arguments (facts, not feelings)
3. Detail and evidence only if questioned
Write two versions:
- Verbal (60 seconds, for the start of a meeting)
- Written (one paragraph, for a Slack message or email)
Flag anything in my original content that sounds defensive, overly detailed, or likely to invite unnecessary questions. Remove it.
-
📌
Note:
Replace the orange text with your own context.
When to use: When something is running late and you need to tell stakeholders before they find out from someone else.
What is delayed: [feature, release, or milestone]
Original commitment: [what was promised and to whom]
Why it is delayed: [be honest: scope change, technical complexity, dependency, underestimation]
New estimated date: [or we do not have a new date yet]
Impact on the stakeholder: [what does this delay cost them: launch, customer, revenue, or something else]
Write a delay notification message that:
1. States the delay clearly in the first sentence, no burying the lead
2. Takes ownership without blaming the team or external factors
3. States what we know and what we still need to determine
4. Gives a clear next update date so they do not have to chase me
5. Offers one thing I am doing to minimize the impact
Do not use the phrase we apologize for any inconvenience. It says nothing. Replace it with something specific.
-
📌
Note:
Replace the orange text with your own context.
When to use: Before a meeting where you need a decision and you know there are competing opinions in the room.
The decision: [what needs to be decided and by when]
Attendees and their positions: [who is in the room and what you know about their likely stance or concerns]
What happens if no decision is made: [what is the cost of leaving this meeting without an answer]
Design a 45-minute meeting agenda that is built to produce a decision, not a discussion. Include:
1. Pre-read: what to send 24 hours before so nobody is surprised in the room
2. Opening (5 min): frame the decision, not the history
3. Context (10 min): what information everyone must have before choosing
4. Discussion (20 min): how to surface the real objections efficiently
5. Decision (10 min): how to close, who makes the call and how
Also tell me: which attendee is most likely to derail the decision, and what should I do before the meeting to neutralize that risk?
-
📌
Note:
Replace the orange text with your own context.
When to use: At the start of a new initiative when you need support from people you do not have authority over.
The initiative: [what I am trying to get done]
Stakeholders involved: [list each person or group with their role and rough level of influence over this initiative]
What each stakeholder wants: [what you know about their goals, fears, or objections]
Create a stakeholder map organized by:
- High influence + supportive: Engage and keep them informed
- High influence + resistant: Priority, address their concern directly
- Low influence + supportive: Keep them updated without over-investing
- Low influence + resistant: Monitor but do not let them slow you down
For each high-influence stakeholder, suggest:
1. The one thing they need to feel heard
2. How to involve them early enough to get buy-in, not just sign-off
3. The conversation I need to have before the initiative goes public
Then give me a two-sentence influence plan: what I should do in the next 10 days to move this initiative forward.
-
📌
Note:
Replace the orange text with your own context.
When to use: When you need to present a roadmap, strategy, or product update to an audience who will check their phones if you show another feature screenshot.
Presentation topic: [what you are presenting]
Audience: [who they are, what they care about, what they already know]
Length: [how many minutes you have]
What I want them to feel or do after: [approve something, be excited, make a decision, or something else]
Build a presentation structure using a story arc rather than a feature list. Use the contrast structure: what the world looks like for the audience today (problem) versus what it could look like (possibility). Organize slides as:
1. Hook (the one thing that makes them lean forward)
2. The current reality (their pain or missed opportunity)
3. What changes with your product or plan
4. Evidence it works (data, story, or demo moment)
5. What you need from them (clear ask)
Also tell me: the one slide most PMs include that they should cut, and the one thing most presenters forget to say out loud that the slides cannot communicate.
-
📌
Note:
Replace the orange text with your own context.
When to use: When you want your team or organization to adopt AI tools but you are getting resistance from leadership or a skeptical team.
Our organization: [what we do, rough size, and what tools or processes we currently use]
The AI use case I want to introduce: [specific, not use AI more but use AI to draft customer support responses or use AI for sprint planning prep]
Who I need to convince: [skeptical CEO, cautious IT team, resistant mid-managers, or the team itself]
The main objection I expect: [job loss, data privacy, quality concerns, change fatigue, etc.]
Write a pitch for this AI adoption initiative that:
1. Starts with the problem we have now (before mentioning AI at all)
2. Frames AI as a team capability amplifier, not a replacement
3. Addresses the most likely objection with specifics, not platitudes
4. Proposes a low-risk first step (a pilot, not a company-wide rollout)
5. Defines what success looks like in 60 days so leadership has a clear proof point
Keep the pitch under 300 words. No buzzwords. No the future of work framing.
-
📌
Note:
Replace the orange text with your own context.
