Deck

Build Features from Customer Evidence, Not Guesswork

Turn a Deck Project into a shipped change where every requirement links to the customer insights behind it. Build it yourself or with your coding agent.

By Matt TeixeiraUpdated

Run it in Deck
Time to Run
1–2 hours
Uses
Projects,MCP Server
You Get
Evidence-Linked Pull Request Description
Run It
In Deck or with your agent

What Does Building from Customer Evidence Mean?

Building from customer evidence means every requirement in a change points at the customer insights behind it. If a requirement has no evidence, it gets evidence or gets cut. The pull request links those insights, so reviewers see why the change exists, and feedback after release shows whether it solved the problem.

Why Customer Context Gets Lost Before the Build

The ticket says “improve onboarding.” By the time it reaches the person building it, the customer quotes are three tools away and the reason it was prioritized is gone. The team ships its best reading of a one-line summary, and nobody can tell afterwards whether it fixed what customers asked for.

How Deck Keeps Evidence Attached to the Work

A Deck Project keeps the customer evidence attached to the work: the insights, the quotes, and the reason it was prioritized. When you build, each requirement traces back to those insights, and the pull request links them. After release, new feedback about the change lands on the same Project.

How to Build Features from Customer Feedback in Deck

Run it yourself in Deck, or hand it to your AI agent. Same steps, same result.

  1. 01

    Open the Project

    Go to Build → Projects and pick a Project that is not started. If it came from the Opportunity Backlog, Deck already seeded it with that opportunity's evidence.

  2. 02

    Read the Evidence, Not Just the Title

    Open the Evidence tab and select Related Insights. Read the quotes. For a bug, open the source conversation to find the steps, the screen, and the error text.

  3. 03

    Write Requirements a Test Can Check

    Group the insights by the problem they describe. For each group, write one requirement, the insights behind it, and whether it is a bug, a usability issue, or a feature request. List what you leave out and why.

  4. 04

    Mark the Project In Progress

    Set the status in the Project header to In progress when building starts. Leave Completed for when the change ships.

  5. 05

    Link the Evidence in the Pull Request

    Add the Project link and each requirement's insight links to the pull request description, so reviewers see why the change exists. Do not paste customer names or emails into code or commits.

  6. 06

    Collect Feedback on the Change

    Link an in-app feedback widget to the Project from Manage → Deck Collect. New responses show on the Project's Feedback tab, next to the evidence that started it.

Evidence-Linked Pull Request Template

evidence-linked-pull-request-description.md
## Deck Project
- [Project link]
## Requirements
Requirement (testable)          | Type                              | Evidence     | Insights       
--------------------------------|-----------------------------------|--------------|----------------
[One sentence a test can check] | Bug / Usability / Feature request | [Deck count] | [insight links]
## Left out
- [Request] — [reason]
## Tests
- [Test name] — covers [requirement]
## After release
- Feedback widget linked to the Project: Yes / no
Plain text. Pastes into Docs, Notion, or your agent.16 lines

Frequently Asked Questions

Product and design leads can do the first three steps in Deck: read the evidence and write the requirements. The build itself happens wherever your team writes code.

Yes. With Deck MCP connected to a coding agent such as Claude Code, Cursor, or Codex, paste the prompt on this page. The agent reads the Project and its insights, shows you a plan, and asks before it changes code or updates Deck.

No. A Project can link to a Linear Project or Jira Epic, and Deck stores the link. Your agent needs its own Linear or Jira tools to read those items.

Set the Project to Completed. New feedback about the change can attach to the same Project, so you can see whether it solved the problem.

Add insights to it first, from Themes or from the Opportunity Backlog. Building without evidence is the guesswork this playbook removes.