Spark: Turn ideas into specs

Jake Sawyer

Updated June 17, 2026 15:48

Spark’s spec flow helps you turn a rough idea or an opportunity brief into a structured, evidence-backed product specification. Spark handles the structure, pulls in customer evidence, and checks your codebase for implementation patterns. You supply the judgment calls that only a PM can make.

This article walks you through each step of the flow, from your first prompt to a handoff-ready spec.

How the spec flow works

The core principle is simple: Spark drafts; you steer.

When you start the spec flow, Spark assembles a first draft by drawing on everything it knows about your product. It structures the document, surfaces relevant customer evidence, checks your codebase for existing patterns and constraints, and grounds scope recommendations in your product strategy. You don't have to gather that context manually.

What Spark doesn't decide for you are the judgment calls: scope, API exposure, onboarding surface, and edge cases. These all require your input. Spark pauses and asks. Your answers shape the final document.

What Spark handles	What Spark asks you
Document structure and standard sections.	Scope: what's in V1 and what's deferred.
Surfacing relevant customer evidence.	API exposure: internal-only or externally accessible.
Codebase pattern and constraint analysis.	Onboarding surface: where users discover the feature.
Product strategy and persona grounding.	Edge cases: persona-specific scenarios and known unknowns.

Before you start

What Spark needs to write a good spec

Spark produces better specs when your workspace context is complete. Before starting, make sure the following are available:

Product strategy documents. Spark uses your mission, positioning, and roadmap context to recommend scope and flag misalignments.
Personas. Spark grounds user stories in the people your product actually serves.
Connected feedback. Customer notes linked to features or initiatives give Spark the evidence it needs to support design decisions.

If any of this is missing, Spark will still produce a draft, but it will flag gaps and ask you to fill them in. See Context management in Spark for details.

Connecting GitHub

Connecting your GitHub repository gives Spark direct access to your codebase. Spark uses it to identify existing patterns, check constraints, and avoid recommending approaches that conflict with how your product is already built. Without it, Spark works from intent alone and may miss implementation realities that affect the spec. See Connect external tools to Productboard Spark for setup instructions.

Writing a spec with Spark

Step 1: Starting from an opportunity

You can start the spec flow from several entry points:

Type /write-spec in any Spark conversation and describe what you want to build.
Open a feature or initiative in Productboard and ask Spark to write or update its specification directly.
Start from an opportunity or finding. Spark picks up the context automatically.

If your initial prompt is thin, Spark asks clarifying questions before drafting. These cover what problem you're solving, who it's for, and what success looks like. Answer them in as much detail as you can. Spark uses your answers, not just the initial prompt, to build the first draft.

Step 2: Reviewing the first draft

Spark's first draft includes the standard sections for a product spec: problem statement, goals and success metrics, user stories, requirements, instrumentation, and open questions. Read through it as you would any PM document.

Pay particular attention to:

The problem statement. Spark derives this from customer feedback and strategy context. Correct it if it doesn't match your intent.
User stories. Check that they match the personas you're targeting.
Open questions. Spark flags the things it couldn't resolve. These become the agenda for the next step.

Step 3: Answering Spark's judgment-call questions

After the first draft, Spark surfaces a set of questions it can't answer on its own. These typically cover:

Scope: what's in V1 and what's explicitly deferred.
API exposure: whether this feature should be accessible externally or is internal-only.
Onboarding surface: where and how users should discover the feature.
Edge cases: persona-specific scenarios or known unknowns that need handling.
Constraints: technical, accessibility, or rollout factors Spark detected or inferred.

Answer each question directly in the conversation. Spark incorporates your answers into the spec and updates the document.

Step 4: Iterating and finalizing

Continue the conversation to refine any section. Ask Spark to expand a requirement, tighten the success metrics, or rewrite a user story. Edits appear as suggestions in the document, which you can accept or reject individually.

The spec is ready when the open questions section is empty and you'd be comfortable handing it to an engineer.

Keeping the spec current as the build evolves

A spec isn't done when writing stops. As your team builds, decisions change, scope shifts, and edge cases surface. Productboard keeps the spec as the living source of truth.

Co-edit directly. You and your teammates can edit the spec document at any time. Spark always works from the current state of the document, so it stays in sync with your manual changes.
Use threaded comments. Highlight any section to start a discussion thread. Tag teammates to surface decisions that need review.
Accept or reject AI edits. When you ask Spark to update the spec, edits land as suggestions. Accept what's right, reject what isn't, and edit inline if neither option fits.
Check version history. Productboard tracks document changes over time. Use version history to see what changed and when, or to recover earlier wording.

Exporting and handing off

When the spec is ready, you have several options for sharing it with your team.

Share with engineering. Send a direct link to the spec document. Engineers can read it in Productboard with full comment and suggestion access.

Pass to a coding agent. If your workspace is connected via MCP, your coding agent can use the spec as a starting point for implementation planning. See Connect external tools to Productboard Spark for setup.

Reference from a connected tracker. If your workspace is connected to Jira or another issue tracker, link the spec document URL from your issues. This keeps context close to the work.

Note: The full spec, including comments, suggestions, version history, and customer evidence links, lives in Productboard. When you share a link or reference the spec from an external tool, only the content travels. The live Productboard context stays where it is.