- Continuous Learning
- OKRs Promote—and Help Facilitate—Good Research and Design
OKRs Promote—and Help Facilitate—Good Research and Design
Why democratizing research through OKRs is a good thing for researchers, designers, and entire organizations
It’s February. We’re all more settled into the year now, and I’m more settled in our new apartment. More settled, but not quite there. I’m still figuring out where I want certain things and learning about the best way to use my new space. I’ve moved my desk around, put my computer in two different locations, and tried to determine the best placement of the shades throughout the day for optimal sunlight without glare.
You could say I’ve been conducting experiments. Which is, as you all know, important in my line of work.
So important that I want to talk about experiments, and more specifically research, in today’s newsletter. The goal with conducting experiments and research when using OKRs is to learn something, right? What we learn affects what we do next. In product (or any facet of business), what we learn helps us collaborate more effectively, improve our designs, and ultimately serve our customers better. We need good research and design. And we can all work toward those things together.
Article: OKRs Promote—and Help Facilitate—Good Research and Design
I’m going to start this article by repeating the title right off the bat: OKRs promote, and even help facilitate, good research and design. I’ll add collaboration to that list. This assertion is something that Josh Seiden and I make all the time in our work (see here, here, here and here) because it’s an important one.
There seems to be an idea floating around that the way he and I talk about and teach OKRs diminishes the value of UX research and the benefits that come from doing real design work. That couldn’t be further from the truth. Josh and I are former UX designers. We spent many, many years practicing in the field. We know the importance of good research and design because we lived and breathed it, and everything we teach teams today focuses on the need to get to know your customers and their behaviors with your products (a.k.a. conduct research) so you can design better products.
OKRs are a part of that equation. OKRs demand good research. They demand good design. If you’re not conducting research with your customers, how can you possibly design features and products that will both help them and achieve the key results you’ve set?
Research is learning. Learning is good.
When we discuss research within the context of OKRs, we’re often talking about discovery work. We define “discovery” as the set of activities that we use to understand a problem, understand the people at the heart of the problem, and find solutions that work. Sounds a lot like research and design, doesn’t it? That’s because it is, in many ways.
In the discovery process, we encourage teams to look at the quantitative and qualitative data available to them, and then figure out things they can do to learn more. Those things take the form of tests and lightweight experiments. But “lightweight” doesn’t mean crappy, cheap, or useless. It means “straightforward,” “with mitigated risk,” “non-resource-heavy.” The goal is not to conduct bad research or design—ever. It’s to learn what you can, as much as you can, in ways for which you will realistically be able to get approval from higher-ups (or, ideally, which won’t require big stamps of approval) so that you can create better design and better products for your customers. It’s all in service of the same goal.
OKRs democratize research and its benefits
Here’s the other key point: Not every team and organization has researchers available to them. Or sometimes the research and design teams are stretched too thin to be able to help with customer research on the product teams’ agenda. When that’s the case, product teams (or any teams within an organization) need to be able to learn things that can move their work forward on their own.
So, when Josh and I talk about product teams conducting tests and experiments as part of OKRs, it’s with the goal of democratizing learning. Because you don’t have to be a researcher or a designer to be able to learn something about your customers that will help you create better products. You just have to be a curious and open-minded person.
If that’s true—and it is—using OKRs has the added benefit of bringing research and its value to a much broader audience. It enables the rest of the organization to get to know their customers better, which will in turn only give researchers and designers more data and information to work from. It will also free them up to go deeper and conduct more meaningful and technically complex research.
All these things promote research, getting to know your customer, and understanding their needs, right?
Keep going to your researchers and designers
Finally, none of this precludes anyone from using researchers available to them. We hope you use them as much as you can. Their whole job is to know how to conduct research well, collect the data, and give recommendations based on what they learn. They are your best assets. So, if your organization employs user or market researchers, use them.
If your organization doesn’t have researchers on staff, you might want to ask your leaders about contracting research consultants. Again, if you have the opportunity to use the pros, take it.
But if neither of those options are available to you, know that you can learn a lot by talking to your customers, running tests and experiments, and conducting some research of your own.
What’s new on the blog
The Connection Between Goals and Customer Centricity – To be customer-centric, organizations need to invest in research and design while working to integrate those teams’ work into a cycle of learning that continuously informs product design and development decisions. If orgs want to set goals the right way (aka outcomes-based goals, aka OKRs) and achieve them, they need these teams—which means all these tech layoffs targeting researchers and designers most are a big problem. More in this blog post.
Prioritizing Work with OKRs – The riskiest part of product development is prioritization—deciding what to work on and when—because you’re attempting to predict the future. Which feature is or will be “more valuable” or “critical” to your success? People will have opinions, so how do you decide what to prioritize when you don’t agree? Use OKRs, product discovery and a bit of educated guessing. This blog tells you why and how.