I put up a 1.4M line PR to move our product management from Linear to Cursor

Recently, it's felt like our tickets are going through a game of telephone:

• Customer success messages "@Linear create a ticket to add XYZ feature" in Slack
• Linear creates a ticket that expands on XYZ - mostly with fluff, and occasionally with complete misinterpretations of the original request (as Linear has only limited knowledge of our codebase)
• The Linear ticket gets rediscovered by an engineer days later, only to get compressed back down into a Cursor prompt to be one-shot
• Engineer asks Cursor to review the PR, and the agent fixes and tests what it can and then responds with a list of things to be manually tested
• Cursor's response is lost in the void, and the QA team then tests only based on the content of the original Linear ticket

Of course there are many things we could do to fill in these gaps, but when I stepped back to really question our process, I couldn't justify having this separate product management platform. One-shot changes should be planned and implemented directly from Cursor. Even larger specs should be made from the ground-up with full context of our codebase. We're producing thousands of lines of code a day, and aligning PRs 1:1 with atomic, testable tickets feels like a relic of the past. The code and surrounding md files (e.g., Cursor skills) are the source of truth now. We're clearly converging on having one centralized "brain" for our company to make our decisions optimally - and for us that's our monorepo in Cursor.

Linear recently shipped Code Intelligence for Linear Agent (Karri, May). The agent can now read your codebase and answer from the source: why a bug may have regressed, what the technical lift of a request would be, who has worked on a feature. They can even auto-investigate issues as they come in. Their own team went from 1,055 Code Intelligence queries in February to a 5,200 run-rate in May. They're clearly all-in on this.

The bet they're making is pretty explicit: Linear is where product work already happens, and the missing piece was the code itself. If your home base is Linear, pulling the codebase into Linear is the obvious move. Optimistically, that could close maybe 80% of the "Linear doesn't know our code" gap. We've also spent the past year shaping the repo around Cursor (rules, skills, the whole workflow), so even that 80% would be Linear reading a codebase that was built to live in Cursor.

The bigger gap is the other direction. Cursor already has the code, the MCPs, and skills that pull GCP logs, Mixpanel, Sentry, and Intercom into a picture of what's happening on prod. What it didn't have was our product management context. I don't want two home bases. And I don't want Cursor calling an MCP to fetch fragments of a roadmap that could just live as files in the repo, indexed with everything else.

For a long time the kanban board and the rich text editor were what made this accessible to the whole team. I don't think that justification holds anymore. Agents have crossed a threshold where one skill can ingest the customer support Slack channel, and another can one-shot a dashboard our QA team can actually use.

The plan

I wrote a Cursor plan to completely overhaul our product management process. It first dumped every single Linear ticket and document into a structured format in our codebase.

That dump was the entire Linear workspace: every issue, project, comment, and attachment. The archive lives in the repo, so we didn't throw away history when we stopped operating out of Linear. Still-open work became one Markdown file per item. Those files only say what should change and why. No status, no priority, no assignee. Those were the fields that went stale.

Then, it created increasingly higher levels of abstraction to help us direct our engineering and QA processes.

The layers look like this. At the bottom: the Linear archive and a flat backlog of Markdown files. Above that: strategy documents for ICP, roadmap, and GTM. Above that: Cursor skills that read those files, plus standup transcripts, Slack, Intercom, and the actual git diff. Those skills produce the artifacts we use every day: who should work on what, a technical changelog per PR, public changelogs, and a per-tester HTML form for manual QA.

Importantly, this is a much more fluid system, ensuring that priorities align with our latest business goals. Rather than hundreds of stagnant tickets in the backlog, we have:

• a skill to dump all of our knowledge from standup transcripts, Slack conversations, Intercom chats, etc
• a set of clear documents outlining our exact ICP, product roadmap, and intended GTM strategy
• a skill to assign the most business-critical tasks to each engineer, enriched by detailed descriptions of the strengths of each of our engineers
• a skill to update an in-depth technical changelog, outlining the exact changes made to the codebase
• a skill to map this technical changelog into multiple artifacts, including a public-facing changelog and an interactive HTML document for each of our QA testers to manually test all changes and leave feedback

Thinking about our own product roadmap, we realize that our customers are also looking to operate their business with an agent that knows about all of their business data. We added an AI assistant to all of our workflows in our latest update, but we also acknowledge that many customers already have the "brain" of their business setup elsewhere. A good product meets its customers where they're at.

Our conclusion is that our API, MCP, and integrations will be crucial going forward into this new era. If you already run your company from Cursor or another agent, you can generate, edit, and export videos there with the VideoGen MCP. The same capabilities are available as a developer API if you want to wire VideoGen into your own stack. Docs are at docs.videogen.io.

The value-add for a document manager and kanban board on top of our existing file structure in the codebase isn't there, but a third-party platform still makes sense (and is actually even more valuable than ever) for anything requiring real infrastructure or external data sources.

To be clear, Linear is one of the most well-built softwares we've used, and I'm sure it can still have immense value for many teams. But for us, it just doesn't make sense anymore.