This is a worked example of a goal cascade for a product organisation: a VP Product owns “30-day retention”, splits it across five product squads (each with a product manager, a designer, an analyst and developers), and every squad goal links to individual goals. It also covers the difference between a goal and a roadmap, how to link goals to Jira epics, what to do when priorities change mid-quarter, and short examples for Sales, Customer Success and HR.
Illustrative example: the company, squads and numbers are invented to show the structure. They are not benchmarks or customer data.
Department, team and individual goals
| Level | Who owns it | What it is for | Good practice |
|---|---|---|---|
| Department | VP or Head of the function | Translates one company goal into the function's contribution | One to three goals, each with a single metric and a baseline. Visible to everyone in the department. |
| Team (squad) | Squad lead or PM, approved by the department head | The part of the department metric this squad can move directly | One outcome goal, plus one to three delivery goals for committed epics. The whole squad shares it. |
| Individual | Employee, agreed with their manager | Each person's contribution to the squad goal, plus their own development | Two to four goals: at least one linked to the squad goal, one development goal tied to a skill gap. |
Top-down communication works best when it is short and repeated: the VP Product presents the department goal and why it matters, each squad drafts its own goal and proposes the target, and the department head approves the set. Squads then draft individual goals with each team member in their next 1:1. Recommendation: allow about two weeks from the company goal to individual goals being agreed, so goals are live early in the quarter rather than half-way through it.
The worked example: VP Product to five squads
Squad 1: Onboarding
Outcome goal: day-7 retention of new users from 41% to 47%.
- Delivery goal: “New onboarding flow” epic (Jira-linked)
- Delivery goal: “Account setup checklist” epic (Jira-linked)
Squad 2: Core experience
Outcome goal: users completing the core action 3+ times in their first week from 30% to 36%.
- Delivery goal: “Faster core flow” epic
- Delivery goal: “Empty-state redesign” epic
Squad 3: Lifecycle
Outcome goal: users inactive for 3+ days who return within 7 days from 18% to 22%.
- Delivery goal: “Re-engagement messaging v2” epic
Squad 4: Reliability
Outcome goal: crash-free sessions from 99.2% to 99.7%, cold start under 2 seconds.
- Delivery goal: “Crash top-10 fixes” epic
- Delivery goal: “Startup performance” epic
Squad 5: Personalisation
Outcome goal: new users who set up a personalised feature in week 1 from 12% to 20%.
- Delivery goal: “Personalised home” epic
VP Product (department)
Goal: 30-day retention of new users from 24% to 28%. Progress is read from the product analytics source, and the five squad goals roll up underneath it so the VP can see which squad is behind.
Why this shape works: each squad has a metric it can move within a quarter (day-7 retention moves faster than day-30), every squad metric plausibly drives the department metric, and the delivery goals show whether the planned work is actually shipping. If a squad hits its delivery goals but not its outcome goal, the bet was wrong, which is useful information, not a performance failure.
How individual goals link (Squad 1)
| Role | Goal linked to the squad goal | Other goal | What the review also looks at |
|---|---|---|---|
| Product manager | Owns the squad outcome goal (day-7 retention 41% → 47%) | Run 8 customer interviews on drop-off and publish findings | Discovery, prioritisation and stakeholder skills on the PM matrix |
| Product designer | Deliver the onboarding redesign, validated in usability tests before build (linked to the epic) | Development goal: prototyping and validation (a skill gap from the last review) | Craft and outcome focus on the designer matrix; see scorecards for subjective roles |
| Analyst | Ship a cohort retention dashboard and read out every onboarding experiment within 5 working days | Automate the weekly retention report | Accuracy, speed and influence of the analysis |
| Developers | Deliver their share of the “New onboarding flow” epic (Jira-linked) | Quality goal, for example no critical escaped bugs and bug fixes within the team's agreed time | Deliverables (speed, quality, complexity), skills for their level, culture |
Team goal or individual goal? The outcome goal is mainly a team goal: the whole squad shares it, and nobody should be marked down because an experiment didn't move retention. Individual performance is assessed on the three lenses in the framework: deliverables (did they deliver their work on time, at the right quality, on hard problems, including bug fixes), skills against the bar for their level, and culture. The squad goal gives context; the individual's delivery goals and evidence decide the review.
Cascading goals into reviews? See what your review cycle costs today, or walk through your own goal tree on a 15-minute discovery call.
Goal vs roadmap: when to use each
A goal
The outcome you want to change, with a metric, a baseline, a target and a date. “Day-7 retention 41% → 47% by end of Q2.” The team chooses how to get there.
A roadmap
The ordered plan of work (epics, features, dates) you are betting will move the goal. “New onboarding flow in May, setup checklist in June.” It changes as you learn.
| Use… | When… | Example |
|---|---|---|
| An outcome goal | You can measure the result and want the team free to choose the solution | Retention, conversion, CSAT, revenue |
| A delivery goal linked to a roadmap item | The commitment is the work itself: a contractual, regulatory or dependency deadline, or a platform piece others are waiting on | “Ship the payments migration epic by 30 June” |
| Both together | Most product squads: the outcome goal is the parent, the roadmap items are child delivery goals | Squad 1 above |
| The roadmap only (no goal) | Small, routine work that isn't a bet on an outcome | Minor UI fixes, library upgrades; track in Jira, not as goals |
Rule of thumb: the parent goal should be an outcome, and roadmap items should sit underneath it as delivery goals. If a squad only has delivery goals, it can hit all of them and still not move the metric; if it only has an outcome goal, nobody can see whether the planned work is shipping.
Jira epic-linked goals
In Revolut People a goal can take its progress straight from Jira, so engineers don't update goals by hand:
- Create the goal (for example “Deliver the new onboarding flow”) and choose Jira as the metric type.
- Paste the epic link.
- Progress is calculated automatically from the epic's child issues: if 3 of 8 child issues are done, the goal shows 38%.
- Progress syncs daily, and a Refresh button updates it on demand, for example just before a 1:1 or a review.
RecommendationMake the squad's outcome metric the parent goal and link one goal per committed epic underneath it. Keep epics well-structured (child issues that represent real chunks of work), because the percentage is only as meaningful as the issue breakdown: an epic with one giant ticket will sit at 0% until it jumps to 100%. Revolut People also integrates with other execution tools such as Salesforce and Looker, so sales and analytics goals can update the same way. See Revolut People performance management.
Handling mid-quarter priority changes
Priorities will change mid-quarter. The aim is that goals change with them, openly, rather than dead goals lingering until the review. RecommendationA simple rule set:
- Decide explicitly: keep, re-scope, replace or drop. Don't leave the old goal untouched “just in case”.
- Yes, add the new goal mid-cycle, with a target that fits the time left. Drop or archive the goal it replaces, with a one-line reason and the date, so the history is visible in the review.
- Cascade the change both ways. If the VP Product changes the department goal, each squad goal and its individual goals must be checked within a week.
- Assess against goals as they stood after the change. Nobody should be marked down for work that was deliberately stopped.
- Set a cut-off. New goals in the last two to three weeks of a quarter usually belong in the next quarter.
- Watch the pattern. If a squad's goals change every few weeks, the problem is planning, not goal-setting.
Revolut People Goals can keep company, team and individual goals lined up when plans change; the important part is the rule set above, which works in any tool.
Example goals for Sales, Customer Success and HR
Illustrative targets. Set your own from your baseline.
| Team | Department / team goal | Individual goal examples |
|---|---|---|
| Sales | New ARR of £X this quarter; pipeline coverage of 3x next quarter's target by week 8 | AE: 100% of quarterly quota (CRM-linked); every open opportunity has a dated next step; development goal on discovery and qualification |
| Customer Success | Gross revenue retention of X% for the book of business; onboarding completed within 30 days for new accounts | CSM: renewal of all accounts due this quarter; documented success plan for each top-20 account; reduce time-to-first-value for new accounts |
| Customer Support | First-response time and CSAT targets by channel | Agent: quality score on reviewed tickets; resolution within SLA; one knowledge-base article per month from repeat tickets |
| HR / People | 100% of teams with agreed goals by week 2 of the quarter; review cycle closed on schedule | People partner: goal coverage for their departments; calibration prepared on time; manager training delivered to new managers |
Why track sales goals in a performance platform when you can see everything in Salesforce? Salesforce shows the outcome. It can't tell you whether a flat pipeline comes from a skill gap, a capacity gap or a team that is burning out, and it doesn't feed the review. Linking the CRM number to a goal puts it next to skills and engagement for the same people. Try the team performance diagnostic to see the logic.
Related: OKR and review alignment for engineering teams · goals that don't cascade · rollout and adoption checklist.
FAQ
Should every product squad have its own goal?
Yes, one outcome goal per squad that it can influence directly, linked to the department goal. Add one to three delivery goals for the epics the squad has committed to. More than that and the goal list becomes a second backlog.
Is a goal the same as a roadmap item?
No. A goal is the outcome you want to change, measured by a metric. A roadmap item is a piece of work you bet will change it. Track the outcome as the parent goal and the work as delivery goals linked to epics.
How does a Jira epic-linked goal calculate progress?
In Revolut People you choose Jira as the goal's metric type and paste the epic link. Progress is calculated from the epic's child issues: 3 of 8 done shows 38%. It syncs daily, and a Refresh button updates it on demand.
Can we add a goal mid-quarter?
Yes, and you should when priorities genuinely change, rather than leaving a dead goal in place. Record the date and the reason, agree it between manager and employee, and assess the person against the goals as they stood after the change.
How do we judge an engineer if the squad goal is shared?
Use the squad goal for shared context, not as the only measure. Individual reviews look at deliverables (speed, quality and complexity of their work, including bug fixes), skills against the bar for their level, and culture. Their delivery goals linked to Jira epics provide the evidence.
Why track sales goals outside Salesforce?
Salesforce shows the outcome, for example a flat pipeline. It does not show whether the cause is skills, capacity or engagement, and it does not feed reviews. Linking the CRM number to a goal puts the outcome next to skills and engagement data for the same people. See the team performance diagnostic.