Note: Productboard Spark is now generally available. If you joined during the beta program, your standalone Spark workspace remains accessible and your content carries over. See Spark pricing and billing FAQ for plan and billing details.
Productboard Spark is an AI agent that understands your product, customers, and market. It surfaces the opportunities worth working on. It drafts delivery-ready specs grounded in your codebase and strategy. It helps you track whether what shipped drove impact. Spark is built for product managers and product leaders, and the whole product team can work inside it.
This article covers what Spark does, how it fits into your day, and how to set it up. If you're new, start at the top. If you're returning, jump to the section you need.
In this article:
- What Spark does
- How Spark knows your product
- Working in Spark
- Collaborating with your team
- Controlling access with visibility settings
- Current limitations
- FAQ
- See also
What Spark does
Spark is organized around the three jobs of product management: deciding what to build, specifying it well enough to build, and learning from what shipped. Most of your time in Spark falls into one of these three jobs.
1. Surface what matters
Spark continuously analyzes the customer and market signal in your connected sources. It clusters the signal into themes and surfaces the opportunities worth your attention, ranked by the evidence behind them. You don't build pivot tables or read every support ticket. The briefing is there when you open Spark, with the underlying evidence one click away.
Each opportunity is a problem statement, not a feature request. It draws together the customer feedback, competitive context, and the quantitative signal behind it where you have analytics connected. You vet what's worth pursuing; Spark does the synthesis.
If you'd rather explore on your own terms, the Insights area lets you drill into the underlying findings, topics, and customer signals directly.
2. Turn ideas into specs
Once you've picked an opportunity, Spark helps you turn it into a delivery-ready spec through a guided conversation. Spark already knows your strategy, target customers, and competitive context. If you've connected GitHub, it also knows how your product actually works in code. The first draft of the spec reflects all of that.
Spark drafts; you steer. Spark handles the parts that follow from known context — structure, customer evidence, references to existing codebase patterns, and analytics considerations consistent with your product principles. It asks you the judgment calls only you can answer. Should this be a public API? How should it surface in onboarding? What's in and out of scope? The output is a spec you can hand to engineering, a coding agent, or both.
You stay in the spec as the work evolves. Engineers and designers can read it, comment, and suggest edits in real time. The spec stays the source of truth, not a static artifact that goes stale the moment Slack starts moving.
3. Measure the impact
Note: Post-release impact measurement is rolling out progressively after GA. The capability described here reflects the direction; specific features ship over time. Track progress on our portal.
Spark already knows the goals and success metrics in each spec. When a feature ships, Spark connects to your analytics and CRM data and compares actuals against the goals you set. The review arrives at 7, 14, and 30 days, and goes to the team — not just the PM who shipped it.
The review goes beyond the headline metric. It surfaces which segments adopted, which didn't, and what the data suggests as the next move. A feature that misses its goals doesn't disappear; it flows back into the opportunities Spark surfaces for the next cycle.
How Spark knows your product
Spark is most useful when it has a strong picture of your product, customers, competitors, and strategy. Some of that picture builds itself; some of it you bring in. This section covers what's automatic, what you add, and how to keep it current.
Initial context
The first time you sign in, Spark uses publicly available information to build an initial picture of your company, product, and top competitors. You'll find the results in the Agent knowledge section, organized into documents you can read and edit.
This is a starting point, not a finished picture. Add the strategy that isn't public, the segments that aren't on your website, and the decisions that live in people's heads. The more your context reflects what your team actually knows, the more useful Spark becomes.
Adding strategy, personas, and competitors
The most useful context to add early:
- Personas and target customers (segments).
- Product strategy and OKRs.
- Pricing and packaging.
- Anything specific to your business that Spark can't infer from public sources — technical architecture decisions, messaging strategy, brand guidelines.
To add context, paste content directly into new documents in the Context folder. You can also attach files to a chat and have Spark turn them into structured context. To attach files, click Context > Attach file.
To add a competitor or persona, ask Spark in the chat panel. Spark drafts the document and places it in the right folder. To use a specific template, @-mention it in your prompt; otherwise Spark picks a default.
Tip: You don't need to populate everything before you start working. Add the strategy, personas, and two or three competitors first, then add more context as specific projects need it.
For details, see Context management in Spark.
Bringing customer feedback in
Customer feedback is the single most valuable signal Spark works from. Connect a feedback source — Zendesk, Gong, Intercom, or your insights boards in Productboard. Spark synthesizes the patterns across thousands of items into themes you can act on.
You can also use specific feedback as context inside a single chat. Type @ in the chat panel to mention notes, filtered insights boards, or specific customer feedback. Spark uses the mentioned items as primary evidence for that conversation.
See Customer feedback management in Spark for details.
Grounding specs in your codebase
Connect your GitHub repository and Spark uses your codebase to ground every spec it writes. It surfaces existing patterns, flags edge cases that depend on current implementation, and respects the architectural decisions already made in the product.
This matters most at the spec stage. A spec grounded in implementation reality is a spec that engineering can build from without a round of clarification meetings. It's also what keeps AI-generated code from contradicting how your product already works.
Spark also indexes your product documentation and any help articles you point it at. Prior decisions about terminology, architecture, and tradeoffs are available to every spec.
Working in Spark
UI orientation
Spark has four main interface elements:
- Main menu: The left edge of the screen. Use it to navigate between the main areas of Spark. Home is at the top; Settings is at the bottom.
- Submenu: The panel next to the main menu. It changes based on where you are. From Home, it shows your documents organized into folders.
- Chat panel: Where you interact with Spark. If no document is open, the chat panel takes most of the screen.
- Document panel: Opens on the right when you select or create a document.
Chats and documents
Chats and documents work differently and are used for different purposes:
- Chats are private to you and not shareable. Use chats to explore ideas, ask questions, and iterate before producing something durable.
- Documents are public to your workspace by default (unless you create them in your Personal section). Use documents for anything you want your team to read, edit, or collaborate on — specs, briefs, persona definitions, competitive analyses.
You can find past chats in the chat history, sorted by time. Each chat shows Spark's reasoning under your prompts so you can see what context Spark drew from to generate its response.
When Spark edits a document, it highlights the changes so you can accept or reject them. To see prior versions or revert a change, open the document's context menu and select Version history.
Templates
Spark ships with templates for the most common product management documents — briefs, requirements docs, persona definitions, competitive analyses, interview scripts. When you ask Spark to create a document, it looks in the Templates folder for a relevant one. To use a specific template, @-mention it in your prompt.
You can edit any template directly, or ask Spark to rewrite one for you. To add a new template, create a document in the Templates folder. Then paste the structure in or ask Spark to draft one for you.
Tip: Use Spark to define your own templates. Ask it to insert short instructions under each section. Spark will follow those instructions when filling the template in later.
Connectors and external tools
Spark connects to external tools so you don't have to switch between platforms. Two connection methods are available:
- Model Context Protocol (MCP) connectors: Query live data from tools like Amplitude, Linear, and Notion through conversation. For example: "Show me engagement metrics from Amplitude for the new onboarding flow."
- File attachment connectors: Attach documents from Confluence or Google Drive as context for a chat. Attach a competitor analysis, then ask Spark to draft three feature ideas that close the gap.
- GitHub integration: Give Spark a deep understanding of how your product actually works at the code level. Before Spark writes a spec, it analyzes your codebase to surface relevant existing patterns, flag edge cases before they become engineering surprises, and ensure the spec doesn't contradict implementation reality.
Spark supports Google Docs, Slides, Sheets, Confluence pages, plain text, CSV, markdown, and PDF.
For setup and supported tools, see Connect external tools to Productboard Spark.
Collaborating with your team
Spark is built for the whole product team. Specs, opportunity briefs, customer insights, and strategy documents live as shared, real-time documents. PMs, designers, and engineers can co-edit, comment, and suggest changes in the same surface. The spec stays current as the team works on it, instead of going stale the moment the conversation moves to Slack.
To invite teammates, add them to your Spark teamspace with the appropriate role:
- Makers can create, edit, and comment on documents.
- Contributors can edit and comment on documents.
For role details, see New board sharing: Teamspace types and member access levels.
Because your team works on the same documents and the same evidence, the knowledge accumulates at the team level rather than in individual chat histories. When someone joins, leaves, or moves between product areas, the institutional context stays with the team.
Controlling access with visibility settings
Space admins can control which users have access to Spark using the visibility setting in Settings > Labs. This lets you configure and validate your workspace before rolling Spark out to your full team.
Changing the visibility scope
You must be a space admin to change visibility settings. If you are:
- From the Main menu, click Settings > Labs.
- Find the Spark visibility card.
- Select the visibility scope that fits your current needs.
Visibility options
Things to know
- Admins always retain access to the Labs setting. Even when Hidden for everyone is active, the Spark visibility control remains visible and editable by admins. You can restore access at any time without contacting support.
- Expanding access takes effect immediately. When you widen the scope (for example, from Visible to admins only to Visible to everyone), newly eligible users see Spark right away.
- Restricting access is applied gracefully. When you narrow the scope, users in an active Spark session can continue until they reload the page or log in again, at which point access is revoked.
- Each space has its own visibility scope. Settings don't cascade from parent to child spaces. Each space admin manages their own space independently.
- Restricted users see a blocked entry point. Users without access see the Spark entry point grayed out, with a prompt to contact their admin.
Current limitations
A few capabilities are still rolling out:
- File upload: Direct upload of PDFs and other binary files into the workspace is not supported. Attach files to chats instead, or paste text content into a new document.
- Change tracking: When Spark edits a document, its changes are highlighted in the UI. If you don't accept or reject them, the changes are accepted automatically. Highlights persist only for the current browser session.
- Document privacy: Documents are accessible to other users in your workspace by default. Chats are always private and not shareable. To keep a document private, create it in your Personal section.
- Core product entities: Spark cannot yet retrieve, create, or update core Productboard entities such as features, releases, objectives, or initiatives directly. You can upvote this on the portal.
- Post-release measurement: The 7, 14, and 30-day post-release review described under Measure the impact is rolling out progressively. Track progress on the portal.
FAQ
Who can use Spark?
Spark is available to all Productboard customers. Plan details determine which capabilities are available; see Spark pricing and billing FAQ for specifics.
Can contributors and viewers use Spark?
Contributors and viewers can see Spark in the main navigation and use Spark chat, including context management, connectors, and Spark skills.
Contributors and viewers can ask Spark about existing boards and data they have access to. They cannot create new documents or folders, except where contributors have been granted document creation permissions in specific teamspaces.
How is Spark different from a general AI tool like ChatGPT or Claude?
Three differences matter most:
- Spark knows your product. It works from a structured layer of customer feedback, product strategy, competitive intelligence, codebase context, and prior decisions. A general AI tool starts from scratch each session.
- Spark grounds every output in evidence. Recommendations are traceable to the customer feedback, support tickets, or competitive signal behind them. You can verify any claim before you act on it.
- Spark is multiplayer. Documents are shared and co-edited in real time. The work of one product manager becomes context for the next. With a general AI tool, the value lives in your chat history.
How is Spark different from a DIY agent setup like Claude Code with custom prompts?
A DIY agent setup can be effective for an individual product manager who has the time to build and maintain it. The tradeoffs:
- Maintenance. Every new tool, project, or team change requires updating the setup. Spark handles that infrastructure for you.
- Output quality at scale. Spark's pipelines are built to synthesize large feedback volumes without misattributing quotes or collapsing distinct signals. Naive pipelines hallucinate as the corpus grows.
- Team adoption. A DIY setup works for the person who built it. Spark works for the whole team — documents are shared, context accumulates, and a new PM inherits everything the team has learned.
Can I customize Spark's outputs?
Yes. Edit templates to control how Spark structures specific document types, and add context documents to control what Spark draws from when generating content. You can also use Spark skills to encode repeatable workflows. See Agentic skills with Spark for details.
What data does Spark use?
Spark uses the documents and information in your workspace, plus any sources you connect or attach. Your data is not used to train Productboard's AI models for the purpose of serving other customers. We do not permit our third-party subprocessors of Productboard AI to use your data to train their AI models.
Is my data secure?
Yes. Spark follows Productboard's standard security and privacy practices. Your data remains within your workspace.
Is Spark a replacement for my project tracker?
No. Spark is the strategy-to-spec layer above your tracker. It helps you decide what to build, how to specify it, and whether it worked. It generates the work that your tracker (Jira, Linear, or similar) catalogs.
Spark exports delivery-ready specs directly to connected trackers, and the spec in Spark stays live as the source of truth as the build evolves.