Guides / Ideas and launching

How to Set OKRs for a Startup (with Examples)

A simple OKR process for small teams: write objectives and measurable key results, set a quarterly rhythm, run weekly check-ins and avoid common mistakes.

Mythex Team · 2026-09-29 · 5 min read

To set OKRs for a startup, pick one to three objectives for the quarter — short, qualitative statements of what matters most — and give each two to four key results: measurable outcomes, with a starting value and a target, that prove the objective was met. Review progress in a short weekly check-in, score honestly at the end of the quarter, and use what you learn to set the next set.

OKRs (Objectives and Key Results) are a goal-setting method associated with Intel and later popularised in the tech industry. For a startup, their main value is simple: they force a small team to agree on what matters this quarter, and what doesn't.

When OKRs help, and when they don't

OKRs help when:

• The team is big enough that people might pull in different directions.
• There are more good ideas than time, and you need a way to say no.
• You have a working product and want to improve specific outcomes, such as activation or retention.

They help less when:

• You're still searching for the problem to solve. Before validation, goals change weekly; a simple list of experiments works better.
• It's just you and the whole plan fits in your head. A single objective on a sticky note may be enough.
• They become paperwork. If updating OKRs takes longer than the work, cut back.

The anatomy of a good OKR

Objective: what you want to achieve, in words. It should be meaningful, specific enough to guide choices, and time-bound (usually a quarter).

Key results: how you'll know you achieved it. Each should be:

• Measurable — a number with a baseline and a target.
• An outcome, not a task — "activation rate from X% to Y%", not "build an onboarding checklist".
• Within reasonable influence of the team.
• Checkable — you know where the data comes from.

Initiatives (tasks, projects) sit underneath. They're your bets on how to move the key results, and you should feel free to change them mid-quarter.

Use your own real baselines. If you don't have one yet, the first key result might be to measure it.

Step 1: Start from the company's biggest question

Before writing anything, answer: what is the most important thing to change this quarter? For an early startup it's usually one of these:

Your go-to-market plan and the metrics in SaaS metrics explained are good inputs here.

Step 2: Write one to three objectives

Draft objectives together as a team if there is one. Good objectives:

• Fit in a sentence and are easy to remember.
• Describe a change, not business as usual.
• Would make a real difference if achieved.

Weak: "Improve marketing." Better: "Find one channel that reliably brings in trial users."

Step 3: Write key results for each

For each objective, ask: "If this were true at the end of the quarter, how would we know?" Write two to four answers as numbers.

A quick test for each key result:

• Could someone outside the team check it?
• Is there a baseline and a target?
• Is it an outcome rather than an activity?
• Would hitting it really mean the objective was met?
• Can it be gamed in a harmful way? If so, pair it with a counter-metric.

Pairing example (made up): a key result to increase trial sign-ups could be gamed by attracting the wrong people, so pair it with a key result on the share of trials that activate.

Committed vs aspirational

Some teams label key results:

• Committed — you expect to hit them fully; missing is a problem to discuss.
• Aspirational — stretch goals; hitting most of the way is a good result.

Say which is which up front so a partial result isn't misread later.

Step 4: Set a rhythm

A light cadence for a small team:

The weekly check-in can be three questions per key result: where is it now, how confident are we of hitting it, and what's blocking it?

Step 5: Score and learn

At the end of the quarter, score each key result. A common approach is 0.0 to 1.0, or simply a percentage of the target reached. Then write a few sentences on each objective:

• What moved the numbers, and what didn't?
• Were the key results the right measures?
• What will we do differently next quarter?

The lessons matter more than the scores.

A full example for a small SaaS (made up)

A two-person team has launched a booking tool for independent tutors. Sign-ups are coming in, but many never set up availability.

Objective 1: New tutors are ready to take bookings in their first session.

• KR1: Share of new tutors who publish availability within 24 hours: from [baseline] to [target].
• KR2: Share of new tutors receiving a first booking within 14 days: from [baseline] to [target].
• KR3: Hold at least eight onboarding calls and log the findings.

Objective 2: Learn which channel brings tutors who stay.

• KR1: Track source for every sign-up (currently not tracked).
• KR2: Run three channel experiments with a written result for each.
• KR3: Identify one channel whose sign-ups activate at or above the overall average.

Notice KR3 in Objective 1 is closer to an activity. That's acceptable when the goal is learning, but most key results should be outcomes.

OKR template

Copy this into a doc or spreadsheet:

Common mistakes

• Too many OKRs. If everything is a priority, nothing is.
• Task lists dressed as key results. "Launch feature X" says nothing about whether it worked.
• No baseline. Without a starting point, targets are guesses.
• Set and forget. OKRs untouched until the end of the quarter are just a wish list.
• Tying them to pay. People start setting targets they know they can hit.
• Copying another company's process. A five-person team doesn't need a large company's cascading goal system.

Tracking OKRs with Mythex

A spreadsheet or doc is enough for most small teams. If you want something more tailored — a simple internal page where each owner updates their key result weekly and the team sees progress at a glance — you could describe it to an AI app builder like Mythex and have a working internal tool with a database behind it. How to build an internal tool and how to build a dashboard cover that approach. Either way, the tool matters far less than the weekly habit of looking at the numbers together.