How to Ship Your First Pull Request as a PM

Rippling killed planning decks. Garry Tan ships 100 PRs/week. One PM changed two words on a CTA and got a 14% conversion lift. The step-by-step system, plus 4 downloadable tools.

Apr 14, 2026

∙ Paid

Matt MacInnis is the CPO at Rippling, a $16B+ workforce platform. He posted this last week:

Three bullets. Three shifts. All already happening at one of the largest product orgs in tech.

And he’s not alone.

Garry Tan, CEO of Y Combinator, open-sourced his entire Claude Code setup (gstack). It hit 33K GitHub stars in a week (now past 65K). He’s personally shipping 100 PRs/week while running YC.

Boris Cherny, creator of Claude Code at Anthropic, ships 20-30 PRs a day. 100% AI-written. He uninstalled his IDE.

Jiaona Zhang, CPO at Laurel, Stanford lecturer, ex-Airbnb: her PMs are “going beyond prototyping to production.” Her designers push code too.

OpenAI’s Codex team shipped an entire product with 1,500 merged PRs and zero manually written code. Superhuman uses Codex so PMs can “contribute lightweight code changes without pulling in an engineer, except for code review.”

A startup CTO posted yesterday: “Last week, one of our PMs built and shipped a feature. Not spec’d it. Built it, tested it, shipped it to production. In a day.”

These aren’t engineers. They’re PMs, CPOs, and CEOs.

This piece is the step-by-step manual for joining them.

Today’s Post

The New Map: PM vs Design vs Eng (start here if this is new to you)
Planning in Git: The Open-Source Planning System
Your First Pull Request and How to Earn Eng Trust (start here if you’re ready to ship)
What PMs Ship and How to Test It (start here if you’re already pushing PRs)
Real-Time Customer Issue Monitoring
Real-World Teardown

Plus 4 downloadable tools: The Open-Source PM Planning System (GitHub repo), The PM PR Skill File, The “Make the Case” Pitch Doc (with enterprise variant), and The Customer Issue Monitoring Playbook.

1. The New Map: PM vs Design vs Engineering

Every PM reading this is asking the same question: Do I need to become an engineer?

No. The boundaries shifted. The roles didn’t merge.

But here’s the part most people miss. Shipping code makes you a better PM.

When you can test a copy change in an afternoon instead of theorizing about it for a quarter, your strategy gets sharper. Your user research gets faster feedback. Your product sense sharpens because you see the consequences of your decisions in hours instead of months.

Nothing in this piece replaces strategy, user research, or stakeholder alignment. Those skills matter more than ever because the cost of building the wrong thing just dropped to near zero. The PM who ships has tighter feedback loops on everything. Shipping is additive. It amplifies every other PM skill.

Here’s how the map actually changed.

The Old Map

PM: specs, tickets, prioritization
Design: mockups, prototypes, handoffs
Engineering: all code, all deploys, all monitoring

Thick walls between each role. PM couldn’t touch code. Engineer waited for the spec. Designer handed off a Figma file and hoped for the best.

The New Map

PM zone expanded into: copy, config, AI prompts, planning docs in git, small front-end changes, production monitoring. The stuff where the PM has the most context and an engineer was just translating PM intent.
Design zone expanded into: coded prototypes (v0, Cursor), design system changes shipped directly, visual QA against real user sessions.
Eng core concentrated on: architecture, infrastructure, security, complex logic, performance, code review. The hard problems. The things that actually need senior engineering judgment.

This makes engineers happier. The Zenflow CTO who posted about his PM shipping code wrote:

“When PMs build their own ideas, their specifications get sharper, because they now understand what the agent needs to execute well. Sharper specs produce better agent output.”

The engineer’s life got better because the PM got closer to the work.

At Anthropic, Cat Wu (head of product) told TechCrunch that code output per engineer grew 200%. The bottleneck shifted from writing code to reviewing it. That’s engineers telling you they need help with the volume. PMs shipping the small stuff is part of how you solve that.

If you’re at a company where this hasn’t started yet: Later in this piece (paid), there’s a pitch doc you can hand your eng director — with a variant for regulated environments.

2. Planning in Git: The Open-Source Planning System

MacInnis said it plainly:

“No more planning decks, only markdown pushed to a git repo.”

The Old Way

PM writes a Google Doc or Notion page. Shares the link. Comments scatter across three tools. Review meeting happens. Engineers can’t find the spec during implementation because it’s buried in someone’s Drive folder. The doc lives in a silo, disconnected from the code.

The New Way

PM writes a markdown file. Pushes it to the same repo where the code lives. Engineers and Claude Code both reference it directly. When you want to know why something shipped, git log shows you. Version control gives you diffs, history, and accountability.

The content is the same as a good PRD. The location changed. And the location matters because it puts the spec where the builder — human or AI — can actually use it.

What a PLANNING.md Looks Like

Here’s a preview. The full worked examples are in the downloadable repo.

# PLANNING: Smart Notification Batching

## Problem
Users receive 12+ notifications/day. "Notification fatigue" tickets up 34% last
quarter. 8% of users muted all notifications.

## Hypothesis
Batching low-priority notifications into a daily digest will reduce mute rates
by 15%+ while maintaining engagement with high-priority alerts.

## Success Metrics
- Primary: notification mute rate drops ≥15% vs control
- Guardrail: high-priority CTR doesn't drop >2%
- Guardrail: DAU doesn't decrease >1%

## Rollout
- 10% of users, 2 weeks, user-level randomization
- Kill if mute rate doesn't improve ≥5% after 2 weeks

That’s it. That replaced a 15-page Google Doc and a 30-minute review meeting.

CLAUDE.md: Your Brief to the AI

CLAUDE.md is a persistent instruction file in the project root. Claude Code reads it at the start of every session. It encodes: product context, coding standards for PM-scoped changes, review expectations, and what the PM should and shouldn’t touch. You write it once and update as the product evolves.

Your PM OS is the deeper version of this. For today, what matters is: if you’re going to ship code as a PM, CLAUDE.md is where you encode your judgment so the AI follows it every time.

You Can Start Today Without a Terminal

Everything in this section works from GitHub’s web interface. Create a repo. Click “Add file.” Write your PLANNING.md in the browser. Commit it. You just shipped a spec to git. No terminal. No Claude Code.

If you’re preparing for PM interviews, fork the repo below and write a PLANNING.md for a case study - it’s a better portfolio artifact than a PDF.

Downloadable #1: The Open-Source PM Planning System

A public GitHub repo you can fork. Designed for product directors to deploy across their team and for individual PMs to use solo.

Get the Planning System

What’s inside:

PLANNING-TEMPLATE.md — fill-in template with every section
Two worked examples — one for a non-AI feature, one for an AI feature with behavior contract
CLAUDE.md — PM-specific Claude Code config with product context sections, review checklist, and PM-zone boundaries
Team rollout playbook — how a director deploys this system, measures it, and iterates
Pilot measurement template — metrics for the first sprint pilot
Weekly review cadence doc — how to run the weekly planning review
Planning review skill — a Claude Code skill that reviews your doc and flags gaps before you share it

The README addresses product directors: “You’re deploying a planning system for your team. Here’s how to set it up, measure it, and iterate.” When they join a new company, they fork this in week one.

🔒 The rest of this post is for paid subscribers.

Next: the skill file that auto-reviews your PRs before engineers see them (so your first merge doesn’t embarrass you). A copy slop audit where one PM changed two words on a CTA and got a 14% lift in trial signups. Step-by-step monitoring that catches production issues in minutes, not weeks. And a full teardown showing how PM #2 shipped the same feature 8.5 weeks faster than PM #1, using this exact workflow.
Plus 3 more downloadable tools, including the pitch doc that gets your eng director to approve the pilot.

Keep reading with a 7-day free trial

Subscribe to Product Growth to keep reading this post and get 7 days of free access to the full post archives.