 Hello, guys. How are you doing? Okay. Welcome everyone to this weekly event for the school. Let me see if you guys are seeing me. Yeah, perfect. It's working. Yeah, welcome. Welcome everyone to this amazing webinar that we have today and congrats to all the US people. Yesterday was a great day. Fourth of July. So, yeah, yes, this is the way we have an amazing speaker with us. He's a former senior program major at amazing companies such as HP Sky. Well, he has a lot of experience. So before we jump into the webinar, I wanted to tell you a little bit more about our events, about us, who we are. So, well, my name is Fernando. I'm the VP of product at product school. What we do is we teach product management. We help people on how to get a job as a product manager. For that, we organize these weekly events, which are free for everyone for you guys to learn more about the different aspects of product management. And I love those lines for those of you who want to take it to the next level and actually break into product management. We also offer part time courses about product management, about coding for managers, data analytics for managers, and we recently opened a new great course called blockchain for managers. So if you guys want more information about any of our courses or you want to break into product management, please go to our website, productschool.com, and then you'll find all the information about our courses, events, and so on. So, today, as I was saying, we have an amazing speaker with us. His name is Paolo, and I would like him to introduce himself. Hey, Paolo, how are you doing? Hey, Fernando. Hi, everybody. I'm here. Hope you can see me. Yeah, we can see you. Great to be here. Thank you very much, product school and Fernando for the nice invitation. I'm very happy today to speak. I'll try to run my presentation and share my screen with you. All right. It says somehow that I've disabled up in the screen sharing. So maybe Fernando, you can do some magic on your side. I'm going to do some magic. Don't worry. But you can start if you want. At least you can start to do this yourself. I'm happy to do that. So, as Fernando mentioned, I am a product manager, I'm used to work for B2B products and B2C products, a company like Ulet Parkard, Microsoft Skype, and as well as some startups of my own, even in the blockchain space. In the past few years, I've been really focusing on to bettering my product management knowledge and sharing with others, especially teaching at the University of Economics and my own course of product management, as well as especially coaching product managers from pretty much all of sort of companies from small startups to mid-sized companies to huge enterprises, some of my clients include, I don't know, Yachting.com, the MSDIT Global Innovation Centre, which is part of Merck, the pharma enterprise. So today I'll be happy to share with you, first of all, the screen. It works perfectly. Thank you, Fernando. Yeah, so this is what I can skip now because we're talking about it. So we're going to talk about OKRs. And especially, we're going to talk about OKRs. Can you still see myself? Yes. We're going to talk especially about OKRs for product managers. So I'm not going to give just an intro about OKRs. I will assume that many of you actually know OKRs and actually some way try to apply OKRs. The experience and the team I coach, there's always some pitfalls for teams to actually try to successfully adopt OKRs. But today I'm going to focus on three aspects that are super valid for product managers in OKRs, which is what you can see there, OKR and strategy, OKRs and product discovery, and OKRs and roadmap. Let's start with strategy. So strategy is something quite blurry, right? When we speak about strategy, it seems like a complicated concept and everyone in the company, from my experience, have their own definition of strategy. So management thinks strategy is something, product people think strategy is something else, maybe developers think the strategy is something even different or they don't even get it. I think it's a marketing plus. So I'll give you, we won't discuss strategy here intensively, but I'll give you my very simple definition of strategy, which means three things. First, we were building the product for what actually is the product and what are the things we're trying to achieve. And so let's see how this fits with OKRs. If you look at OKRs that plant quarterly, you can do it differently, but usually they're planned quarterly. So for those of you that are not familiar with OKRs at all. This is a methodology that was originally introduced by Andy Groove, the CEO of Intel, and then spread by John Doar and Google and now lots of companies and product teams from small startups to big enterprises use it to successfully align strategy with execution for the product. So if we look at the planning of the OKRs, we need to keep consistent our strategy, which is usually for a longer period of time with the OKRs of the current fiscal year, and we need to keep consistent the OKRs of the current quarter with the OKRs of the current fiscal year as well. So what happens if I zoom in the picture before, our long-term strategy needs to be defined, and it's very good that all of us in the company actually do perfectly agree on that. Every function from marketing to product to development to management is supposed to fully agree and be on the same page on the strategy. Having that in mind, we should plan the OKRs for the current year in a way that do not contradict our strategy. So if our objectives are going against or diverging from our strategy, then we should either rethink the strategy or reframe the strategy or change the yearly OKRs. And what I'm saying may seem extremely trivial, but it happens to me all the time as a consultant to try to fix things in order to align the long-term strategy with the yearly OKRs. And then when you go one level down and you plan with your team, you write down the OKRs for the current quarter. In this case, in the example, there's a Q1. Well, then if you made sure that your long-term strategy, so what you're going to build, for whom you're going to build it, and what are the goals is actually aligned with the fiscal year OKRs. All you need to do is to make sure that the OKRs of the current quarter do not contradict actually the OKRs of the fiscal year. And just at the bottom of this, there are the real tasks and activities that you and your team are going to perform every day. Please note OKRs do not focus on these tasks. Tasks are things you're going to do in your daily job. OKRs focus just on the outcomes. For instance, if you are, I don't know, a startup founder who's trying to raise a serious A, well, don't write in your OKRs. You're going to try to speak to, I don't know, 50 possible VCs. Try to put in the OKRs that you try to raise a million for the CSA, which is the outcome and not the output. That's also another common mistake I see people doing. So when it comes on a strategy in OKRs, the important thing is that, you know, we don't have it all figured. We cannot predict the future. So what happens is that when the quarter ends, we actually haven't met all our objectives. Sometimes we miserably fail at some objectives, and that's absolutely fine. But what we need to do, we need to evaluate the things we have not accomplished and just see if strategically still makes sense to carry them over or not, or maybe to slightly change them. And the same actually happens when you do, when you compare the actual goals with the overall fiscal year OKRs. So say that now we are in July, so this is Q3, actually teams have just been planned OKRs for Q3. When we were writing down in December 2017 to 2018 OKRs, for sure we have not predicted what could have happened possibly in July. So there's nothing bad with updating the early OKRs because they're not written in stone. If things change, it's better to just update them. And this process actually, as per my experience in many teams, I know it's hard. It's hard to keep things consistently, and it simply gets better and better quarter after quarter with your team, you're going to be sharper and sharper in doing this. Another key element is that OKRs is, I see it as a powerful communication framework, communication tool, which acts bottom up and top down. So the company needs to give the initial inputs for the OKRs and then needs to also get the inputs from down the teams and the individuals. This is a very powerful tool to actually include people's angles, your team's strengths into your strategy, and make it even stronger. So let's get to the second section, which is one of my favorite OKRs and discovery. Now, product discovery is also very broad. You can do initial product discovery. You can do a doc product discovery, which means sort of periodically anytime you need it. Or you can do it continuously, which literally means every week or top every two weeks. And continuous product discovery is something that is a very advanced product practice. It means admitting the truth, which is, as product managers, can have it all figured. You can't predict the future that we said before. So we just try to discover our product in a way it's useful for our users. And we do it by staying on a weekly basis in touch with our users with interviewing, showing them our prototypes and stuff like that. So the flow of product discovery of product management actually is being split into two parts. One, which is the product discovery, in this case the continuous one, and the other which is done by the product owner and the team about building and actually shipping and delivering the product to users. So one of the powerful tools, not just the only one, but one of the most adopted ways of work when it comes under product discovery is very much allocated by Marty Kagan, the SVG principal, and is the dual track model. So as we said, there's a discovery track where mostly PM and UX people focus together with the users, and they simply run experiments. And not only experiments will actually work, some of them will work, some of them will fail. And this is why you have a discovery track, because you're just going to harvest the successful experiments, the promising experiments, and feed them to the team that are going to build the product. So you're not going to waste the team's time and the developer's time on building something users don't want. That's the key part of dual track ajar. This dual track model is also called dual track ajar. So as you can see, the two tracks are clear. But where does where do actually okay ours kick in this model. Well, something as to inform the discovery track, who actually drives this experiment. Similarly, we cannot believe that PM and UX people are so much sharp to be able to overrun the right experiment. So what you need is actually objectives informing the discovery trap. So if you look at the key phases, this is basically simply lean cycle which is spread over a single line. We need to put something ahead of discovery, and many people do it with ideas. So how does this idea let me figure if it's a valid one let me discover if users really want it. Let me show them some prototype. That's better than non discovering everything. But again, there's a flow. It doesn't tell me what your idea contributes to when we talk about product objectives when we talk about product goals and what we talk about product strategies as you seen a moment ago. As I said, this is good helps you validating whether you are the next job or not where your ideas actually after they get in the hands of users and being measured succeed or not. But that's pretty much it. Instead, it's much better to actually inform the discovery track with objectives with the objectives within your okay ours. And what if you have an idea. Well, that's still good. You can actually have a mixed approach, which is not actually trying to validate all ideas, but just to have certain objectives that inform the discovery track, and validate those ideas that are selectively matching or contributing to product objectives. That's a way better way to go. So, I'll use the last minutes, just to show you, I would look all of this in a roadmap. I tried to keep this presentation very brief to try to address all your questions, because many of you may have your own cases. So when it comes down to okay ours and product discovery and product strategy. Well, at the end of the day, as we see in the first slide, your roadmap actually derives from your strategy and your backlog should derive from the road. Again, roadmap should be consistent and should not contradict the strategy. But what I see all the time, when I jump on a new team to coach. Well, what I see is that the roadmap looks like that. So that's the roadmap for instance for 2019 for the next year. So, every quarter, the guys have planned already they're going to ship some features. That's the case. What would you even need objectives and what would you even need product discovery for you get it all figured. As we said, for the discovery means admitting to a certain extent, at least that we had, we haven't, we haven't got all figured. I'm being in an application of countrymen innovation. If you have a waterfall roadmap. This, all okay arts methodology and produce government authorities won't actually help you. Instead, what it should look like, and that's my last slide and then I'm happy to answer your questions is, you should have a roadmap that states for each quarter, at least one goal. Now the best practices of okay ours, tell us that you can have sort of, you know, three, four, five goals and three, four, five k hours each than the numbers varies depending on who's saying that. It doesn't really matter. The key thing is that our trends that try to focus for one goal at quarter for your product. It makes it way sharper, because this quarter you want to focus on, I don't know, increasing engagement, or if you're Uber this this quarter you focus on getting more rides, or whatever getting more rights in that moments of the day, for instance, evening, or mornings, whatever. So in this case you can speak at least one goal, at least one goal for each of the quarters in a roadmap. And then what happens if you have table stakes. The roadmap you've seen before is mostly table stakes. Table stakes means features you need to have in your product. For instance, if your product is sky, and you don't have a chat. Well, I mean, there's not much of an MVP you can do without a chat. So, in this case, feature a will be our chat something we have to put there, something we know, we have to ship the chat. But we need to reserve a list of capacity for features we will discover on the way. And quarter after quarter, we need to, again, reassess whether the objectives we have not met are still valid to pursue. So these features we haven't got figured, and we're going to just discover on the way. The key part is that these are all features that then actually contribute to the goal or the objectives of that specific quarter, as well as even the features that then sort of more waterfallish way the table stakes we need to have in our product, while also those, they still need to contribute to our objectives, and they still need to prove that actually contribute to those bison numbers which we call key results. So thank you very much. And for now I guess we can go for the questions. Yes. Thank you. Thank you very much, Paolo. It was great. It was very insightful. So yeah, as you said, now we're going to have a few minutes of Q&A. So, folks, please feel free to type your questions within the comments on Facebook, because I'm going to be reading some of them. If you have any questions for Paolo, I will pick some of those so he can answer them. Okay, so I'm going to start with the first question that we have here, which is from Homuria. I hope I didn't pronounce it very bad. The question is, can you please distinguish clearly between objective and key results? Yeah, sure. So objective is something inspirational. For instance, as I said, we want to increase the engagement of users. And key results are simply the numbers we're going to track to see if we met the objective. So objectives in a, you know, in a simpler way is where we want to go and key results is how do we know we are there. For instance, in the case of engagement, we can measure, I don't know, weekly active users, racing by 30% or 50%. Nice. That's a good one. I have one more question for you, which is from Shashwat. His question is, what are some components of goals in product strategy? What are some components, components of goals on product strategy? I'm not sure what components means, but if you look at product strategy, it depends on what stage the product is. But say that you want to launch a product. For instance, you're a startup, or you are even a new product initiative or spin off within an existing organization. Well, the first goal would be to get an option, for instance, to get some users, and then depends another element of the strategy will be which users. Your product is surely not for everybody, but should meet some kind of market, and that's what called market and what are defined in simple words, what the product is for. Nice. I have another question from Tommy, who says, could you speak to an appropriate prioritization method that would be in line with what you're discussing? Hi, that's a very, very good question and very interesting one. So, first of all, when you do continuous discovery and OKRs, the prioritization happened at two levels. First of all, if you have a bunch of ideas or a bunch of opportunities to validate in your discovery process, you need to pick those you actually want to go after because you don't have capacity, your team doesn't have capacity to run experiments for everything. And the second part, and in this case, the only appropriate method of prioritizing simply ideas or opportunities is comparing and contrasting them, so simply discussing it with a broader team. But then when you have some valid idea or something that has the green check mark out of your discovery track is valid, users like it, maybe they've seen a wireframe and they can enjoy it. At that point, if you have a set of valid ideas, which one is the one that you're actually going to pick? Because again, you don't have capacity and your team doesn't have capacity to do all of them or to do all of them at once. You need to choose what you want to do first. In that case, the best prioritization method I like is simply an impact effort score. So you choose how much impactful will be that valid idea for your users and how much effort it would take your team to actually build. That was a good one. I have another question from Emily. She's asking the following. Do you have an example of a goal for retention? A goal for retention? Well, for sure. A typical goal, a typical objective to be used for retention is reducing the charm. The charm is the number of users that are leaving your product or that become dormant that just don't stop using your product, even if they are theoretically still registered. And you can easily define the charm like this for a B2C product. For a B2B product, you may want to use, for instance, the revenue, the monthly recurring revenue or MRR charm. The charm, so seeing every month what are the users, the clients or the customers in this case is B2B that unsubscribe from your license of your product. These are two typical examples of retention. Perfect. Wow. We're receiving so many questions. I'm going to be able to read a few of them. The next one is from Juliana. She's asking, which are the most common mistakes companies are committing on product discovery process? Oh, that's a good one. As I said, the reason why I had this webinar about OKRs and product discovery is the key common mistake is doing product discovery without an objective. So not linking product discovery to OKRs is for me a huge mistake because you may find something valuable to your users, but that feature might not be valuable to meet your business objectives. So if you have discovered something valuable to users, but not something valuable to your strategy, then that's definitely a mistake. And the other most common mistake that companies do with product discovery is they simply don't do it. The majority of the companies, and this is what I mostly need to help actually encourage product managers and teams within my job, is are not doing discovery at all. They just building the product first and then they're giving it to users. Instead, you should first check with users and then with only what for them is valid and what meets your business objectives. Great. Flavio is asking if you can suggest a book to learn more about OKR. A book? Well, there are many, many books about if you just type OKRs on Google, you'll find more, but there are two that are my favorite. One is the original Andy's Groove book. It's a little bit dated, but it's still very valid. I think it's called High Impact Management, but I don't want to be mistaken on the title of the book. And the second is just a YouTube video, maybe Fernando Canal posting it after on Facebook. And that's a very famous popular YouTube video about OKRs by Google Ventures or Google Venture Labs. And it sort of describes how OKRs have done in Google. And as I said, John Dorr, who was Andy's colleague at Intel, he then got involved with Google at the early stages and he started really pushing Google to adopt OKRs. And from there, because of Google's brand, it got spread to many other companies around. Yeah, those are the ones. Now I'm going to add something here. As you guys know, we launched last year the product book. And it's a book that was built based on the training that we follow, the frameworks that we follow here when we train people on how to get a job as a product manager. So we are giving today this book for free. If you guys type book within the comments on Facebook, you'll get a free copy of the product book. So I encourage you to do so because it's amazing. So, Paolo, I have two more questions. One is, yeah, this one, could you please give us an example of long term objective and how to break it in objectives, key results and daily tasks? Well, that's a very good question. It will probably take a little bit more time to address. But I'll try to make up a very simple example for it. So imagine that you are a project management tool, a software as a service tool, like many on the market, your long term objective could be to become the market leader in project management tools, such as trial log, for instance, many product managers use. And in order to actually break it down in smaller steps for this year, for instance, you will like to conquer, I don't know, the small and medium businesses, part of the market. And for the year after, you will like to actually go after the enterprises and so on and so forth. So in the three or five years, you're hopefully going to reach the objectives or work at least towards the objective of becoming a leading market project management tool. Yeah, and I have one question for you, Paolo, that we always ask to all of our amazing speakers. As you know, we work with a lot of people wanting to break into product management. So I wanted to know what your biggest advice for them, what do they have to do in order to break into product management? I'll give you a secret insight. So as I said, I consult many CEOs on product management, and many times the CEOs of companies ask me, hey, I want to hire my head of product or I want to consult some metal products and ask me, hey, I want to hire my product managers. What should I look for? How these ladies or guys should look like, what skills they need to have? And for me, the answer I give is always these three things. They need to be smart, they need to be switched on because there's no substitute for intelligence. They need to be passionate about product, about product management, about users, especially about they need to buy in the product they're going to work on. And they need to be quickly learning because this job changes very fast and product management definition is so broad that depending on the team you're going to work on and the product you're going to work on, there should be so much to learn. So these are my three key advices. And I totally agree. Thank you so much, Paola, for your time. It was great. We made it on time. It was 30 minutes as we said. So thank you so much. And before we leave, I wanted to remind you guys that we have a lot of events. We have 15 campuses worldwide. So if you go to our website, productschool.com, you will see what's the campus that is closest to your place. And you can see all the onsite events that we have. We also organize these online events every week. So please go to the events section on product school to see what are the topics that you are more interested in and so on. And as I said at the beginning, in addition to hosting these free events, we also offer part-time courses for those of you who are thinking of breaking into product management. We train people on how to build great products, but also on how to get a job as a product manager. And we've helped so many people so far within teaching product managers for four years now. And it's been amazing so far. We are growing like crazy. We also have more courses. It's not only about product management perspective. We also try to cover all the aspects of the product. We have the product management course. We also have the data analytics course, coding for managers course and blockchain course. So if you guys want more information, just go to productschool.com and you'll see everything in there. It was great guys. Have a good day and I hope to see you soon. Bye-bye.