Popular misconceptions in the product craft

(simple electronic music) (applause) - Thanks John, hello everyone, are we good? Recovered from last night? Yes, quite? All right, let's see how we go.

I'm gonna be talking about misconceptions today. And I wonder, if you think about some popular misconceptions, what might come to your mind. I was trying to think about the earliest misconception I possibly could have had.

And I couldn't think of quite what that may be. So I did what every project manager does, when they get stuck.

I asked my mum for advice.

And she told me that apparently, when I was a toddler, I used to think that when you kissed a girl, that's how she got pregnant.

So sufficiently embarrassing misconceptions. And I assure you I eventually worked that one out. I have two beautiful children.

Abigail, my daughter, it was her birthday yesterday, her fourth birthday's really exciting to share. Today, you'll be glad to know, I'll be sharing misconceptions, not of my childhood memories, so it's okay. If you'd like to know them, I'll tell you afterwards. But of the product management craft.

And these misconceptions have been built, really over my 10 years of experience of doing product at Atlassian.

I've seen the product management team go from about 10 people, when I joined, to nearly a 150 product managers, just at Atlassian. And at the same token, I get to speak to a lot of customers.

Some of you who are here today.

Who, many of which are product managers.

So when I'm doing research for the products that I work on, I'm sort of interviewing product managers, and trying to learn about their craft.

And so, over the years, I've just been building up this thing in the back of my mind, about these misconceptions that I've seen, debunked multiple times, over the years.

And I wanted to share that with you today.

So let's dive straight into it.

The misconceptions that I'll pick today, I've tried to pick three broad categories, I initially had five, and then I've just tried to dump it down to three.

So I picked one from just the day to day work of product management, the kind of stuff you do everyday. And then I've picked another misconception of working with other teams.

And the last misconception I'll talk about, is really about progressing your career as a product manager.

So, let's start to debunk some myths.

The first misconception.

Product managers make all the decisions, right? I noticed something when I started product management 10 years ago.

I arrived at my desk, and engineers would come to your desk, and they ask you for something, and you answer it, or you unblock people.

You feel like you're always unblocking people. And I felt great.

More and more people were coming to my desk, asking for more and more things to be unblocked. Questions about what colour to make this button, or what decision are we gonna make about this feature, and, you feel like part of your role is to be interrupted, and to unblock your team. You do more and more of this over time, and all of a sudden you just feel like, I've just got way, way too much to do, and I have literally no time to focus on the bigger picture.

I don't know about you guys, 10 years ago.

I still feel this, time and time again.

And I expect a lot of project managers that still feel like they struggle with this on a regular basis. It was a few years ago that I was having a one-on-one with my manager.

And I was in this venting session.

You know those one-on-ones where you just like unloading. Like, I need to do this, I need to do that, and I've got this coming up, and I've got to do this. And, you know those conversations you have with your manager where, or with someone, they look like they're not really listening. They're sort of like looking straight past you. Waiting for you to finish your blurb, and then they'll get their five cents in.

It was one of those conversations.

So I finish unloading and she's looking at me, and she's like, uh, that's great Sherif, that's great. You just need to find more time on the more strategic things.

The strategic things? I mean like, who in the world that sits around, and they're like going, oh I've got way too much time to spend on their strategy.

This product manager doesn't exist, right? We're always told we're not spending enough time on the bigger picture, the strategic things. But we've got so much to do, on the everyday work, it feels like this nirvana's impossible to reach. And so, over the years, I've been mentoring a lot of people and going through the struggle myself.

And I think what the big shift that we need to make, as our product management discipline, is to change our mindset on this product managers own, or this decision making statement.

And we're supposed to flip it around, and actually think about, hey, we own the velocity and speed at which our team should be making decisions.

And I think if you approach it from that perspective, you can end up with quite a different outcome, that will hopefully, or I should say, I have seen multiple times, enable you to focus on the bigger picture.

So, how do you do this? How do you focus on the velocity of decision making? Well, there's a lot of decision making frameworks out there. You've heard about Amazon's famous two way doors. Maybe you've heard of, someone yesterday talked about RACI.

Think it was David talking about the decision making framework.

There's another one called a DACI.

There's a tree framework that talks about how to focus on big decisions and small decisions. You should Google, 'cause if you don't have a decision making framework in your tool belt, you should Google some, there's a heap out there. They're all helpful, in helping you make a good decision. I don't think a lot of them are helpful in helping you speed up decision making as a team.

If I were to share the one thing that I've seen that helps all teams speed up decision making, it's this; it's to build a shared understanding as a team. What they're really doing, is teams are building this really, this shared brain.

This shared knowledge.

A shared understanding of what? It's a shared understanding of the customer, the problems, the product vision and the product strategy. It sounds really fluffy, but in reality, if you spend your time focusing on building the shared understanding, with your team, rather than taking on the decision yourself. The speed at which your team will make decisions will increase significantly.

And so, there are lots of things you could be doing to doing shared understanding.

But it's hard, because every day, there's lots of little things you know you need to do. You know I speak to a lot of product managers. John was saying earlier, I work for Atlassian, and yet we make the product, Jira.

I'll take your feedback later, save it for the coffee drinks.

But, it pains me, the amount of product managers I speak to, that spend their time on their Jira backlogs. Actually I was talking, some of your screens. Some of those of you had laptops yesterday, and a few of you were spending a lot of time in your Jira backlogs.

Stay away from your backlogs.

Run, as fast as you can.

This is not because you are more important than everyone else in your team.

I think this is because you have a context, that the rest of your team doesn't.

Why is it that you think you have the knowledge to drag this card, and make it more important than this card? There's some context in your mind that the rest of the team doesn't.

And you just haven't empowered them to do that. So you need to think about what is the thing that I'm about to do, and how can I empower the rest of my team to do that. Does that make sense? So how do you build a shared understanding? Well, I'm hoping, we heard a lot about some of these frameworks yesterday.

But you're all building your tool belts, or your toolkits, or your plays, for all the different techniques that you could do as a product manager.

To improve your understanding of the customer, the problems, your product vision and strategy. You will just grow these, your own personal tool box, over the years of your career path.

But the trick here is, these activities that you do, when I Speak to so many product managers, they do them by themselves.

That is a very ineffective use of your time. In fact, I would argue, almost a waste of your time in many scenarios.

If you do these activities with a group of people, your team.

You reach that aha moment as a collective.

And you empower them with a context that you had. Does that make sense? As a really simple example.

A personal policy of mine is, I never do a bit of customer research or a customer review by myself. I just refuse to do it.

I'll line up an interview, I'll have engineers on a roster, on a page, and I'll cherry pick off the top, who's joining me for the interview. I'll have designers join me all the time.

I'll bring the writers, I'll bring the marketers with me. The number of times the people in the room that get their own light bulb moment for themselves, and then end up being twice as more engaged. Way more customer context, and can speed up decision making themselves, without coming to me, as a consequence of this, is incredible.

Like I lose count of the amount of times this happens. And you're really just empowering them to make decisions a whole lot faster.

So these activities that you're probably gonna do this week and next week, you're gonna do, so maybe you've done it by yourself.

Have a think about who else can I pull in with me, to do this together.

And you'll find it speeds up this decision making velocity in your team.

So the next question I ask is, okay, shared understanding, I get it.

I'm doing stuff as a team, and building product's a team sport, so involve them in that whole process. How do I know when I've reached it.

How do I know when I've got there.

I don't know if you ever reach that understanding completely.

We can always be doing more to learn more about our customers and our problems and our needs. This never-ending pool of market research that I know we could all do.

But I think what you can do is identify where the gaps lie, in your team shared understanding, and focus on that.

So find out where you can spend your time.

So, how do you do this? I've created a very simple framework that stuck with me over the years.

I call it the three Ws.

The Who, the What and the Why.

So have a think about these three questions. You are gonna ask your team these three questions. I have enough customer context and feedback for what I'm working on, the who.

Like who am I doing this for? The what, I understand the customer problem I'm working on. And the why, I understand why on earth are we even doing this.

How it fits in the bigger picture.

How it fits in the product strategy.

The who, the what and the why, the three Ws. Now, the thing is, the "I" here is not you as the product manager, it's your team.

It's the person you're talking to.

So if you're on a small team, you wanna be going out for coffee with your engineers and your team members. Having these discussions and talking about; "hey, do you understand what we're doing, "and what we're not doing?" The larger teams I've seen, I've seen a few teams do this at Atlassian, is they'll run a survey, like a quarterly survey.

I'm generally not a big fan of surveys, but this works pretty well.

Rate from one to five sort of thing.

Like, where do you think you are, in understanding the who, the what and the why.

Ask your team.

Measure it.

You'll get feedback.

And ask them, if they gave something a three, why did they rate it a three? Like, what do you think you're missing? And this is a simple example, the team sort of knows who they're building it for.

They really understand the problem they're solving, but maybe in this example, they don't know the why. They don't have the context.

Okay, so your job here is to work out, what do I need to do to get that two to a four, or a five.

So you'll talk to them, and you'll find out what's going, do you know why we're not doing it as a business perspective? Do you know why we're doing it from a customer perspective, or the product strategy, or how it fits in our vision? And then you'll go back to your plays, your playbook, all the little techniques you've been building them out with.

Learned about yesterday, all the frameworks, to fill that gap.

Go and do the discovery together.

Go and do the customer interviews together. Do the research together.

Analyse the analytics together.

And then come back and then go, all right, did we get that context? So all you're trying to do here is identify the context that you have, where are the gaps that the team doesn't have that context.

And then you're gonna try to fill it.

And you just rinse and repeat, and you'll never get a five, five, five here.

And if you do, come let me know, that's pretty awesome. But you're just trying to continuously improve. Your team will always grow and shrink, and you'll lose and get people.

And you'll always need to level-set people. Alignment, is a constant challenge.

The other thing you could do is start from the opposite. So start, what success might look like.

I asked a whole bunch of product managers, how do you know that you've got shared understanding. What are some of the signals for success that you've seen in the past? People say things like, you know, I haven't seen my Jira backlog for months, and everything's going fine. That could mean either two things, you're doing a terrible job as a product manager, (laughs) or you're doing a really good job.

It's one of those two extremes, it's very rarely in the middle.

But it's a good sign that the team can take on the day to day prioritisation work. And you've spent time just aligning on the goals for this sprint.

That's a really good sign.

Maybe your team challenges you with something that there is in their backlog, that isn't aligned, in their north star, or their product vision.

Awesome, they have a really good context there. Maybe team members, I don't know about how many of you guys, the engineers on your team can reference your customers by name.

Or give you examples of customers.

If you don't have that, maybe you need to spend some more time getting them exposed to customers. Maybe your team's pushing you on, hey, I don't care about shipping this thing, what's the outcome we're trying to get for our customers? What's the customer metric we're trying to move? Wow, this is awesome, these are good signals of success, right? My favourite one is, you're doing, you always sit around in demos, but an engineer who gets up to do a demo, and I'm prompted, they can talk about the problem they're solving, who they're solving it for, why it's important to solve the problem, and show you how that solution nails that.

Again, a really good sign that that person has got a shared understanding.

So I'm hoping you're thinking about different ways that you can build a shared understanding with your team. So to help you do that, I've got a bit of personal reflection time.

So I'm gonna give you a minute or two.

You've all got paper, do we have paper in front of us today? Oh, we don't, yes we do.

In the middle of the table, is some paper and pens. I want you to grab that, don't worry, I'm not gonna make you unlock you phone and share it with the person next to you.

Take out your wallets everyone and ... (laughs) Grab the paper and I want you to think, to write three things down for me.

So the first thing I want you to think about. Think of a task that you did this week, or last week. Where you felt that it was "in the weeds".

You were grooming the backlog, you were prioritising something, you were writing a spec. Maybe you were trying to take on a decision, or explore something.

Think of that thing that you felt was burden on you, that was really "in the weeds". And have a think what that is.

Write that down.

So, if you got something there, the second thing I want you to think about, is what context did you have, where you felt like you had to do that work, and nobody else in your team did.

Your engineer couldn't do that, your designer couldn't do that, your team leader couldn't do that. What context did you have, that the other person didn't. If it was you that had to prioritise the bugs to do next sprint.

Why is it you that had to do that? Why couldn't your scrum-master, or your team leader do that? Again, not because you're more important, but you're trying to think about the context that you have, that they don't have, right? So think about, what is it that you had here? Maybe you spoke to some stakeholders internally, you had bit of a better business context.

Maybe you have access to knowledge that they don't have. Maybe you have a very clear picture of what your vision is. So the last thing I want you write is, now what is it that you could do, to provide them with that context? So this is back to all the techniques that you building in your tool box, like what is it that you could do? Is it an interview that you had with the customer, is it some data that you've been analysing on some dashboard.

Is it some research that you know, maybe internal stakeholders that you've spoken to? How can you get the rest of your team exposed to that? So, it's pretty simple, but it just requires stopping, and taking a step back, and just thinking about what do you have that the other person doesn't have. Now, the hard thing about this, is that it's super delayed gratification.

Because if someone walks up to your desk and says Sharif, I really need to know, are we doing this option or this option? The quickest thing you can do, is say, go with option A, right? That's the quickest thing you could do.

But if you stop for a moment, and ask yourself, why am I convicted, or why do I know that this is the right decision? What access to information, or what context do I have, that they don't have? And just pause for a moment, and do the hard thing and take a few steps back.

Take them on that journey.

You'll find the speed of velocity of decision making that they can do, it will be way way faster. Make sense? So, flow, I've given you a practical tip there. So product managers make all the decisions? I don't really think so, I think we should think about it as, us owning the speed of which the rest of our team can make decisions.

So the decision making velocity.

And I hope I've given you a few ways to think about this. First of all, you should be continuously building this tool box of techniques to build shared knowledge as a team.

And remember, you're never doing this by yourself. You're doing this as a team.

I need to go off in the room and just write out these customer interviews.

I need to go off and analyse the data, or group the feedback I've been receiving, into themes, by myself.

Don't do that.

Find people in your team and do it together. And if you're in a bigger team, think about ways you can measure shared understanding.

Or just get signals for where your gaps lie. And iterate on that, I gave you the three Ws, the who, the what and the why.

So try that technique together.

I will say, just a reminder for everyone, no one ever says to me, I wish engineers spent more time coding, and less time understanding the problem.

No one ever says that, right? But I think, indirectly, our behaviours exhibit that desire. For some reason, we feel like, oh, if they just could be coding more, they'd get more of an output.

But if we take them, I always say, 100% of engineers time is coding, if you take that and you spend 80% of them giving them context, I would argue, the rest of that is, they're gonna produce a far better outcome. So think about, they don't always have to have, be coding full time.

They should be involved in the discovery process. So, my second misconception is that marketing driven development is bad.

Working with marketing teams is painful, and it's a dirty thing, right? And this is how, let me explain what I mean here. Maybe you've been asked to do something for a particular launch date.

Maybe you've been asked to produce a demo for a blog, or an announcement.

And I think, a lot of engineering teams and product teams sometimes feel that a lot of this is not the right thing. It's vapour , it's sale-zee, it's seen as a dirty thing. And I think product teams, really, we should be staying as far away from marketing teams as possible, 'cause the best product always wins, right? I'm not sure that's the case.

Maybe you're hearing things like this from your team. Oh, they're making us hack stuff up for a date, we're building months and months of tech debt. Or they say, do we really have to announce this thing early? Maybe your marketing team wanna push for a pre-announcement of something, and your team feels very anxious. Why are we doing this? Or do we have to keep announcing it, we've already announced it before.

Or, maybe this just all vapour where we're just producing something for a demo.

For a sales thing, it's gonna get thrown away, and we're never gonna see this again.

So what do we do about this? Well, the hacky code with lots of tech debt statement, that's really actually on us, when you think about it. Our job is to find the most valuable thing to ship, and to break it down into small deliverable chunks. If the team feels that's unrealistic, then maybe we haven't done a good job of looking at how to break it down to small chunks.

There's been a lot of talk about defining the MVP yesterday. I know that the last thing we tried to stay away from the word, MVP.

It has caused so much pain for us, because it means so many things to so many different people. MVP could mean, the smallest test I want to do to prove something.

MVP could be the first iteration of something that I will ship to customers, a 100%.

MVP could be the thing that I wanna do to learn, right? And so we're always telling teams, what are you trying to do, what's the outcome you're trying to achieve, stay away from the term, MVP. Actually explain what it is you're trying to do. If you haven't seen, Jeff Patton's talk on MVP, if you Google Jeff Patton. He's the father of User Story Mapping, if you've tried that framework before.

If you Google Jeff Patton, MVP, he gives a talk where he talks about 12 different definitions of MVPs, and how it's just confusing teams and just causing so much pain everywhere.

But anyway, our job is to work out what is the first possible iteration we can ship to customers, and break that down into smaller chunks.

The whole, do we have to announce it, and we announce it early and announce it often. I actually think sometimes we get over anxious about communicating and feel like over communicating is a bad thing.

I've been doing this for 10 years, and I'm yet to experience one scenario where I feel like we've over-communicated anything, to be frank. Share with you a quick story.

A few years ago, we were working on a highly-voted feature request for one of our products.

I was told by customers, it was a problem we wanted to solve, we knew we needed to solve it, we knew it would take multiple years to solve. And we had started working on it.

And then our annual customer conference came along. And we were debating if we should announce this thing, that we know will take years to ship to our customers. By the way, we don't ever work on anything that takes years to ship, we've never done that at Atlassian. It's happened a few times.

So we were debating if we should pre-announce something. And we were debating if we should pre-announce something, knowing that it wouldn't ship in a few years. It wouldn't ship till a few years.

Sounds like a good idea huh? Guess what we decided to pre-announce it.

And I remember at the time, thinking this is gonna be a disaster, this is an embarrassment, I really don't want us to pre-announce this.

Feel like I lost this battle with stakeholders, we're gonna pre-announce it.

We pre-announced it, the audience loved it and the people were so excited, et cetera.

A year later, at the following annual conference, I am super anxious.

We're still not gonna ship this thing, we've probably got another year left.

What are we gonna do? Should we just not talk about it, and just hope people forgot about it, just under the carpet? Should we pre-announce the pre-announcement again? What do we do? We decided to share again that we're still working on this thing.

Now I was sitting in the audience, and this was my project. And I was so embarrassed.

I just did not want this to happen.

The amount of internal fighting I went through to just make sure that this didn't get announced. I completely lost.

It got announced.

We walked out, and we talked to a lot of customers. And there was really two camps of feedback here. Camp number one was, I had no idea you guys were working on this, thank you so much.

It's something we've been asking for, for years. I'm really glad you're working on it.

Even though we've announced it, we've blogged about it, we've Tweeted about it, we've talked about it a lot. We're all living in this bubble where we think, everyone's heard the thing that we've talked about all the time. 90% of the customers don't care, they just doing their day job.

We're just in our own bubble.

We hear it a lot, but you realise they actually didn't even know about it.

The second camp was a bunch of customers that did remember it from the following year, or did read number two. And they were like, I'm just glad you told us, because we're committed to this project, and we're glad that you're working on it.

And I'm glad that you're not releasing it till you get it right.

So I appreciate that.

That was it.

And all of a sudden I was like, over communication is never a bad thing.

I'm yet to experience where we felt that it's terrible. What about this last point here? That this is all marketing vapour, it's all fluffy stuff. Don't deal with marketing and sales teams, it's a terrible thing.

I think they all get, all these statements all have the same problem.

Which is this belief that doing anything with marketing is a bad thing.

And there's this tension between a product team and a marketing team.

If I asked you for a second, to pause, and think about how would you describe the relationship between your product team, and your marketing team. What would you say? Maybe the fact that I'm even calling them two different teams, maybe that is part of the problem, isn't it? Brian Donohue, who leads product at Intercom, a good friend of ours.

Has a brilliant talk, link's over there.

I encourage you to watch it.

And talks about this product purist mindset, and how it's incredibly dangerous.

And he shares the stories at Intercom, how they went through this experience.

Where they felt that the best product wins, and we don't wanna work with marketing and, it's all fluffy stuff, and et cetera, and they realised the hard way that the value they get from storytelling is incredibly powerful.

So I encourage you to check Brian's talk.

The link's over there.

There's a slider of being completely product driven and completely marketing driven. Now I think there's always a balance we should be looking for here.

If your engineers in your team feel like, that team on the right is, is that right? Yeah, your left, my right, sorry.

That team there is doing things for the wrong motivations. That that job's on you to show the value of marketing to your team.

You're part of the problem, and you're part of the solutions, right? And so you need to work out how you can be part of the solution to bridge the gap between those things. And I think at the heart of it, it's not an honest thing that marketing's really about. I'm just calling it marketing, but when you think of all the activities marketing does, demand gen, content marketing, field marketing, brand, story telling, a whole bunch of stuff that all revolves around telling a powerful story.

Connecting the customer to the problem that you're trying to solve.

Storytelling's really about just explaining the thing that you're working on, why it's valuable to someone. We should be doing that as product teams.

Not marketing teams doing it in their own silo. We should be doing that as product managers, with our teams, everyday.

It's a huge part of the wire, right? I can tell you, as an example, as someone who works at Atlassian.

I've worked on Jira and Confluence in the past. And I speak to customers that use Jira a lot. And Jira used to be called JIRA Agile, a few years ago. And we know people buy the why and the story of the what. I talk to customers that are like, yeah, yeah, we're Agile, blah blah blah.

I use Jira, therefore I'm Agile, yeah uh ... I press the Start Sprint button, we're Agile. I'm like, tell me what you do every day.

There's no agility in their mindsets of how they build software.

They've committed to something, and they're gonna do it, regardless of what the outcome is. But the why is so powerful, right? People buy the why, not the what.

And so I wanna encourage you all as product leaders, to think about what is your storytelling play. The activity that you do with your team to get them to think about the story, on a regular basis. You might think about creating a fake landing page. I think someone talked about this yesterday in their talk. It was like a fake landing page to explain your product or your service.

Or maybe the feature that you're working on. I was talking about someone at dinner last night. We were talking about the Amazon press release. And we were talking about, have any of you guys seen that framework where they pre-write a press release in advance? As if they've announced something and worked their way backwards.

Another technique I've seen teams do is fake the journey. So before they begin, fake the video, the marketing video they would do, and work their way backwards.

I wanted to share with you a play that I love. That I'm really excited about.

It's called a build-a-box exercise.

As anyone here heard of the build-a-box exercise? Two people, awesome, three, great.

I love this, because it's a visual activity that your team can do.

The thing I struggled with the Amazon press release one is, it's a lot of text, and hard to understand what the experience would be, our might be. I like this 'cause it's visual, and it gets your whole team involved.

Let me explain it briefly.

For our visitors in the room, this is an Australian breakfast cereal.

It's called Weet-Bix.

But when you think about when you buy a physical product in the shopping centre.

What do you do? You walk down the isle, you look at the physical good, you pick it up.

And by the cover, you should be able to understand what it is, why it might be valuable to you, and why you would consider purchasing it.

So Weet-Bix here, it's got it's little hero shot to explain what the product is.

Shows you the key benefit statements.

And the logo, or on the side.

If I want more detail, I can flip the side and, or read the sides, or read the back.

I'm looking at the audience here, trying to guess most people's age, but I think most of you will remember, we used to ship software like this all the time. You had to go to a physical store to buy software. Enterprise, B-to-B, B-to-C, like you actually had to get a box and installer.

Floppy discs, CDs, whatever you did back then, I don't know anything about floppy discs, but, you know, someone told me about it once. But there was something incredibly valuable about the physical box, that encourage us to tell the story. So we do this activity as a team, called the build-a-box, and I've done this multiple times in many projects. We literally get a box, for the product or feature. Now, we all don't build products everyday.

Just a reminder you can do this at a feature level, or at a problem level.

And think about who would pick up this box. What does the box look like? What's on the front, the side and the back? It is an amazing forcing function to tell a story. The designers like to go wild with this, and if you have a designer in your team, that you know, boxes always look better than ones that don't have a designer. And it's a little competition, but we literally buy those boxes you buy from Australia Post, wrap some pages around it, grab the team for a couple of hours and do this thing.

Every time I've done one of these exercises, we have gone back and asked some fundamental questions about what we're doing, and why we're doing it. The amount of times I've heard this: "Ah, but Sherif, but the story will be so much better if," and you're like, wow, why didn't we think of that earlier? And so we take that assumption and go, all right, let's test if we change this, would it be a more powerful story? And go back.

How do you do this build-a-box? I've tried to jam in all the play in one slide. This is a text-heavy slide, but hopefully you can take a photo of it, and it's useful for you. Grab your team for an hour, or I think two hours is better. If you have five people, maybe an hour is fine. If you're doing it with more then that, maybe grab two hours.

Your whole product team, so not just you and your designer, your engineers, your marketers, anyone that you can grab that is involved in the project development process. The things you need, the materials, pens, paper, cardboard boxes, if you can.

Obviously you don't need the boxes, you could just do it on a A3 sheet of paper. The boxes add a lot of fun, I can assure you. Get some boxes from Australia Post and stick paper on them. What are you doing? You're telling the team the three Ws.

So you're telling the team, hey, your job is to design a box for the problem we're working on, or the feature we're working on.

And ask yourself three questions.

The who, who would pick up the box? Who is the persona that you're trying to solve this for? What are they thinking? What are they feeling? Why would they even consider picking this up? Are you trying to get to what's the need here, right? For a lot of you out there, that build collaborative software, or software that has more than one user, this is an awesome opportunity here to play off teams, with different personas.

So you may have one team take one persona that you're building for.

Another team take another persona.

And consider the problem you're solving from two different angles, or from a consumer or creator or someone that reads it, et cetera. And you'll see the different benefits and value properties from each one.

Then you think about, okay, what problem are you solving. How do we express the value of this thing, or the hero shot. We use the phrase and term it the hero shot, in one illustration.

Now you're not all building features or buttons, or whatever.

But for some people it may be a flow chart. It may be a graph of before and after, like in maybe this is the numbers before, and this is the numbers after. It may be, you working on back-end services, an api call, or an api response.

That could be the hero shot.

So think about how do you express in one visual, the value of the thing you're working on.

It's a very good constraint to have, and try and see how you go.

What are the supporting value props.

Think of the Weet-Bix box with the yellow stuff on the side. And then the benefits, what are the benefits? What else would you put on the sides and back. Would you put a customer testimonial? Would you put other ways you could think about the story, what would you put on the sides and back? A lot teams like to have fun here, and they like do the whole Hipster, made with love, you know, all that kinda stuff at the back.

But that's where the fun comes in, and people really remember this exercise, as a team.

Some pro tips.

Split into multiple teams if you have a few people, and get them to play back, and compare boxes.

And ask them, why did you put this on the front, why did you put this on the side, why did you put this on the back? This works, again, reminder, you don't have to work on shipping your product every week.

We all don't do this.

We all work on some sub-category of a feature, or a product, or an api.

You can do this for each basically project you're working on.

I encourage you to do this.

You may wanna iterate on your boxes, so every time we've done the build-a-box exercise, most members of the team have told me, A, we should have done this earlier, or B, can we do it again after we validate these things. And so you may wanna put it in your milestone timeline, when you're doing your discovery.

Try a couple of different flavours of the box. Be careful with people that write in small size 7 font, 'cause they'll just jam it.

The goal here is to communicate as succinctly as possible, the value of this thing.

I've seen teams do the build-a-box exercise in a digital form.

And still like, they'll draw it up and a mock-up or whatever.

The challenge there is, they just jam more words in, they just jam more words in, so I think the physical aspect helps reduce that.

So I hope you see that I think our mindset around anything with marketing is tainted and bad. And really needs to flip about, embracing the opportunity for us, as product leaders, to tell the story, or I should say, on a regular basis, refine the story.

'Cause often the story is not right.

The story's maybe directionally correct, and throughout the process of discovery, we refine the story. We get better at communicating the value and making it really really punchy.

To do this, it's on you, to educate your team on the value of great marketing.

Great storytelling is essentially what marketing is. And it's on you to encourage your team to do that. Ask yourself, what is your play to tell a story, with your team.

What is your play? If you don't have one, try one of the ones I talked about. Press release, the build-a-box is my favourite, fake landing page.

Just have a go-to play that you know, is the storytelling play in your tool box.

All right, our last misconception.

To progress in your career as a product manager, you know what you need to do.

You have to manage people.

This is certainly something, I've gone through this journey myself as a product manager, and I found this to be an incredibly popular misconception, as I've shared my story, publicly with a lot of people.

I think we all know how this story goes.

You all start in you careers as product managers in various things.

Maybe you own a sub-part of a product, and then you expand your horizon to own multiple parts of a product. Maybe over time you end up owning a whole product or a portfolio of products.

And at some stage of your career, you hit this fork. Where you basically feel like you need to decide if you wanna manage people, or you don't.

There's these crossroads, and I think quite often it seems like the natural path, or the right path to go ahead and manage people. But I think quite often, we forget that maybe the biggest impact we could have, as individuals, is just getting better at the things we're already good at.

And so there are several motivations behind this push of, this natural push that we need to become managers. There may be a few reasons for this.

The ones I hear about all the time; My manager asked me to step up into this role.

The words, step up, come up all the time, doesn't it? I wasn't sure if I would share this or not, but I'll share it.

I was listening to a podcast a few months ago, a fairly popular product podcast.

And they had a speaker in, talking about career paths and product management.

And the whole talk, completely was concluding that everyone needs to manage product managers. But it was mixing the terms, managers and and leaders. And basically saying all managers are leaders. Now I don't know about you guys, I think you're all good with this.

You can have great leaders that are not managers. You can have great leaders that are managers. You can have managers that are terrible leaders, but they are great managers.

We need to really understand that both crafts, and how we can encourage people to get better at both. We always say at Atlassian, the main thing a manager is KPI'd on, is the growth of their team. The team could be doing 50 wrong things, but are they growing and learning incredibly fast and have a really good balanced team? The individual contributor should really be KPI'd on the output and outcome trying to achieve, if that makes sense. But quite often we get a manager, we'd give them both responsibilities, and they do good at either job. The second motivation I often hear is basically, I feel like there's a layer in my organisation, maybe part of the org.chart, two layers up, that that's where the strategic decisions are made.

And so to do that, I need to have a title of a group product manager, or head of product, or I need to be part of that group.

And this is quite natural, and something I hear about in a lot of organisations that happens all the time. And they feel like if they're not in that organisational chart, they miss out on the offsite, or the strategy meeting, or the FY planning, or whatever it is that they wanna be involved in.

The last one is just, I feel like I need to be promoted, I've got a family, I wouldn't mind a pay rise. I feel like I need to progress and it seems like the only way to do that, is become a manager, so I guess I'll do it. We've seen this happen a lot at Atlassian.

People go into management for the wrong reason. We have gone through people going into management, doing a terrible job, including myself, and then the result, people leave, or they're unhappy and then the consequences are pretty bad.

They're not bad motivations here, but I think we need to ask ourselves would these people stay on an individual contributor path, if we just solved some of these problems. These are all solvable problems, right? I think we heard about Hunter Walk yesterday, I can't remember who spoke about it, David maybe? Hunter Walk yesterday, who ran product at YouTube for many years.

And he's come out and shared a story about, like, basically he would have stayed at YouTube way longer if he didn't feel like he had to become a manager, and then deal with the politics associated with becoming a manager. It's a craft in itself.

It's a very challenging and difficult craft. We were talking last night at drinks, to a few managers, it's a very thankless craft too.

I think people don't really appreciate managers enough at all.

Again, a great talk on career paths, and product management, if you wanna read it. A blog, sorry, this one.

So you can look up Hunter Walk's talk on the mixed panel blog here.

So what do we do about this? A few years ago I came across the "How Google Works" book, has anyone read this book? Ah, only a few people.

It's actually a great read for product managers. It's pretty short.

It's a series of plays, like lots of short chapters, and different things you could do to improve product teams and how you build things.

Jonathan Rosenburg, former SVP of Google, has a chapter in there about asking yourself a question for your career path.

What does your job look like 10 years from now. So an activity that encourages everyone to do, to work out what am I gonna do in the future. Do I need to manage people or not.

Is to write your job, write your CV, in 10 years from now. And I remember when I came across this chapter a few years ago, and I sort of dismissed it. I was like, yeah, this seems like a pointless activity, I'm just gonna write ...

So I was in my mind, I was, yep, senior product manager, principal product manager, head of product, VP of product, yeah, that sounds awesome, I can't wait to get VP of product or director.

Can I just say, I work with our head of product, our VP of product at Atlassian.

I don't want his job, it's an incredibly tough job. Very different, but I wrote job titles.

And for me that was career progression.

I think for a lot of us, that may be our initial inclination of career progression.

Is that I have to be able to change in progress and job titles.

I came to this activity a few years later, and really, I think I realised what I should have been doing is, running the activities that I love to do.

Or the activities that I'd love to learn, or focus on. So instead of writing that job title, write the thing that I wanna do.

Do I wanna launch a new product, do I want to get better at analytics? Do I want to be involved in vision painting, write the activities that you enjoy doing.

And then work out what you need to do, to do more of those activities.

These are maybe things that you're already good at, and you just need to get better at them.

Or these may be things you haven't tried yet, and you wanna try.

And so you see the traditional PM career path looks something like this.

You start at the bottom, and you all your way up the top. No wonder some people say, stepping up is the next thing you need to do in your career. You need to step up into management.

But has anyone stopped and asked, why does it need to look like this? And Atlassian, over the last few years, we've changed our thinking here, and we're playing catch up here.

A few industry leaders have been leading this. We're certainly not claiming to be leading the way here at all.

We have an individual contributor track, and a management track.

So when someone wants to move into management, it's seen as a craft change.

It's seen an adjacent move.

You're trying a new craft, you're moving to a different craft.

Sure, having product management skills as a manager of product managers, is essential. But you're now gonna flex a very different muscle, then you would have, if you stayed in a product management craft.

For those of you looking at this chart closely, you're probably thinking, hang on, is it possible for a manager to manage someone that gets paid more than them? Absolutely, happens all the time at Atlassian. In fact I think we should be encouraging that, if this is the behaviours we want people to do. We don't want people to enter into management for the wrong reasons.

It has pretty significant negative consequences down the track, for the company, the employee, and the people that report to that manager. Never turns out good.

So the other thing you might wanna do is thinking about growth profiles in your company.

And I understand all of you here, are not managers, and you may not be able to influence the career paths in your companies.

But you may be able to take this as a framework to influence within your team, your immediate team. For example, for our individual contributor path, we have these growth profiles, and we have all the different levels.

And we try to describe the role in one word. Which is an incredibly hard constraint, never accurate. Lots of debates about it.

Coming from learning, to doing to mastering such role. And we try to describe the role.

And then we have the different product expectations. Now product expectations are what I would say, is specific to your company, that is about how product managers can be successful in your organisation.

As we heard yesterday, product management can look very different from company to company, and team to team. And a large part of that is because product managers need to work the organization's culture, to achieve an outcome. And we know, culture is how work gets done, and that looks very different, depending on your org. size, and your team size.

So for Atlassian, these are our four product attributes. Leading and inspiring, PM mastery, deliver outcomes, great communicator, they're very specific to our culture and how work gets done at Atlassian.

I was sharing with someone yesterday, we have a content-centric culture at Atlassian.

A lot of write ups, a lot of fire-hosey content information, and so being a great communicator both in the written form and the oral form, is super super necessary to be successful as a PM at Atlassian.

In other environments that I've worked in, they don't write much, so it's all about just being able to influence just through talking and sharing and you don't need to show your working out, if you like.

It's a different culture.

Neither of these are bad, you need to work out how to work the culture to get that customer outcome.

Now, it's also important to note that not every product manager is the same.

If you do a simple Google of the different kinds of product managers, you'll find there are lots of different frameworks out there.

That is my result, incognito results of searching for product managers.

Pretty embarrassing.

We heard the different kinds of attributes and skills, yesterday, of product managers, from the awesome polygon. I wanna share with you a framework that our head of product created while he was at LinkedIn, he ran product at LinkedIn for seven years, Joff Redfern.

He calls it the Product Management Triangle, Craft triangle, you can Google it.

It's a very simple framework, not on the different skills of a product manager, like the polygon.

This is on the types, or the flavours of product managers you can have.

And he has a very simple framework, general manager, an artist and a scientist. And you're somewhere in this triangle, where would you put yourself? Now, I speak to a lot of people that say, ah, I love to be in the middle.

In my 10 years, I've found very few people that are ever good in the middle.

In fact I can only probably name one person that I know, that is an amazing middle of that triangle product manager. Most product managers that are amazing, tend to gravitate towards one of these sides, or in the middle of these sides. They find something they're good at, and they just get better at it.

We were talking at dinner last night, of an analogy here, damn it, I can't remember what it was.

Usain Bolt, Usain Bolt right, it was Usain Bolt, yeah? We were talking about Usain Bolt last night, and we were like, hey, think about great athletes, what do they do? They do one thing really well.

You guys remember Usain Bolt, fastest guy in the world, yeah, everyone still remembers him, he's still alive, yeah, okay, yeah.

What does he do every day, he wakes up, just runs, straight, that's it.

He's good at it, he's damn good at it.

He just runs straight, it's all he's good at. Three years ago, two years ago, he came to Australia, 'cause he's retired, and trying to cash out on all his fame. And what did he do? He joined in an Australian soccer club.

So this is the fastest man in the world, is playing soccer. This has gotta be a good thing, right? He was a disaster.

The bloke was useless.

Like he couldn't even zig zag with the ball. But he could run super fast, but when he got to the ball, he just couldn't kick it.

That was the problem.

But, silly analogy, but trying to draw an analogy from the sporting industry, they just do one thing, and they do one thing really well.

And I think, often, as product managers, we think that we have to have this balance, or whatever. No, just find the side of the triangle that you're good at and just go hard.

Just keep going on that triangle.

Those are amazing product managers, and someone yesterday talked about knowing your weaknesses, and then balancing out your team with that.

That's what you gotta do.

So the scientist PM, is someone who's way more on the quantum side of things.

Data, testing, hypothesis driven, it's sort of like head over heart kind of person.

In contrast to the artist product manager, that might be more vision driven, user experience driven, able to get people won by emotion, and passion.

Then you got the general manager who thinks about, really building effective and sustainable business. Thinking about pricing and support and all the other contact that a product has with the rest of the business. And so you wanna think about where you might lean in this triangle.

Maybe between two sides, or towards one corner of that. And just keep getting better at it.

Now I'm super curious, 'cause I've asked this at multiple conferences.

And there's been an amazing trend that I cannot believe, so I'm gonna ask it again here.

I'd love to see a show of hands, if you think you're more on the scientist side. Okay, now a show of hands if you're artist side. And I guess, is everyone general manager? A lot of general managers? Wow, okay, pretty similar in other places, I always see, general managers always number one, which is incredibly fascinating.

I don't know why, if you have any hypothesis for why that may be the case, it would be pretty interesting to see why.

I often find scientist is number two and artist is number three.

I think over here, it's probably the other way around, maybe 'cause it's the Melbourne creative hipster vibe here. That's probably it, right? So, have a think about what kind of PM you are, and just go for it.

To progress in your career, you mainly manage people, I don't think so, I think you need to discover, and I used the word discover here, 'cause you may need to try management, and work out if that's something you can get passionate about, and get good at. To discover what you're passionate about.

Now hopefully I've given you some ways to think about this. Try the 10 years from now exercise, write the activities you wanna do, not the job titles you wanna do. Where are you in the craft triangle? We use this triangle all the time when were hiring now. So we can sort of think, okay we need a scientist kind of PM, for a growth role.

We've made a mistake of hiring an artist type PM in a growth role, and guess what happens, they do terribly, but they're a great artist PM, so we just need to make sure they're the right work.

So have a think about that, when you're working with product managers.

If you're a manager, and you can influence this dual track thinking of the different career paths, please try to do that.

I think all your employees will benefit from that. And if you can't, that's fine, think about those employees that are motivated by being involved in strategic activities.

How can you pull them into the strategic activities, without them having to get into management. Think about how they can grow their role, without necessarily have to become a manager. So misconceptions hopefully we've debunked today. The first one we talked about product management making all the decisions, but I think in reality, we own the speed at which we can empower our team to make decisions. So building shared understanding here, is key, and never doing those activities by yourself.

I've given you hopefully,the three Ws, the framwork for trying to work out where the gaps are, in your shared understanding. Working with marketing is bad, and a terrible thing, but really no, we should identify ways and more opportunities to embrace storytelling.

Your job's to educate your team on the value of a powerful story, and ask yourself, what is you storytelling play.

I did the build-a-box with you.

Find one that works for you and just keep at it. And lastly, to progress in your career, you need to manage people.

I think in reality, you just need to work out what you're good at, and just get better at it. What can you get passionate about, where are you in that PM craft triangle, where would you say you are. And how can you do more of that, if you're a manager, encourage your individual contributors to get involved in strategic activities, even if your organisational career path might not support it yet.

So get them involved.

So, that's it from me, I hope I've debunked some myths for you in the product craft.

Thank you.

(applause) (simple electronic music)