What makes product context buildable?

Buildable context identifies the customer problem and desired outcome, defines scope and exclusions, states business rules, includes testable acceptance criteria and edge cases, and exposes unresolved decisions instead of asking the agent to guess.

Product-to-Engineering Workflow · September 4, 2026 · 11 min read

The PM-to-Cursor Handoff: Turn Customer Evidence Into Buildable Context

Q: How do product managers hand requirements to Cursor?

Product managers should turn customer evidence into an approved problem, outcome, scope, business rules, acceptance criteria, edge cases, and success measures. Developers can then retrieve that structured context in Cursor through MCP and combine it with repository instructions.

Q: Should customer feedback be pasted directly into Cursor?

Raw feedback is useful as evidence but should not become an implementation instruction by itself. Product teams should synthesize repeated signals, make a decision, and give Cursor the approved requirement with traceable evidence.

Q: Does MCP replace the PM-to-developer handoff?

No. MCP improves access to the current requirement. Product and engineering still need to agree on scope, resolve ambiguity, review the implementation plan, and verify the result.

Move from “customers keep asking for this” to an evidence-backed product decision that Cursor can retrieve, interpret, and implement without inventing the missing requirements.

A reliable PM-to-Cursor handoff has five stages: collect customer evidence, synthesize the signal, make the product decision, express it as buildable context, and make the approved requirement retrievable inside Cursor.

The handoff is complete only when the developer and agent can identify the source evidence, current scope, explicit exclusions, business rules, acceptance criteria, edge cases, and unresolved decisions—and can verify the final diff against them.

Why Copying a Ticket Into Cursor Is Not a Product Handoff

A support ticket reports one person’s experience. A sales note often mixes a customer problem with a requested solution. A roadmap card compresses months of discussion into a title. None of these, by itself, tells a coding agent what the product team has decided to build.

When raw evidence becomes an implementation prompt, the agent must silently choose:

whether the request represents one customer or a repeated pattern;
which user and business outcome matters;
which proposed solution is approved;
what is inside and outside the change;
how permissions, failures, and edge cases should behave;
what evidence would demonstrate success.

1. EvidenceTickets, interviews, reviews, and usage signals

2. SignalRepeated problem, affected segment, and evidence strength

3. DecisionOutcome, tradeoff, priority, scope, and exclusions

4. ContextPRD, stories, criteria, rules, edge cases, and metrics

5. DeliveryCursor retrieval, plan review, implementation, and verification

The Complete PM-to-Cursor Workflow

Stage 1

Collect evidence without turning every request into a feature

Bring together support tickets, interview notes, sales objections, app reviews, and relevant product signals. Preserve the customer’s language, source, segment, date, and surrounding circumstance.

Do not begin by counting feature names. Look for the underlying job, friction, or risk. Five customers may request five different solutions to the same problem.

Output: a traceable evidence set—not yet a requirement.

Stage 2

Synthesize the customer signal

Cluster evidence by problem rather than wording. Identify who experiences it, how frequently it appears, how severe it is, which workflow it interrupts, and whether it connects to retention, activation, revenue, cost, or risk.

Separate three things that often get mixed together:

Evidence: what customers actually said or did;
Interpretation: what the team believes the evidence means;
Assumption: what still needs validation.

Output: a problem statement, affected segment, evidence summary, and confidence level.

Stage 3

Make the product decision before asking Cursor to build

Evidence does not choose the solution. Product judgment is still required. Decide which outcome to pursue, what tradeoffs are acceptable, why the work matters now, and what the team will deliberately leave out.

Record unresolved decisions explicitly. “Needs a product decision” is safer than allowing the coding agent to select plausible behavior that becomes difficult to unwind later.

Output: an approved outcome, priority rationale, scope boundary, exclusions, and open-decision list.

Stage 4

Translate the decision into buildable context

Buildable context is specific enough for planning and testing without dictating every technical choice. It should contain:

customer problem and supporting evidence;
desired outcome;
in-scope and out-of-scope behavior;
user stories or jobs to be done;
business rules, permissions, and constraints;
testable acceptance criteria;
negative scenarios and edge cases;
dependencies and unresolved decisions;
success and guardrail metrics.

For a deeper checklist, read What AI Coding Agents Need From Product Managers.

Output: a structured PRD and implementation-ready user stories.

Stage 5

Put each kind of context in the right place

Do not paste the complete workflow into every prompt. Use the PRD for product decisions, Cursor Rules for durable engineering instructions, the repository for current implementation state, MCP for retrieving approved external context, and the prompt for the immediate task.

Context	Location	Example
Product intent	PRD	Problem, outcome, scope, exclusions, criteria, risks, metrics
Engineering conventions	Cursor Rules	Service boundaries, approved libraries, test commands, file-specific guidance
Current external requirement	MCP retrieval	The approved story and acceptance criteria selected for implementation
Existing system	Repository	Code, schemas, interfaces, tests, and dependencies
Immediate instruction	Prompt	Retrieve story INV-12, inspect the current flow, and propose a plan without editing

Use the full PRD vs Cursor Rules vs MCP framework when designing this context architecture.

Output: one authoritative source for each context type, with less duplication and drift.

Stage 6

Make the approved PRD retrievable in Cursor

Once the requirement is ready, an approved MCP connection can give Cursor access to the relevant PRD or story without requiring the developer to paste the document into every chat.

The developer should begin with a read-only verification prompt:

Use the ProdMoh MCP tools to retrieve story INV-12. Return: - the customer problem and desired outcome; - in-scope and out-of-scope behavior; - business rules and acceptance criteria; - edge cases and unresolved decisions; - the source PRD identifier or version. Do not edit files.

Compare the response with the source requirement before implementation. This catches wrong-document retrieval and ambiguous product language early.

Output: verified access to the intended, current product context.

Stage 7

Require a plan before implementation

Next, ask Cursor to compare the requirement with the repository and identify conflicts. The plan should connect every proposed change to a named acceptance criterion and separate required work from optional improvements.

Inspect the repository for the existing invitation workflow. Compare it with story INV-12. Before editing, report: 1. relevant files, interfaces, and tests; 2. conflicts between current behavior and the PRD; 3. missing product or technical decisions; 4. the smallest implementation plan; 5. which acceptance criterion each step satisfies. Keep optional refactors separate. Do not edit files.

Output: a bounded implementation plan that product and engineering can inspect.

Stage 8

Verify the implementation against both product intent and engineering quality

After implementation, review two different questions:

Product correctness: does the delivered behavior satisfy every acceptance criterion, preserve exclusions, handle expected failures, and support the intended outcome?
Engineering correctness: is the implementation secure, maintainable, tested, compatible, observable, and consistent with repository standards?

MCP improves access to the requirement; it does not replace code review, testing, security review, or product judgment.

Use the feature-drift prevention guide to map the implementation plan, tests, and final diff back to the approved decision.

Output: a reviewed diff with traceability from evidence to decision to acceptance criteria.

Worked Example: Customers Cannot Replace Expired Invitations

1. Raw customer evidence

“I invited our finance lead last week. The link expired, but the product says the email is already invited. I cannot resend it or remove it.”

“We created a second email address just to get our client into the workspace.”

“Support had to delete the invitation manually before I could try again.”

2. Synthesized signal

Workspace administrators become blocked when an invitation expires because they cannot recover without support. The requested solutions differ—resend, delete, or replace—but the shared problem is the missing recovery path.

3. Product decision

Allow administrators to replace an expired invitation while preserving audit history. Do not include bulk invitations, member-role changes, or replacement of active invitations in this release.

4. Buildable context

Only workspace administrators can replace an invitation.
The action is available only for expired invitations.
Creating the replacement permanently invalidates the old token.
The new invitation uses the original email and selected role.
The audit record connects the original and replacement invitation IDs.
A repeated request must not create multiple active invitations.
If delivery fails, show a recoverable state without restoring the old token.

5. Cursor handoff

Cursor retrieves this approved story through MCP, inspects the existing invitation service and tests, reports conflicts, and proposes the smallest change. The developer reviews technical quality; the PM verifies the resulting behavior against the criteria and exclusions.

PM-to-Cursor Handoff Checklist

The source evidence remains traceable.
The repeated customer problem is distinct from requested solutions.
The affected user or segment is named.
The desired outcome and priority rationale are explicit.
In-scope and out-of-scope behavior are documented.
Business rules, permissions, and constraints are decided.
Acceptance criteria describe observable behavior.
Negative scenarios and recovery behavior are covered.
Assumptions and unresolved decisions are visible.
Success and guardrail metrics are defined.
The PRD or story has a stable identifier and current version.
Cursor can retrieve the intended requirement through an approved connection.
The agent summarizes its understanding before editing.
The developer approves a bounded plan.
The final diff is checked against product and engineering criteria.

Five Handoff Failure Modes

Request-count prioritization: counting solution phrases without understanding the shared problem or affected segment.
Evidence without a decision: giving Cursor customer quotes and expecting it to choose the product behavior.
Scope without exclusions: allowing adjacent improvements to become part of the implementation silently.
Acceptance criteria without failure states: defining the happy path while leaving permissions, concurrency, retries, and dependency failures to inference.
A stale copied PRD: pasting requirements into a chat that no longer reflects the authoritative product decision.

Who Owns What?

Product managers who do not work in code can still guide the outcome. See how PMs can guide Cursor without writing code while keeping technical approval with engineering.

Product owns	Engineering owns	Shared verification
Evidence interpretation, outcome, priority, product scope, exclusions, business rules, acceptance criteria, and success measures	Architecture, repository conventions, technical plan, implementation, tests, security, reliability, maintainability, and deployment	Ambiguity resolution, feasibility tradeoffs, plan boundaries, acceptance evidence, release readiness, and post-release learning

Frequently Asked Questions

How do product managers hand requirements to Cursor?

Turn evidence into an approved, structured requirement; give it a stable identifier; and make the relevant PRD or story retrievable through an approved MCP connection. Ask Cursor to summarize the requirement and compare it with the repository before editing.

Should customer feedback be pasted directly into Cursor?

Feedback can provide useful supporting evidence, but raw requests should not become product behavior automatically. Synthesize the signal and make the product decision first.

What makes context buildable?

Buildable context defines the problem, outcome, boundaries, rules, observable acceptance criteria, failure behavior, dependencies, and unresolved decisions without unnecessarily dictating the implementation.

Does MCP replace the PM-to-developer handoff?

No. MCP makes current context accessible. PMs and developers still need to resolve ambiguity, agree on boundaries, review the plan, and verify the result.

Can this workflow work with Windsurf or other coding agents?

Yes. The evidence-to-decision and buildable-context stages are tool-independent. The final retrieval step requires a client and product-context source that support the chosen integration.