Legibility, Actionability, Authenticity
Three tests any goal must pass, regardless of whether you call it an OKR.
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 94%
After deprecating OKRs at Figma, reinstating them, and then renaming them 'commitments,' Yamashita concluded that the label does not matter — three properties do. A goal must be legible (anyone can look at it and understand what it means), actionable (reading it makes you want to do something differently), and authentic (it honestly depicts what the team is actually doing day to day). The framework exists because both standard OKR failure modes are traps: a metric you can move but nobody cares about, or a metric everyone cares about but you cannot prove you moved.
Origin
Yamashita's own multi-year experiment cycle at Figma. He spent most of his career on core experiences, where OKRs were 'the bane of my existence.' He deprecated them in year one in favor of headlines and report-card self-scoring; a head of data (a former Uber colleague) reinstated them with more rigor; they were then rebranded 'commitments.' He is explicit that Figma has not cracked it.
Core principles
- 01The name of the goal artifact matters far less than its properties.
- 02Two failure modes bracket every goal: measurable but meaningless, or meaningful but unmovable.
- 03If an engineer stopped in the hallway cannot state the team's goal, the goal is a post-rationalization.
- 04Start from what you are optimizing for; figure out how to measure it second.
- 05Qualitative scoring you can defend beats a quantitative metric nobody believes.
How to run it
- 1
Get the headline first, before any metric
Ask each team what they are trying to do philosophically, with an explicit instruction not to stress about whether it can be measured. Debate and agree on that before touching measurement.
Watch out Leading with metrics produces goals reverse-engineered from what is measurable, not from what matters.
- 2
Then attach measurement — qualitative allowed
Once the headline is agreed, discuss how it could be measured. Some of it will be quantitative, some qualitative, and that is acceptable.
Pro tip A report-card approach works: have the team give itself a score and explain how it derived that score. The inputs can get more sophisticated over time.
- 3
Test for legibility
Can anyone look at the goal and immediately understand what it is? If it's an obfuscated metric that means nothing to anyone outside the team, it fails.
- 4
Test for actionability
Does reading the goal inspire action — does it make someone want to do something differently? A goal that changes no behavior is decoration.
- 5
Test for authenticity
Does the goal honestly depict what the team is actually doing day to day? If the team is working on a project and the goal is a post-rationalization stapled to it, the goal has no value.
Pro tip The hallway test: stop an engineer and ask what the team's biggest goal is. If they answer with a project name instead, the goal failed authenticity.
Watch out This is the failure that survived Figma's rigor upgrade — the metrics got better, but commitment to moving them did not.
In the wild
As PM for the rider experience at Uber, the ambitious goal would be to contribute incremental trips — the experience gets so good that more people come back. But that metric has many hops between the work and the outcome and is not under the PM's control, so by the time you get there you cannot prove you moved it. The alternative is a secondary metric like a satisfaction survey score that you can move but have never shown correlates with retention or anything that matters to the business.
→ Yamashita names this as the structural bind: 'either you incred something that like matters but you can't move or you make it something that you just move it doesn't actually matter' — which is why he shifted to headline-first goal setting.
In his first year, Yamashita killed Figma's OKRs — the spreadsheet review meetings were dreadful and nobody could tell what teams actually cared about — replacing them with headlines and self-scored report cards. A newly hired head of data judged that too subjective and risky, so OKRs came back with real data-science rigor. Then they tried calling them 'commitments' to get people to take them more seriously.
→ Each iteration fixed a different problem and exposed a new one; Yamashita concluded the label is not the variable and distilled the three properties instead — while openly stating Figma still hasn't cracked the code.
Common mistakes
Running goals as a task list
Teams treated OKRs as a to-do list to complete by end of quarter, then felt they had done their job. The dreadful spreadsheet review meetings that followed revealed nothing about what teams actually cared about.
Post-rationalized OKRs
Writing goals that describe the projects you were going to do anyway, then crossing your fingers at quarter end, produces goals nobody thinks about daily — which defeats the entire point of publishing them.
Believing a rename fixes it
Yamashita openly admits people pushed back that 'commitments' were just OKRs with a different name. Terminology changes do not create commitment; the three properties do.
Is it for you?
Best for
Product and engineering leaders whose OKR process has become a quarterly ritual that nobody references between planning meetings.
Not ideal for
Sales or growth orgs with a genuinely clean, controllable, high-signal top-line metric — there, standard OKRs work fine.
From the transcript
“some secondary metric that nobody actually cares about right that technically you can measure and technically you can move but like you haven't actually proven…”
“either you incred something that like matters but you can't move or you make it something that you just move it doesn't actually matter”
“I just want to understand like your headline like what are you trying to do like philosophically and just like don't stress about whether you…”
“I think like actionability like I want an OTR to inspire action”
“and then the third one is authenticity which is like does this actually honestly depict what you're doing or what you're trying to do on…”
From the episode
An inside look at how Figma builds product
Yuhki Yamashita (CPO of Figma)