Product Operations as a Discipline

Standing up a Product Operations function from scratch at Alef Education. Four pillars, a small sharp team, twelve items shipped in Q1 2026, and a clear position on what the function does not do. The framing was the work.

The problem

Alef had product managers. Alef had designers. Alef had engineers. What it did not have was the connective layer between them: the function that owns the rituals, the data infrastructure, the release governance, and the operational discipline that lets a 200-person product organisation move at the same cadence as a 30-person one.

The symptoms were familiar. Quarterly planning that drifted into the quarter it was supposed to plan. Launches that surprised marketing. Release notes that nobody could find. A leave tracker built in a Google Sheet that quietly stopped being maintained. Each problem was small. The aggregate cost was a product organisation operating at maybe 60% of its potential throughput.

What I did

I took on the Product Operations remit alongside my Head of Design role. The brief from leadership was loose: “make this work better.” I treated it as an organisational design problem rather than a tooling problem.

Position the function

Product Operations at Alef would own four pillars: Knowledge & Documentation, Tooling & Tracking, Compliance & Governance, and Cross-functional Enablement. Everything outside those four was out of scope. Naming what the function did not do was as important as naming what it did. Most P-ops functions get sold internally as “we will help you do your job better”, which sounds like overhead. I positioned this one as “we will own the things that nobody else owns and that everyone is suffering from.” That framing got the function adopted rather than tolerated.

Build a small, sharp team

Four people. Each one an operator who could write SOPs, instrument tools, and run sessions without needing a manager in the room. P-ops only works when it is run by people who have been operators themselves. It cannot be staffed by junior project coordinators and produce senior outcomes. That is the staffing call that determines whether the function delivers or quietly collapses.

Write it down

The move that most P-ops functions skip. I built a library of skill packs and standard operating procedures so the work was repeatable and not dependent on me being in the meeting. The leave anti-system replaced a failing spreadsheet with a two-gate logic: hard availability block plus two-party confirmation. The competitive intelligence routine became a quarterly market scan with explicit deduplication. The market research function got a structured methodology rather than ad-hoc requests.

Q1 2026: twelve items shipped

The first full quarter of the team operating against the four-pillar model. Twelve items delivered:

In parallel, four items carried into Q2 by design: leave tracker production deployment (pending hosting and security sign-off), team shared calendar, retrospectives rhythm, and freelancer onboarding Phase 2.

Honest reflection

Cross-functional dependencies remain the single biggest source of slowdown. Much of what P-ops does requires sign-off from teams already running at capacity. That is not a problem to solve in one quarter. It is the structural reality of being the connective tissue. The work in Q2 is reducing the friction without inflating the function.

The other reflection: P-ops has a visibility problem by design. Most of what the function does is invisible until it ships. The quarterly review format I built was partly the response to that. It forces the team to make the work legible, and it gives the rest of the organisation a place to ask for what they need. A P-ops function that nobody can describe is a P-ops function that gets cut in the next budget cycle.