# Make the Case: PMs Shipping Production Code, Pilot Proposal (Regulated Environment Variant) **To:** [CTO / VP Engineering, Head of Compliance/Security] **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 strictly bounded PM zone. Our product operates under [SOC 2 Type II / HIPAA / PCI-DSS / FINRA / GDPR / other applicable regime] and any change to our operating model must include an explicit controls story. This document proposes the pilot, the PM zone, the controls framework, and the audit and review surfaces. The controls framework is designed to meet or exceed our current review standards while expanding the range of authors. --- ## Why Now The case for expanding the author pool has shifted materially in the last 18 months as coding agents, planning artifacts versioned in git, and PR-level automation have made it possible to run a change-authorship expansion without loosening the controls. The bottleneck in most product orgs has shifted from code authorship to code review, and in regulated environments that shift is amplified because every review carries a compliance burden. Giving product managers a bounded zone in which to author small, reversible changes, under the same controls as any other contributor, is a way to increase throughput without increasing risk surface. The proposal below is designed to be auditable, reversible, and fully defensible under our existing compliance regime. --- ## Control Framework (Read This Section First) Every control in our current engineering operating model continues to apply to PM-authored changes. No control is relaxed. Several are tightened. Specifically: ### Authentication and Authorization - Pilot PMs receive commit access only to the feature branches relevant to their pilot scope. They do not receive blanket repo write access. - Pilot PMs cannot merge their own PRs. A separate engineering reviewer is required for every merge, without exception. - Pilot PMs are added to a dedicated group in our identity provider so access can be revoked in one action if needed. ### Change Authorization - Every PM-authored PR is gated behind a feature flag by default. No PM-authored PR ships unflagged, regardless of the apparent blast radius of the change. - Feature flag changes by pilot PMs are limited to flags they own, listed explicitly in `CLAUDE.md`. - Every PM-authored change to a production-bound surface requires sign-off from both the engineering DRI and the product DRI, captured in the PR. ### Audit and Traceability - Every PM-authored change is traceable from intent (`PLANNING.md` commit) to implementation (PR commit) to deployment (flag flip log) with a continuous git and system-of-record trail. - The `PLANNING.md` file acts as the change-justification artifact. Changes without a corresponding planning doc are rejected by the PM PR Review skill file and by the engineering reviewer. - All flag flips executed by pilot PMs are logged to our central audit log with author, timestamp, and flag state. ### Separation of Duties - Pilot PMs cannot approve, deploy, or roll back changes that affect authentication, authorization, payment, or protected-data pathways. These remain engineering-only, without exception. This is enforced through repo CODEOWNERS rules on the relevant directories. - Pilot PMs cannot modify our audit logging or compliance-monitoring infrastructure under any circumstance. ### Protected Data - Pilot PMs work only against surfaces that do not handle PHI, PCI data, or similar protected classes in v1 of the pilot. Expansion to protected-data surfaces is explicitly out of scope for this proposal and would require a separate, subsequent approval cycle. ### Incident Response - In the event of a production incident traced to a PM-authored change, the rollback is a flag flip (seconds) and the incident is handled through our standard incident response runbook. - Pilot PMs are added to the incident notification list for surfaces they are authoring on, and are expected to participate in post-incident reviews. --- ## The Problem This Solves Same as the standard pitch, with one addition specific to regulated environments: In regulated environments, the review burden per change is higher than in unregulated ones. Engineering review capacity is therefore the most constrained resource in our product velocity equation. Moving low-complexity, high-context PM work into a bounded, controlled zone with clear author-level gating increases throughput without relaxing any control. --- ## 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 of comparable compliance sensitivity. - **Four-week duration.** Each PM ships a feature of comparable scope. One in the old operating model, one in the new. - **Compliance scope:** both pilot features are on surfaces that do not touch protected data in v1. - **PM zone (strictly bounded).** The two pilot PMs can directly author PRs that modify: - User-facing copy on non-protected-data surfaces. - Feature flag configuration on flags they own, where the flag controls only presentation or non-protected-data logic. - AI prompt templates for features they own, where the feature does not process protected data in v1. - Analytics event additions and dashboard wiring, where the events do not capture protected data. - Small composed front-end changes using existing design system primitives on non-protected-data pages. - **Engineering zone (unchanged, enforced through CODEOWNERS).** Data models, API contracts, authentication, authorization, session handling, payment processing, protected-data handling, encryption, logging infrastructure, build and deploy configuration, core agent orchestration, and all compliance-monitoring infrastructure remain engineering-only. These are enforced through repository CODEOWNERS rules, not through convention. ### Reviewer Model - One engineering DRI per pilot PM. Roughly two to three hours per week per DRI (higher than the standard variant to account for compliance review overhead). - Every PM-authored PR passes the PM PR Review skill file before engineering review. The skill file's security-and-privacy section is treated as a hard blocker. - The engineering DRI pays specific attention to: CODEOWNERS compliance, protected-data scope, and audit-log implications. ### Metrics Same four process metrics and one feature outcome as the standard variant, plus two compliance-specific metrics: 1. **Compliance review findings per PR.** Count of findings raised by engineering review that are specifically compliance-related. Baseline drawn from last four features. This should trend flat or down. If it trends up, the pilot stops. 2. **Audit-log completeness.** Manual spot check on the audit trail for every PM-authored PR. Target: 100%. Anything less is a blocker. --- ## Risks and Mitigations **Risk: A PM-authored change triggers a compliance finding in our next audit cycle.** Mitigation: The pilot runs for four weeks, well before any audit cycle. All PM-authored changes are traceable through the same controls as engineering-authored changes. Our auditor has been informed that we are piloting an expansion of authorship, and we are prepared to walk through the control framework at the next engagement. **Risk: A PM-authored change inadvertently touches a protected-data path.** Mitigation: CODEOWNERS rules prevent merges on protected-data paths without the relevant owner. The PM PR Review skill file also flags any file touched that is under CODEOWNERS protection. **Risk: Scope creep during the pilot.** Mitigation: The pilot zone is defined in this document and in `CLAUDE.md`. Any proposed expansion during the four weeks is rejected. Post-pilot expansion proposals are handled as a separate approval cycle. **Risk: The pilot succeeds, and we rush the expansion faster than compliance can absorb.** Mitigation: The rollout playbook explicitly separates greenfield (wave 1) from regulated-sensitive (wave 2) surfaces. Wave 2 requires a fresh compliance review before it begins. **Risk: Engineering resents the change.** Mitigation: Same as standard variant. I will talk to every engineering DRI and every compliance owner before we start. If any of them is uncomfortable, we do not run the pilot on that surface. --- ## Success Criteria The pilot is a success if all six of the following are true at the end of four weeks: 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. Compliance review findings per PR trended flat or down. 4. Audit-log completeness was 100% across all PM-authored PRs. 5. PM self-reported energy averaged at least 3 out of 5. 6. The feature shipped and moved its primary metric in the expected direction. If five of six are met, we iterate and run a second pilot. If fewer than five, we roll back and stay on the current model. --- ## What I Need From You 1. Approval from engineering leadership. 2. Approval from the head of compliance or security, with sign-off on the control framework as written. 3. Two to three hours per week of one senior engineer's time per pilot PM, for four weeks. 4. Agreement on the PM zone boundaries and CODEOWNERS rules as written. 5. Your and the compliance lead's participation in the end-of-pilot readout meeting. Explicitly not asking for: - Any change to our current audit or compliance posture. - Any relaxation of existing controls. - Any expansion of PM access to protected data. - Any commitment beyond the four-week pilot. --- ## Appendix A: Files Pilot PMs Can and Cannot Touch (CODEOWNERS-Level) **CAN touch, within the feature folders they own:** - `**/*.md` (documentation and planning) - `**/i18n/*.json` (user-facing strings) - `**/prompts/*.md` (AI prompts for their own features) - `**/flags.yaml` for flags they own (enforced by CODEOWNERS) - `**/analytics/events.ts` (new events only, additions only) - `**/components/*.tsx` within their feature folder (non-breaking changes) **CANNOT touch (CODEOWNERS-enforced):** - `**/auth/**` - `**/payments/**` - `**/phi/**` or `**/pii/**` - `**/migrations/**` - `**/infra/**` - `**/audit/**` - `**/security/**` - `.github/workflows/**` - Any file outside their assigned feature folder without engineering co-authorship. --- ## Appendix B: Pre-Pilot Compliance Walkthrough Before the pilot starts, I commit to a 45-minute walkthrough with the compliance lead covering: 1. The control framework in this document. 2. The CODEOWNERS rules that enforce it. 3. The PM PR Review skill file and what it catches. 4. The `CLAUDE.md` file and the PM zone boundaries it encodes. 5. The audit trail from `PLANNING.md` commit to flag flip. Any adjustment the compliance lead requests is made before the pilot starts, not during. --- *Proposed by [your name]. This variant is designed for regulated environments. In unregulated environments, use the standard variant, which has a lighter controls section.*