1.
Hi folks!
Here is the feedback we collected from you all at the session on OKRs for Product Teams on
stickies. Thanks to everyone who came, asked questions, and contributed feedback and
questions!
I have tried to give a short answer to each question below.
Pluses - things we thought were valuable
● Commit hard, recalibrate often
● Don't make one metric king. ex. balance revenue w/margin
● Organization of the topic was very effective. Appreciated the dissenting opinion on such a
popular topic.
● Pragmatic and practical. You covered a lot in a finite amount of time.
● Nice intro+metaphor between OKRs and BHAGs! -Angela Nguyen
Questions - what else we wanted to know
● How often should we be going OKR planning?
○ At least every quarter after you’ve had a chance to learn from your results. That
said, collect and review those results at least every 2 weeks and adjust your OKRs
right away if you figure out you are on the wrong track!
● So how can OKRs work with cross-functional teams? What if teams (creative for example)
have resourcing limitations?
○ You can’t allow specialists (no matter how talented) to become bottlenecks. You
may need to hire or you may need to allow teams to do the work themselves, with
less (or no) contribution from specialists. This is usually more efficient in getting to
results than waiting on resource availability.
● How did you measure awesomeness at Localytics?
○ We developed a 5-point scale of an arbitrary morale measurement we called
“awesomeness” based on a 3-question form about “how awesome” things were at
the company, on the team, and for individuals. We eventually developed an app you
can use: www.awesomeness.team
● How do you translate Business OKRs to Product OKRs?
○ Product OKRs should support business OKRs directly. Think of them as a subset or
a means to the business ends. If the company wants to move up-market to larger
customers, the product OKRs should include successfully selling to that new target.
● What happens if you're not on track with your KRs?
○ This happens all the time and your first response should be to ask “why” are we not
on track? Are we late with deliverables? OK, adjust the delivery date and get on with
it. Were we on time but our work did not have the desired effect? OK, what was
wrong with our assumptions? Do we just need to tweak what we shipped or totally
rethink our approach? If you recognize early that you are not on track you can

2.
simply adjust your actions to get back on track. If you learn that your underlying
assumptions are wrong and your OKRs are not achievable with any amount of time
and effort, it may be time to change (or “recalibrate”) your OKRs. This is OK if it is a
rational response to what you’ve learned.
● How often should Os and KRs change?
○ This depends heavily on the pace of change in your business. If your business is
stable or growing predictably, your annual OKRs may not change during the year.
Your quarterly OKRs will be created each quarter with the prior quarters results in
hand. If your business is very dynamic, though, and you are learning fundamentally
new things all the time, you may need to revisit your OKRs every month or two.
● How granular should OKRs be? Does it change based on business users? -Angela Nguyen
○ Larger companies with greater specialization of roles and teams will usually have
more granular OKRs. That said, the base unit for OKRs should ideally be a team of
people who own those OKRs and the means of achieving them. This is usually a
team of 3-8 people. The granularity should be what 3-5 objectives and 3-5 KRs per
objective) that team can effectively accomplish in a quarter.
● What is the balance between building RATs/MVPs and having quarterly OKRs?
○ RATs (Riskiest Assumption Tests) and MVPs (Minimum Viable Products) are tests
meant to help a product team learn how they can best meet their objectives -- their
OKRs. If you have an OKR to improve website conversion, you could deploy a test
to test an idea about what might improve conversion. If it works, you could roll it out
to everyone and measure your results against your conversion KR. If it doesn’t work
(enough), you need another idea to test.
● When in a quarter do you start OKR planning? How much time do you dedicate to the
"how"?
○ You should have a good idea of whether Q1’s OKRs will be achieved a few weeks
before the end of that quarter. That’s the right time to leverage that experience in
devising Q2’s OKRs. Ideas for “how” to achieve those OKRs will come up during
those few weeks and you should discuss, record, and prioritize them so you can
start in on the most
● Is there a specific point when it's helpful to revisit a mission statement? Is it ever a +?
● How to be iterative about building products versus having OKRs and roadmaps?
● Doesn't the measurement frequency depend on how often you're shipping features/code?
● How do you improve calibration across teams? What mechanisms are there for sharing
between teams with connected OKRs?
● How do you connect a team deliverable (e.g. Epic, etc.) to the OKRs? All the mapping gets
annoying. I need a legend now.
● There is a school of thought that you need only OKRs or roadmaps... not both. What is your
view on this?
● Talk to me about prioritizing KRs (w/P0-P3). What's the value of doing that?
● Can someone deliver the same results without OKRs and just roadmaps and stories?

3.
Deltas - things that could be improved
● Do missions ever derive OKRs? Think about motivation and intentional alignment, not
ideation. Start with insights. Start with HMW statements. Design leads will provide this and
give product what you're looking for for OKR derivation on the tactical level.