Break it down into milestones. What's the minimum piece you could complete that would be usable by someone (even just a beta user to gather feedback)? What's the next incremental piece that would be useful after that?
You can measure milestones completed, and you can also apply some type of scoring to the feedback you collect from your beta users. If your beta user feedback is "This is terrible, it doesn't do the key thing we need to do for our jobs!", that's actually a great outcome, because you can course-correct early, rather than having to revisit 1+ years of eng work to address the feedback.
> My only goals are to come into work, do what is expected of me, get paid, not get fired, and go home.
OKRs should just be the process of you writing down "what is expected of me" in a somewhat structured and measurable way. Team OKRs of "Hit milestones #1, #2, and #3 in development roadmap of system X" are fine, and are pretty common for greenfield projects. The main key is to have a "definition of done" for each milestone - does the milestone include documentation? Monitoring? Who decides that work is complete?
You can measure milestones completed, and you can also apply some type of scoring to the feedback you collect from your beta users. If your beta user feedback is "This is terrible, it doesn't do the key thing we need to do for our jobs!", that's actually a great outcome, because you can course-correct early, rather than having to revisit 1+ years of eng work to address the feedback.
> My only goals are to come into work, do what is expected of me, get paid, not get fired, and go home.
OKRs should just be the process of you writing down "what is expected of me" in a somewhat structured and measurable way. Team OKRs of "Hit milestones #1, #2, and #3 in development roadmap of system X" are fine, and are pretty common for greenfield projects. The main key is to have a "definition of done" for each milestone - does the milestone include documentation? Monitoring? Who decides that work is complete?