Setting a goal is easy. Knowing exactly what to do tomorrow morning to get there is the hard part.
That's the gap process goals fill. Most goal-setting advice focuses on outcomes — the number you want to hit, the milestone you want to reach. Process goals flip the script. Instead of asking what do I want to achieve?, they ask what do I need to do consistently to get there?
If that sounds obvious, you'd be surprised how rarely teams actually build process goals into their planning. They set outcome targets, declare the work planned, and then wonder why nothing happens.
This article explains what process goals are, how they differ from outcome goals, and how to use them in a business context, including how they connect to OKRs.
What are process goals?
A process goal is a goal focused on a specific behaviour or action you can control, rather than a result you're aiming for. It defines what you'll do, not what you'll get.
The simplest way to think about it: a process goal is a commitment to an input.
If your outcome goal is to increase customer retention by 10%, a process goal might be "conduct 20 customer interviews this quarter." You control the interviews. You don't control the retention rate directly.
The concept comes originally from sports psychology, where coaches found that athletes who focused on their technique and training habits performed more consistently than those who obsessed over scoreboards. The same logic applies to teams and organisations.
Process goals sit alongside outcome goals, performance goals, and a handful of others. If you want to see the full landscape, types of goals covers all the major categories with examples.
Process goals vs outcome goals
Most goal-setting frameworks distinguish between two types of goals:
Outcome goals define a result: revenue target, number of new customers, market share percentage. They're motivating, but they're lagging indicators. By the time you know you've missed, it's often too late to fix the underlying behaviour.
Process goals define actions: number of calls made, articles published, customer check-ins completed. They're leading indicators. You know within a week whether you're on track, not at the end of the quarter.
Some frameworks add a third category, performance goals, which sit in between. A performance goal might be "write a proposal that scores above 80/100", where you control the quality but not whether the client says yes.
For business teams, the most useful distinction is usually just process vs outcome. Outcome goals tell you what to measure, and process goals tell you what to do. Both are necessary. The pair is what makes a goal system actually work.
Process goals vs outcome goals: examples
Here's what the difference looks like across common business functions. In each pair, the outcome goal definesthe result the team is aiming for — the process goal defines the specific, repeatable action most likely to getthem there.
Why teams struggle when they only track outcomes
Here's a common pattern: a leadership team sets quarterly OKRs, the team feels motivated at kickoff, and by week six nothing has moved.
The problem usually isn't that the goals were wrong. It's that no one defined the specific actions required to achieve them. The outcome was clear. The process was fuzzy.
This is particularly common in knowledge work, where the path from effort to result is indirect. A sales team can count calls made. A content team can count articles published. But a strategy team working on market entry? The inputs are less obvious, and without process goals, it's easy to stay busy without making progress.
The fix isn't more tracking or stricter reporting. It's getting specific about what consistent, controllable behaviour looks like.
When you don't have a clear outcome yet
Not every process goal starts with a key result. Sometimes the most useful thing a team can do is commit to a set of actions before they've figured out what to measure.
This comes up most often at the start of a new initiative — a market the team hasn't entered before, a product bet with no historical data, a channel no one's tested. In these situations, demanding a precise outcome goal before any work begins can actually slow you down. You're being asked to define success before you have enough information to know what success looks like.
A process goal solves this. Commit to running 20 customer conversations this month. Ship a rough version of the feature to five users. Post three times a week on a new channel. These actions generate signal. Once you have that signal, you can set a meaningful outcome goal — one grounded in real data rather than a number someone invented in a planning meeting.
This is why process goals and OKRs work well together even in ambiguous situations. If you can't write a good key result yet, write a process goal instead. Treat it as the exploratory phase of the same cycle. The outcome goal comes once you know enough to write one worth tracking.
Examples of process goals in a business context
For a sales team:
- Make 50 outbound calls per week per rep
- Send personalised follow-up within 24 hours of each demo
- Complete product training for two new features each month
For a content team:
- Publish two long-form articles per week
- Respond to reader questions within 48 hours
- Review competitors' content each fortnight to identify gaps
For a customer success team:
- Schedule a quarterly business review with every Enterprise account
- Log a check-in note within 24 hours of every customer call
- Send product update summaries to at-risk accounts monthly
For an individual contributor:
- Block two hours of deep work each morning
- Share a weekly update in the team channel every Friday
- Complete one training module per fortnight
Notice what these have in common: they're specific, they're frequent, and you can tick them off without waiting for results. You know if you did them or not.
How to set effective process goals
A good process goal has three properties:
1. It's within your control. "Close five deals" is not a process goal. "Make 30 outbound calls" is. If the outcome depends on someone else's decision, it's not a process goal.
2. It's measurable. "Have more customer conversations" is vague. "Run four customer interviews this week" is measurable. You need to be able to clearly determine whether you did it or not.
3. It connects to an outcome you care about. Process goals without an outcome anchor become checkbox exercises. If you can't explain how doing this thing consistently gets you closer to your outcome goal, reconsider the process goal.
A useful test: can you explain to a team member in one sentence how doing this process goal, consistently, gets you closer to your outcome goal? If yes, you have a solid process goal.
Process goals and OKRs: how they work together
If you use OKRs, you already have outcome goals: those are your key results. Process goals fit naturally as the action layer beneath them.
Think of it this way: key results define the what, and process goals define the how. For each key result, you can ask: "What are the two or three things we need to do consistently this quarter to move this number?"
The answers become your process goals. In Tability, teams often track these as check-in notes or as part of their initiative updates, keeping the process visible alongside the outcome so the team can see whether the inputs are actually happening.
This matters more than most teams realise. A key result that's not moving is often a process problem, not a people problem. When you make process goals explicit, diagnosis gets much easier: did we do the thing or not? If yes, and the metric still isn't moving, you have an assumption to revisit. If no, you know exactly where the gap is.
For teams serious about building a strong goal setting framework, process goals are the missing layer most frameworks skip. And if you're looking for concrete examples of the outcome goals that process goals support, business goals examples gives you 30+ across functions.
.png)
.jpg)
