There’s been a tonne of talk about OKRs lately...
And rightly so, because objectives and key results have become hugely popular, especially during these uncertain times and in the current climate of remote work. It seems more and more companies are looking for the best ways to understand OKRs, including their performance and execution. In fact, some have moved away from maintaining long lists of tasks, and opted for an OKR only system instead.
Well we got the chance to explore this more in a chat with Kyle Evans, Lead Product Manager at Teem by iOFFICE, ahead of his talk at Product-Led Festival. We touched on his interesting work at Teem, discussed PMs moving away from roadmaps to OKR based frameworks, and explored whether or not they’ll replace roadmaps entirely...
Q: Can you give us a bit of an overview of your career journey so far? You’ve had an interesting background building product across a range of industries!
A: Years ago, even before I graduated from college, I had the opportunity to start working with the development team there. And we were working across all of the faculty and students and building the products for the university, basically from the scheduling to the things that the professors were using in their classroom, and I absolutely fell in love with it. Though I didn't know this was product at the time, I loved what I was doing. And fortunately, was able to continue doing product after that, and worked across a variety of different industries. So I'm moved from that into the financial sector.
I did product there for a number of years. And then moved back into higher education for a few years, and then into healthcare, and then into product there and then into marketing. And I'm currently at a company called Teem where we work on intelligent workplace management. So it's a very interesting space right now. But yeah, I've worked across a variety of different industries in the product management space.
Q: Can you tell us a bit about what you're working on at Teem? How are you establishing goals and priorities when the future of work is still uncertain in the current climate?
A: Teem focused on intelligent workplace management. It's a really fascinating space because there's a tonne of questions right now that everybody's asking. And that's kind of what really drew me to the role. Because I think that there's a tonne of opportunity in the space right now, with what the future of work looks like, because nobody really knows what that is, right now. None of us do.
And so it’s about being able to help define that, and we're working on a few things right now. So first off, being able to help people return to the office. So as everybody is starting to get back into the office, what does that look like? And how do we start getting back into the office?
Also, how do we protect our various offices? So you know, I think we've all gotten very comfortable, or at least many of us have gotten comfortable with the fact that we can do a lot of our roles from home or the office. And we basically shifted ahead five to 10 years in remote work. And so how do we start to balance that? And then what does the future of work even look like now that we've taken that giant leap forward?
What does the future hold for everybody? And so defining some of those things I think is kind of where some of the greatest opportunity is, and that really excites me about not only what we're doing, but just work and the workplace in general. Because there's so much uncertainty, but also so much opportunity as well. And so, when we're looking at our goals and priorities, one of the things that we're constantly thinking about is what we can be doing to be facilitating this future, and the future of work and helping people accomplish the goals that they have.
We have a few principles or tenets as I like to think of them. And one of them is how can we empower users? And how can we help them do their best work in their environment? And so in all of the things that we do, with our prioritization and our goals etc, one of the things we always come back to is how can we empower people to do things themselves. To experiment, do different things, learn in new ways, manage their environment. And so as we're building things, we think about how it’s empowering them to do things as well. Essentially, we focus on how we can be innovative so our users can also be innovative, and bring new ideas to the workplace, that's something that we were trying to prioritize, often above other things.
So if there's lots of people doing something, we may not necessarily want to follow suit, because that might not necessarily be the most innovative thing for us or our customers.
We also ask ourselves how can we focus on some of the biggest problems, whether it's something that we currently do as an organization or something that is just a big problem for people working in general? And even if it’s something not currently in our wheelhouse, we start to think about those things and prioritize them and make goals around them.
So I think it comes back to there's a lot of uncertainty, but how do we embrace that? And really prioritise those things and put some goals around them in order to solve those types of big, interesting problems for the future.
I feel like we've moved past the way things were. And you know, I think we'll love to get back to seeing each other and doing some of the things that we used to do. But as far as work and the workplace and remote versus in-office, and all of that sort of stuff, I feel like we've moved past a lot of those types of things and have moved into kind of a new era of how things are going to work.
Q: There’s a lot of talk about OKRs at the moment, and how successful they can be... Why do you think many PMs are moving away from roadmaps to OKR based frameworks?
A: Yeah I think that we have a love hate relationship with roadmaps and for good reason. In fact, I actually wrote an article about this a few years ago, it was called “Roadmaps love, hate and hate.” And for this exact reason, like we have a love hate relationship with roadmaps because they cause all sorts of problems for us, because they've been used incorrectly by so many people for so long.
Because I think roadmaps are used for a lot of things. They've been confused for a project plan or a release plan, or a timeline or commitment list, and all of these different things. And so, I think that we have a desire for certainty almost. And we use a roadmap to kind of fixate on this idea that we can bring certainty into the uncertainty of product development.
I think OKRs help shift that a little bit. But I think a good roadmap can also do that. And so I don't think that roadmaps and OKRs necessarily are the opposite. I think a good roadmap and OKRs can definitely work hand in hand. But roadmaps when they're done wrong, which is often the case, are very difficult to use in the right way. I think people use them incorrectly very often.
So I think OKRs can often be the solution to that and hopefully pull roadmaps back into the right places, like a strategic document that is meant to convey the vision and help us have the right conversations about where we're going and what we're going to do.
I think that the OKR framework really helps us think about what is our objective, like high level, and what is it that we're trying to achieve? How are we going to do it? And then, what are the pieces?
So it almost shifts the conversation back up, which is what I've seen and what I try to do every time we go for OKRs. Because often we get down into the weeds of all of the features, here's the list of things that we're trying to do, and we forget about the why. So why are we trying to do it? What are we trying to accomplish?
Everybody gets fixated on trying to release this thing and that thing, by this date. And we never really get back up to why are we doing it? What are we trying to accomplish? And so OKRs help flip that back up to thinking about our objective. For example, we're trying to increase our user retention, and we want to focus on that over this quarter. And then we can get back down into, here's how we think we can do it, it's these three or four features.
Your roadmap can then help us focus on what we’re going to experiment with, and things like that. But when we fixate on it, I think that's the problem. And so, the OKRs, and our roadmap can work hand in hand. But if we get sucked too far down into just the feature list of the roadmap, then that's when I think there’s a problem.
So I think that's why we as product people gravitate back up to our framework, our objectives and our key results, because it helps everybody shift their focus and shift the conversation back up to where it should be. Which is, why are we doing these things? What are we trying to accomplish? And how do we know if we've done a good job at it? Not that we don't need the features, because we do like that. That's the means by which we accomplish it. But we shouldn't be constantly down in the weeds. Just focus on those things.
Q: Can a product team move to an OKR only system rather than maintaining long lists of tasks? And do you think that OKRs will eventually replace product roadmaps entirely?
A: I think that there will probably always be some cohesion. And I think that good roadmaps can really work well together with OKRs. Especially when we keep in mind what a good roadmap should be. It’s not like a release plan. It's not a Gantt chart of like here’s this feature, here's the next one and the next one. And we see this all kind of strung out with the dates, and all of the things. I think of a roadmap as much more.
Then you have the OKRs that we're trying to achieve for this quarter, and then here are the things that we're going to focus on, or that we think will help us achieve that. And you're not necessarily focusing just on those, but really focusing on the high level portion of it. Then for those who need to understand what's going on a bit more in depth, those things can kind of work together. And I see those as like the framework that works hand in hand. Like being able to have both of those things working together. That's probably a little bit idealistic. But I think that’s the goal that we can aspire to over the long term.
I think that it's difficult to get fully away from the roadmap, especially in the way that a lot of people are using it. And I think that we definitely need to be using the OKRs, and using that framework to shift the conversation back up to where it should be, so that people aren't so focused on the feature level.
I think it’s perhaps the first step and I think that OKRs could replace the way that we do roadmaps now, in that they could replace the bad way that we do roadmaps. So, yes, the framework could replace the bad way. And hopefully that will help us do it in a much better way.
Q: Your talk at the Product-Led Festival will delve into taking OKRs from Theory to Practice, and we’re hearing a lot of failed efforts to effective OKRs currently. What are some of the common pitfalls that PMs fall into when setting OKRs?
A: Yeah, that's a great question. We actually had this exact discussion recently with our product organization. And I think there's a bunch of pitfalls that we fall into as product people. The most common ones, and I'll be diving into this in my discussion as well during Product-Led Festival, but I think that there's probably five buckets that we can sort of put them in.
One being we try to rush the process and OKRs aren't necessarily something that you can rush through and do them well. Next, is not having the right data or not having the right links across the organization. It's a very difficult thing, especially once you've already put in the work, and you're not able to kind of show how all of it ties together. So not having the right metrics or the right data.
Then number three, a lack of focus. So once you've done the work and you’re getting the data, not actually focusing on the OKRs throughout the time that you're doing that. And number four, and we talked about this one quite a bit, not actually having the autonomy to do it in the way that you want to. So this is almost more structural or organizational. So you're having the OKR framework, but then not having the room within your organization or your department to manoeuvre quite like you hope.
And then finally, and this is kind of more of a mindset that I think we can fail with, is thinking that it has to be an all or nothing proposition. So not feeling like we're successful, because we haven't been successful completely, or in the way that we expected to be. And I'm excited to talk about this one more, because I think that we have to take a little bit of a longer term view, because we're not going to be fully successful from the start. I won't give away too much of my talk, so make sure you sign up, but I think this is a big pitfall that we can fall into.
Q: Could we get another extra tease on your talk at the festival next week?
A: Yeah, I’ll go with a quote that I have in the presentation:
"In theory there is no difference between theory and practice - in practice there is."
Which is why it's so important to not only talk about the lessons but to learn from what works, what doesn't work, and what you can expect from what other people have done. From what they've learned and what they failed at in implementing OKRs.
Be sure to check out Kyle’s session at Product-Led Festival on March 23rd! It’ll be exploring how to take OKRs from theory to practice while avoiding any pitfalls.
