Product Controller

ABOUT PLANE

Plane is an incisive response to config-heavy, opinionated, and restrictive project management software. Read our manifesto https://plane.so/manifesto.

In just two years, Plane has grown to #1 in its category on GitHub and become a viable open-core alternative to Jira, Monday, Wrike, Asana, ClickUp, and Linear. Our growth has come on the back of the product’s true flexibility without artificial limits, simple configurations that work out of the box, and thoughtfully packaged features that nurture our customers’ growth instead of punishing it.

As a modern product start-up, we obsess over new and power users equally. Our mission is to empower teams everywhere with the simplest, most delightful work management experience on the planet. Our vision is to become the WorkOS of the future with a workbench of unified tools and techniques that intuitively and progressively form a greater whole for knowledge workers.

ABOUT THE ROLE

THE PRODUCT CONTROLLER

Air traffic controllers don't fly planes and they don't build runways — but nothing moves without them. They hold the full picture, sequence priorities, resolve conflicts in real-time, and route traffic across multiple vectors simultaneously.

That's what this role is.

At Plane, the Product Controller owns both the what and the how of product execution. You hold the roadmap in one hand and the execution plan in the other, and your job is to make sure every team — engineering, design, infrastructure — is cleared for takeoff, routed correctly, and landing on time.

This isn't a project manager who chases status updates. This isn't a product manager who writes specs and hands them off. This is someone who sits at the intersection of product thinking and operational coordination, maintaining real-time situational awareness across the entire system of work.

WHAT YOU'LL DO

HOLD THE PICTURE, MOVE THE WORK

Own situational awareness — maintain a live mental model of everything in motion: what's being built, what's blocked, what's about to collide, and what's coming over the horizon. When someone asks "where are we on X?", you don't check — you already know.

Sequence and prioritize across teams — when two priorities compete for the same engineering bandwidth or a design dependency threatens a release timeline, you make the call. You don't escalate ambiguity — you resolve it.

Route work across boundaries — manage transitions from product thinking to design exploration to engineering implementation to release. Make sure the right context arrives with the right work at the right team at the right time. No dropped context, no orphaned decisions.

Shape what gets built — synthesize user feedback, competitive signals, community requests, and technical constraints into clear product direction. Write the spec when a spec is needed, skip the spec when a 5-minute conversation will do. Know the difference.

Protect team throughput — push back on scope creep, flag unrealistic timelines before they become crises, and actively remove blockers. Treat the team's focus as a finite resource and defend it.

Coordinate releases end-to-end — from feature definition through QA, documentation, changelog, and release notes. Own the entire surface area of getting a thing from idea to shipped and communicated.

Bridge community and product — we're open-source. Our GitHub issues, Discord, and community channels are a live signal of what users need. You translate that signal into action without letting volume override judgment.

WHAT A TYPICAL WEEK MIGHT LOOK LIKE

• Running a lightweight daily sync that gives every team exactly the context they need and nothing more.
• Making a real-time call to re-sequence a sprint when a critical customer issue surfaces.
• Sitting with a designer and an engineer to resolve a UX-feasibility tradeoff on the spot, instead of routing it through three rounds of async review.
• Writing a tight product brief for a feature that synthesizes five different customer conversations into one clear direction.
• Noticing two engineers on different streams building toward a merge conflict, and rerouting before it costs anyone a day.
• Saying no to a feature request from a paying customer because it conflicts with architectural direction — and being right about it.
• Shipping release notes that communicate what changed and why it matters.

WHAT WE'RE LOOKING FOR

YOU, IDEALLY

• You've done both product management and project management, and you found the boundary between them artificial. You're not interested in picking one lane.
• You can context-switch between a roadmap discussion and a sprintlevel blocker without losing altitude on either. You think in systems — dependencies, throughput, bottlenecks — not task lists.
• You've shipped software in a small team where nobody had the luxury of a narrow job description. You understand that in a team this size, ownership means end-to-end, not role-to-role.
• You have strong opinions about how product teams should operate, loosely held when the evidence says otherwise. You're comfortable making decisions with incomplete information and reversing them when new information arrives.
• You have solid technical instincts. You don't need to write code, but you need to understand systems well enough to evaluate tradeoffs, spot architectural risks, and hold your own in a conversation with senior engineers.
• You write clearly and concisely. Specs, briefs, release notes, internal comms — your writing reduces ambiguity rather than adding process.
• You've used or studied tools like Jira, Linear, Asana, or Plane and have strong views on what they get right and wrong. You understand the domain we're building in because you've lived in it.

BONUS POINTS

EVEN BETTER IF

• You've worked in open-source companies and understand the dynamics of building product in public — where your roadmap is visible, your community is vocal, and your users file PRs alongside feature requests.
• You have experience with enterprise customers in regulated industries — aerospace, defense, healthcare, finance — where the cost of coordination failure and release mismanagement is high.
• You've read about or practiced Lean and Kanban thinking: flow efficiency, WIP limits, Little's Law, cycle time. You think about delivery as a system, not a checklist.
• You've worked at a startup with fewer than 30 people and thrived in the ambiguity. You don't wait for structure to appear — you build it, just enough, and move on.