Small changes stuck in the backlog? How PMs can change a live app without waiting on engineering

Originally published on butterneck.com.

A product manager spots a problem on the live app. The button label is wrong. The empty state says nothing useful. A form asks for a field nobody needs. The fix is small. Getting it done is not.

Most teams have a list of these paper cuts: wrong labels, unclear empty states, a field in the wrong order. Each one is too small to fight for in sprint planning, so the list grows.

This post is about how a PM can change a live app without waiting on engineering, and without engineering losing control of what ships.

Changing a live app as a PM, in short: Small changes wait because of the relay around them (tickets, screenshots, sprints, staging deploys), not because of the code. With Butterneck, the PM asks in a chat on a live copy of the app, a coding agent the developer already uses edits the files on the developer's computer, and the PM sees the change on the same screen. Butterneck does not commit, push or open a pull request; a developer decides first what ships, and Butterneck never merges or deploys.

Why small product changes sit in the backlog (it isn't the code)

The change usually takes a developer a few minutes. The wait comes from everything around it:

• Writing a ticket that explains which page, which state, which button.
• Adding a screenshot, then a second one because the first was the wrong screen.
• Waiting for the ticket to reach the top of a sprint.
• A developer asks a clarifying question. You answer a day later.
• A staging deploy so you can check it. You find one more thing.

None of that is coding. It is relay. We wrote about this in human-in-the-loop AI coding: the change is small, the back-and-forth is what takes the week.

Paper cuts also lose every prioritisation call. Next to a feature or a bug, "rename this button" never looks urgent, so it waits behind work that does. Nobody decided the fix wasn't worth doing. It was just never worth a developer's context switch. That is the gap AI change requests for product teams are meant to close: the person who spotted the problem asks for it directly, and a developer only steps in to decide.

What "without waiting on engineering" should mean

It should not mean PMs pushing to production. Most engineering leads will say no to that, and they are right to. Code review, tests, and release steps exist for a reason.

What a PM actually needs is narrower:

• To describe the change on the screen where they see it.
• To see the result quickly, on the real app, not a mockup.
• To iterate ("a bit shorter", "no, the other button") without a new ticket each time.
• To hand a finished, visible change to a developer who decides whether it goes live.

That removes the waiting from the PM's side while keeping the decision with engineering.

The options teams use today

Tickets and screenshots

The default. Works, but every round trip costs a day. The developer still has to find the page and guess the intent.

Give the PM a no-code tool

Fine for marketing pages built in a CMS. Not useful when the change is in the product's own code.

Give the PM an AI coding tool

Some PMs install Cursor or Claude Code and edit the repo. This can work for technical PMs, but it means a local dev setup, git, and a PM opening pull requests. Many teams do not want that. If you want PMs to use your team's Claude Code or Cursor without a terminal, see Claude Code for product managers. We compare the main options, from prototype tools to ticket-to-PR agents, in AI tools that let non-developers change an existing web app.

Let the PM ask on a live copy

The PM asks for the change in a chat on a running copy of the app. A coding agent makes the edit. The preview updates. Butterneck does not commit, push or open a pull request; a developer reviews first and decides what ships. This is the approach Butterneck takes. Why the requester's check comes before any PR is covered in live preview before the pull request.

How it works: make changes to your live app with AI, and a developer decides

1. A developer connects a project folder on their own computer to Butterneck through a small bridge app. The bridge starts the app and gets a public share link for it.
2. The PM opens the link. They see the live app with a chat beside it.
3. The PM types the change: "Make the button say Book a call."
4. A coding agent the developer already uses (Cursor, Claude Code, or Antigravity) edits the files in that folder. The app hot-reloads and the PM sees the change on the same screen.
5. The PM keeps going until it is right. If a turn goes wrong, it can be stopped and its file changes usually rolled back.
6. The developer reads the conversation, checks the diff in their own tools, and publishes it the usual way. Or discards it.

Butterneck never merges, never opens a pull request, and never deploys. A developer decides what goes live.

The share link needs no VPN or staging deploy, and viewers do not need an account. The developer chooses who can send requests: a named list, or anyone with the link. A developer can reply in the chat without starting the agent: the reply is saved and changes no files, though it can be included as context on the requester's next turn. More detail in how to share a local app without deploying.

See it before you set anything up: create a free account and try a request on a sample shop before connecting a computer. On your own project, the edit runs on your computer. Your team still decides what goes live.

What engineering keeps control of

This is the part to show your CTO.

• The folder. The agent works in one folder the developer chooses. That can be a git worktree, so in-flight requests do not touch the main checkout.
• The ignore list. .env files and any globs the team adds are put in the agent's instructions as off-limits. That is a guardrail, not an enforced block, so keep production secrets off the machine that runs the bridge.
• The release. Nothing is committed, pushed, or deployed by Butterneck.
• The agent account. The coding CLI runs under the plan it is signed in with and that provider's terms; use a team or API plan that allows use on your team's behalf. The CLI sends code context to that provider, as it does in normal use. Chat messages and preview traffic go through Butterneck's server.

For the full picture, read how Butterneck runs an AI coding agent in a sandbox on your machine.

What a PM should still not do alone

Being clear about limits helps adoption.

• Changes to pricing logic, permissions, or data models need an engineer's eyes, even if the preview looks right. "Looks right" and "is right" are different checks.
• Big features need design and scoping. A live-copy chat is for small, visible changes.
• The developer still reviews every change. The requester sees the change on the preview in the same session, and the developer reviews it with the intent already written down in the conversation.

To write these limits down for your team, use our policy template for non-engineers requesting changes with AI.

A simple way to start clearing the small-change backlog

• Pick one app and one developer.
• Agree on the kind of changes PMs can request: copy, layout, small UI fixes.
• Share the link with one PM for a week. If you need sign-off first, our 4-week pilot proposal is written to send to an engineering lead.
• Give that PM a simple format for requests: where, what it says now, what you want, what must not change, and how you'll check it. Our change request template for AI coding agents has examples.
• Pick the paper cuts first: the small copy and UI fixes that have sat in the backlog longest.
• Count how many requests went from ask to reviewed change the same day.

FAQ

Why do small product changes sit in the backlog?

Usually not because the code is hard. The time goes into the relay around it: writing the ticket, finding the right screenshot, waiting for a sprint, answering a clarifying question, checking a staging deploy. Small fixes also lose prioritisation calls to features and bugs, so they wait.

How do you clear a backlog of small copy and UI changes?

Put the small copy, layout and UI tickets in one list, close the stale ones, and write each remaining one as "where, what it says now, what it should say". Then take them out of the sprint queue: the person who raised each one asks for it on a live copy of the app and checks the result there, and a developer reviews the finished changes and decides what ships. Keep pricing logic, permissions and data-model changes in the normal engineering flow.

Can a PM change a live app without engineering?

A PM can make the change happen and see it on a live copy without waiting. A developer still reviews it and decides whether it ships. That is deliberate.

Can designers use this for small visual fixes, not only PMs?

Yes. Anyone the developer lets send requests can use it: a designer, a support lead or a PM. A designer opens the same share link, goes to the screen with the problem, and types the fix, for example "add more space above the Save button" or "use the smaller heading style on this card". Each message carries the page address and route they have open, and they can attach up to five screenshots or files, so a screenshot with the problem circled works well. Name the element by its visible text, as in our change request template. The preview reloads with the change, the designer checks it there, and a developer reviews it and decides what ships.

Does the PM need a dev environment or git?

No. The PM uses a share link in the browser. The developer's computer runs the app and the coding agent.

Does this change the production app directly?

No. The agent edits a copy in a folder on the developer's machine. Production changes only when the developer publishes.

What if the AI gets it wrong?

Ask again in the chat, or stop the turn and its file changes are usually rolled back (if not, the chat says so). The developer can also just discard the change.

Can requests come from Jira instead of chat?

Yes. Add the label butterneck to a ticket and assign it to a teammate whose Jira account is mapped to a computer that has the project. A preview link is posted back on the ticket. See Jira ticket to pull request with AI.

Why not use a tool that opens the pull request for you?

Butterneck runs on a developer's computer, where the project already runs, so there is no new cloud environment to set up and no need to copy secrets into a hosted machine. The person who asked sees the change on a live preview, and a developer decides what happens next. Butterneck itself never opens a pull request, merges or deploys. A tool that opens pull requests can suit teams who want a PR as the hand-off. Butterneck suits teams who want a developer to decide before anything becomes a PR.

Try it

Book a 30-minute demo and bring a real change your team has been waiting on. Or check pricing: Starter is free for one developer and one requester, and a workspace owner on Starter can try Pro free for one month. Learn more at butterneck.com.