Quality-Check Existing OKRs
Audits a set of draft OKRs for measurability, ambition, and cascade alignment. Built for PMs reviewing team OKRs before commit or as a mid-quarter health check.
When to use this prompt
Use this when a team has drafted OKRs and you want a structured quality review before committing them. You will need the draft OKRs and the parent company or org OKRs. The prompt runs 5 quality checks and produces specific rewrites for anything that fails. It works well as a PM manager audit of a direct report's draft, or as a peer review exercise across multiple teams. It is deliberately strict because loose OKRs at commit time guarantee vague outcomes. The prompt will call out OKRs that look polished but lack substance.
The Prompt
You are an experienced product operations lead reviewing a set of draft OKRs for quality. Run 5 quality checks and produce specific rewrites for any OKR that fails. Draft OKRs: {{draft_okrs}} Parent OKRs (company or org level): {{parent_okrs}} Team context: {{team_context}} Run the following 5 checks: CHECK 1: MEASURABLE â Every KR has a numeric baseline, numeric target, and deadline. Fail any KR that lacks even one of these. Rewrite failures to include all three. CHECK 2: STRETCH â The KR target represents a meaningful stretch (estimated 60-70 percent probability of hitting). Fail KRs that are obvious (business as usual) or impossible (no realistic path). Rewrite failures with a more appropriate target. CHECK 3: OUTCOME â The KR measures an outcome, not an activity. "Ship feature X" fails; "50 percent adoption of feature X" passes. Rewrite activity KRs as outcome KRs. CHECK 4: LADDER-UP â Each objective connects explicitly to a parent OKR. Fail objectives that do not ladder up; either the team is working on the wrong thing, or the parent OKR is wrong, or the connection is not documented. CHECK 5: OWNERSHIP â Each KR has a named human owner (not "the team"). Fail KRs without a clear owner. Output format: For each objective: - Objective title - Summary pass/fail for this objective - For each KR, run all 5 checks and mark each check PASS or FAIL with a 1-line reason - Produce a rewritten version of any KR that failed any check At the end, produce: OVERALL QUALITY SCORE â Simple count of KRs that passed all 5 checks out of total KRs. For example: 7 of 12 KRs passed all checks. TOP RECOMMENDATIONS â The 3 most important changes to make before commit. Prioritize by impact on team focus. Be direct. Vague praise of weak OKRs is the opposite of helpful.
Example Output
OBJECTIVE 1: Make the invoices dashboard the trusted source of truth. Overall: PARTIAL. KR 1.1: "Ship overdue sort feature" - Measurable: FAIL (no number, just activity) - Stretch: N/A - Outcome: FAIL (activity, not outcome) - Ladder-up: PASS - Ownership: FAIL (no owner named) Rewrite: Reduce spreadsheet-export events by billing admins from 1200 to 400 per week by end of quarter. Owner: Priya. KR 1.2: "Improve trust" - Measurable: FAIL (no metric, no baseline) - Outcome: PASS (trust is an outcome if measured) Rewrite: Increase NPS for billing admins from 32 to 50 by end of quarter. Owner: Marco. KR 1.3: "Reduce median days-to-collection from 18 to 12 in active accounts." - Measurable: PASS - Stretch: PASS - Outcome: PASS - Ladder-up: PASS - Ownership: FAIL (no owner) Rewrite: Same, with owner Dan. OVERALL QUALITY SCORE: 0 of 3 KRs passed all checks before rewrite. After rewrite, all 3 pass. TOP RECOMMENDATIONS 1. Every KR needs a named owner. Missing owners is the most common failure across this draft. 2. KR 1.1 and 1.2 are activity-focused; rewriting them as outcomes sharpens the whole objective. 3. Confirm ladder-up to company OKR "Improve gross retention" is documented in the team charter.
Recommended Tools
Notion and Coda support inline OKR comments and can host the quality-check results as a live review document. Airtable works when quality checks run across multiple teams and you want to track common failure patterns. Use Notion or Coda for single-team reviews, Airtable when you are running a quarterly OKR audit for an entire org.
Frequently Asked Questions
When should I use this prompt?
Use it at OKR commit time as a forcing function for quality, and again at mid-quarter as a health check. Running it at commit time is more valuable because rewrites cost nothing before the quarter starts. Mid-quarter rewrites are sometimes resisted because teams feel locked in, but the honest response to a poorly written OKR is to fix it, not to pretend it was always meaningful. Do not use it on OKRs written by a single PM for themselves; the check is more valuable when a peer or manager runs it.
What if my team pushes back on the rewrites?
Ask them to defend each failed check individually. For example, 'Why is this KR measurable without a baseline?' Usually the team will concede that the original was lazy rather than defend the failure. If the team pushes back on the stretch check specifically, that is healthy debate; stretch is subjective and worth discussing. But if they push back on measurable or ownership checks, the OKR is broken and the discussion is about commitment, not quality. Teams that refuse to name owners are signaling they do not intend to be held accountable.