Prompt library for common Spark use cases

When to use: You're tired of personas that feel made up. You want them grounded in what customers actually say and do.

Develop 3-5 personas for PRODUCT_OR_MARKET based on actual customer feedback. For each persona, what are their core goals? What problems keep them up at night? What's their current workflow? Ground each persona in real customer quotes and frequency of mention. Rank by market size and revenue potential.

What you get: 3-5 detailed personas with supporting evidence, pain points, workflows, and market ranking. Each one is backed by real customer quotes so your team believes them.

Why it matters: Personas become a shared language for your team. When engineering debates a feature, you can say "this solves a problem for Persona B" and everyone understands what that means.

When to use: You're trying to figure out who to focus on. You have customer feedback but need to see the distinct segments and which ones are most valuable.

Apply segmentation frameworks to customer feedback. What distinct customer clusters emerge from how they describe problems, company size, industry, and use cases? Which segments show strongest product-market fit signals? Rank by revenue potential and strategic fit.

What you get: Customer segments with supporting evidence and strategic ranking. You'll see which segments love your product and which ones are struggling.

Why it matters: You can stop trying to be everything to everyone. Focus on the segments where you're winning, and build a roadmap that serves them better.

When to use: You're launching a feature and need messaging that actually lands with customers.

Develop 2-3 distinct positioning angles for _FEATURE targeting _SEGMENT. For each angle, what's our category claim? What's the narrative that makes this matter? What makes us unique? Stress-test each: What objections will customers raise? Which positioning best aligns with our strengths and customer demand?

What you get: 2-3 positioning options with competitive advantages, customer appeal, and a recommended approach with rationale.

Why it matters: Your sales team has a clear story to tell. Your marketing knows how to position the feature. Your customers understand why they should care.

When to use: You're drowning in low-ROI work and need to make the case for cutting features or projects.

What are we building or maintaining that isn't driving customer value or business outcomes? Analyze PRODUCT_OR_AREA for low-usage features, low-satisfaction capabilities, or high-maintenance work. What's the opportunity cost of keeping these? What could we build instead?

What you get: A list of 3-5 low-ROI items with supporting data, customer sentiment, and recommended actions ranked by impact.

Why it matters: You have the data to make hard cuts. Your team understands that saying "no" to low-impact work means "yes" to high-impact work.

When to use: You have customer call transcripts or feedback but it's scattered. You need to identify the top problems and see which ones matter most.

Extract the problem taxonomy from these customer calls for PRODUCT_AREA. What are the distinct problems customers face? How do they cluster? Which problems appear across multiple customers vs. which are segment-specific? Rank by frequency and severity.

What you get: A structured list of 5-10 distinct problems ranked by how often they appear and how much they impact customers. You'll see which segments are affected and what patterns emerge about root causes.

Why it matters: Instead of re-reading transcripts, you have a prioritized problem list you can act on immediately. This becomes the foundation for your roadmap.

When to use: You're exploring how to build a feature and want to ground it in what customers actually need.

What customer problems could FEATURE_NAME solve? Synthesize the feedback to identify 3-4 core problems. What are customers actually asking for? What are the common themes in how they describe the solution? Propose 2-3 solution approaches and evaluate which best addresses customer needs.

What you get: A problem analysis with 3-4 core problems, 2-3 solution approaches with trade-offs, and a recommended approach backed by real customer evidence.

Why it matters: You walk into stakeholder conversations with evidence, not opinions. Your team can see exactly why you're building this and what customers want.

When to use: You're defining a new feature and need a complete PRD that connects customer evidence to requirements.

Create a PRD for FEATURE_NAME that connects customer evidence to requirements. What problem are we solving? Who are we solving it for? How will we know it's working? What are the non-negotiable requirements vs. nice-to-haves? Make the case compelling enough that engineering understands the 'why'.

What you get: A complete PRD with problem statement backed by customer evidence, detailed requirements, acceptance criteria, and success metrics.

Why it matters: Engineering stops asking "why are we building this?" because the PRD explains it. They understand the customer problem and can make smarter trade-off decisions.

When to use: You have a big initiative but need to figure out what to ship first and in what order.

Break down INITIATIVE_NAME into shippable features. What's the core value proposition? What are the 4-6 features that build toward that outcome? What's the MVP vs. phase 2? What are the dependencies? Propose a phased rollout with rationale.

What you get: A feature breakdown with 4-6 features, user stories, dependencies, complexity estimates, and a phased rollout plan.

Why it matters: You can ship value faster. Instead of waiting for everything, you get the MVP out, learn from customers, and adjust. Your team knows exactly what to build and in what order.

When to use: You're preparing to launch a feature and need to coordinate product, engineering, design, marketing, sales, and support.

Plan the end-to-end launch for FEATURE_NAME. Who are we targeting? What's the narrative? What happens before launch? On launch day? After launch? How do we measure success? Make this coordinated across sales, marketing, customer success, and support.

What you get: A comprehensive launch plan with pre-launch, launch, and post-launch activities, owners, timelines, and success criteria.

Why it matters: Everyone knows what they're doing and when. Marketing isn't surprised by what engineering shipped. Sales knows how to talk about it. Support is ready to help customers.

When to use: You have an upcoming customer call and want to be prepared with their feedback history.

Summarize all feedback from CUSTOMER_NAME to prepare for an upcoming call. What are their top problems? What have they requested? How satisfied are they? What's changed since we last talked? What should we focus on in our upcoming conversation?

What you get: A customer summary with top problems, sentiment, talking points, and recommended questions and opportunities.

Why it matters: You have clarity during the call. You remember what they care about. You can have a strategic conversation instead of scrambling to remember context.

The goal of this sequence is to dig into what customers are saying about a topic and what it means for the decision at hand. Use it when you need to prepare a thorough analysis of customer feedback before you begin prioritization, spec drafting, or a stakeholder alignment meeting.

With this sequence, Spark distinguishes between broad signal and outlier noise, names specific accounts or segments, and gives you a clear next action.

Tip: Don't accept the first synthesis as final. Ask what it's missing, which accounts are outliers, or whether the pattern holds across enterprise vs. SMB. The second answer is usually better than the first.

Use this sequence every time Spark produces something you're about to use or share. Knowing where Spark is confident and where it's inferring changes how you use the output.

This forces Spark to point to specific sources, flag where it reasoned vs. where it found data, and give you a concrete thing to validate. If it can't tell you where something came from, treat it as an inference.

Tip: One follow-up question takes 30 seconds and saves a lot of credibility. Sharing Spark output without running one of these checks first, especially for anything going to leadership or customers, can lead to decisions being made on shaky ground.

This sequence is great when you're working through something end-to-end, like feedback-to-spec, discovery-to-brief, or a signal-to-stakeholder update.

Spark keeps the thread across the whole conversation, so you don't need to start over at each step. By the end of the sequence you have a finished, usable output.

In this example, we're running a feedback-to-spec workflow.

Tip: Keep the whole workflow in one conversation. Starting a new conversation for each step causes you to lose the thread, and skipping the whole process to start writing a spec without grounding it in real feedback is where bad decisions come from.

Use this sequence when you need to define what to build, whether starting from scratch, refining a rough idea, or iterating on feedback. Spec writing is one of the highest-frequency PM tasks. Spark does its best work here when the conversation is grounded in a specific, well-defined problem.

This sequence will help you write a spec that clearly separates problems from solutions, has explicit assumptions flagged, and reads like a decision document. Spark will surface the weak spots and likely engineer pushback before you do.

Tip: Don't ask Spark to write a spec without grounding it in the problem first. The output will be generic. Give it real feedback or a clear problem statement before asking for a draft.

A skill is a saved set of instructions that Spark follows every time you invoke it, like a shortcut for your team's most-used workflows. Once created, anyone on the team can call it with a single slash command, with no prompt engineering required every time.

Productboard's pre-built skills cover the core PM workflows: spec writing, feedback analysis, and competitive research. When that doesn't cut it, you can create your own skills. And Spark can help you do that too.

You can create skills for all sorts of things, but the examples in this section help you capture the voice and perspective of a specific person or team: how your CPO evaluates a roadmap, what your manager pushes back on, the standards your team applies before shipping.

Use this technique when there's a perspective you or your people need regularly but can't always access, such as a senior stakeholder's judgment, your own review style scaled to your team, or the lens a specific decision-maker applies to work.

Tip: Make sure you explicitly ask Spark to build a skill. Spark ships with a built-in skill-building skill that it'll use to help you create your own. You can invoke it directly with "/create-skill", or simply mention you need help building a skill.

Tip: Be specific about the personality you're trying to capture. "They care about quality" gives Spark nothing to work with. The more specific you are ("they always ask about the edge case for mobile users," "they push back on anything without a metric attached," "they want a rollback plan before approving anything"), the more useful the skill will be.