 Well, hello, everyone. My name is Johnno. I'm super excited to be here today to talk to you about a practical team-centric approach to building products. And I'll really be speaking to this idea of defining objectives and your team roadmap and your product roadmap as a collective with your engineers, your designers as well, not just as a PM on your Lonesome. A bit about me, I'm a Senior Product Manager at Atlassian. We build tools like Trello, like Jira Confluence. Currently, I am looking after platform teams, specifically how we bring in third-party data from external apps and our own data across our different first-party products and utilize that data to create various product experiences for our end users. Before that, I've worked on product teams like Jira. And prior to that, I worked at my role just before I came to Atlassian was working at Microsoft, looking after a portion of Australia, how we support startups, local startups, and help them grow. One other thing, which I do it at Atlassian, which is a big part of why I love the whole idea of product school is I'm one of the leads of our Associate Product Manager, APM program, where we bring in what we see as high-potential future product leaders and train them up to think about the craft in a very specific way. And we really help them grow very quickly into product leaders, hopefully at Atlassian, but also if they then go out into the product ecosystem into the tech world to be awesome product managers out there, too. And it's a program I actually came through when I started about three and a half years ago. So I love this idea of passing on knowledge to newer PMs in the space. And I'm still very much quite new in the space myself, so I'm continuing to learn as well. So let's get stuck in. Now, I want to start by talking about what I see as the most impactful thing a PM can do. And to me, the most impactful thing that a PM can do is, as on this slide says, create a shared understanding within their team. More specifically, to create a shared understanding of your product's objectives and problems to solve. Now, for you, you can really interpret this idea of creating a shared understanding very similar to this idea of bringing your team on the journey with you. And this is super important because as a PM, you don't have people reporting to you other than other product managers, unless that is different elsewhere. But generally, that's sort of the common structure I've seen with PMs and reporting lines. So you have to get it done through influence, not through authority. And influencing your team to run in a certain direction becomes really bloody hard when they don't have the same context about what your product is trying to achieve, the goals that you have, and the problems you're trying to solve and why what you're proposing to do is important. And I'd argue that if they don't have this context, if your engineers and your designers don't have this context and they're not asking you and challenging you, you have an even bigger problem. Because you really want to ensure that your teams are aligned and they're building the things that are most important to your customers and your end users, and equally are ensuring that what you are hoping the outcome of a certain project will be is the same as what is in their mind. So generally, I would hope that you have a culture within your teams of ensuring that your engineers are challenging you to make sure that they understand what you're building and you all agree that it is the right thing to build for your end users. And the reason I'm starting with this context is because it really speaks to the core benefits of building out objectives and inherently the key results, the metrics underneath those objectives and roadmaps as a team. Specifically, there are two key benefits that I see that are really, really important. And this is increasing and improving the engagement and motivation of your team and more selfishly effectively scaling yourself as a PM. So let's dig into that a little bit further. On the engagement and motivation front to validate this benefit, I wanna share this example that you can see on the screen from a team health survey from one of my teams recently. During COVID, as we all went remote one day, they just said middle of the day, pack up all your stuff. This was about last March, pack up all your stuff. You're going home, we don't know when we'll be bringing everyone back into the office again. And as part of that, as we moved into this very new everyone being remote world, we had a team of people that utilized research at Atlassian to build out these pilot surveys that every two weeks we would get. And it would ask questions that would, the answers would speak towards team health and happiness in this remote world. And as you can see here, some of the areas that we strived and we really nailed were the goals of my work being clear to me as an engineer and largely this was all from engineers on our team, being free to decide how people perform their work and being excited about the work they're doing at Atlassian. We scored 100% across the board and you can see on the very far right that this was quite a lot higher than other teams that were also doing these pilot program surveys. So why are these results important? Well, an outcome of your team coming together to define what you're trying to achieve is that they'll generally all understand and believe in your product's direction and how to get there. This speaks to this idea of the goals of work being clear and being excited about doing the work that they're doing at Atlassian. Now, the reason why working together to define these things will lead to their understanding and belief in direction is because they've played a part in defining that direction. You have worked with them on defining those roadmaps, taking their input on those objectives and inherently the problems that you're solving. And by doing so, your team has intrinsically become tied to its success. And this really speaks to human nature. When people play a part in creating something, they understand its reason for being as its creator and equally they cared deeply about carrying that forward. They're very much tied to its success because it has come from them and they're on the line. Their suggestion is on the line. Their name is on the line. So bringing people together by having this back and forth with your team to define your objectives, they inherently understand the goals of their work because they define those goals and they're excited about the work they're doing again because they define what we should be doing. They are motivated by their own suggestions. Now, the second benefit about scaling yourself is a bit of a selfish one. Now, I remember three and a half years ago, I started as a PM and one of the biggest things I noticed was that there's a difference between you being busy and being productive, but I always felt busy. And I'd look at more senior people or people that have been in the game a bit longer and I was just like, how the heck do they do so much more than me? Do it so effectively. But there's not like there's just magically more of them as a human. They don't suddenly grow 10 different arms and legs and can be in 10 different places at once. And for me as a newbie product manager which is trying to figure out how to prioritize my time and already feeling busy, I was just blown away and couldn't quite understand how people were spreading themselves so thin but still being effective. So this was the biggest question. I kept asking myself and others, how do you scale yourself as you take on more? And I was fortunate enough in my early days I met one of through somewhere I don't even remember one of the VPs of the guy that could drive drove Google photos from its early inception and he'd recently moved to Australia in Sydney. And I would go to the Google officers and we just sat down in a room and jammed on a lightboard about random questions I had. And one of the big ones I asked was this, like, man, how do you scale yourself? And he was like, yeah, sure, I have become, obviously I've got a lot more experience than you I know where to prioritize my time but I'm not some superhuman. I just have more people to help. I have a chief of staff, I have all these teams around me I have amazing people that understand what we're doing and I can pass off work to them. And it's so simple, but it really clicked with me. I was like, oh, that makes tons of sense. This speaks to the notion of creating a shared understanding. If more people have context, it's way easier to hand off things to others to own with confidence that they'll make the right calls based off what your team is trying to achieve holistically. And this speaks to on that survey that I just showed you that goal that there was, sorry, the result that there was around, they have freedom to choose what they do. And I can confidently afford them this freedom because I know they understand where we're heading and they will make the right decisions based off that understanding. So for me as a PM, I've been able to, I went from one team where I was, there were two PMs with five engineers to one stage I've had three to four teams underneath me and this was still while I was an APM and I was significantly more effective when I had more teams and it was just as I became better at creating a shared understanding and then using that shared understanding to effectively delegate my work and scale myself. So that's been hugely impactful to me and this is something that I try to pass on to other newbie APMs as they're coming up the ranks and coming into Atlassian. So to summarize the core benefits of creating a shared understanding and doing so by working together on objective definition and roadmap definition is firstly, improving engagement and motivation of your team and a happy team is all that you can ask for. It really provides a happy team, generally will deliver a much higher quality product because you have engaged people and it also enables you as a PM to better scale yourself. That's what I apologize, I'm continuously trying to push this headphone into my ears. I'm sorry about that. So now let's talk about the meat and potatoes. Like what is the actual tangible process that we go through to do this as a team? Well, really at a high level, it's quite a simple set of steps. I start with defining the objectives and inherently the key results underneath those as a team and to do that, I start with setting some context through a presentation. We then ideate and prioritize as a team and then my leadership team will go away and refine and share back. Once we have those objectives and key results, we then utilize that to feed into our roadmap. What are the problems that we are going to focus on solving based on those objectives we're trying to achieve? And again, I set context, we ideate as a team, prioritize and then refine and share. So let's start with defining objectives as a team. What does that really look like? Well, very simply, we generally will put a two-hour session aside and with this session, we will do a number of things. I will firstly start with a context-setting presentation about the company and organization objectives that we ladder up into. I then level set, I'll come down to the team level, talk about the team mission and insights that then help us suggest and move towards, okay, based off that mission, those insights, what are the potential problems we could solve and then we work on actual okay, our objective and key result ideation. And a really important thing about this is I will usually go into this knowing the sort of key results, the sort of objectives and key results that I want. And it's just because I've thought a lot more deeply about it, it's my job to do that versus engineers that have a lot of other things that they're the builders on the team, right? And it's my job to lead them towards that place that I've already settled on. But doing so in a manner where they still have their input, they can challenge me on things, we can mold my thinking even further, but inherently you'll come to the same end state, but do that in a very constructive team-specific way and collaborative way. And that's why it's important as I go through this, you'll notice that I will start, I will use some of those product insights to suggest some potential problems to solve and start to follow them towards general areas of focus that we could define objectives around. So let's start with the presentation. I start off with it's the most important thing is understanding the world you live in. So I will context that by explaining what the company objective and key results are for the year ahead or whatever the time period is, a quarter, half a year a year. And this is important to understand what are we laddering up into? And I'll go deep on each of the objectives and the key results and I'll then focus in and pick out the key results and objectives that my team should be thinking about the most in terms of contributing to. We're obviously not going to contribute to absolutely all of them or it's unlikely we would. So I go a little bit deeper on the ones that are specific to us and I'll explain to the team, this is based off these objectives and key results and who we are as a team. These are the ones that we'll probably think more about leaning into. With the context and understanding of the higher level, the org and the company that we work within, all the end level set and our team should already know this but I keep hammering it home. What is the mission of our team? So this is a past mission for one of my teams to enable and express it to editing experience through media and links. I won't go into depth now, but I would touch upon like, what does it mean to be expressive? What does this idea of media and links, what does that remit encapsulate? So I will have started with the global optima, what is the company trying to achieve and what are we trying to achieve as a team? And then I'll start to give them context about the things that we could think about. So for both links and media, I will talk through firstly, some insights, some qualitative and quantitative data. You see I'm not sharing you the exacts here because unfortunately I can't. I'll walk through some numbers, some qualitative data as well and talk about what those things potentially mean. And I'll do the same for the media, the other part of our mission using the example I had before for the team. And then based off that, I will then pull out some of the core problems. And I'll say like, based off those numbers, these are the problems or opportunities that we have that we could focus on. So a real world example was in the past, we noticed that in JIRA or in Confluence, one of our products where people were in a page or a description or a comment, they were going and say they were in a Confluence page, they were going and finding Confluence pages elsewhere and then copy and pasting those links in. So we saw a huge amount of links from other pages being inserted into Confluence pages. And we had this shortcut link picker where you could press Command K and this link picker would pop up while you're on the page and you could search for other pages and insert. But we realized no one was using it or very few people were using it and we were also getting a lot of complaints about it. And this was when we looked into it, implementation way back in the day didn't allow for a user to search across all of their pages. It would only give them a very small subset. So they were essentially not being provided the ability to really find what they were looking for. They only would be able to search within a small subset of pages which generally didn't give them what they needed. So TLDR, first party search, searching for other pages within the same product was really poor. So for me, one of the things I talked about was like this is something given the amount of usage, the amount of feedback we get that we could probably start to think about. So once I've gone through that context setting, we then would jump into a whiteboarding app of choosing move to a prioritization session where the output would look something like this. Along the top, those colored boxes are the objectives that we came to and then we would generally have a couple, one, two, three key results under each. So how do we get there? This is the end state. For objective ideation, we firstly start by like what are our O's? What are our objectives? What are the goals? And I would start with a blank board and here I would have two groups based off our mission. So one focus area is the links, one was media and we'd spend about 10 minutes and people would just dump down ideas about objectives. I'd give them some example objectives so they could understand sort of the wording, the framing and then they would just, the team would just throw down ideas and this, when I talk about the team, this is my entire team. It's my, me as a PM, my engineering manager, my design lead and then all the engineers that sit on that team. And then after that, we would go through and group these. So they were generally similar areas that people would write objectives about. For example, search or performance and reliability or more something experiences. So we would group these into themes and then we would vote as a team and we would vote on the ones that we thought were the most important to focus in on the things that we could have the most impact on during the coming year. Again, based on the understanding of what our company is trying to achieve, what our mission is, some of the insights that I've provided. So based off this, we come to a point of view, okay, these are the most important things and I very quickly create rough. I would take all of those ideas and turn it into a very roughly worded objective. So we would then have our core objectives that we decided were most important. So one example here is, provide a reliable, scalable and performant links and media experiences. Or users can easily find and insert the media and links they're looking for speaking to this idea of search. Now, once we had our objectives, we would do the same for key result ideation. We would set aside some time and I would use some examples of what key results could look like and then everyone would just ideate and dump down ideas for key results that would speak to those, how we could measure success of those objectives. And again, we would group and vote on the different themes of key results. Based off that, our end state would be, we would have a very rough directional idea of our objectives and prioritized key results for the year. Now, one important part here is that I would always explain to the team is like, this is directionally what it would look like, but I would then go away and work with my leadership team and the leadership teams around me, the leadership teams above me to make sure that exactly what we were proposing fit into what they were thinking about and any dependencies we had. So there was a little bit of, there was definitely refinement after the fact, but it was centered around what we had defined here. As a team. And once I had that, then I would share it back to the team as kind of a final state of what our objectives and key results were. Again, based off what we had done as a team. Now, once we had that, I would set up another time. We now knew what our objectives were, where we were heading, what our key results were. It was now time to actually think about our roadmap and the problems that we were gonna solve in moving forward those objectives and key results we had defined. So we would generally start with some context setting and ideation and about a week or a few days before the road mapping session, which again was about two hours, an hour to two hours. I'd create a page and this page would have at the top in that blue box. I think it's blue, I'm colorblind, it could be purple. Pretty sure it's blue. The three objectives that we had decided on. And then I would just have a table and table have rows and for each row, there were four columns. The customer problem that we thought was important to solve and you would have to go in and add what that problem was context there. An idea for to give people an understanding of tangibly how this could come to life in the product. And I am not advocating for starting with an idea first. I'm definitely advocating for start with a problem, but the idea just helps people understand how this could play out in the product. The impact that we see it could have. And again, with the impact and with the problem, I would suggest adding some for this example, I don't actually have the customer data added here, but we'd always suggest the team add customer data and the data points qualitative, quantitative, and then making sure that they referenced the objective that it was in service of. So this first line around first party link search improvements spoke to this idea of users can easily find an insert, the medium links they're looking for that third objective. So we would ask the team to just go away and throw down this is a rough ideation in the lead up async ideation of different problems we could solve. And I would just get this huge list of ideas and problems that we could think about solving. And before the session, I would call some of them just based off and I set the context of the team that there's a lot of other things going on. And there were some things that I just knew that we wouldn't get to. So to ensure that we were a little bit more focused during the collaborative session, I would remove a bunch of stuff, but I would still have a heap of ideas. And then as we moved into the session, we would again use a white boarding tool and I'd have each of the objectives. You can see those boxes along the top and then under each objective for the ideas and problems to solve that remained, I would just list them on post-its below each one. And then on the right, you can see this impact and urgency matrix. And we use this to have a discussion and start to prioritize the different problems, the different roadmap items that we could solve. And the importance and the value of this is it is a relative prioritization session. I'll speak to what that means, but it allows us to bring in each potential roadmap item and have a discussion around its importance based on these two axes, as well as its importance against each of the other potential problems we could solve. So the way it works is we start by pulling in the first idea or problem to solve. And we have a discussion as a team around what is its potential impact? Is it really high? Is what's its urgency based off what we know? And we would just roughly guess where it could land. It's not super important to get this right at the start. Then we'd pull in the second idea and we'd have the same conversation. And as you can see here, we had a discussion about its relative priority to the first problem that we pulled on, the first idea we pulled on. And we realized that this was more urgent, more impactful, and the idea that we'd initially put on was a little bit lower in terms of urgency and impact. So we started to shuffle things around. And we would just continue this as we would have a discussion and move things around based off impact urgency and the other potential roadmap items that were there. And eventually we'd get to this state. And again, it does not need to be perfect. But here you can see that we have based off discussions we've had as a team around the different problems and how they ladder into our goals. Where things would land. And you get this final state. Now the next thing that you do is we draw these lines. And what these lines mean, it splits it up into three, this matrix into three parts. The top third are the things that we list as must do. Middle third is nice to do or nice to have. And the bottom third is all the things that we probably won't get to. And this is not set in stone, but it gives us a relative priority and a directional sense of our priorities for our roadmap that we should be working on. So I would then go away and take all these ideas and the things in the must do would come at the top of our roadmap. Nice to do would come further below and won't do would come below that. And in this session, we would also probably just write, we generally will just write a list of all these. So we'll end up stack ranking them one after the other. Because as you can see, they're kind of a bit all over the place. So we would decide and the must do is what comes first, second, third, et cetera. And the output of this is a roadmap in a similar template, a similar table format, which just talks to that stack rank, those stack ranked problems and the priority of those and the objectives that it ladders up into. Again, I would go away with my leadership team and we would refine it based on dependencies, other things that we would understand outside of impact or urgency or things that we had discussed in the meeting and we'd shuffle things around slightly but it would largely stay directionally correct and we'd end up with a roadmap that looks like this. And we would share this back to the team based off our objectives and the sessions that we had done. This is the roadmap. And one thing to call out here is I am not advocating for a year long roadmap set in stone. That is an anti pattern. Please do not do that. The things closer to the start of the roadmap, we have more context about so they are likely to stay where they are. As you get further down the roadmap, it's directionally correct. It's not, there's still a lot of gray areas there. As customer needs change, this information, new information comes to light, those things will probably shift but it gives us a general idea of where we're heading. So now we have objectives, key results and goals and sorry, and roadmap items. And to recap what that set of steps to get there was, we would start with objectives. I'd set context of the presentation. We'd ideate and prioritize as a team and then my leadership team, my triad being myself as a PM, my engineering manager and my design lead, we would refine and share it. We then set off a second roadmaping session. We're prior to that, I'd give some context about the objectives that we needed to ladder up into and I'd ask the team in an asynchronous manner to ideate. We would then work in a collaborative way in a session on prioritization. Again, my leadership team would refine and share that back to the point where we actually had a roadmap. So with that said, I wanna kind of wrap up the key takeaways that I hope you will walk away from this session with. And they're really three things. The first is it is imperative that you build a shared understanding as a PM. This to me is the most impactful thing you can do. The rest in terms of building a successful product to my mind will follow. The second is a way that you can do this is by defining objectives and your roadmap as a team. And this has two really key benefits. It increases motivation and engagement of your team but it also enables you to better scale yourself as a PM. Now the last piece that I didn't speak a lot about or much at all really is to iterate and mold the process to suit your team and ways of working. Consider what I've shared as a boilerplate, a template for how you can test out this process. But for us as well, every time we run this, we change things slightly. We realize what works, what doesn't work, the sort of information that I share that is or isn't valuable. And we're constantly tweaking this to make sure that these sessions are as valuable as possible and continue to evolve with the way that our company works but also the way that our team works and prefers to work. So key takeaways, most important thing, build a shared understanding. You can do this by defining objectives and roadmap as a team and it has a bunch of awesome benefits. And this process is not set in stone. Please iterate and mold it in a way that works and makes sense for your team. So that's it, I'm gonna leave you with this. I really hope that by understanding and utilizing some of these techniques and processes that I've shared, you can go away and work better with your teams to build amazing products. And for me, I always think about this, it's quite corny, the idea of having one team, one dream and this coherent shared understanding as a team really enables you to work better, to build better products. And hopefully if you do these things, you too could see survey results like this where your team is incredibly motivated, incredibly clear on what they're trying to do and incredibly free in the sort of approach they take to get their work done. So with that, I'm gonna leave you. Thank you so much. It has been an honor to have a chat to you today. So thanks a lot.