qarium goga-define-goals
Purpose
Define the product outcomes that should be achieved by solving the identified problem for the relevant users.
Transform the established understanding of the product, problem, and users into a small set of clear product goals.
Goals describe the change we want to create, not the features or implementation used to create it.
Contract
consume:
- product
- problem
- users
produce:
- goals
Core Principle
A goal describes an outcome, not a solution.
The skill must answer:
What should become different if we successfully solve the problem?
Do not turn the user's requested feature into a goal.
For example:
"Build an export to Excel."
is not a goal.
A better goal is:
"Allow operations managers to easily share the relevant order data with colleagues who do not use the product."
The specific mechanism used to achieve this belongs to later stages.
Product Interview
Goals are product decisions and must not be inferred from the requested feature alone.
Use the problem and users to formulate candidate outcomes, then validate the intended outcome with the user.
Interview the user when necessary to determine:
- what should change as a result of solving the problem;
- which outcome is most important;
- whether there are multiple competing outcomes;
- what should explicitly not be optimized;
- whether the requested feature is actually the intended outcome.
Do not assume that the requested solution represents the user's actual goal.
If multiple reasonable goals would lead to materially different solutions, present the distinction and ask the user to choose.
Process
1. Connect goals to the problem
Review the established problem.
For each proposed goal, verify:
Problem
↓
Goal
The goal must directly contribute to solving the problem.
Do not create goals merely because they sound beneficial.
2. Consider the relevant users
Use users to determine what outcome matters to the people affected by the problem.
Consider:
- what users need to accomplish;
- what currently prevents them;
- what should become easier, possible, clearer, safer, or more predictable;
- what meaningful outcome should result from the change.
Do not restate user personas as goals.
3. Define product outcomes
Describe the desired change in product terms.
Good goals typically express:
- an outcome users should be able to achieve;
- an improvement in the user experience;
- a capability that removes the identified problem;
- a meaningful change in product behaviour.
Avoid implementation language.
4. Keep goals focused
Prefer a small number of meaningful goals over a long list.
Do not create separate goals for every requirement or user interaction.
For example, these are usually requirements rather than separate goals:
The user can click the button.
The system shows a confirmation.
The user receives a notification.
A goal may be:
The user can complete the task confidently and understand the result.
5. Distinguish goals from requirements
Use this distinction:
Goal
What outcome should be achieved?
Requirement
What must the product do to achieve that outcome?
Example:
Goal:
Users should be able to determine the current state of their order
without contacting support.
Requirement:
The product must clearly display the current order state.
Do not put requirements into goals.
6. Challenge the requested solution
Check whether the proposed solution is actually necessary to achieve the goal.
For example:
Requested:
Add a CSV export.
Underlying goal:
Allow users to transfer selected data to another workflow.
The goal should remain independent of the proposed implementation.
Do not reject the user's proposed solution at this stage. Preserve the desired outcome and allow later stages to determine how the product should behave.
7. Check for missing goals
Look for meaningful outcomes implied by the problem and users but absent from the current goal set.
Consider:
- Is the main user outcome covered?
- Are important secondary users affected by the outcome?
- Does solving the problem require a specific trust, clarity, control, or safety outcome?
- Would achieving the stated goals actually solve the problem?
Do not add speculative goals.
Goal Quality
A good goal should be:
Relevant
Directly connected to the identified problem.
User-oriented
Expressed in terms of meaningful user or product outcomes.
Actionable
Specific enough to guide the next stages.
Solution-independent
Does not prescribe a particular feature or implementation.
Limited
Does not introduce unrelated improvements.
Goal Relationship
The final goals should form a coherent chain:
Problem
↓
User needs
↓
Goals
If a goal cannot be explained as a response to the problem or a relevant user need, challenge it.
If solving the stated goals would not adequately address the problem, report a conflict.
Conflict Detection
Report a conflict if:
- a goal contradicts the problem;
- goals require mutually incompatible outcomes;
- a goal contradicts established product behaviour;
- the requested solution cannot reasonably achieve the stated goals;
- an essential outcome is impossible under the known constraints.
For example:
conflict: |
The current goal requires users to complete the workflow
without leaving the product, while the existing product
constraint requires this workflow to be completed externally.
reason: |
The goals and existing product constraints describe
incompatible product outcomes.
The orchestrator will invoke goga-define-resolve.
Do not resolve cross-context conflicts yourself.
Missing Information
If a meaningful goal cannot be defined because a critical product decision is missing, ask the user for the minimum necessary information.
Do not ask questions about implementation.
Do not create speculative goals to fill gaps.
Do Not Define
This skill must not define:
- user experience;
- user journeys;
- product requirements;
- UI behaviour;
- technical architecture;
- APIs;
- databases;
- implementation details;
- scope;
- success metrics as a separate analytics system.
Success criteria are defined in a later stage.
Goal Decision Check
Before producing goals, verify:
- every goal is intentionally chosen;
- no important competing goal remains unresolved;
- goals are outcomes rather than implementation requests;
- the priority between materially conflicting goals is known.
Do not produce goals while a material product trade-off remains implicit.
Output
Produce a concise set of product goals.
Each goal should clearly describe:
- the desired outcome;
- who benefits from it when relevant;
- how it addresses the problem.
Avoid:
- feature lists;
- implementation plans;
- technical details;
- duplicate goals;
- unrelated product improvements.
The final result must provide a clear direction for the subsequent User Experience stage.