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 honestly this is where most PMs do their best work. The gap between "we should measure this" and "we are measuring this" is where most feature bets quietly die.
Planning in git
Forget the Google Doc. It scatters comments across three tools and drifts out of sync with the code inside a week. Put a markdown PLANNING.md in the same repo as the code instead: the problem, the hypothesis, the success metrics, the rollout, a kill condition. That file replaces a twelve-page Notion doc and two planning meetings, and any engineer rotating onto the team can absorb it in under fifteen minutes. It all works from GitHub's web interface. Create a repo, click Add file, write it in the browser, commit. No terminal.
Then two things before your first PR, both non-negotiable. Read the engineering standards, the style guide and the linting rules, before you write a line. And run the PM PR review skill file. It flags gaps in your test plan, missing telemetry, untouched docs, standards violations, roughly 80 percent of the feedback an engineer would otherwise leave in a review comment. Do those two and your first PR reads as a signal of seriousness rather than a tax on the reviewer's time.
None of this threatens your engineers. When PMs own copy tests, flag configs, and prompt tuning, engineers get their deep-work hours back for architecture. So this week, pick one Level 1 change, write the PLANNING.md, run the review file, and open the PR.