Product Manager - Branching
ABOUT SUPABASE
Supabase is the Postgres development platform, built by developers for developers. We provide a complete backend solution including Database, Auth, Storage, Edge Functions, Realtime, and Vector Search. All services are deeply integrated and designed for growth.
Supabase is the open-source Postgres development platform that 10M+ developers and thousands of enterprises depend on every day. We're hiring a Branching PM to own the whole path a change takes from a laptop to production: local development https://supabase.com/docs/guides/local-development with the CLI, migrations and seed data, configuration as code, an isolated branch https://supabase.com/docs/guides/deployment/branching per pull request, the GitHub integration https://supabase.com/docs/guides/deployment/branching/github-integration that tests it, and the promotion to production https://supabase.com/docs/guides/deployment/managing-environments. Agents now drive a growing share of this workflow: they open branches in parallel, run migrations constantly, and need feedback in seconds. The path has to hold for people and agents alike.
WHAT YOU'LL BE RESPONSIBLE FOR
- Talking to customers across the full spectrum. Indie developers running the CLI for the first time, startups wiring up a branch per pull request, platforms that provision environments on Supabase for millions of their own end users, and enterprise teams who need a documented route from development to staging to production. They ask for features. You find the need behind the ask, and those needs set the roadmap.
- Making the pieces feel like one workflow. The CLI, migrations, seeds, configuration, branches, and Git integration have to land on developers as one path. You decide where one tool ends and the next begins, and the mental model is yours to defend.
- Owning the outcome of each launch, and defining how it's measured before it ships. The metric, the threshold, and the read afterwards are yours: time to a developer's first migration, branch adoption, the share of teams shipping through a reviewed workflow. Shipping starts the measurement, and the read decides the next call.
- Owning the problem statement and the commercial shape behind every bet. You capture the customer evidence, name the constraints (provisioning latency, compute capacity, cost per environment, how much production data an environment can hold), and set each target at how good it needs to be. Every environment costs compute, so you decide what stays free to win a developer and what a company pays for.
- Deciding what gets built, what gets deferred, and what gets cut. Every quarter you're choosing between local development ergonomics, partner platforms that run their whole user base on this workflow, enterprise release requirements, and the infrastructure work that all of it runs on. You know the path's SLOs and what spending the error budget costs the roadmap. The priorities are yours to defend, and the written non-scope settles most mid-flight asks.
- Keeping engineering, design, and leadership aligned. Your roadmap runs through compute, storage, the CLI, the dashboard, and the GitHub integration. You write it down, surface dependencies before they become blockers, and keep decisions moving.
YOU MIGHT BE A GOOD FIT IF YOU
- Have 7+ years of product management experience on developer tools, or you're an ex-founder with strong product instincts. Technical here means hands-on: you follow a design discussion, get into the code when the answer lives there, with or without AI assistance, and form your requirements from what the system actually does.
- You've shipped developer-workflow products. You've owned at least one of local development tooling, migrations, CI/CD, ephemeral or preview environments, or Git-integrated deploys. You understand the tradeoffs well enough to judge them: what belongs in a CLI vs. a dashboard, schema-only environments vs. environments with data, copy-on-write clones vs. dump-and-restore, why branching is cheap and merging stateful systems isn't, and how much of a workflow can live in a config file before developers stop reading it. Familiarity with the Postgres ecosystem (migrations, extensions, tooling) is a bonus.
- You're biased toward action. You break big bets into pieces that ship early, treat each release as a test of your assumptions, and deliver carefully enough that this quarter's launch doesn't become next quarter's support burden. You measure speed by how fast the outcome arrives.
- You build with what you own. You run the workflow yourself: a project running locally, migrations and seeds under version control, a branch opened off a pull request, and a promotion to production you'd trust on a Friday.
- You use AI to move faster. You reach for AI tools to cut the slow parts and spend the time you save on judgment calls.
- You work async by default. You make decisions in writing and move threads forward without meetings.