I used to advocate for OKRs for individuals, not just teams. I believed in setting OKRs for everyone. However, I’ve changed my mind, particularly when it comes to cascaded OKRs. You can still set goals for individuals in an OKR-like format (more on that later), but I avoid including individuals as part of the regular OKR process.

The power of OKRs is their ability to link and cascade through the organization, providing everyone with an understanding of how they contribute to the overarching strategy.

In cascading OKRs, it might seem appealing to apply them to individuals as well. It seems like a good way to describe how everyone will contribute to the strategy. However, I’ve come to believe that this cascading should stop at the team level.

A well-crafted OKR describes and measures an outcome, but it can be challenging to create an outcome-focused OKR for an individual. A single person typically can’t generate an outcome independently - outcomes are the result of team efforts. Individual OKRs tend to become output measures. It’s straightforward to gauge an outcome, but surprisingly difficult to objectively assess an output. You can measure that it happened, but measuring how well it was done is subjective.

So, you might end up with a series of "ship this" and "write that" OKRs. It’s tough to naturally link milestones and tasks to outcome-based OKRs.

Furthermore, when an individual has OKRs, it’s tempting to utilize them for performance management. After all, you have a list of things they are supposed to accomplish, so why not evaluate their performance based on whether they accomplished those things? Meeting their OKRs (or not) starts influencing their bonus, salary, or even employment.

This approach undermines one of the key strengths of OKRs: stretch goals.

Stretch goals are magic. If you assign a person a reachable task, they’ll usually accomplish it. If you’re new to running and set a goal to run a mile by the end of the month, you’ll likely do it. That’s an achievable target. But if you set a goal to run five miles, you probably won’t make it. But you’ll run more than one mile. By setting a goal just beyond reach, you’ll progress further than if you simply tried and stopped.

Yet once you start using goals for performance management, you’ve changed the incentives. Achieving and surpassing a goal brings status and monetary rewards like promotions and bonuses. Consequently, people craft goals that are easily attainable, ones they can consistently surpass. They play it safe.

Using OKRs for performance ratings can actually diminish performance. It creates a disincentive for individuals to push themselves.

This is not to suggest that individuals shouldn’t have goals. Everyone should have personal improvement objectives or major initiatives that they’re leading. These typically take the form of milestones or tasks. They might include "learn Javascript" or "deliver higher quality proposals," with KRs describing how these will be evaluated.

But these are not cascades from the overall corporate goals. They’re standard personal goals, simply structured in the format of an OKR. If your company is struggling with OKRs, expressing these goals as OKRs might add confusion. However, if your company is successfully using OKRs, presenting personal goals in an OKR format can enhance understanding.

I’ve helped lots of teams implement OKRs or fix a broken OKR process. Here are the 10 most common problems I see, and what to do instead.

1. Including routine work in OKRs

You shouldn’t put every task and workstream into an OKR. Things you’d do anyway in the normal course of business don’t need to be objectives.

An objective should leap the business forward. These are the “big rocks” discussed in strategy sessions or the things your boss’s boss’s boss cares about.

2. Putting metrics directly into objectives

Your objective shouldn’t be a number. Objectives should be aspirational. When an objective includes a number, the KRs become tasks instead of measurements.

Pick an objective specific enough to measure but avoid making it a measurement itself.

3. Using output as objectives

Teams love putting their upcoming release, feature, or announcement as an objective. But your real goal isn’t shipping something—it’s the impact of what you ship. When you use a release as an objective, you end up with milestone-based KRs instead of measurable outcomes.

Instead of making the feature the objective, think about why you’re building it. What value are you creating? Start there. Your KRs then measure the outcomes you’re aiming for.

4. Writing Key Results as tasks or milestones

If your KR is measured by “did we do it or not?” then it’s not effective. It won’t stretch your team, and others won’t understand your goals clearly. Avoid yes/no KRs; they’re missed far more often than those with numbers attached.

A good KR measures the outcome of your work, not the activity itself. Clearly tie KRs to measurable outcomes.

5. Setting goals your team can’t realistically influence

It’s tempting to set business-level OKRs, but you shouldn’t create goals beyond your control. For example, a small product team shouldn’t set an objective like “Grow product X by $10M in revenue,” because external factors — like market downturns, sales priorities, or competitors — can derail it.

Instead, set OKRs focused on what you can directly influence. Figure out how you’ll contribute to the larger goal and make that your OKR.

6. Relying on long-term objectives without checkpoints

Keep your objectives short. Long-term objectives rarely work. Teams lose sight, priorities shift, or the goal becomes irrelevant—yet teams continue pushing because of inertia.

Stick to quarterly objectives. This length is long enough to achieve something meaningful but short enough to pivot if needed. If larger initiatives span multiple quarters, set quarterly OKRs to move them forward incrementally.

7. Playing it safe with easily achievable Key Results

If your KR is easy, it won’t help you grow. Teams achieve more with ambitious goals. Don’t sandbag by setting easy targets.

Instead, stretch yourself when defining KRs. If you’re confident you can get five customers to try a new feature, set your KR to seven. Even if you don’t always hit the stretch goal, you’ll achieve more than you would otherwise.

Bonus tip: This is why you don’t use OKRs to measure performance. People will sandbag and you won’t get the benefits of stretch goals. “When a measure becomes a target, it ceases to be a good measure.” - Goodhart’s Law

8. Including internal outcomes

Instead of internal metrics, measure external impact. Improving uptime might seem like a good goal, but internal metrics like “uptime” or “release frequency” limit creative solutions.

Make your KRs about the impact on customers or users to encourage better solutions. Can you measure your objectives from a customer perspective? Instead of “reduce outage duration by 30%,” use “reduce customer complaints about outages by 30%.” This keeps your focus on real-world outcomes.

Even internal teams support external results. Always ask: Who consumes your work, and how is their life improved?

9. Leaving out quality measures

Every goal-setting method can be gamed. A KR of “five new logos” isn’t helpful if four churn immediately. “Fill 65% of open roles” can be manipulated by lowering standards.

Prevent gaming by explicitly adding quality metrics. Think of these as anti-KRs — what scenario would undermine your intent? State quality explicitly, such as “Add five new logos without increasing churn.”

10. Rolling out OKRs to the whole company at once

Rolling out OKRs to dozens of teams at once fails. No one knows what success looks like, leading to frustration and abandonment.

Instead, start with one team. Use their success as an example for others. Christina Wodtke recommends starting with a high-performing team, as they’re more likely to get it right and set a positive example. Others suggest beginning at the executive level, defining corporate-level OKRs first.

Getting OKRs right takes practice

OKRs are simple, but using them effectively takes practice and discipline. Avoiding these common traps will help your teams get more from the framework. When done right, OKRs align your teams, clarify priorities, and drive measurable results. Start small, keep your goals ambitious, and always measure outcomes.

Success in the era of AI means being good at things AI can’t do. Not because AI is going to take those jobs, but because if you can do it with AI, so can everyone else. So you need to be good at things that more or faster knowledge doesn’t solve. A common theme from AI founders, influencers, and academics about what skill to develop is “taste.” I’ve been hearing that word everywhere, from education trade magazines to career podcasts.

Taste is subjective, but it’s really the ability to pick the best option from a group and do it more often than others. Having more or faster knowledge doesn’t do this for you, so AI can’t do it. All the smarts in the world won’t tell you if putting off repairs will result in your car breaking down, if a new cereal flavor will be a hit, or if your product feature will attract higher‑paying customers.

But even with perfect information, outcomes remain uncertain. That uncertainty makes taste valuable. More precisely, it comes down to navigating trade‑offs.

This means being able to consistently choose the best imperfect alternative. To make the most effective use of scarce resources like time and money. To have intuition about how upsides and downsides will balance out.

Want to thrive in an AI world? Get very good at navigating trade‑offs.

What companies call their top product hire is a big clue to the company stage, the role’s scope, and the relationship with the CEO or founders. Here’s a decoder for what you’re getting into for different head of product titles.

Director of Product / Product Manager: Often the first product hire. Regardless of title, the role is an IC to execute the founder’s vision. They triage bugs, prioritize for engineers, and handle inbound feature requests. Product vision and strategy remains with the founder. This role often fails due to mismatched expectations.

Head of Product: Somewhere on the spectrum between a Director of Product and a VP of Product. This role might be exactly how I describe the Director role, might be really a VP role. Often is a blend of both. Sometimes used when the company is unsure of which title to give because they think they can’t get the right people using a Director title and aren’t ready to hand out VP titles.

VP of Product: Owns and scales the product. There’s one dominant prroduct that has product-market-fit, and perhaps a second smaller product, add on, or incubating product idea. The company vision is the same as the product vision, so the CEO is setting the broad vision overall. The VP of Product handles TAM expansion, processes, hiring, and detailed product strategy. The founder or CEO does oversight to keep the product aligned with their vision and runs any big transformational bets.

CPO: Focuses on scaling the product function and creating the conditions for product success. Not a lot of direct product work, the CPO isn’t building products. The CPO defines the broad portfolio strategy: which markets to enter and where to invest. They set up methods for measuring and improving the product organization and make sure it’s well aligned with the company goals.

TL;DR: The top product hire’s scope by title

• Director: Tactical work to execute founder’s vision
• Head Of: maybe Director, maybe VP
• VP: owns the product in a single-product company
• CPO: Doesn’t build product; functional exec creating conditions for product success

Seth Godin explains the difference between a brand and a logo by saying that if you heard Nike was going to open a hotel, you could instantly imagine exactly what that hotel would be like. That’s a brand. Nike has a distinct point of view that shapes how it presents itself to the world. This point of view is so strong and consistent that you can easily extend it to a hypothetical hotel.

This concept is very similar to how you should think about company culture.

Your culture is the framework that helps people understand how they should act, even in situations they haven’t encountered before. It must be rooted in a strong point of view. This is why you can’t simply adopt another company’s corporate values as your own. Those values are shaped by a unique perspective that doesn’t necessarily align with yours.

Your culture, then, is the combination of your organization’s point of view about how to behave and the actions your employees take to embody that perspective.

Designing processes can be tricky. Often, people create individual processes to solve specific problems. Running around plugging holes might feel effective in the moment, this piecemeal approach is counter productive.

When you focus only on individual problems, you risk creating a heavy and cumbersome process. Over time, these processes can feel authoritarian and arbitrary, leading to frustration and disengagement among your team. Instead, it’s crucial to adopt a systems thinking perspective.

Systems thinking helps solve complex problems by looking at how the components of a system interrelates. The systems thinker evaluates actions in context of all the other actions, activities that take place. To apply systems thinking to your policy creation instead of focusing on isolated incidents, consider the overall problems facing your business. Ask yourself:

• What outcomes are we trying to achieve?
• How can we create those outcomes effectively?
• What else will happen if we implement this policy?

By shifting your focus to the larger issues at hand, you can design processes that are not only efficient but also aligned with your business goals.

Evaluate the underlying causes of problems rather than just treating the symptoms. This way, you can create policies that genuinely add value and support your team, rather than constraining them.