I’d like to add another element to the discussion that often gets overlooked when operating at high speeds — framing. OKR line items can be very dry: we are going to do X to raise metric Y by Z%. Even if the idea is rooted in a very real user need, it is not very motivating for the team to work on that project if they don’t understand the reasons behind it. For example, one of the designers on my team recently started a project to “figure out how this new payment model we want to test will work.” There was a real sense of urgency to deliver designs due to dependencies, so the designer simply knocked out the flows. The solutions proposed were fairly reasonable, but could the designer have generated more innovative solutions? I think so. I wish, as a design leader, I had reminded the entire team of the reasons behind that project. I wish I had talked to them about how research showed that the current payment model led to analysis paralysis, and that the new payment model was conceptualized to eliminate that particular decision-making factor, ultimately focussing the user on the more important factors at hand. With this in mind, my next challenge is to nudge the organization to rethink how we might frame the OKR items in a way that is rooted in user needs.