OKRs are set. Now what?
2020 is coming to a close and everyone is starting to focus on 2021. If your business is like Weave, then leadership has set objectives and goals for 2021 and now you and your product team need to figure out how you can help the business achieve those goals. This is a big task and one that can be hard to get right. Luckily there are processes in place that can help us reduce the risk and increase the probability of success. While other approaches exist, this is a breakdown of the processes I’m planning on following in 2021.
Team OKRs
Business OKRs are big, broad and meant for the entire organization. Because of that, it’s important to create team objectives and key results based on what you have ownership over.
Team OKRs can be set on a quarterly or yearly basis and should ideally be done with the team. This helps expand the perspective on ways to impact the business, while also helping the team buy-in to the goals.
OKRs shouldn’t be based on existing projects or roadmap. Instead, OKRs should be the strategy that determines what work will be done. If planned work aligns with an OKR, then it should continue to be considered.
Once the OKRs have been set for the team, it’s easy to start brainstorming projects and solutions. While this is common, the danger in this approach is we are left with a lot of ideas without a clear way to evaluate which one would best meet the OKRs.
Identifying Opportunities
The product team is tasked to build the right thing at the right time for the right audience. That’s a lot of things to get right. Product discovery helps teams learn fast, reduce risks, build an understanding of the right people, and figure out the right thing for them.
Product discovery can be broken down into two main buckets: generative and evaluative. Generative is about understanding customers — their environment, needs, pain points, motivations, what they do and how they do it, etc. This is about creating ideas and choices.
While product teams don’t have to strictly follow scientific research methods, borrowing some of the foundational elements, like a problem statement, research questions, and a hypothesis, can help focus generative research.
Problem statements should work within the context of the team objectives and inspiration for them often come from the plethora of feature ideas and requests from internal team members and customers. Product teams often don’t have the context or the why behind these requests, but they usually can be bucketed together around themes.
When thinking about requested features, Teresa Torres, a product coach and author of producttalk.org, suggests asking “why would your customer’s life be better off?” Asking this question, even if we’re not sure of the answer yet, can help identify opportunities, instead of just solutions.
Problem statements should also include information about who’s experiencing the problem or opportunity. This addition helps the product team, as well as the leadership, understand the focus and scope of the intended solution.
Once the problem statement (or opportunity statement) is created, a product team can create research questions, or what they want to learn from the research. These questions usually start with how, what, when, and why.
Product teams are often tempted to use their research questions in customer interviews, but this leads to bad data. Instead, the research questions should be a guide in developing questions that ask customers to share specific examples and experiences they’ve had. Since humans do a poor job of generalizing behavior and tend to rationalize it, asking general questions can lead to false data. For example, if I asked you how often you go to the gym, you might say five times a week. Instead, if I asked you how often you went to the gym last week, you might say twice. The difference might be because you have a goal to get to the gym five times a week or perhaps your brain is rationalizing that you would have gone to the gym five times if you could, or maybe you plan to go five times this week. Regardless, asking the general research questions won’t lead to good data and insights. Asking what has happened opens up the opportunity to understand the situation around the action as well as any motivations. These would be missed otherwise.
The Jobs to Be Done framework can be useful during generative research. What job are you hired to do? How are you succeeding? How are you failing? What other products or services is someone hiring to do the job? These are the kinds of insights the generative research should create.
Problem or opportunity statements and hypotheses shouldn’t be static; they should evolve as more information is learned. It’s also important to capture and share key customer anecdotes so the entire team is building empathy and understanding. These inputs help drive the ideation process.
Ideation
It’s time to brainstorm possible solutions. I say “brainstorming,” but different ideation approaches can help keep the thinking fresh and the ideas flowing. Interaction Design Foundation has a great list of ideation ideas here.
If those feel too overwhelming, brainstorming around the problem statement or changing the problem statement to a “how might we…” prompt can be a great place to start.
Other ideas to try while ideating is changing up the size of the group and the roles represented. Consider having people think of ideas on their own and then present them to a group to avoid having sessions dominated by a few people. Use the concept “yes, and…” to expand and build on ideas. Welcome all ideas. This is about quantity over quality.
Evaluating solutions
Some of the ideas are easily filtered out, but how do we know which of the top solutions should be pursued? In Marty Cagan’s book, Inspired, he talks about 4 main questions we are trying to answer.
- Is this feasible? Can we build it?
- Is this viable? Does this work for our business?
- Is there value in this solution? Will the customer buy it and use it?
- Is the solution usable?
Feasibility and business viability are usually addressed internally. Answering feasibility might might include research into new technologies and if anyone has the needed expertise. Business viability answers can usually be found in the product strategy or company vision documents. If those documents don’t exist and the work is large and risky, then talking to product and company leadership can help make sure they’re aligned and see the value in the work.
Getting answers about value and usability is the job of evaluative research. It helps validate solutions and decide which ones will best help the team meet its OKRs.
Using evaluative research early in the process helps teams move quickly, but can also be an opportunity to co-create with customers. Whether getting their feedback on rough sketches or conducting usability tests with prototypes, customer input helps refine solutions and ensure they’re solving the problem.
I like evaluating 2–3 potential solutions for each opportunity. This helps avoid bias and identify the best idea to move into the delivery phase.
Evaluative research is also important once a product or feature is launched. Monitoring metrics and asking customers for feedback help gauge if we’ve met our OKRs as well as identifying needed improvements.
When is research done?
Research is about learning fast; teams shouldn’t delay building just to test every assumption. The goal is to know enough that the risk of building is lessened. Sometimes product teams know what work needs to be done and the risk is low so they go straight to the delivery process.
When product discovery is happening, it’s easy to approach it in a linear, waterfall way. In reality, it’s much more fluid. A team might be doing evaluative research only to find they don’t understand the opportunity area well enough. But the biggest missed opportunity is stopping generative research when we feel like we understand the problem area and start to ideate. Product teams make customer-related decisions every day so it’s important to constantly be talking to customers. Opportunities and problems are almost always bigger and more nuanced than we think. Staying humble enough to keep asking questions and trying to learn is key to building the right thing.
With my focus on year-long OKRs, continuous generative research is even more important. I want to be constantly learning about these opportunity areas and discover new potential solutions. There’s no reason why I can’t be conducting both generative and evaluative research each week. For each solution that’s being evaluated, I’ll ask the product team at the end of each week if we know enough to start the delivery process or if we need to learn more.
Last thoughts
From design thinking to lean start up practices to jobs to be done, there are no shortage of processes to help guide product discovery and delivery. I’m still searching for the right mix, but using generative and evaluative product discovery with some new ideation tactics will be at the heart of my 2021 approach. It’s a combination of a lot of ideas, but one I’m hopeful will lead to great product releases and exceeding team and company OKRs.
