Goal or outputs: what success means

Every project produces outputs (UK «результати роботи»): the things the team makes. For the physics launch these are the curriculum, the tutor pool, the diagnostic test and the landing page. The goal is different: a change in the world that the outputs are meant to cause. Here, families choose Klasna for physics exam preparation, book a package, and learners keep coming to their lessons.

The trap is to report outputs as success. On 1 February everyone can truthfully say “my part is done” while nobody has booked. Finished outputs prove that the team worked, not that the project achieved anything.

A quick test for any line in a plan: could this be fully done while nothing changes for learners? If yes, it's an output. Keep outputs in the plan (you still need them), but don't let them stand in for the goal.

Success criteria say in advance how everyone will judge the project. Write them in two parts.

Delivery (UK «виконання») judges how the work was handed over: the date, the budget and the agreed scope. For physics: classes open on 1 February 2027, within the budget Leo approves, with the agreed scope.

Result (UK «результат») judges what changed afterwards, in numbers, by a date: 120 learners have booked a physics package by 28 February 2027, and three in four of them still attend in their fourth week.

Outputs such as “the page is published” are neither: they go into the plan, not the criteria. Vira's point shows why the result has two numbers: a booking can be bought with an ad, but a learner still there in week four stayed because the lessons work. A criterion that someone can't check on a named date isn't a criterion yet.

A result criterion needs a target, but a new project rarely has data to set one. The honest move is not to drop the target and not to dress it up as a benchmark. Write it down and label it as an assumption.

Leo's 120 bookings came from his physics plan, not from other schools' results. “Three in four still attending in week four” is also a guess. Both go into the criteria marked as the plan's assumptions, with a date to check them: the results check on 1 March.

Why keep a guessed number at all? Because without it, every outcome passes: 40 bookings becomes “a promising start”, 200 becomes “a great success”, and nobody learns anything. A labelled assumption gives you something to compare against and tells everyone how much to trust it. Vira's tutors won't be judged on a number presented as fact.

When every output is finished on time and within budget, the project has met its delivery part, and only that. The result part is checked later, against what changed for learners.

For the launch, “curriculum, tutors, test and page ready by 1 February, within budget” is excellent delivery. It says nothing yet about whether 120 learners booked by 28 February or whether three in four still attend in week four. Those answers arrive weeks after the outputs are done, which is why the project stays open until the results check in March.

The pitfall is declaring victory at the delivery moment. It feels natural: the team worked hard, the date held. But a launch can be delivered perfectly and still miss its result. Say both halves out loud: “delivered on time; result to be checked on 1 March.”

The two parts of success judge different things. Delivery judges the team's work: did we hand over what we promised, by the date, within budget? The result judges the bet behind the project: did that work change what we hoped it would?

Kept apart, neither can hide the other. If physics opens on time within budget but only 60 learners book by 28 February, delivery held and the result missed. That's information, not blame: maybe the price, the timing or the offer was wrong, and March is when you find out why. If 120 learners book but classes open on 15 February, the result held and delivery failed, and the two lost weeks in exam season hurt every learner.

Two pitfalls follow. Don't punish a team for a bet that didn't pay off. And don't rewrite the target afterwards so the result “passes”.

Any output can be traced to a result you can check, in five steps, each needing the one before:

1. Name the output: the diagnostic test is live.
2. Ask what it should change for learners: parents see their child's level and pick the right package.
3. Choose something you can count: the share of test-takers who then book.
4. Set a target and label it as an assumption until you have data.
5. Name the date you'll check it.

Danylo's test becomes: “the share of February test-takers who book by 1 March, target labelled as an assumption.” The order matters: you can't choose a count before you know the change you want, and a target means nothing without a number to compare it with. The date comes last and turns the target into a check someone will actually run. Skip step 2 and you end up counting test completions, which is just the output again.

A good success criterion lets you answer the sponsor's question with a number on a date. When Leo asks “so how many learners?”, only a criterion written with both parts gives a clear answer: classes open on 1 February 2027 within the approved budget; 120 learners booked by 28 February 2027 and three in four still attending in week four, both labelled as assumptions.

The weak versions fail in recognisable ways. “Launch physics successfully and on time” can't be checked: what counts as successful? A list of finished outputs covers delivery and is silent about learners. “As many learners as possible” has no target, so 30 and 300 both pass.

Before signing a criterion, read it as Leo will on 1 March and ask: can someone say yes or no to this, with data, on a named date? If not, rewrite it until they can.

Success criteria do their job only if they're agreed before the work starts, in writing, and signed by the sponsor. For the launch that means October, not March.

Two reasons. Early criteria steer decisions: when Danylo must choose between polishing the page and finishing the test, the result criterion (bookings after the test) tells him which matters more. And early criteria can fail, which is what makes them useful. Criteria written after the results are in always pass, because they describe what happened.

The habit for every “done”: ask “done, and what changed?” The same idea runs through the Outcome-Based Product Roadmaps course for whole roadmaps; here it's applied to one project with a fixed date.

How it fits together: outputs aren't the goal; success has a delivery part and a result part, kept apart, with labelled assumptions, agreed up front. Next lesson puts these criteria on one page with scope, limits, assumptions and an owner.