A PM at a fintech needed to show her director a prototype. He wanted to see what the team was building. He had been a strong PM long before AI tools existed. He wanted to work on the prototypes alongside everyone else.
He couldn’t get his technical environment set up.
She was on a team of four PMs working on the same project. The other three moved between branches, opened each other’s prototypes, traded feedback. Her director sat at his laptop and tried – clone the repo, install dependencies, set environment variables, run the dev server, find the right port, wait for the build.
The cost of the setup tax
It hides in a small moment – someone asking “where do I go? Where can I pull this down? How can I run a local dev server to look at this?” – that unfolds into weeks. A PM tries to onboard another PM onto a prototype. “Just switch to my branch, then reload your dev server.” The other PM doesn’t understand. She is building in a separate tool because understanding Git and local development has never been part of being a PM, and the tool she was told to use has made it part of the job.
The setup is the gate to building. The gate runs on npm, environment variables, the difference between localhost and a deployment, the patience to debug when the AI breaks and you need to know why. Intellectual capacity, seniority, and product judgment have nothing to do with it.
When a PM walks into the week without those things, she does not pick them up by Friday. When the director walks into a meeting without those things, he stays in the spec lane while the prototype gets built without him. A team meant to work in parallel ends up working in serial. The work requires engineering-grade infrastructure fluency to get started, and the PM who already has that fluency becomes the bottleneck.
How teams try to work around the setup tax
Her team tried three different patterns to solve this. First, a branching structure. Different PMs, different branches. Then: “who merges the branches?” The process collapsed. Then, single-PM ownership. One PM owns the prototype, everybody else watches. Visibility disappears. The other PMs stop trying. The team starts to bifurcate.
What the field is reaching for is a tool that runs in the browser, against the team’s real codebase, with no local install. A tool that does not demand a PM understand Git workflows to see what her teammate built. A tool where the setup step – the step that breaks teams – is gone.
What her director needed next was a tool he could open. She said it plainly: “It’s not a person problem. The tool is asking the wrong people to do the setup. The setup is the part that needs to disappear.”
Why one PM ends up doing all the building
When a tool demands engineering-grade environment fluency, it concentrates the work on the PMs who already have that fluency. The team becomes bimodal: one group shipping, one group waiting. The PMs who can build get the visible wins. The PMs who cannot pick up the supporting work – specs, research, notes – and they are not in the room when the prototype ships. Over a year, that shape hardens. Promotion conversations become harder when half the team has demos to point at and half does not.
She mentioned this pattern in a single meeting with her director. I have heard it in 70+ interviews – “everybody’s saying, if you don’t know it, you’re falling behind”, “I am not comfortable in a dev environment”, “I’ve been left to do it on my own”. On any team of three or more PMs, if the tool demands local setup, the work concentrates.
When the setup step disappears
Else lets PMs and designers prototype and test inside their actual product, then hand engineering a PR they merge, not rebuild. Everyone opens a browser, including the director.
For the on-ramp on what Cursor actually asks of a PM, see Cursor for product managers.