Project, operations or product work?

A project is temporary work that exists to create a defined result. Two features carry the definition: it has a start and an end, and what it produces is one-time, not a cycle that repeats.

Everything else is optional. A project can be urgent or quiet, big or small, run by a dedicated team or by people who keep their usual jobs. A deadline alone doesn't make one: tutor payouts have a deadline twice a month and never end.

At Klasna the physics launch fits: the result is a subject the school can sell and teach, and once it exists and is handed over, the launch is over. The test is simple: ask what result will exist at the end, and what makes the work stop? If you can't answer both, you're looking at a different kind of work, which the next cards sort out.

Organisations do three kinds of work, and the quickest way to tell them apart is to ask what ends it.

• Operational work repeats with no planned end: daily lessons, tutor payouts twice a month, the support chat. Nothing ends it; the cycle simply runs again.
• Product work improves a living product, like Klasna's booking flow: new goals every quarter, no finish line, because the product and its users keep changing.
• A project ends when its one-time result exists and is accepted: physics classes open and the result is handed over; the last tutor signs the updated contract.

The same company runs all three at once, often with the same people. Danylo's team improves booking all year (product work) and, for a few months, also builds the physics option for it (a project piece). Naming the kind of work tells you which tools fit: a brief and a closing for a project, routines for operations, goals and a backlog for product work.

The three kinds of work are different, not ranked. Operational work is where the money comes from: every delivered lesson at Klasna earns revenue and pays a tutor. Product work keeps the platform competitive. A project is a temporary push to create something new that operations will run afterwards.

That has a practical consequence. Projects almost never have their own people: Vira still runs the existing programs, Danylo still owns the platform backlog, Roman still handles tutor operations. The launch borrows their time. If you treat the project as more important and quietly pull people away, support answers slow down, payouts slip, and the business that funds the launch suffers.

So a project lead agrees on time with the people and their managers, writes the agreement down and returns what was borrowed. The project's job is to hand operations something they can run, not to win against them.

A project frame means a brief, one accountable lead, a plan and a closing. It costs time, so use it only where it earns that time back. It pays off when three conditions meet:

1. A fixed date: the result must exist by a moment that won't move, like classes opening on 1 February before the spring exams.
2. A one-time result: once it exists, the work is done.
3. Several people handing work to each other: Vira's curriculum feeds tutor onboarding, Danylo's test feeds the page, marketing waits for both. If one is late, others wait.

Without these, the frame is ceremony. A two-day fix by one developer needs a task and an owner, not a kickoff meeting. Weekly recurring work needs a routine. And “the CEO says it's important” is not a condition at all: importance changes priority, not the kind of work.

A common mistake is to wrap continuing product work in a project with an invented date. It feels energising (“a date gets people moving”), but the work has no defined result, so the date can't mean anything.

Leo's “AI partner relaunch, deadline 15 December, goal: make it better” is exactly that. Klasna tunes the AI practice partner every week from learners' feedback and will keep doing so on 16 December. Two things can happen: the team fakes a “done” on the date and stops improving, or the date slips and deadlines everywhere lose meaning.

The fix is to frame only a one-time piece inside the product work, one with a real result and a real date: “move the AI partner to the new model before the old one is switched off”. That piece can be a small project; the rest stays product work with quarterly goals.

A project ends when its result is accepted and handed over to the people who will run it. It doesn't swallow the work that follows.

For the physics launch, the result is a subject operations can run: tutors ready, a curriculum, a diagnostic test, a page and booking. Classes open on 1 February, but the project stays open a few more weeks to watch the first classes, fix what breaks and confirm the handover. It closes in March. From then on, teaching physics every week is operational work, exactly like English and math: it repeats with no planned end.

Why draw the line so sharply? Because a project with no end becomes a permanent team with a temporary name, and nobody can say whether it succeeded. Write down early what “handed over” means: who runs physics from March and what they receive.

A project ends in one of two ways: its result is accepted and handed over, or someone with the authority, usually the sponsor, decides to stop it. Both are real ends.

Stopping is not a disgrace. Priorities change, a cheaper route appears, the money is needed elsewhere. If Leo stopped the physics launch in November, the right move would be a short, proper closing: release Vira's, Danylo's and Roman's time, end open agreements with freelancers, save the draft curriculum where it can be found, and write down what was learned.

Two traps to avoid. The zombie project: nobody says “stop”, so it keeps borrowing people with no result ahead. And finishing because it's half done: the effort already spent is gone either way; only the value of the remaining work justifies continuing. Whether to stop is the sponsor's decision, made in writing.

A project owns only the one-time pieces its result needs and borrows everything else for a while. Physics needs a subject option in booking, so the launch owns exactly that piece: physics bookable before classes open. The booking flow itself stays product work before and after, with Danylo's team.

A simple test for any item: is it a one-time piece the result needs by the date? Then it's inside. Does it repeat (payouts, support answers) or improve something with no end (weekly booking fixes)? Then it belongs to operations or product work, now or after the handover. Whatever the project owns, it must deliver and hand over.

How it fits together: a project is temporary work with a one-time result; it ends with a handover or a decision to stop; a frame pays off only with a fixed date, a one-time result and hand-offs. Next lesson: what success means, beyond “the work is done”.