A CPO I advise sent me a screenshot last week. One of her PMs had shipped a feature. Not spec'd it, not queued it for three sprints. Built it, tested it, shipped it to production, and wired up the analytics herself. Total elapsed time from hypothesis to live feature flag: a day and a half. The PM is not an engineer. She is a senior PM with a classic B2B SaaS background. What changed is not her. It is the surface area she is now expected to own.
The four-level ladder
I coach PMs up a ladder I built after watching two pilot groups go too deep too fast and generate the exact PR-review thrash that gives engineering leaders an excuse to shut it all down.
Level 1 is copy and configuration: button text, error messages, feature flag config. First PR: change two words on a CTA, run the test, report the lift. Level 2 is AI prompt changes on features you own, versioned in the repo with a test plan. Level 3 is small front-end changes, composing with existing components, not architecting anything. Level 4 is telemetry and instrumentation, and this is where most PMs do their highest-leverage work, because the gap between we should measure this and we are measuring this is where most feature bets go to die.
Planning in git
The old way is a Google Doc that scatters comments across three tools and drifts out of sync with the code. The new way is a markdown PLANNING.md pushed to the same repo as the code, with the problem, the hypothesis, the success metrics, the rollout, and a kill condition. That file replaces a twelve-page Notion doc and two planning meetings, and it is absorbable in under fifteen minutes by any engineer rotating onto the team. Everything works from GitHub's web interface. Create a repo, click Add file, write it in the browser, commit. No terminal required.
Earning trust
Two non-negotiables before your first PR. Read the engineering standards, the style guide and linting rules, before you write anything. And run the PM PR review skill file, which flags gaps in your test plan, missing telemetry, untouched docs, and standards violations. It catches roughly 80 percent of the feedback an engineer would otherwise write in a review comment. Do those two things and your first PR lands as a signal of seriousness, not a tax on the reviewer's time.
This is not a threat to your engineers. When PMs own copy tests, flag configs, and prompt tuning, engineers reclaim deep-work hours for architecture. This week, pick one Level 1 change, write the PLANNING.md, run the review file, and open the PR.