qarium goga-define-success
Purpose
Define the criteria that determine whether the product change successfully solves the identified problem and delivers the intended user experience.
Transform the problem, goals, user experience, requirements, and scope into a concise set of observable success criteria that can be used to verify the completed product.
These criteria are an intermediate PRD artifact. They are not intended to become a long-term analytics or product-metrics framework.
Contract
consume:
- problem
- goals
- user_experience
- requirements
- scope
produce:
- success_criteria
Core Principle
Success criteria answer:
How will we know that the implemented product actually delivers what we decided to build?
They should verify the intended product outcome and behaviour.
Do not turn this stage into a metrics-design exercise.
Only define metrics when a quantitative measure is necessary to make the PRD sufficiently precise for engineering and subsequent validation.
Product Interview
Success criteria must reflect what the user considers a successful product outcome.
Do not invent success metrics or targets merely because they appear useful.
Interview the user when it is unclear:
- what outcome should define success;
- which outcome is most important;
- whether a quantitative measure is actually necessary;
- whether several possible success definitions imply different product priorities.
Prefer observable outcomes over arbitrary metrics.
If a quantitative target is not explicitly justified by the product context, do not invent one.
Process
1. Start from the goals
For each important goal, determine what evidence would demonstrate that the goal has been achieved.
Use:
Goal
↓
Expected outcome
↓
Success criterion
A criterion should make success observable rather than merely restating the goal.
2. Validate the user experience
Check whether the important user scenarios described in user_experience can be verified.
Consider:
- successful completion;
- important alternative paths;
- meaningful state transitions;
- failure and recovery behaviour;
- user-visible feedback;
- important consequences of actions.
Not every interaction needs a separate success criterion.
Focus on behaviours that determine whether the intended experience was delivered.
3. Validate requirements
Review the requirements and identify the behaviours that must be demonstrably true for the product to be considered complete.
Examples:
A user with an eligible order can cancel it before preparation begins.
After cancellation, the user can see that the order is no longer active.
These are useful success criteria because they describe observable product behaviour.
4. Use quantitative metrics only when necessary
A quantitative metric may be appropriate when the product decision genuinely depends on measurable behaviour.
Examples:
- completion rate;
- error rate;
- time required to complete an important task;
- adoption of a newly introduced workflow.
Only include a metric when:
- it directly reflects a goal;
- its meaning is clear;
- the metric can reasonably be measured;
- without it, success would remain materially ambiguous.
Do not invent arbitrary targets.
Do not add metrics merely because PRDs often contain metrics.
5. Prefer verifiable outcomes
Success criteria should make it possible to answer:
Did we solve the problem?
Did users get the intended outcome?
Does the product behave as specified?
Prefer observable statements over vague language.
Avoid:
The experience should be intuitive.
Prefer:
A user can complete the primary workflow without needing to leave the product.
6. Distinguish success criteria from acceptance criteria
Success criteria describe whether the product change achieves the intended outcome.
Acceptance criteria may describe detailed conditions for individual requirements and are normally created later during implementation planning or testing.
For example:
Success criterion:
Users can complete the cancellation workflow successfully.
Acceptance criteria:
- Cancellation is available only before preparation starts.
- Confirmation is shown after cancellation.
- The cancelled order cannot be cancelled again.
Do not turn this stage into a complete test specification.
Criterion Quality
A good success criterion is:
Observable
Its outcome can be verified.
Relevant
It directly relates to a problem, goal, user experience, or important requirement.
Specific
It is clear what constitutes success.
Proportionate
It contains enough detail to remove ambiguity without becoming a full test plan.
Evidence-based
It does not rely on invented facts or arbitrary thresholds.
Challenge the Criteria
Challenge the success criteria against the full context.
Ask:
- If all criteria pass, have we actually solved the problem?
- Does every important goal have evidence of success?
- Are critical user scenarios represented?
- Are we measuring something meaningful rather than something easy to measure?
- Are any criteria actually requirements rather than success criteria?
- Are any metrics arbitrary?
- Are we missing an important observable outcome?
- Could the product technically satisfy every criterion while still failing the original problem?
If the criteria do not provide credible evidence that the problem has been solved, revise them.
Conflict Detection
Report a conflict when:
- a success criterion contradicts a goal;
- a criterion requires behaviour that is not present in the requirements;
- a criterion contradicts an established constraint;
- success cannot be demonstrated within the defined scope;
- a quantitative target is required but cannot be justified from the available context.
Example:
conflict: |
The success criteria require the workflow to be completed
immediately, but the defined user experience and requirements
allow the operation to remain pending.
reason: |
The criteria describe a stronger outcome than the product
solution currently guarantees.
The orchestrator will invoke goga-define-resolve.
Do not resolve cross-context conflicts yourself.
Missing Information
Ask the user only when success cannot be meaningfully determined without an important product decision.
Valid questions may concern:
- what outcome should count as success;
- whether a particular user behaviour is essential;
- whether a quantitative target is genuinely required.
Do not ask for technical monitoring or implementation details.
Do not invent metrics or numerical targets.
Do Not Define
This skill must not define:
- analytics architecture;
- monitoring implementation;
- dashboards;
- telemetry systems;
- technical tests;
- test automation;
- development tasks;
- long-term KPI frameworks;
- technical performance budgets unless they are explicitly part of the product requirement.
Output
Produce a concise set of success criteria that demonstrate whether the product change achieves its intended outcome.
The result should provide enough evidence to verify:
- the original problem is addressed;
- important goals are achieved;
- the intended user experience is delivered;
- critical product behaviour works as defined.
Use quantitative metrics only where they materially improve the precision of the PRD.
The final result should remain an intermediate product artifact, not a permanent product analytics specification.