Earlier this year I shipped an expansion of Remote's country document checklist to production, the part of payroll onboarding where customers upload the documents we require, or optionally require, for smoother onboarding and data collection. I did it with Claude Code. I built a skill that takes the approved requirements, makes the JSON schema changes, runs the tests and checks, produces a QA sheet I can verify against the source, and opens the merge request. I am a Senior Product Manager, not an engineer, and until this year production had never been part of my job.
Production always looked like engineering territory to me. Protected, carefully reviewed, and a lane I had no particular reason to be in. I spend my days on product problems, customer needs, and operational complexity, but the step where a change actually reaches customers always belonged to someone else.
The project came out of a capstone. Remote had been running AI training internally, and that training is now public as AI for Actual Work, a free course. The capstone had to be something you would use in your real job, so mine was an actual change to an actual product.
Why a product manager was editing JSON schemas
The requirements already existed. The business team provided them in a spreadsheet, and payroll experts in the countries reviewed and approved them. Nothing about the content was in question. What was missing was the step that moved approved requirements into the product, and that step meant JSON schema updates, tests and checks, a QA pass against the source, and a merge request for review. Small production changes still need care.
So I started by giving Claude Code the context I would have given an engineer: a lot of context from previous projects, existing merge requests that had already done this kind of checklist update, and Arnold. Arnold is an internal Claude based agent that Remote's EOR team uses to make its own updates to onboarding forms and JSON schemas, which takes routine pattern work off Product, Design, and Engineering. Arnold is where I took most of my inspiration, because the shape of the work was already familiar there.
What the workflow does, and what it does not do
It took a few iterations to get the skill to where it is today. What it needs from me now is two inputs: the country name and the source data from the spreadsheet. From there it reads the requirements, makes the schema changes, runs through the tests and checks on its own, and creates a QA sheet. I use that sheet to confirm the output is what we expect, and then it opens the merge request.
So I was not translating rows by hand. I set up the workflow, gave it the right inputs, and checked the result. The human involvement is reviewing the merge request and approving it, which is where it should be. What changed is that I could carry the work to that point myself rather than hand it off.
Working in developer tools also gave me a lot of appreciation for engineering. You do not really see how much goes into shipping something to production, even when it looks small, until you try it yourself.
The part I keep coming back to is that this is repeatable. A product manager can take approved source data, apply a pattern that already exists, run the checks, and prepare a merge request for review. Payroll specialists and operations teams sit on a lot of work shaped like this, structured and recurring and easy to describe once you know the pattern. The person closest to the problem can build more of the solution, as long as the guardrails and the review points stay where they are.
The next country checklist update will not require me to work any of this out again. I also had more fun building it than I expected to.
If you want to build your own workflow for real work, sign up for Remote’s free AI for Actual Work course at aiforactualwork.com.
