Workflow and prompts

Use your own workflow, or a framework

The MCP server doesn't impose a way of working. It exposes your specs to your agent — what you do with them is up to you.

• Working freestyle? Pull a spec, talk through the plan with your agent, and build. No setup beyond the connection.
• Using a structured method? Spec-driven development frameworks such as Spec Kit, GSD, and BMAD give your agent a repeatable process — establishing principles, breaking work into tasks, and checking the result against requirements. The Productboard spec slots in as the source these frameworks build from.

Either way, the spec stays in Productboard as the single source of truth, and your agent reads from it on demand.

Where engineers get the most from it

The MCP server shines when the spec is your starting point for building. Here's where teams feel it most.

Spec-driven development

Spec-driven development means treating the spec — not a quick prompt — as the source of truth your agent builds from. It's a fast-growing way of working with coding agents, because a precise spec produces far better output than a vague instruction.

The MCP server makes the spec a live input instead of a copy that drifts out of date:

• "Pull the spec for the export API and help me plan the implementation."
• "Read the spec for the notifications feature and write the route handler from the acceptance criteria."
• "Generate integration tests based on the acceptance criteria in the billing spec."
• "Compare what I've built so far against the spec — what am I missing?"

Because the agent reads the spec directly, it works from what the product manager wrote today, not a version someone pasted in last week. Fewer wrong turns, less rework.

Find the right spec without leaving your editor

Before you write a line of code, you can check whether a spec even exists:

• "Is there a product spec for the notifications feature?"
• "List the product specs related to billing."
• "What specs are owned by Sarah?"

Close the loop when the spec falls short

When a spec doesn't answer your question, you don't have to guess and move on. Your agent can route the question back to the person who owns the spec:

• "The spec says 'respect existing permissions' but doesn't cover guest users — add a comment asking the PM about it."
• "I found an edge case the spec misses. Flag it on the spec as an open question."
• "Reply to the comment about authorization and say this decision was deliberate."

The question lands in Productboard, where it gets answered once — instead of being settled by a guess that's quietly baked into the code.

For product managers: build to refine your spec

The MCP server isn't only for engineers. Product managers can connect their own coding agent and turn a spec into something clickable — a quick prototype to pressure-test an idea, gather reactions, and sharpen the spec before it reaches engineering.

• "Use the spec for the onboarding redesign to generate a working prototype I can click through."
• "Build a rough version of the settings page from the spec — just enough to show in a review."

The result is a tighter feedback loop between "spec written" and "something I can react to."