Isn't this engineering's job?

Else is not an IDE for PMs. It is the path between a validated bet and a PR engineering can review. Engineering still owns the merge, the tests, and the production posture. The PM owns the bet and the build. What moves is the shape of the handoff, not the boundary between the roles.

Engineering does. The PR Else opens runs through the same CI pipeline, the same tests, and the same merge gate as any other PR. PMs typically do their own behavioral QA in the prototype – the flow they showed the customer is the flow in the PR – but production-grade QA sits on the engineering side.

What about security or compliance review?

It happens on the PR, the same way it happens for any PR on the repo. There is no second review surface. If the team has a security checklist that runs on every PR, it runs on this one.

Does this break our merge or deployment process?

The Else PR is a frontend PR on the repo. Whatever tooling already runs on merges – required reviewers, required checks, required deploys – runs on this one. The process is not something Else replaces.

We have a design team. Where do they sit in this?

Unchanged in principle – design owns the direction, the system, and the review of what the PM builds against. Some teams run a design-review step on the prototype before the PR opens; others have the designer working alongside the PM inside Else. It depends on how the team already operates.

Our engineers will rewrite whatever we hand them anyway.

That is the pattern most PMs have lived – the 10-50%+ rework. The reason the rework exists is that the prototype lives somewhere the codebase doesn't. Else writes against the real frontend, inherits the components and CSS already shipped, and opens the PR directly on the repo.

What if our engineering culture rejects a PR from a non-engineer?

That is a conversation to have with engineering before the first PR opens, not a reason to skip the attempt. Most objections collapse when the PR shows up looking like a PR from the team. Some cultures will not accept this workflow at all – that is also useful information. The point of the PR-as-artifact is to make the conversation concrete, not to win it by default.

How does this land on the roadmap conversation with my VP?

The conversation changes from 'please staff this for a sprint' to 'here is a PR against the repo; here is what it changes; here is what we saw when users touched it.' That is a different ask. Whether it lands depends on the VP – but the artifact is concrete, testable, and already in the shape engineering reviews.

Ship the feature without putting it in engineering's queue

For the PM who spends more time calculating whether to ask engineering than describing what she’d ask them for. What changes when the artifact is the PR.

The PM has the bet. The customer is on the call. Engineering is committed for the quarter. The math runs the same way every time: the cost of interrupting a committed sprint is bigger than the size of the ask, and the ticket dies in the PM’s draft folder before anyone else sees it.

TL;DR

The PM doesn’t have to ask engineering to drop what they’re doing. The ask changes shape. The PM builds the prototype against the real frontend, validates with real users, and hands engineering a PR to review – not a ticket to staff for a sprint.

Engineering’s time goes into code review, tests, production posture, architecture calls. The PM’s time goes into deciding the bet, validating with users, committing to a direction. Both keep the part of the job only they can do.

The calculation

A PM at DeepHow, describing the math she runs before filing any ticket:

“We need to figure out if the juice is worth the squeeze before we start ringing everyone’s bells on our engineering team. Hey guys. Drop what you’re doing. We’re focused on this.” – Product Leadership, DeepHow

The protocol runs four questions. The old answer pulls the ticket back before it leaves the PM’s draft folder. The new answer – where the artifact is a PR, not a PRD – changes all four.

Question 1. Is this worth asking engineering to drop what they’re doing?

Old answer. If the engineering team is tied up for months, the threshold to ring their bells goes up. Many PM ideas die at this question. The cost of interrupting a committed quarter is higher than most asks can justify, and the PM self-censors before anyone else gets to say no.

New answer. The ask changes shape. The PM is no longer asking engineering to drop what they’re doing and build. She is handing them a PR to review when the prototype is ready. Review time is smaller than build time, and it falls on a smaller surface.

Question 2. Can I describe this well enough for someone else to build it?

Old answer. This is the question that eats a PM’s week. A prototype in Lovable or Figma Make settles the behavior question – the customer clicked, the flow worked – but the PRD still has to translate that behavior into something an engineer can pick up. Imaginary prototype becomes a PRD. PRD becomes a ticket. Engineering reads the PRD, looks at the prototype, and starts from scratch on the real codebase.

New answer. The prototype is the description, and the PR is the prototype. The PM builds against the real frontend, targets real users, sees the flow working on the real product – and the build is what gets reviewed. Engineering reads code, not descriptions of code.

Question 3. Will what they build match what I showed the customer?

Old answer. The cost of the translation layer every PM running this play pays – in explanations back to the customer, in the second round of tickets when the shipped version behaves differently from the prototype they signed off on, in the sprint the PM thought was over. This is the vibe-coded work that disappears at handoff.

New answer. There is no translation. The PR contains the code the prototype ran on – the components from the design system, the CSS from the repo, the conventions from the team.

Question 4. Will it survive the next sprint reshuffle?

Old answer. Engineers tied up for months, roadmap defended for the quarter, and every incoming idea landing on a queue that is already full. A PRD and a Lovable link don’t survive that. The validated prototype goes into a Figma file. The customer conversation that motivated the ticket becomes a paragraph in a doc nobody reads next quarter.

New answer. The work exists as a PR against the repo from the moment the prototype is done. It ships or it doesn’t, but the build doesn’t evaporate into PRD-limbo while the team pivots. The artifact is durable in a way a ticket description is not.

What changes in the PM’s relationship to engineering

The old relationship: the PM asks, engineering decides, engineering builds, the PM explains the gap to the customer.

The new relationship: the PM builds, engineering reviews, engineering merges, the PM explains the shipped behavior to the customer. Engineering’s time goes into the part only they can do – code review, tests, production posture, architecture calls. The PM’s time goes into the part only she can do – deciding what to build, validating it with users, committing to a design direction. This is what vibe coding for product managers looks like in practice.

The PM owns the bet. Engineering owns the merge.

What you built is what ships

What you tested is what ships. No “they rebuilt it and lost the design.” The prototype matches the code. Your intent survives the handoff.