# Make the Case: PMs Shipping Production Code, Pilot Proposal **To:** [CTO / VP Engineering] **From:** [Your name, title] **Date:** [YYYY-MM-DD] **Status:** Proposal, pending your approval --- ## TL;DR I am proposing a four-week pilot in which two senior product managers ship production code within a clearly bounded PM zone. The zone is limited to copy, configuration, AI prompts, feature flag changes, telemetry wiring, and small composed front-end changes. Everything outside the zone stays with engineering. At the end of the pilot, we will report on four process metrics and one feature outcome, and jointly decide whether to expand, iterate, or roll back. The pilot requires one senior engineer's time as a reviewer and sponsor, roughly two hours per week for four weeks. --- ## Why Now Three shifts in the last 18 months have made this proposal viable in a way it was not before: 1. **Code output per engineer has roughly doubled in most teams using AI coding assistants.** The bottleneck has shifted from authorship to review. Absorbing the low-complexity, high-context PM-authored work is one way to protect engineering's review time for the architecture and integration work that actually needs senior engineering judgment. 2. **Planning artifacts can now live in git and be consumed directly by coding agents.** This was not true two years ago. It is true now. A `PLANNING.md` pushed to the same repo as the code removes the translation loss between product intent and implementation. 3. **The industry norm is moving.** Companies explicitly committed to AI-augmented development are seeing their PMs and designers ship directly. Our competitors are hiring PMs with these expectations. If we wait another year, we will be training catch-up, not advantage. --- ## The Problem This Solves Three specific problems in our current operating model: 1. **Small, high-context PM changes queue for weeks in engineering's backlog.** A copy test that a PM could ship in an afternoon sits in a sprint queue because the change is not urgent enough to jump the line but the cumulative cost of the delay is high. 2. **Specification ambiguity generates re-work.** The PRD says "improve error messaging" and the engineer ships one interpretation, and the PM realizes the interpretation was wrong only after the PR is in review. This round trip costs both sides. 3. **PM feedback loops on production behavior are slow.** PMs monitor their OKRs through dashboards that engineers built months ago, and the instrumentation gaps only surface when a PM tries to pull a number they cannot get. Letting PMs directly author changes inside a bounded zone eliminates all three. --- ## The Proposal ### Pilot Design - **Two PMs, hand-picked.** One experienced PM on a surface they know well. One equally experienced PM on an adjacent surface. - **Four-week duration.** Each PM ships a feature of comparable scope. One in the old operating model, one in the new. Same brief. - **PM zone (explicit and bounded).** The two pilot PMs can directly push PRs that modify: - User-facing copy, including error messages, empty states, and onboarding strings. - Feature flag configuration and rollout percentages on flags they own. - AI prompt templates and agent system prompts for features they own. - Analytics event additions and dashboard wiring. - Non-breaking additions to config files that govern their feature. - Small composed front-end changes using existing design system primitives. - **Engineering zone (unchanged).** Data models, API contracts, authentication, build and deploy configuration, core agent orchestration, and security-sensitive code paths all remain with engineering. - **Hard rule:** every PM-authored PR must pass the PM PR Review skill file (see toolkit) before it is sent to engineering review. This catches roughly 80% of the feedback an engineer would otherwise have to write. ### Reviewer Model - One engineering DRI per pilot PM. Two hours per week per DRI. This is the major ask in this proposal. - The engineering DRI reviews PM-authored PRs on the same priority as any other PR in the team, with the understanding that the automated review skill file has already run. - If a PR contains anything outside the PM zone, the engineering DRI sends it back with a request to pair, not with line-by-line feedback. ### Metrics We will report on four process metrics and one feature outcome: 1. Days from idea to first commit. 2. Engineering review cycles per PR. 3. Cycle time: PR opened to PR merged. 4. PM self-reported energy on the new operating model, 1 to 5. 5. Primary metric movement on the feature itself. Baselines will be drawn from the four most recent features shipped in the old model. Dashboards will be set up before the pilot starts. --- ## Risks and Mitigations **Risk: A PM ships a change that breaks production.** Mitigation: Every change in the PM zone is gated behind a feature flag by default. Rollback is a flag flip, measured in seconds. The engineering DRI has full veto on merges. We have not made the PMs production owners; we have made them authors within a bounded, reversible surface area. **Risk: PM-authored PRs generate more review overhead, not less.** Mitigation: The PM PR Review skill file is a hard gate. If a PM cannot get their PR to pass the skill file, it does not go to engineering. Engineering time is protected by construction. **Risk: The pilot succeeds but the operating model fails to scale past two PMs.** Mitigation: The rollout playbook (see toolkit) is designed for staged expansion. Wave 1 goes to greenfield surfaces, Wave 2 to high-coupling surfaces, over one quarter. We do not mandate. We pull. **Risk: Engineering resents the change and attrition follows.** Mitigation: This is the real risk. I will personally talk to every engineering DRI before we start and ensure they see the change as a gift rather than a threat. If any engineering DRI does not feel that way, we do not put a pilot PM on their surface. --- ## Success Criteria The pilot is a success if, at the end of four weeks, all four of the following are true: 1. Days from idea to first commit on the new-model PM's feature dropped by at least 30% versus the baseline. 2. Engineering review cycles per PR did not increase. 3. PM self-reported energy averaged at least 3 out of 5. 4. The feature shipped and moved its primary metric in the expected direction. If three of four are met, we iterate and run a second pilot. If fewer than three, we roll back and stay on the current model. --- ## What I Need From You 1. Your approval to run the pilot. 2. Two hours per week of one senior engineer's time per pilot PM, for four weeks. 3. Your agreement on the PM zone boundaries as written above. Any adjustments should be made before the pilot starts, not during. 4. Your participation in the end-of-pilot readout meeting so we decide together. I am not asking you to commit to anything beyond the pilot. No team-wide rollout. No permanent policy change. Four weeks, two PMs, clear metrics, joint decision. That is the ask. --- ## Appendix: What the PMs Will and Will Not Touch in Week One **Week one activities for the pilot PMs:** - Read the team's engineering style guide end to end. - Set up their local dev environment with help from the engineering DRI. - Push a `PLANNING.md` for their feature to the repo and get engineering DRI sign-off on the planning PR. - Push one trivial PR as a shakedown: a single-word copy change on a non-critical surface. This proves the tooling works end to end before anything real is attempted. **Week one no-go list:** - No changes to anything production-critical, regardless of how small. - No changes outside the PM zone. - No PRs that skip the PM PR Review skill file. - No PRs without a linked `PLANNING.md`. --- *Proposed by [your name]. Questions, pushback, and scope changes welcome before we start.*