When you connect your coding agent to Productboard, the spec you wrote in Spark becomes something you can build from directly, and it always stays up to date. This guide walks product managers (PMs), product ops managers, and Productboard admins through the spec workflows that save the most time. You don't need an engineering background to follow it.
Note: This guide assumes your agent is already connected to Productboard. If it isn't, start with Connect a coding agent to Productboard via MCP.
In this article:
- Start here: Write your specs first
- Building a prototype to test an idea early
- Handing engineering a spec that's always current
- Turning a spec into an update in seconds
- See also
Start here: Write your specs first
The MCP server delivers the specs you author in Spark, so the first step happens inside Productboard. It can't deliver what hasn't been written yet.
Open any initiative, feature, or subfeature and go to the Specification tab. When the field is empty, click Write spec to launch the write-spec skill. Spark reads the item's description and related context, asks a few clarifying questions, and drafts a spec into the Specification field. Review the draft and accept or reject the changes, the same way you would with any Spark edit.
A clear, current spec is what makes everything below work. The sharper your spec, the better your agent's output.
For the full walkthrough, see Write product specifications with Spark.
Building a prototype to test an idea early
A written spec is easy to agree with and hard to react to; a working prototype is much better. Connect your agent, point it at a spec, and turn it into a clickable prototype you can put in front of stakeholders.
Try prompts like:
- "Use the spec for the onboarding redesign to build a working prototype I can click through."
- "Build a rough version of the settings page from the spec, just enough to show in tomorrow's review."
- "Turn the acceptance criteria in the notifications spec into a clickable wireframe."
When the prototype reveals a gap, fix it at the source. Your agent can write the change back to the spec:
- "The prototype showed we never defined the empty state. Add a comment on the spec flagging this as an open question."
Handing engineering a spec that's always current
When you share a spec with your engineering team, their coding agent reads it directly from Productboard. That means they build from the version you edited today, not a copy someone pasted into a chat last week. This approach is often called spec-driven development: the spec, not a quick prompt, is the source of truth the agent builds from.
When you update a spec, the next person to pull it gets your latest thinking. That means less drift between what you wrote and what gets built, and less rework when something changes.
You can also signal when a spec is ready to pick up:
- "Mark the billing spec as ready for engineering."
Tip: Your engineers may want the full setup and workflow details, including the list of tools, the data-access model, and how the server fits with spec-driven development frameworks like Spec Kit, GSD, and BMAD. Send them to the technical guide.
Turning a spec into an update in seconds
Because your agent can read any spec you own, it's also a fast way to prepare for stakeholder updates or release notes:
- "Summarize the API partners spec into one paragraph for my stakeholder update."
- "Pull the billing spec and draft release notes from it."