Some good observations here but I disagree with the conclusion. > Shipping features from the roadmap is a chunk of our core job. It shouldn’t usually be in our

Some good observations here but I disagree with the conclusion. > Shipping features from the roadmap is a chunk of our core job. It shouldn’t usually be in our OKRs. First of all, your roadmap shouldn’t be static. You should give teams flexibility to change it. When/why? When they see a better way of achieving the teams objective. Ideally you can set up your KRs to also be flexible WRT implementation. People loose sight of this, but it’s one of the two big value adds from OKRs. The second big one is legibility outside your team/org. OKRs are about making your goals and work easily understandable, because the alternatives don’t scale as well. So vis. the article, you should start with the question of what you want to make visible to the org, and make sure you craft your OKRs to highlight that part of the roadmap. Concrete example, I plan with two buckets: new features, and bug fixes/ops/quality. The customer for new features is users, and the org cares about this. You need OKRs to make your impact legible to your CEO, who (let’s be real) is not going to log into Jira and read the full backlog. Bug fixes and ops need to happen, and they should be groomed and prioritized ideally, but in the ideal world nobody outside of the owning team should see them. Internal tooling should be on the roadmap but not OKRs, unless you are in the red and your CEO wants to know that you are improving after, say, a business-impacting outage. So the roadmap is going to have a bunch of detail on the current delivery plans, sequencing, etc, but it’s downstream of your objectives. You should align your objectives with leadership first, then make your roadmap and propose KRs.