Scope is worldwide and no work-authorisation, presence, language, timezone, or credential restriction was found in the body text.
“Remote, Anywhere” Geographic scope — No location restrictions stated — worldwide.
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 with the CLI, migrations and seed data, configuration as code, an isolated branch per pull request, the GitHub integration that tests it, and the promotion to production . 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.
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.
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.
We move fast, build in public, and use what we ship. If it’s in your project, we probably use it in ours too. We believe deeply in the open-source ecosystem and strive to support—not replace—existing tools and communities.
Straight to the employer's own application — no middleman.
Tell us and we'll mark Supabase as a company that has actually hired in the Caribbean. It's the most useful thing on this board and it only exists because people report it.
I got hired here →