The Product Strategy Prompt Pack: 18 Prompts

I'm going to describe my product as I usually pitch it. Then I want you to rewrite it two ways:

1. As a clear, jargon-free description of what it actually does and who it actually helps
2. As a skeptic would describe it (someone who tried it and wasn't convinced)

My pitch: [paste your current pitch or one-liner]

For each version, flag any claims that sound like marketing rather than fact. Ask me up to 3 clarifying questions if you need more specifics before rewriting.

I'll describe who we think our ideal customer is. I want you to:

1. Point out where the description is too broad to be actionable
2. Ask me 5 questions that, once answered, would make the ICP precise enough to use in a cold email subject line
3. After I answer, rewrite the ICP as a single paragraph that includes: job title, company stage/size, the specific problem they have, what they're doing today instead of using us, and what they lose by continuing to do that

Current ICP description: [paste your current ICP or "we haven't defined this clearly yet"]

Walk me through the full value chain from when a customer first encounters our product to when they get their core outcome. I'll describe what we know, and I want you to:

1. Map the steps in order
2. Identify where friction likely exists at each step
3. Flag the 2-3 steps most likely to cause drop-off before the customer gets value
4. Ask me what data we have (or don't have) about each friction point

Our product: [describe]
What the customer is trying to accomplish: [describe]
What we know about where users struggle: [describe or say "not much"]

I want to map our positioning against what customers actually use when they don't use us (not just direct competitors, but spreadsheets, workarounds, doing nothing, or hiring someone).

Product: [describe]
ICP: [describe]

1. List the realistic alternatives this customer has, including non-software options
2. For each, describe what they get that they don't get from us, and what they lose
3. Based on this map, where is our positioning strongest? Where is it weakest?
4. What's the one positioning claim we should probably stop making because a real alternative makes it false?

I'm going to list what we believe are our product's differentiators. For each one, I want you to:

1. Rate how defensible it is on a scale of 1-3 (1 = any competitor could copy this in a quarter, 3 = structural advantage)
2. Explain why you rated it that way
3. Suggest how we could strengthen weak differentiators

Our differentiators: [list them]
Our competitors (name them if known): [list them]

Based on what I tell you about our customers, build a motivation map: what they're trying to accomplish (functional goal), what they want to feel (emotional goal), and what they want to avoid (anxiety).

Customer description: [paste ICP or interview notes]
Recent customer feedback or quotes (if any): [paste or describe]

Then: based on this map, what are the top 2 product or messaging decisions we should reconsider?

Here's a list of things we're considering building or doing in the next quarter. I want you to pressure-test the priority order.

Our goal this quarter: [e.g., reduce churn, reach 100 paying customers, expand to a new segment]
Team size/constraints: [e.g., 2 engineers, 1 designer, me on product]
List of candidates: [paste list]

For each item:
1. How directly does it serve the stated goal?
2. What's the likely effort (low/medium/high)?
3. What would we miss if we skipped it?

Then recommend a final order and flag anything on the list that probably shouldn't be on the list at all.

We're planning to build [feature or initiative]. Before we start, I want to define what success actually looks like so we can evaluate it honestly later.

Describe the feature/initiative: [describe]
Who it's for: [describe]
Why we're building it: [describe]

1. What metric would move if this works? (Be specific: not "engagement" but "weekly active users who complete X")
2. What metric would we expect to NOT move, and is that okay?
3. What's the minimum outcome that would make this worth the build cost?
4. What would we see in week 4 that would tell us it's not working?

I want to define kill criteria for [a project, feature, or experiment] before we invest more in it.

What we're doing: [describe]
What we've invested so far: [time, money, eng resources]
Current status: [what's been built or decided]

1. What are 3 specific, observable signals that would mean this isn't worth continuing?
2. What's the decision date: when should we evaluate against these signals?
3. What would we do instead if we stopped this? Name at least one concrete alternative.
4. What's the sunk cost argument we'll probably make to keep going even if signals are bad? Call it out now so we can ignore it later.

A stakeholder (customer, investor, or internal teammate) has requested we build [feature]. We're leaning toward not doing it, but we need a clear rationale.

The request: [describe]
Who's asking and why: [describe]
Our hesitation: [describe]

1. What's the strongest case FOR building this? (Steelman it)
2. What's the strongest case against? (Not just "we're busy" but a strategic reason)
3. Is there a smaller version we could do that addresses the core need without the full build?
4. Draft a 3-sentence response we could send to the person who asked, that's honest, respectful, and doesn't leave the door open if we mean it to be closed.

We're considering expanding to a new customer segment or use case. Help me think through whether it's a good idea before we commit resources.

Current segment: [describe who we serve now]
Proposed new segment: [describe]
Why we're considering it: [e.g., inbound demand, market size, a big customer asked]

1. How similar is the new segment's core problem to the one we already solve?
2. What would we have to change in the product to serve them well?
3. What's the risk that going after this segment dilutes our focus on the current one?
4. What's a low-investment way to test whether this segment actually wants what we'd build for them, before we build it?

We're trying to decide whether to build [capability], buy a tool/vendor for it, or integrate with an existing solution.

What we're deciding: [describe the capability]
Why we need it: [what customer need does it serve?]
What we've looked at: [any tools or solutions considered so far]

1. What factors most determine whether this should be built vs. bought vs. integrated?
2. What are the long-term risks of each path?
3. Which path most protects our core differentiation?
4. What's the question we should ask any vendor before committing?

We're about to [launch a product, start a quarter, ship a major feature]. I want to run a pre-mortem: assume it's 6 months from now and this didn't work.

What we're doing: [describe]
Our plan: [high-level]
What we're betting on: [key assumptions]

1. What are the 5 most likely reasons it failed?
2. For each reason, what's a signal we could watch now that would give us early warning?
3. Which of these failure modes is most in our control to prevent?
4. What's the one assumption in our plan that, if wrong, breaks everything?

I'll describe our competitive landscape as we understand it. I want you to challenge our assumptions.

Our understanding of competitors: [describe who you watch and why]
What we think our advantage is: [describe]
What we think competitors are doing: [describe]

1. What are we probably wrong about?
2. What competitor behaviors or moves would most threaten us if they happened?
3. Who are we probably not watching that we should be?
4. If you were a well-funded competitor entering our market, what would you do to beat us specifically?

Here's our current product strategy or roadmap. I want you to extract every assumption embedded in it, rate how validated each one is, and flag the ones that could sink the strategy if they're wrong.

Strategy or roadmap: [paste or describe]

For each assumption:
1. Is it validated (we have data), partially validated (we have signals), or unvalidated (we're guessing)?
2. How damaging would it be if the assumption is wrong?
3. What's the cheapest way to validate the high-risk, unvalidated assumptions before we build?

I'm going to describe our current product and customer base, including some recent customer feedback. I want you to identify signals that we may be serving a different customer than we think we are, or that our best customers are different from our typical customers.

Product: [describe]
How we describe our ICP: [describe]
Recent feedback or behavior patterns: [describe what you know]
Who's getting the most value (if you know): [describe]

1. Who does the feedback data suggest we're actually best for?
2. Are there signals we're trying to serve too many types of customers?
3. If we had to cut our ICP to a single sentence and only build for that person, who would it be based on the evidence?

I'm going to give you our stated strategy and our actual roadmap. I want you to tell me whether they are the same document.

Our stated strategy: [paste or describe, including who we serve and why we win]
Our roadmap for the next two quarters: [list the work, with rough effort on each]
Where our engineering time actually went last quarter: [describe honestly, including the unplanned work]

1. Which roadmap items directly advance the stated strategy? Which are unrelated, and what percentage of the effort do they represent?
2. If someone only saw our roadmap and never read our strategy, what would they conclude our strategy is?
3. Where are we spending real effort on something we have never named as a priority? Where did that work come from?
4. If the strategy is right, what should come off the roadmap? If the roadmap is right, what should change in the strategy?

I want you to test whether our strategy is actually a strategy or just a statement of intent.

Our strategy: [paste it]
Our target customer: [describe]
What we believe makes us win: [describe]

1. What is this strategy explicitly saying no to? Name the customers, features, and markets we are choosing to lose.
2. If you cannot find a real no, tell me directly. A strategy that costs us nothing is a wish.
3. Which competitor could adopt this exact strategy statement tomorrow without changing anything about their business? What does that tell us?
4. Where have we written a tradeoff as a both-and ("simple and powerful," "fast and thorough") to avoid making the choice?
5. Rewrite our strategy in two sentences that contain a real choice, one someone on the team would be uncomfortable defending to a prospect we would be turning away.