welcome everyone welcome to product school and thank you for joining me today on this topic on leveraging objectives and key results towards product development so before we get going i wanted to give a quick intro my name is yogesh ratnaparky and i am a principal product manager at microsoft since joining i launched a v1 product for onedrive and sharepoint which has been adopted by thousands of enterprise customers worldwide my journey of product management though began at a local startup which recently went ipo then i launched several v1 products ranging from api based platform to ux
products on web and mobile working at a startup and at large tech companies i learned many valuable lessons along the way and if there is one thing that i took my heart is what's considered a product management success what's considered a product management in jarvan and here's my three pillar definition of a happy product manager first a product manager is responsible for delivering tangible concrete outcomes or value to the organization a value or outcome could be measured by the revenue the number of users reduction in cost or customer satisfaction it really varies based on the
type of your product based on the phase of your product the type of your organization or the market you are in but making sure that you're consistently delivering this value is key part of a product management success and in order for you to deliver this value you need to establish a strong alignment with your stakeholders including your leadership team that way you can be sure that you are not only delivering just any outcomes or any value with the right outcomes the one that jive with your overall business strategy and the company culture and finally you
want a cross team ownership where everyone in your product team is excited and inspired towards the product vision now why is that important when everyone owns the product they bring their best the designer makes them thinking how she can improve the ux towards the final outcome and then the engineer lays a strong foundation towards the long term vision of the product so that's how i measure my success as a product manager while this is a lifelong pursuit there are definitely frameworks like you can leverage to get closer to this ideal state so to understand this
framework let's take the classic shopping cart scenario which typically looks like this so once an item is added to the card customer proceeds to check out add shipping details payment details review the order and then clicks the checkout button and they get a nice confirmation of their order imagine you are the product manager for this checkout experience you're responsible for the success of this checkout process or checkout product so based on your assessment and the discussions with your business owners you define your success as improving the checkout rates now let's say the checkout rate is
defined as the conversion from a point an item is added to the card to the final confirmation step so you set this goal you get everyone sign off on this primary outcome for your product i mean who doesn't like more checkouts right now you can assess opportunities ideas solutions against this feature and start building a prioritized roadmap for example apple pay seems like a promising way to give more choices more payment choices to the users and in turn help improve your checkouts your engineering team has proposing to upgrade the checkout apis which promises to be
more robust and fewer errors and seems like a great way to impact your checkout rate this yet another idea of expanding this experience on android devices for example to increase your market share now this is a great strategy in theory you're off to a great stack in fact this approach is better than listing just listing a list of features getting excited about it without worrying about the goal so in theory you defined your goal you're doing all the right things you got your stakeholders do not on this goal you prioritize these features based on this
goal and if you deliver on this roadmap you are off to success so did we get any closer to the nirvana with this approach yes and no here's the problem and here's why in reality you have often multiple fuzzier goals and the feature are almost always a set of hypotheses meaning you're not sure if the feature will indeed deliver the outcome you're after and the feature are so disjointed or so if not disjointed if so far from the goal it's it's harder it's not easier to measure the impact of these features against the goalie that
you're after so how do we upgrade our approach how do we upgrade our technique so we can be more confident that the product strategy will indeed drive the results that you're after at each phase of the product development cycle and that's where okrs come into play so okrs stand for objectives and key results the objective is the top outcome that you want to achieve and key results are the interim milestones or sub outcomes that when achieved will move the needle on the parent outcome so our goal now becomes the objective which is to increase the
checkout rate and then we identify a handful of key results or krs that will deliver our objective to get the key results in our case we ask ourselves the question what needs to happen in order to improve the checkout rate well if we reduce the number of clicks leading to the final checkout we would have fewer drop-offs along the way the customer will have an easier time to the checkout process and thus lead to a more successful checkout overall so that becomes our first kr or key result similarly if we reduce the drop-off at the
payment screen which is a typical bottleneck for e-commerce products then again we'll impact the checkout rate that makes it for our second kr and finally if we improve the overall customer satisfaction then also we'll improve the total checkouts now this particular kr could be measured by a survey on the post checkout screen notice we haven't mentioned a single feature yet unlike our previous strategy instead we broke our goal into granular measurable outcomes so that we can easily track our goal and we can even start ideating features that that can more easily map to our outcomes
and remember key results are inherently measurable so it's easy to quantify and prioritize them and which makes it easier to get alignment with your team your stakeholder or and everyone involved on your overall strategy more importantly you yourself feel grounded in reality and feel connected with your business outcomes so that's how you break your goals into okrs now now that we have established a great strategy how do we apply this framework to the rest of the product development cycle in a typical product environment you usually start with a strategy which we just did by setting
our product or chaos i mean there's more to do in a strategy but you already laid a great foundation for that the second thing is the build groom and prioritize your backlog the third we take the top backlog items to a quarterly planning meeting with our engineering teammates with our stakeholders and leadership and fourth we start building this product that we committed to or the list of features that we committed for a specific quarter or semester and then finally we launch these features or the product having okrs as our strategic foundation we already taken good
care of the step one as i mentioned now we are ready for step two which is to build our backlog so to build our backlog you put the objective at the top as you can see in that orange bubble and then the key results are the second level nodes in the blue boxes below it and then you facilitate the brainstorming with your team ideally focusing on one kr at a time you let the team come up with solutions that could potentially impact the specific key results remember we want to foster creative we want the team
to own the solution space and to do that you want to make sure you include representation from design engineering data science and extended teams like support customer success and even legal teams based on the type of the product you could even invite your partner teams like in this case let's say we want inputs from the payment team we should invite them into this brainstorming session now this process fosters creativity and ensures a diverse perspective from everyone involved but making sure that you keep the conversation focused on a specific key result for example your design team
has already been proposing to revamp the checkout experience now equipped with this key result they can now refine the scope to deliver the specific outcomes we are after and you can you can then repeat this for other features and then you can finally repeat this for other key results and build a super objective and organized backlog as you can see here you don't always have to start with a new brainstorming session it's common to have a backlog built through conversations with customers or with your internal teams and then you can use this process or this
opportunity tree framework which was originally formalized by terrorist attorneys to actually organize your backlog around your okrs and now that you have the first pass at organizing your backlog you're ready to start stack tracking them against a specific kia there are proven techniques to help you achieve this first and foremost make sure to add key instrumentation or telemetry if it's not already available you can't truly improve anything if you cannot measure it so make sure your first priority is to add all the key things that you want to measure this could also mean investing in
a good dashboard that will help you to see how you're doing on a specific key result second you want to make fact-based data driven decisions you probably heard this phrase several times but you cannot still overstate it and now that we have a crisp key result to focus on in this case let's say it's the first year which is to increase the checkout rate it's much easier to now be fact based when you're evaluating different features against a specific care versus comparing with the overall objective that we did in the our very first approach and
third you want to apply the 80 20 rule whenever possible which means favoring features that apply to 80 of customers or 80 of scenarios this will ensure that you're investing in features that make the most impact and finally you want to fail fast by validating your hypothesis as early as possible for that you could do user studies or prototyping or you could do a eb testing so that you can be sure before doing a full deployment you did all the new all the due diligence to pre-validate a feature and to assess it against the key
result that you're after and then you can put this backlog into your existing issue tracking system like jira most issue tracking systems offer a hierarchy like epic being at the top and then you have features underneath it and then you have multiple stories to support that feature you can leverage this existing hierarchy to plug your okrs into the system for example your epic is now your objective which is to improve the checkout rate and then your features are really the key results that will make this objective happen if your issue tracking system doesn't support okrs
um then you could be creative you can use custom tagging within the issue tracking system or you can add custom fields to make sure you every issue or story or feature is mapped to the key result that it's tracking and with that you're done with the second phase in the product development cycle which is to groom and prioritize your backlog the next phase is to build a three to six month product plan having a solid objectified backlog we built in the last step you're now ready to have an okr driven product planning session what that
means is as a team you can propose the features you want to build but more importantly you come into the key results for the planning quarter and now you can put actual numbers on your key results with reasonable confidence thanks to the feature validation work you did earlier for example you as a team now could say in q1 will reduce the number of clicks by x percentage along with the list of features that will write the features that will drive the key result now this is a great way to hold yourself accountable for the actual
outcome and not just features and then the team feels ownership of the features they're committing a because they were part of ideating this and b they now really understand why they are building specific features and since you already plugged okrs into your issue tracking system you can build char charts like the one you that you see on the right side where you can break your story points or issues by key results and ensure that you're investing in the same proportion that you intended your investment portfolio that you see here shows that you're investing more in
the key result one and that's what that's exactly you wanted because you know that will have more impact on your overall checkout rate for example so using charts like this you can actually validate that your planning is aligned with your strategy now one and once you have a sign off on this plan you can start executing but having this objectified framework or commitment will help you get a better sign of an easier sign up from everyone involved now we are ready to execute our commitment for this quarter or whatever timeline that you agreed upon again
you can continue to leverage okrs throughout your product development process of building this particular feature set and make sure that you use those cares to course correct your future strategy remember your commitment is for the key result example your commitment is to reduce the drop off of drop off at the payment screen you're not so much tied to the features so if you're learning evolves throughout the quarter based on whatever tests you did based on whatever limited deployment you did of your features you could course correct your feature strategy you could fine-tune some of the
feature scopes based on this learning so that you can stay as close to delivering on the key results as possible you can drive the key results you can drive the daily and weekly discussions with your team using these key results to address dilemma that may happen or scope decisions and finally as your sprint progresses as you burn down your backlog make sure to supplement the speed sprint reports with the cares that they are after even if you didn't make the kr it's important to include them so that you remind the team and everyone um that's
listening to this sprint progress reports to understand why we are doing specific key results and how close we are to actually achieving these outcomes so that was the fourth step and the fifth and final one in this cycle is to actually launch your features based on your age old practices or your release cycles you may be launching features daily weekly bi-weekly monthly regardless make sure that you document your launch dates so that you can attribute the key result impact as the feature gets adopted by the customers most key results will not be impacted right away
after you deploy the product there will be a delay by the time you actually see the result but it's important that you document this so you can start attributing the impact of something that you launched maybe a week or two weeks ago to the results that you're seeing now and then as you have as you close on sprints and move on to the next and you do your sprint retail meetings sprint retro meetings make sure you use the key result as a way to drive this discussion if you didn't meet the kr ask yourself why
didn't we meet this is it because it's too early or is it because our hypothesis was incorrect or our feature fell short of making a specific key result impact regardless make sure that you bake your learning into the overall process so that you can continually evolve adjust and make sure that you get closer and closer to the key results that you committed at the beginning of the quarter and then as you launch features and you communicate to everyone involved make sure you mention the key results if you meet the numbers it is a great way
to encourage and energize the team because not only did they launch features but now they know that they made a meaningful impact towards your company or to the customers and there's nothing more rewarding than seeing this impact the game going goes back to making sure that everyone in your team is empowered and energized towards the long-term product vision so did the okr framework take us any closer to the product management nirvana let's see we want to deliver value to the business and by keeping okrs at the core you ensured an outcomes driven strategy from day
one and then you use okrs to drive engagement at every stage of the product life cycle that way everyone was aligned everyone was informed and everyone was on board on why we are doing certain things and how we are doing it and finally by offering a guiding framework you empower dreams and drove ownership to ensure a lasting product impact so that's my take on applying okrs to product management principles and taking you closer to your own product management irvana so before we open for questions i want to call out a few common pitfalls when applying
this framework in product management first don't let great be the enemy of good don't let perfection limit you from applying this framework if you're new to this approach or if your team is new to the approach start small start simple be incremental in your approach and as you apply this framework don't insist on micro prioritization don't boil the ocean to set the exact key results in my experience these things evolve with time and experience and application so get started and then commit to a continuous improvement and then you will be successful in actually leveraging this
framework to its best second make sure to close the loop teams get excited about okrs in the early phases like planning or grooming but then as the sprint progresses they forget to track the metrics and measure the impact of the product so it's important to report back on the key results even if you didn't make the target that's okay that way you can adjust the strategy and get back on track finally occurs is a means to an end it's a framework it's a guiding principle the best innovations often are bottom-up come from the teammates uh
that that are closest to the core base are closest to the customer so make sure you foster creativity instead of stifling it by enforcing a top-down approach so if a teammate proposes a great idea that is aligned with the overall mission but doesn't fit any of the key results you have maybe it's time to evolve your framework itself maybe it's time to introduce a new key result or even a new objective but as long as it jives with your overall mission or vision or strategy make sure that you're inclusive of all these great ideas in
short you want to keep the framework living and breathing so that you get the best artifact so that's okrs in product development thank you thank you so much for um thank you so much yogesh that was a great presentation um so to everyone we now have some time for a few questions and i see that there's already a few in the chat so feel free to turn off your mic to ask a question directly or if you don't feel comfortable talking or if you would rather use a chat then that's fine as well so we'll
start with the first one that's here um that says at what point should we determine if the features identified or backlogged will help meet the objective and then waiting to build all features first might not align with the fail fast approach box got it so the first question was at what time should we start um evaluating a feature against uh a key result so um i think as early as possible um as as i mentioned in the previous uh previous slides you want to take a first pass at kind of organizing your features based on
a little bit of a subjective maybe a judgmental approach but then once you have your first pass that's a great opportunity right before the planning session because remember for planning you're bringing your top features and you're also committing to the kr so right before planning that's that is the time to make sure you have as much validation done as possible and usually let's say you're planning for q2 q1 is a time for product managers and designer or maybe the engineering lead to start grooming your q2 backlog and that's where you're doing some sort of pre-validation
so by the time you're ready for the planning you've done enough validation and homework so that you can actually evaluate the impact to the specific care with reasonable confidence hope that answers the question and what was the second question nikki forgot second question was um well i think it was more of a statement waiting to build all features first might not align with the fail fast approach and what are your thoughts on that waiting to build all the features definitely no we definitely don't want to wait for all the features um in fact as i
was saying even before you build features you want to fail fast like there are multiple ways you could learn about a features potential impact uh by doing testing or prototyping or deploying it to a small set of subset of customers with this limited scope and then you kind of start evaluating so in some ways this discovery pre-validation is happening continuously as you're getting ready for your next quarterly planning so yes it has to be incremental you're not waiting for all the features to be deployed hope that answers the question again okay and then we have
um someone wanting if you could maybe go over the slide that uh mention the percentages with about product planning and communication um if you don't mind sure being a little pressure on that one this one we can't i don't know just can anyone see the screen let me see no no let me let me get back on the share one sec is this the one i believe so yeah that's one got it and what's the question on this if you could er anon if you have the question about it or if you want um i
think just to kind of go over it one more time to clear things up sure so this slide demonstrate or gives a sample of how you could commit to specific key results for an upcoming quarter so idea here is let's say you identified reducing clicks as one of your krs now you can actually start putting numbers on it so let's say you determine that in your new ux that you're proposing instead of 20 clicks now you're going to have say 10 clicks so you could actually now say that you will reduce the clicks by 50
again you don't have to be um exact at this you want to be a little bit aspirational in in this case it's more object um it's more objectified but there are other times where you want to be more aspirational but the idea is based on the validation you did on the features you have some sense of what impact you would make let's say there is an error that is happening on twenty percent of scenarios and you know that if you fixed it you will have a twenty percent more increase in the success rate it's okay
to actually put twenty percent there because that's how you know that you know you're going to make an impact on the key result i hope that answers that question thank you great all right so we have time for a couple more questions um and also if anyone wants to speak up just go ahead and unmute yourself and you can ask oh yeah nikki i can ask a question here hi yagesh vishal here uh thank you for this great presentation uh very quickly i always hear that there is always a recommendation that your okr needs to
be very aggressive and it should be set in such a way that if you are every time you are consistently achieving them 100 it means there is a problem so so from your perspective what formula you suggest you know how aggressive that should be uh you know i want to understand you know because you have been using this tools and techniques so what do you recommend there in that in that area absolutely so chaos are meant you meant for you to be aspirational right and you definitely need to have at least one or two key
results that are moonshot so when you think of moonshot i think there is no formula it's more like what really inspires the team without losing touch with the reality so you want to have uh k results that in excites the team but at the same time the team feels that as that's actually achievable if you know if you did all the things and if you have a little bit of a luck you know we'll get it i think that to me is the kind of formula in some ways and it depends a lot on the
culture of your team if you're working with a conservative team who take pride in delivering what they promised and if you're introducing framework new it's okay to start with more rooftop chaos which are more realistic and start slowly introducing more moonshot and if your team is over optimistic maybe it's time to tone down down that a little bit so so that's my take uh which i like uh does that answer your question it does and thank you very much um yeah this this answer my question very well so just kind of a quick one follow-up
or related question here um when we said the okr uh again it all depends on the organization and the culture but but just from your perspective uh should we kind of target this okay like quarterly or you suggest it's too short period you know it should become too difficult to manage so what's your kind of suggestion there yeah um i think you broke a little bit but i got the gist of it uh you need to have enough uh time frame that allows you to launch something measure it and see the impact and in most
cases it's usually three to six months so in most scenarios again it really varies with the organization but usually you want to set okrs for the next uh one or two quarters now there are teams and there are products which are super aggressive by nature so for example if you're in a marketing team and you're you have aggressive built-in a b testing campaigns then you don't want to wait for three to six months it could your targets could be more short-term but again you still need to have more long-term targets and then they are supplemented
by more short-term ones so the answer is three to six months for most but it could change based on the type of team you work with thank you all right we have time for just one more question and then we'll have to close it out um from the chat we have a question about discovery how does how that fits into the flow and then um another question about managing features post launch so let you choose got it so when you said discovery i assume you are talking about discovering the opportunities having conversations with the customers
or the marketing general correct yeah i think uh product is yeah i'm assuming that's what they mean so discovery i i gave another talk at product school a year ago it was about how do we have continuous discovery so my philosophy is discovery is a continuous process while this is this cycle is happening as a product manager you're continuously talking with your customers and your internal customers and kind of keeping your list of hypotheses kind of up-to-date and then keeping them validated as much as possible so that when you're at the quarterly planning meeting you're
not doing discovery by scratch you've already been working for it last three months or what have you so um so you're ready for this planning session that you see here and then as soon as you plan as soon as the team is off to races you again start your discovery full swing so that by the next quarter you know you're ready with your next set of hypothesis and sometimes you have enough learning and you you don't need to be that aggressive about discovery but in general it's a continuous process all right well thank you so
much and with that we are going to have to close it out where cuddy uh cutting um into a little bit of time but thank you so much yogesh for that really insightful presentation and for everyone um in the comments asking questions and for joining us today um if you have any closing remarks or anything that you should like to leave us with no thank you so much for listening um and for the great questions and insights you can reach me at uh at my email or stay in touch on my linkedin profile if you
have any follow-up questions but again thank you product school nikki and everyone who attended the call today thanks a lot
