1 min lesson
How the role expands once you live in the codebase
Take this case and make the call: "Cursor's stated goal is to shrink the coding step until there's no distance between an idea and a shipped feature. Per the workshop, what does that shift do to where a PM's impact sits?"
Step 1 of 2
A traditional PM's main point of impact is the plan phase - PRDs, ideas - then a handoff to engineering and QA. Once you have Cursor and codebase access, that footprint stops ending at handoff and stretches across the entire software development lifecycle (SDLC).
The strategic reason is simple. Cursor's goal is to shrink the coding step until there's no distance between having an idea and it being built. When the build step collapses, impact moves to either side of it: deciding what to build and why, and making sure it works, deploys and reaches customers. You can now build bad things fast, so deciding what not to build matters more, and the deep expert on what customers actually want wins.
At Cursor a feature that once needed a five-person eng team is now one engineer who doesn't need a PM to assign work. What helps that engineer is brainstorming and a steady stream of real user feedback - not a backlog manager. So lean into being the deep expert on what customers want, and shy away from managing engineers and tracking tasks, which is increasingly automated.
create no distance between you have an idea and it's built... having that user empathy is probably more important than ever.
Learn more
Full explanation
Where a PM Operates Now
Interactive diagram. Step through it with the Next and Previous controls below, or Tab to a region to read its detail.
The plan phase used to be the whole job. Now it's one station of seven.