A PM at a 3,000-person Series F company was telling me about something his executive team did two weeks before we talked. His VP and SVP asked for Cursor access for the product team. They were past the question of whether to evaluate Cursor. They wanted their PMs in it.
Cursor is a great tool, for someone who already lives in a terminal.
Cursor assumes you can spin up a local environment, navigate a terminal, read build output, debug a failing test, hold a mental model of the file structure in your head. Engineers learned those things over years of writing code. They are not skills a PM picks up in a Tuesday-to-Friday sprint, or by reading a Substack.
There is a small group of PMs for whom this is not a wall. PMs with engineering backgrounds. PMs at very small companies who have been pushing small changes themselves for years. Growth PMs whose role specifically includes shipping copy and flag flips. For those PMs, Cursor is a real productivity tool. They were comfortable with the engineering skills before Cursor existed; the tool helps them do faster what they already did.
For most PMs, the assumption Cursor makes about its user is the wrong one.
The fix is a tool that does not ask the wrong people to do the setup. Tools that run in the browser, against the team’s real codebase, with no terminal step, are what PMs in our discovery interviews keep asking for. The setup gap is the actual barrier. Removing it puts PMs back in the chair, asking the codebase the question themselves, instead of routing it through an engineer.
That is what we are building at Else.
For the broader playbook on AI prototyping inside an existing product, see AI prototyping for product managers. For the on-ramp piece on what happens after a vibe-coded prototype works, see vibe coding for product managers.