In February 2026, Y Combinator published its Spring Requests for Startups. Item one on the list: a Cursor for product managers.
YC partner Andrew Miklas framed it plainly. Cursor and Claude Code have changed how engineers write software. But code was never the hard part. The hard part is figuring out what to build in the first place — and that problem, he noted, is still almost entirely unsolved.
The timing is not a coincidence. AI coding agents have gotten genuinely fast. Teams shipping with Cursor are moving faster than they ever have. But the bottleneck has shifted. The constraint is no longer how quickly you can write the code. It's how clearly you can tell the agent what to build.
What Cursor actually did for engineering
To understand what a Cursor for PMs would need to do, it helps to be specific about what Cursor actually changed for engineers.
Before Cursor, an experienced engineer sat down, held a mental model of the codebase, and wrote code. AI tools existed but they were mostly autocomplete — suggestions that saved keystrokes. Cursor changed the interaction model. You describe what you want. The agent does a first pass. You review, correct, redirect. The engineer's job shifted from writing to directing.
What made that possible wasn't just the model. It was context. Cursor knows your codebase. It can read the files, understand the patterns, and make decisions that are consistent with the existing system. That context is what turns a language model into something actually useful in a real project.
The same shift needs to happen for product management. And it hasn't yet.
What the PM's job actually looks like right now
A product manager at a company with any meaningful customer base is swimming in signal. There are Zendesk tickets. There are Intercom conversations. There are interview transcripts from last month's user research. There are Slack threads from the sales team about deals that got blocked on a missing feature. There are GitHub issues tagged as feature requests. There are Amplitude dashboards showing what users do and don't do.
None of this is organized. None of it talks to any other part. And almost none of it connects to the spec that eventually gets handed to an engineer.
The PM's job, under the surface, is to read all of this, find the pattern that matters, make a judgment call about what to prioritize, and communicate that decision clearly enough that a human engineer can act on it. That last step — communicating clearly enough for a human engineer — is a craft that took years to develop. Most PMs are still doing it the same way: a Notion doc, a Jira ticket, a PRD in Google Docs.
But the consumer of that spec is no longer just a human engineer. Increasingly it's an AI coding agent. And AI coding agents don't read between the lines. They need structured, unambiguous, complete context to build well. A vague brief produces vague output.
What YC is actually asking for
When YC says Cursor for PMs, they mean a system that closes the entire loop.
Not a better note-taking tool. Not a smarter Jira. Not a research repository with AI search bolted on.
They mean a tool that starts where your customer signal lives — interviews, support tickets, analytics events, Slack messages — reads across all of it, finds what actually keeps coming up, ranks it by evidence, and generates output that an AI coding agent can execute directly.
The key word is evidence. The problem with most PM decisions isn't that PMs are lazy or wrong. It's that the process of going from a customer conversation to a shipped feature involves so many handoffs, so much summarizing and re-summarizing, that the original customer signal gets diluted or lost entirely. By the time the spec reaches the agent, it's a combination of memory, assumption, and institutional opinion — not evidence.
A Cursor for PMs would preserve the chain. The spec would cite the signal. The agent would know not just what to build but why a customer asked for it and which customers asked for it most.
The MCP layer changes everything
There's one piece of this that most people haven't fully processed yet.
Cursor and Claude Code support MCP — the Model Context Protocol. MCP lets external tools act as live data sources for AI coding agents. An agent with an MCP connection can query a system in real time while it's building: what are the current priorities? what decisions have already been made? what did customers actually say about this feature?
This means the relationship between product intelligence and development isn't just handoff anymore. The agent can ask questions while it's working. The product context becomes ambient — always available, always current, no copy-pasting required.
That's genuinely new. It means the spec isn't a document that gets handed over and then forgotten. It's a live connection between what customers said and what the agent is building right now.
Why the timing is right
Two things had to be true for this category to exist.
First, AI coding agents had to be good enough that the constraint actually shifted upstream. That happened in 2025. Cursor and Claude Code are genuinely capable of taking a well-written spec and producing working code at a quality level that would have taken a junior engineer days.
Second, there needed to be enough signal for AI to synthesize meaningfully. Most companies with any real customer base have years of Zendesk tickets, interview recordings, and analytics data sitting unused. The infrastructure to connect to those sources and do something useful with them has only recently become practical to build.
Both conditions are now true. The category is real.
What this isn't
A few things worth being clear about.
This is not Dovetail. Dovetail is a research repository — a place to store and tag what you've learned. It's valuable. It's not the same thing. Dovetail does not synthesize across sources, rank by evidence, or generate output your agents can act on.
This is not Productboard. Productboard is a roadmap tool. It sits at the end of the discovery process and helps you communicate decisions. It does not do discovery.
This is not a fancier PRD template. The output from a Cursor for PMs isn't a document in the traditional sense. It's a structured artifact — with scope, user stories, acceptance criteria, edge cases, and a tracking plan — written specifically so that an AI coding agent can execute without asking clarifying questions.
What it actually needs to do
If you're evaluating whether a tool is a real Cursor for PMs or just using the phrase, here's what it actually needs to do:
It needs to ingest from where signal already lives. Not just CSV uploads. Real connections to Intercom, Zendesk, Slack, GitHub, Jira, Linear, Amplitude, Mixpanel. Audio interview transcription. The PM shouldn't have to move their data to use the tool.
It needs to synthesize, not just organize. Tagging and categorizing is not the same as finding what keeps coming up. The system needs to read across everything and surface what customers are actually asking for, ranked by how much evidence is behind it.
It needs to generate structured output in the formats teams actually use. Specs. PRDs. Linear tickets. Decision docs. Not generic documents — artifacts with the specific structure that AI coding agents can parse.
It needs to connect to the agents directly. Not just export a file. A native MCP server that gives Cursor and Claude Code live access to priorities, decisions, and signals while they build.
And it needs to remember. Product context compounds over time. The decision made six months ago is still relevant. The customer insight from last quarter should still be citable. The system needs a memory that persists and gets more useful over time, not a feed that resets every time you open it.
That's the category. It exists. And the teams who build on it early will have a meaningful advantage — not just in shipping faster, but in shipping the right things.
The bottleneck has shifted. The tooling is catching up.