What you wrote is different than what I do; use what works for you.
For me, each objective gets one explicit measurement and one explicit timebox. And the key results can be a simple list of a few highlights that bolster the objective.
For me, an explicit measurement and explicit timebox both work better than implicit, because teams can be on different metrics and cadences-- such as engineering teams using uptime metrics for quarterly OKRs, VP teams using cashflow metrics with yearly OKRs, and launch teams using user metrics with target date OKRs.
OKRs are famously vague to begin with, and you are ignoring the little tangible guidance that does exist. You're just describing regular old planning.
That's fine, because OKRs have a drawbacks and lots of people struggle to make them work. But if you're teaching people you shouldn't call your approach OKRs.
Totally agree about famously vague. :-) You know what you're talking about, and your more-detailed points are more-faithful to Andy Grove's writing than mine.
Want to help? I'll donate $50 to your favorite charity if can take a look at the GitHub link OKR in my top post, and tell me what needs fixing/changing/improving to help all people know how to use these better and for free.
For me, each objective gets one explicit measurement and one explicit timebox. And the key results can be a simple list of a few highlights that bolster the objective.
For me, an explicit measurement and explicit timebox both work better than implicit, because teams can be on different metrics and cadences-- such as engineering teams using uptime metrics for quarterly OKRs, VP teams using cashflow metrics with yearly OKRs, and launch teams using user metrics with target date OKRs.