(upbeat music) - Thank you so much.
Hi, everyone.
I guess the click-bait title sort of worked. Like Megan said, I am a product manager at Atlassian. I worked at a few startups.
Uh yeah, I wanted to talk about a topic that I've been trying to do myself and hopefully share some of the learnings.
So I wanna talk about how to get your team to start thinking like a product manager.
But first, I wanted to tell you a bit more about essentially what I do at Atlassian and how I even wanted to even start thinking this way. So Atlassian if you don't know, we build software tools for teams, we have a few products like JIRA, JIRA Service sister core. Helping software teams essentially deliver on their projects.
So it's like a project management tool.
We have other tools like Confluence, which is where you kind of store like your documents and stuff like that.
Trello, most people I imagine use Trello Bitbucket.
Stride is something that recently went away, but we still miss you Stride.
And Statuspage was like a tool that you put your status on in the Atlassian marketplace. Plus a lot more.
I don't work on any of those.
So if you have any complaints about JIRA, or Confluence, don't talk to me.
(chuckles) I actually work on the platform team.
So I know if you've been in the previous talks, we've talked a little bit about that.
We build cross product experiences for all of the tools essentially.
So for example, if you wanna upload a file, we wanna make sure the way that you upload a file is consistent no matter what Atlassian tool you're using. If you wanna mention someone the way that you mentioned someone is gonna be the same no matter what tool you're using. So that's me.
Yeah, like Megan said, I used to work in a lot of startups. So when I first joined Atlassian this was really my expectation of a team you know, one PM, one designer the average is around like four five engineers to a PM. But little did I know when I first joined, I had 20 people on my team and they were working on by like five projects. It was all around the same space.
But still, it's still like five different problems we're trying to solve.
And being in a large organisation working on a platform team that has about like 20 products or something. You are doing a lot of coordination.
And so usually the PM is the kind of the centre person of it all trying to talk to all these products and trying to understand what needs they want and kind of see what we need to build.
And so before long, I was like, wow, this is this is me, like I saw this GIF and I was like, holy shit. This is literally my life as a product manager. Sorry if I can't swear.
Because like everything was on fire.
I was like I was doing everything was coming to me. Good thing that Stan did a talk because he talked about a lot of the problems that I was having.
But essentially I was becoming the bottleneck, right? Like everyone would heavily rely on my opinions to do the next thing like asking question like, I appreciate that you appreciate my opinion. But there's so much going on.
And I was focusing a lot on the short term, so just day to day just really trying to unblock the team so that they can continue working. And so I didn't really have a really good chance to focus on long term strategy.
Why was this happening? Well, I mean, the team didn't really understand, like, why we were doing things.
And you know, you might see this in a lot of product talks, but I'm really understanding why it's really, really hot.
Like, you can tell people a problem statement, they're like, "Oh, sure, yeah, it's a problem.
"Yeah, we should solve it." But they didn't really understand.
Like, why was this problem so important? They didn't really have the context that I had, that the leaders had.
And that's why they were coming to me for all of those questions and couldn't really be empowered.
And that's why I am super passionate about to stop democratising what's in my head so everyone can start thinking a bit like me, because usually PMs you do all the research do have to what you are expected to be the expert of your field.
But you really need to start at least especially on a scale yourself.
So I wanna talk about that.
So you need to bring them on the journey.
And by bringing them on the journey, and I'll share a bit of tips on how you can kind of do that. Your team can be empowered to stop making some of those decisions on their own. Instead of like asking you every single day what to do, maybe it's like once a week, once a fortnight, they can be as engaged as you are in the problem. And we know that if they're engaged, they're going to be way happier, they're going to be way more excited.
So as a PM you can really affect how your team feels about work. And then your team can actually focus a bit on the new term, you know, actually work day to day really get that work done.
While you can start thinking about like what is next. So I'm gonna have three tips about what I kind of do today. Hopefully, these things you can easily implement in your day to day work.
Very first one is that review feedback as a team, often times So this is like a feedback collected that we have, you might have other places where you store feedback. But essentially, a very practical thing that we do in my team is that we have a feed weekly feedback review, and we treat it as important as sprint planning. We treat it as important as retros part of the practises that we do.
And so we put into the calendar 30 minutes every week, depends how much feedback we get, we get about like 10 or 12 per week on our subject, and everyone is invited, everyone has access to that feedback.
What we do usually is depending how much feedback we get, we split the feedback.
And so you would label the feedback, normal stuff that you kind of do as a PM but you're really getting the whole team involved and you would reply to the customer.
So the engineering team is involved, sometimes you can invite the marketing first depends who you kind of work with.
And if you really want, we do have like a template as well on like, you know, these are the labels that you have. This is what the reply usually is, if it's about this problem, just so you can have consistent messaging to customers, but you don't even really need to do all that You can just like start it.
And then like, you know, create tickets as needed.
Like the engineering team, anyone can start creating tickets if they think it's important.
But what is like the really also thing that changed my world was just finding a way to automatically send notifications about feedback to your team, like to your whole team, to the 20 engineer to the 15.
You can do it through JIRA using the issue collector, which is what we use obviously.
And you can subscribe your whole team's every single day when they're on the train.
They just take out the mobile and they look at the first email which is the customer feedback email, and then they can stop building this thing very likely. Two minutes a day.
It's super easy.
We also have like stuff like slack box box that you can connect.
Probably the most incredible thing, even if you don't do the weekly feedback review, doing this one thing will just build this understanding without you having to do slides, documents, however way you can of doing it.
And so what kind of happens like magic happens, let me tell you, like I see from an engineer's asking me, "hey, should we prioritise this" to them being like, I think we need to prioritise this.
We've been getting feedback on this every single day. And I'm like, yeah, done.
Cool. Like, I don't know what my job is anymore. You know, like, they're doing it.
It's awesome.
And the second thing that I think really worked well, at least in the 20 person context, was this concept of a feature lead who has who knows what a feature leader is? Awesome, cool.
So I'm glad I can like share a little bit.
So at Atlassian and maybe another company There's usually three, I guess like leadership type roles.
One is a team lead, so or tech lead or engineering manager, they usually, depending on the company look off to like the technical directions and the engineers and the growth and the coaching.
Then you have the product manager, and you have a designer.
A feature lead is kind of like a leadership role, but not exactly like, functionally.
So it's usually an engineer.
And this is a good definition by thought works feature lead is essentially responsible for coordinating and driving the team towards successful delivery of a feature of your service or your product. And so, typical responsibilities, you can define these yourself, but the whole idea is that you have this one person that owns the feature, while the delivery of the feature and they work with the PM to really understand that problem and requirements.
So usually as a PM, it's very easy to get the people you work very closely with to understand how you think This enables you to kind of do it with the engineers that you might not get as much like FaceTime with. They drive the technical direction based on those requirements and the problem and they break down the work.
And they usually kind of drive the executional pot without the teams.
The key thing about a feature lead It's like it's not one person forever.
It's something that people can rotate.
If you have an engineer that you think is a really good has like a good product mindset, or has responded like capabilities, it's usually that person, you can have many feature leads, depending how many features you have.
So three or four at a time if you really want and eventually, you'd hope that everyone in your team has this chance to be a feature lead.
What I love about the concept of feature leads is that it's a great growing opportunity for engineers. But the second one is the fact that you can actually really start to work closely with feature person.
I think especially as a product manager, I'm always talking to customers, you know, the products and stuff like that. And I did interact with the team, but definitely not as much as I'd like, I definitely work with my tech lead and my designer a lot.
But feature leads, because you work so closely with them, you do like weeklies with them.
It's a really good way for you to really get to know each of these people and building that trust doesn't hurt anyone. And the third tip I have is set up a prioritisation framework.
And I think most product people have that in their head, but actually kind of writing up on a document and every and actually practising that with your team is probably where I think is the most important. For it's the first thing you probably do at least the last thing is like we set high level goals or OKRs.
Check out to ability if you want to learn more about it. But essentially, most teams have an OKR.
And this is like the North Star that the heading towards O stands for objectives. key results is how you might measure whether you're reaching that goal or not.
So for example, this is like an allocation of one of my teams that I used to work with 40% of the team is going to be what we call keep the lights on bugs, customer feedback, tech, debt, reliability, performance, all those sort of things. And then the rest of them will be working on OKRs, essentially, and you might have one OKR that you're working on, in the case of my 20 engineering team we had two so for example, we had an OKR objective around like getting more enterprise customers being better at enterprise.
And another one is to make customers essentially love us a bit more on certain products.
And two areas when my engine this is actually something my engineering manager suggested to me and also I don't know, like, should we really prioritise as a team? Isn't that gonna be really hard for 20 engineers and we're like, how can we get alignment? That's impossible.
But as long as you get the high level basics, right, and you really explained what you're doing and why. So with the OKRs, they really need to understand why exactly we're doing that this actually worked magically.
And I was so surprised that we were actually pretty aligned. That being said, like the ordering might be a little different.
But again, the goal is, is still there.
And the best part about this is that you get everyone in that mindset.
So simple things you can do is just pretty much write down all the things you could do for set goals.
Everyone probably has some ideas in their head or things that you already thought about either sticky notes spreadsheet, however you want to do it have a framework. So this is a very simple two matrix ones.
I've had spreadsheets that I did like four or five things that I'm thinking about, but like 10 but this is just an example.
So you have your goal at the very top that could be OKRs or some other thing that you however you want to do your goals and the impact is like okay, which thing actually helps us achieve this goal the most. And it's that thinking that is really important more so than anything getting your teams to practise that. Because so often I think they just, they're just like, oh, PM, what do you reckon? I'm like, yeah, this because x y z, but you know, that's not the best way.
And then yeah, you kind of prioritise as a team. And you have really great conversations like these. You know, somewhat an engineer might say, like, which one is more important? And you don't answer.
I try not to answer nowadays.
I try to like ask them like, "Hey, what do you actually think?" Because I already have the answer in my head but trying to kind of build that knowledge. And then you start have like seeing people actually suggesting stuff to you.
And you're like, Oh, well, this is really important. Because customers are asking for it.
I'm like, yeah, that's cool.
customers are asking us for everything right? But does it help us with our goal? And then eventually, you're going to see people asking you let's say your team about "Hey, can we do this," and they're just going to answer them that "no, it's not part of our goals this year, "sorry, we'll kind of think about a bit later." And then, like, proud PM right here.
So these are essentially the three tips I had. One is try to have practises just like you do with sprint planning goals, review customer feedback, it's a great, great way for you to actually show that whatever your team is doing is actually, you know, people are noticing people do care to introduce the concept of feature leads or something similar, pretty much that elevated, not elevated, sorry, you know, that person that has capability to really, you know, be your partner in crime for the product or the feature. And thirdly, where possible, prioritise as a team, really get them to think the way that you do try to ask a bit more questions in it like finances. Other tips that you could do as well is if you have demos, I think traditionally, a lot of them are just like engineering demos, but you could kind of just share people like what you've learned about the customer this week, some cool metrics that you've been looking at. I think that could be a really good way.
Where possible, invite everyone like your engineering team and your the team that you kind of work with the most need to like vision setting workshops, project kickoffs, design sprints.
Often times people be like, "Oh, I don't want that many people." So there is a like, balancing act there.
But I think at least get some people to be able to participate in each of these where possible would be a really great thing.
And try to stay out of the backlog.
This is like something that at Atlassian that we kind of like it's a philosophy around that. If you're going to the backlog as a PM, you're going to into the details and you should kind of level yourself a little bit up a lot harder said than done. But if you start kind of building this capability within your teams, you can can see that will happen naturally. So before PMs make all the decisions not true after hopefully you can have PMs strive like more the major ones will the critical strategic ones.
And the team is empowered to make some of the more like little not the little ones were more like day to day things before PMs prioritise everything after you know the PMs actually set a framework and a goal way for people to prioritise like focus areas and stuff like that.
And PMs are the experts on the problem.
No, that's not true, you should make sure that everyone in your team is an expert on the problem. So your role is essentially creating a shared understanding so that they are empowered.
And by doing this you can do like so many benefits like increased velocity.
They don't need to they don't have bottlenecks. They can just do it like actually make decisions themselves. The team is way more engaged and excited about what they're doing.
And that (mumbles) My favourite part about being a PM is passing a team being as passionate as I am as this thing. And then you can actually focus on the long term. So I think like who as a as a PM who has ever said like, "oh, man, I do too much strategy work." Never.
I never do too much strategy work.
I wish I did more of it.
And I think at the end of the day, you just have better solutions because people understand the problem a lot more.
If they don't understand the problem, they might not question whether this is the right solution. And we all know that the collective brain is a lot more powerful, and everyone has something to bring to the table, especially when they're not a PM.
So I definitely encourage it.
And I want to kind of finish off with one of my favourite quotes by Marty Cagan.
"Great product teams are made up of ordinary people "who are empowered and inspired." So in no way he doesn't mean that you know, your team has to be like super awesome in order for this to be happen.
A really important role as a product leader or a product person is to make sure that they are empowered and inspired by the vision and then they can do awesome things.
And thank you. That's all I had.
(upbeat music)
