Easy Agile Podcast Ep.17 Defining a product manager: The idea of a shared brain

"Sherif shared a lot of things that I really resonate with, and have had an impact on my career." - Jerome Salimao

In this episode, I was joined by Sherif Mansour - Distinguished Product Manager at Atlassian.

We spoke about styles of product management and the traits that make a great product manager. Before exploring the idea of a shared brain and the role of a product engineer.

Sherif has been in software development for over 15 years. During his time at Atlassian, he was responsible for Confluence, a popular content collaboration tool for teams.

Most recently, Sherif spends most of his days trying to solve problems across all of Atlassian’s cloud products. Sherif also played a key role in developing new products at Atlassian such as Stride, Team Calendars and Confluence Questions. Sherif thinks building simple products is hard and so is writing a simple, short bio.

Hope you enjoy the episode as much as I did. Thanks for a great conversation Sherif.

Listen now on:

SPOTIFY

APPLE PODCASTS

SIMPLECAST

Transcript

Jerome Salimao:

Thanks so much for joining us today, Sheriff.

It's awesome to have you with us. So, Sherif is a distinguished product manager at Atlassian. And we met each other in December last year at AgileAus. So, it was the first in-person conference that I've been to in many, many years. And it was awesome. Sherif was speaking there. And it was so awesome to meet you and to hear you talk. Yeah. So, welcome. Welcome to the podcast.

Sherif Mansour:

Thank you. Thanks for having me, Jerome, and the Easy Agile team.

Jerome Salimao:

Very exciting. I just found out today that you went to Wollongong Uni.

Sherif Mansour:

Yes. I studied computer science at Wollongong. Used to do the drive from kind of Southwest Sydney, where I'm from. So, enjoyed many, many drives down there and trips up and down [Mount Ousley 00:00:53]. And absolutely loved Wollongong. So, just recently spent the summer there, the holidays there. So, for listeners on the call, you guys, most of the Easy Agile? Is all of Easy Agile down at the Wollongong area, the South Coast of Australia?

Jerome Salimao:

Yeah. I think one of us is up in Sydney. But yeah. I had no idea you studied computer science. For some reason, I just thought you were always a businessy person, but I guess maybe that's where we should start now.

Sherif Mansour:

Yeah. I learned that one. Yeah. I learned that I wasn't a great computer scientist that way. Yes.

Jerome Salimao:

So, maybe let's start there. How did that go? I assume that you started off as an engineer at some point. How did you end up where you are now? Give us the headlines.

Sherif Mansour:

Yeah. It's a been wee journey. The short version of the journey is, yeah, loved working with computers and programming back in the day. And at the end of school in university, a friend of mine ran a business building websites, before there were on these website-builders and you could make a business out of it. So, we were coding at the top of his dad's house. And I was studying at university at the same time and kind of balancing both. And then went to university full-time. Finished my degree. And then I guess got a job coding.

Sherif Mansour:

And I think a year or two into it, I kind of realized I probably.... I think I realized a bit of this during university. I loved building things and then being involved in the process of solving a problem and finding a solution to the problem, but I just wasn't a great engineer. I was one of those engineers, if there are any engineers listening on the call, that would be like, "It works. Don't touch it. We don't need to make it any better. Just leave it. It works." Yeah. So, I did engineering. I did mostly a software engineering role for five or six years out of university.

Sherif Mansour:

And to cut a long story short, I was a... or still am an Atlassian fanboy, I guess. We had used Atlassian products in the company I was working at. I had seen how some of their products transformed how we work, in particular around opening up our company. And I was fascinated about the business model. This company had created, like, there's this phrase that people throw out there now, product-led growth. I think Atlassian, I mean, this is before my time, effectively, to my knowledge, is the first company that's kind of did that, where didn't have a sales team, didn't really have an option back then, and the product sold itself. And so, I was fascinated about the business model.

Sherif Mansour:

I'd wrote a few blogs about Atlassian and the business model. And I had someone who was running product at Atlassian, Audra Eng, who's still around in Sydney today, she reached out to me and said, "Oh, you seem interested and think deeply about our products. Would you be interested in a product management role?" Long story short, I replied and was like... well, actually, I looked up in our job-seeker websites in Australia, I searched for product manager. And this was probably more than 13 years ago now, 12 and a bit years ago. And there was zero search results. And I was like, "What the hell is this role?" And I replied to her, I was like, "Yeah, I'd love to work for you guys. I'm not a great engineer, so I'm pretty sure I couldn't get a engineering job. I like being involved in products." And in my email, I think I replied and said, "What is a product manager." It's a great start to a job interview. So, yeah. We just went through the process.

Sherif Mansour:

And I kind of learned product management on the job from... very lucky to have the Atlassian founders as kind of mentors and guides and a whole bunch of people at Atlassian. And then also lucky that a lot of our customers today are product managers too. So, I get to interview them about how they build products and learn about their style of product management. So, that's how I fell into it. It was totally by accident. Never heard of the role before.

Jerome Salimao:

Yeah, yeah. It's really exciting, I think. And it's funny because, yeah, I think I mentioned in December, I'm sort of in that zone where I feel like maybe it's something that I want to do and maybe it's a transition that could be coming up in the next quarter or so. So, it's very exciting. And it does feel very... it's weird because I've been reading a lot of product management material lately. And the thing that I keep hearing about is how new we are as an industry or how new it is as a role. Like, 10 years of ago, maybe it didn't exist, maybe there were no roles.

Jerome Salimao:

But maybe this is a good question. Like, maybe could you tell us what you think a product manager is by definition?

Sherif Mansour:

Yeah. This is super hard. Apparently, I'm half-famous from my YouTube video on this topic. And this was... I recall doing a flight from Sydney to San Francisco. And one of the Jira software product managers, product marketers, said, "Hey, there seems to be a lot of demand around what is product management searching on YouTube. Do you want to create a video for it?" And I was like, "Oh, really?" And so, I wrote the script on the plane on the way from Sydney to San Francisco. Landed. Got off the plane. Was desperate for a shower. Showers weren't working in the office. And recorded a video of just this, you know, five-minute video.

Sherif Mansour:

But I think it's really hard to answer that succinctly. But I would summarize for most medium to large organizations, a product manager job is someone who works with customers and internal teams to balance and find... work with the team to build a shared understanding of the customers' problems, what solutions you might build, and help the team execute and build a solution to that. The hard part of that role is in growing organizations. It is largely bringing the team along in the journey. In smaller organizations, you'll find a product manager is doing a lot of generalist-type work and getting their hands way more involved in the tactical day-to-day. In larger organizations, you'll find product management is largely about building a shared brain within a group of people. And it's funny because it's still the same job. You're still trying to identify a customer problem, solve it in a sustainable way that's viable for the business and solves the customer problem, but how you do that changes drastically in smaller to larger teams or smaller or larger organizations.

Jerome Salimao:

Yeah, totally. I think something that sort of just stood out in your last sentence was this idea of a shared brain. What does that mean to you and to your teams at Atlassian?

Sherif Mansour:

Yeah. For me, it's one of the most powerful tools to build product at scale. And so, what I've learned over the years, and I give a talk about this, where I had thought the role of a product manager was to make all the decisions on the product. And that might work for a startup or a small team. And you find, over time, as you get to even just to 20 people, you find the best way to achieve the customer outcome and the business outcome is actually to empower others with the same context that you have.

Sherif Mansour:

And the classic example I give is like, "Hey, hi, I'm from Atlassian, the makers of Jira," and then I'll usually insert a Jira joke here where I apologize for all the Jira feedback they might have, and we have lots of teams trying to make that better. But something that pains me as a product manager is seeing the amount of product managers that are in their Jira backlogs that are dragging and dropping individual stories up and down the priority list. And granted, I think most product managers will have to start doing that at some point in their career or maybe it's a life cycle. Every time you join a new project, you might have to get your hands dirty and then whatever.

Sherif Mansour:

And I always say to those folks, "Your job as a product manager, there's some context that you have in your head that lets you decide that this is more important than that. And what is that context? It's probably context from three areas, the customer context, the product vision context, or the business context. Like, you know about how your business needs to operate, or you know some detail about a customer problem, or where you're headed. Those three contexts that you have, the best way you can scale yourself and build and scale product teams is by empowering engineers and other people in your team with those three contexts so that they can make those decisions on which card should go before which card."

Sherif Mansour:

And you can zoom out of it and align more on the broader strategy, the goals for the sprint, rather than the tactical [inaudible 00:09:37] type of work, which I always tell people, "It is not a bad thing. And it's not like you're more important than other people and you shouldn't do that. Sometimes you just got to help your team out and do whatever you need to do. But in reality, most engineers don't want to be told what to do. They want to be involved in a process and build something meaningful."

Sherif Mansour:

And if you think about those three contexts and why you can put one card over another card or why you think that this is the problem we should solve next, that context and the shared brain has to expand from your head to your whole team's head to even your stakeholders, to some degree in larger organizations. So, it's just a very important tool in a PM's toolbox to scale themselves. And it's the only way I've managed to do it sustainably.

Jerome Salimao:

Yeah, totally. And I mean, me, as an engineer currently, it's something I also really appreciate. And it's something I would say to our product managers here, to Teagan and to Elizabeth, like, "I'm the kind of engineer that likes context. Give me context as soon as you can early so that I can think about it and I can bounce ideas off with you." Yeah. So, I get that. But from a more practical perspective, how is that done effectively, do you think?

Sherif Mansour:

Yeah, yeah. And I think that's even become more challenging in the remote world, as more and more teams are going remote first or remote is a large part of their culture. How it's done is lots of tactics. I think this is where the PM toolbox of frameworks, techniques, and processes help. Whether it be user journey mapping, whether it be customer interviews and research, whether it be surveys, whether it be analytics and data analysis, whether it be vision setting, et cetera, those are the tactics that a product manager learns or improves or frameworks they create on their day-to-day job.

Sherif Mansour:

But doing them as a team, rather than as just the PM and the designer or just as the PM by themselves, is how we bring people along on the journey. And so, one of my goals is to always never do customer research or customer interviews by myself. Sometimes it ends up happening and I'll have to record it and share it with my engineers or whatever. But my effectiveness, I get 10 times more effectiveness if engineers are in the call or designers are in the call.

Sherif Mansour:

Effectiveness, if engineers are in the call or designers are in the call. Same thing with vision setting, how can I do vision setting with a collective group of engineers so that they all feel like they're part of the process? If I'm going to sit here and analyze some data and a tool or run some sequel queries or something, how do that in a way that brings people along on the journey? If I'm going to do a survey, I hate surveys but sometimes you got to do them, or if I'm going to do some market research. Simple example, we were doing some market research the day of tooling that solved similar problems. We assigned every engineer one of the tools and told them here's the template, rather than PM doing it all. This is a bit counterintuitive because a lot of people think, "Wait, wait, that means my engineers are spending less time coding?"

Jerome Salimao:

Coding.

Sherif Mansour:

And there's a bit of tension there where you're like, "Ah, but they're not picking up tickets off their backlog. Engineers are writing decisions now and engineers are like doing market research, what's going?"

Sherif Mansour:

I always encourage folks, your goal is to build the right thing that solves a particular problem. And the risk in the whole of the process is that you actually build the right thing. That's the number one risk in the whole process. So no one ever says in their careers, "Man, I wish engineers spent less time understanding context and more time coding." The old way of doing it is PMs would write specs and hand it over to engineers. I tell people, "You should try to avoid writing specs because a spec is an attempt at a shared brain." And sometimes you'll have to write specs, sometimes you'll get to [inaudible 00:13:37] of your product where... I mean, you're probably going through this Jerome as well, you work on a few Easy Agile products, and the product gets more complex and there's more edge cases to think about. So someone needs to put pen to paper and think about it.

Sherif Mansour:

But the specs solves the problem of a shared brain and it's one way to solve it. But historically that's never worked, or it hasn't worked as effective as it could be. And so then how can we bring other people in the journey? I'm guessing you felt this too Jerome, right?

Jerome Salimao:

I have. I feel that deeply. Actually. And it's not even funny, like on a day to day, it's actually quite frustrating sometimes. But I think you've hit a nerve for me. I think one of the reasons that really held me back from ever going after a product role or transitioning away from an engineer is because there is this vibe. I get this vibe that the most valuable skill that I bring is code. And it's really been like a bit of like a blocker sometimes. Because I feel like I can't try anything new or like people are sort of hesitant to give me new tasks because I am a coder, because I'm an effective coder. It's like people value that so much that it holds me back sometimes. So it's a really interesting point.

Sherif Mansour:

And for you Jerome, and I guess in your mind, are you thinking, "Well, if I'm hired as a coder, my job's to code." And then correct me if I'm wrong, but like then in your mind you go, "Well, how do I become a better coder?" There is excel at the engineering aspect, which I think will need different types of engineers to do that as well. Like performance and scale or accessibility. Or you may be a specialist in a type of language or a front end. Backend. But there's also build the thing better for the customer and that's another way to excel, right?

Jerome Salimao:

Yeah, totally. But I think, this is just my personal opinion. That I feel like the way we sort of define success for engineers is very much this sprint we're going to hit this and we are going to hit these bigger goals over these sprints. And as an engineer, I feel like we don't often always get the time to think or be involved in these bigger, bigger topics with the PMs or the designers, for example. Because we are very much focused is getting things done and hitting these goals, which I think is a shame because this shared brain idea is powerful, I think. Especially when you look around at an engineering team, there's often so much talent and so much experience, that's not directly related to code.

Jerome Salimao:

Like I used to work with like engineers in Germany, that they used to build rockets for example. And one was a baker and one used to be an artist. And there's a whole room of people with so much experience and such a different perspective that I feel like it's a waste if you don't sort of tap into that as shared brain.

Sherif Mansour:

Yeah, definitely. Actually last week we did a Mary marketing lead for one of our products. She ran a what we call a builder box exercise. People can Google it. Build a box is a framework, there're lot of them out there for how we will frame a particular improvement or a product to our customers. How we'll message it. Think of it as like when you open your app store on your phone in three screenshots, you sort of get what the app does and there's three value propositions or whatever. And the engineers were involved in that experience. So they were involved to come out of there to write texts on we did a digital lease, we did it in mural or whatever. And go, "Okay, if we were to ship this as a product, like what's on the front of the box?"

Sherif Mansour:

And as a team, the shared brain aha moment we had is actually, "That's going to change our roadmap." Typically people do that, we're finished building the thing. How do we market it? Then engineers being involved in that process are now thinking, "Well, hang on a second. The story would be so much more powerful if this changed. Or if we actually talked about the feature this way, not that way." And as a consequence of that, we're now changing our roadmap and engineers that were involved in that brainstorming activity are now better equipped to think about and make the decisions in the day to day feature they're working on. How are they going to make trade offs on exceptions and edge cases? And how might the experience work with their designer? And so I think involving those people there, it just has a huge impact.

Sherif Mansour:

And you're right the balance there is like, as a team I'm currently working on a new product at Atlasian. I think you're probably seeing this today. I saw this at the tail end of my time when I used to work on confluence, but it seemed like a lot of teams were moving away from strict sprints to more using the sprint ritual a as a point of check-in. Less about did we last week's goals or not? As rigid as it used to be, now it's very much the classic [inaudible 00:18:45], which is like, we set a high level goal for that week. And how did we go for that week? Are you seeing the same trend?

Jerome Salimao:

I think it really depends on the team.

Sherif Mansour:

Yeah.

Jerome Salimao:

And like what the business is doing. Like in a previous role, we had nine months to get this online checkout live. And it was very much like we need to get this done before this, so that we hit these milestones. So I think it really depends on the team.

Jerome Salimao:

So maybe I can pick your brain. I've got so many questions for you. And I think it's just crazy that I feel like you've gone down a similar path, as me. So in those early days, when you were switching from development to product, how did you go about doing it? Because maybe I'll share something first. So as I'm going through this transition now, the thing that I really am not enjoying about it so far is that it's not as... When I'm approaching a problem as an engineer, I'll often know what to do and I know how to do it. It's very clearly defined, the ways to get there are defined. Whereas in product, I feel like there's no clear way to get anywhere, or to answer any question. How did you approach that in your early days?

Sherif Mansour:

Yeah. I remember switching from engineering and hopefully folks listening, maybe this engineers wanting to switch or do more PM work or feeling the same. Just feeling this endless pool of work and then feeling unbounded with how to approach something. And then the anxiety associated like, "Well, I could do marker research. If I could just do marker research forever." Like when do I actually stop? Right. Like the definition of done, it's endless. I actually found the transition quite stressful because I felt like there's in every area of a PM's life, you feel like there is a never ending pool of work. Whereas, I think engineering's probably the same there's always coding and clean up whatever. But when the task is done, as I felt, it was done. Yes, it was improvements, but I could clearly box the time I spent on things.

Sherif Mansour:

And I think this touches the heart of the PM role, which is making effective, efficient and the right trade off calls. Because you're making trade off calls day to day with working with engineering design, marketing, trying to balance everyone's needs, and most importantly meet the customer problem and then deal with your stakeholders. And so you are always... The PM role is largely balancing a bunch of trade offs. I used to use this phrase, "A roadmap to your products is effectively a sequence of decisions that you've made." Like you've said, "No" to other stuff, so you've put other themes to work on in your roadmap.

Sherif Mansour:

But that feeling of lost ness is really hard because you just, "What do I do?" And I found that quite hard. I drowned quite a bit in and then I still go through these moments where you're just like, "Oh man, I could spend forever on this." So I think that's one aspect of the lost ness I think you're describing, I hope folks feel. Well, that's how I felt too.

Sherif Mansour:

And the other aspect is like, "How do I go about doing my job?" So this never ending pool was one problem. So like I could do marker research forever or I could do customer interviews forever. And then the other pool was like what's the frameworks I go about doing my job? Is there a tactic or a template I'm supposed to follow? And that goes there. I think with the never ending pool thing, the way I've managed to solve it is to try to help me constantly reset, "What is the most important thing I could be doing for my team today?"

Sherif Mansour:

And to this day I ask my questions, I don't know, a regular basis. So example, I may do a series of customer interviews. Some point I've got some learnings we've shared together as a team, whatever. And you realize that's no longer the most important thing. And now there's like something else I need to work on, that's the most important thing. So you're always dropping balls as a PM. If you use the juggling analogy, your job is to work out which ball you should catch next. And the only tactic I found to solve that first problem is constantly asking myself, "Have I done enough of that thing? Or is there something else that's popped up that's more important?" And it's a discipline.

Sherif Mansour:

It's like every day you come in, I rewrite... Call me old school, but let me just pull of my book for the audiences watching video at home. For those listening to the audio, you won't experience this, but I kind of rewrite my to-do list on a regular basis, probably every two days. I literally rewrite my to-do list and things drop off all the time. And I think that's how I've solved that first problem.

Sherif Mansour:

The second problem with like, how do I go about doing discovery? I've come to learn over the years, my VP of product, Josh Redfern has a framework. Folks can Google it, it's called the PM Craft Triangle. I've written the blog about it. There're different styles of discovery that people naturally lean towards from their background, their tendencies or their styles. He has a simple framework, but there're a few other PM-

Sherif Mansour:

[inaudible 00:24:01]. He has a simple framework, but there's a few other PM type frameworks, which is artist, scientist, general manager. So it's about the different approaches to discovery. Neither of these edges of the framework are bad, it's just what are you good at, how do you use that to do your discovery, and how to balance yourself so that other people can be involved. As an example, I am very much an artist. When you read the framework, I'm very much an artist-side style approach to product management. What does that mean? I'm way more vision-led than I am data-led. I'm way more on beliefs and bets than I am on actuals. Right?

Sherif Mansour:

I've learned over the years, I'm a terrible growth product manager, like someone who's trying to optimize a funnel or improve a single metric. I'm actually really bad at that. My strengths are more on creation of new value and identifying potential opportunities, and therefore my styles, my frameworks, or my practices are slightly different to an engineer who's more on the scientist side of the spectrum.

Sherif Mansour:

So long way of saying is I'd encourage folks listening to find a framework that works for them on styles of product management. If you're looking for one out there right now, I could tell you just Google the PM craft triangle. You'll find Joff's article or my article on it. Depending on your style, you'll take a different approach to discovery, and there's different frameworks and approaches to doing things. And so, you'll then look up different frameworks appropriate to your style, or you'll just create your own and discover it as you go. Right? I tried this method for this thing. It wasn't that great. We stopped using that. We use this other one, and we prefer that more. Yeah.

Jerome Salimao:

When I talk to PMs, this is what I tend to hear, is that, "Oh, that didn't work for me, so I just do this spreadsheet on Google Docs. It's what I do." And so, I'm feeling like it's clear as mud, honestly, compared to engineering, where I know things work and I know how to get there. But I think that's part of the adventure, hey? I'm curious now, now that Atlassian's so big, I feel like you maybe have more data points. I feel like I'm more data based, yeah?

Sherif Mansour:

Yeah.

Jerome Salimao:

Where are you finding the PMs are coming from? Do they tend to be coming from technology like me, like from engineering? A lot of our PMs here are from marketing? Where are they coming from, from your perspective?

Sherif Mansour:

Look, historically, I think a lot of companies will say, "Oh, computer science is required for product management, et cetera." The truth is, as always, the classic PM answer is I think it depends. I think, if you make a generalization, the bulk of the observations I've seen have come from a business information systems, computer science background, et cetera. When I was at university, there was no options to study this line, but, if you went down the business path, you were doing similar things.

Jerome Salimao:

Yeah.

Sherif Mansour:

And I think now there's more deliberate courses that are lined up, and a lot of universities are adapting their curriculum to adopt this. So I think some people are more coming in straight with the assumption they want a product management's job, and they know what that is. So we hire a lot of business graduates, business IT graduates, that go straight into our associate product manager program, as an example.

Sherif Mansour:

On the flip side, we have some incredible product managers at Atlassian that have zero technical background. Our Trello team, I think, was our team with the most product managers, with the least technical background. We had philosophy backgrounds, arts backgrounds, mathematics backgrounds, so completely different. But I think, more traditionally, if people move to product management, in my experience, and especially Atlassian's experience, we have about or close to 300 product managers now, is they've come from a team that's close to the product manager. So marketing switching to product management's common. I think what I've seen most common is engineering to product management, because engineering, also, your job is to identify a solution to a problem and build the solution to the problem. So you're thinking problem solution a lot in your role.

Sherif Mansour:

I've seen design switch to product management. Not as common. I have seen that. Uncommon. I've more seen product managers move to design, want to be designers, which is a running joke. That's another common trend. So you'll often see one of those three falling into it. I think, if I were to make some generalizations at Atlassian, our probably most common path internally is engineering to PM, but we have had marketing to PM, we've had design to PM. I think we've had support to PM as well. Customer success to PM a few times. Again, a lot of problem-solution mindset falling into product management.

Sherif Mansour:

People say, "How do I go get a product management job," or, "How do I get into it?" Lots of advice here, but, if you're working in a medium-to-large organization, internal transfers are your best approach because you're tried in a safe environment, you're already familiar with the cultural context of the organization. Product management looks different company to company because culture, how we do work, looks different company to company. So you have to adapt to that culture, move work forward, and align your stakeholders and align your internal teams. I think that's an awesome thing to do.

Sherif Mansour:

The other thing I tell people is think of everything you do as a product manager and then frame your résumé as a product manager, if you think about it. So I firmly believe, I only discovered this last year, and I've been married to my wife for many years, I think she's basically doing a product management job. My wife works for a local council or, for the American listeners, a county, if you like, and she's a strategic project officer. You're like, "Well, what does that mean?" I don't even know what that means.

Sherif Mansour:

But when I listen to her day-to-day work, she could frame that completely in a product management role. So she works with residents in some suburbs to understand their needs, then works with our transport planners and our road builders to work out cycleways, pathways, and where they should go. Then they come up with proposals and get feedback sessions from their residents, right? Then they've got to balance that with internal stakeholders, local members of parliament that are pushing different agendas, right? Everyone's got their pet features. There are so many parallels you can draw with everything you do to building a product, so think of what you're doing as a product. You may have a funnel, you may have customers, you may have stakeholders, something you need to build. You can frame a lot of your experiences that way.

Jerome Salimao:

Yeah, totally. And I think, yeah, I'd agree, actually. I feel like most engineers ... I think a lot of engineers, maybe there's a subset of engineers that actually do behave in this way. It's actually how I found you, how I heard about you the first time. For the listeners, I first heard of Sherif, it must have been 2019. I was living in Munich at the time. I was being given these tasks by our PO, and I was wondering, "Why are you giving this to me?" I felt like it would be something that was senior. We had a staff-level engineer on the team. Very lucky. He was excellent. Technically brilliant. I just assumed it was something that he should be doing or probably something more that he would do.

Jerome Salimao:

The PO actually was like, "No, I just feel like it's the kind of engineer that you are." Then he sent me a link to your blog post about product engineers, which was very, very fascinating. It validated a way forward for me, a way forward of working, which was very exciting. Did you want to have a chat, a quick chat? I feel like we're going to run out of time soon, but do you want to have a quick chat about that blog post, because I found it so [inaudible 00:32:16]? I was having a chat to one of the grads here the other day. Yesterday, actually. She also read it, and she watched your video, and she also felt identified with that persona that you wrote about. Did you want to talk about what you think a product engineer is and how they can help in the product space?

Sherif Mansour:

Yeah, yeah. I've had a lot of people talk to me about that post. I heard of this term from our former VP of engineering, Jean-Michel, who just came off, actually, running engineering at Shopify for many years. I was on this flight with him from Sydney to San Francisco, too many flights of those for me, and I was sitting next to him. The poor guy didn't know how much I could talk, but we were trying to reflect on what worked well in some product teams and why some product teams were better than others or seemed to perform better. There were lots of reasons. I'm not claiming that all this is the only reason. But one observation we picked up that I felt the urge to codify somehow was that a lot of those teams, even though they had product managers on them, whatever, had what he described as a product engineer. And I was like, "Wait, wait. What the hell's a product engineer?" Never heard that phrase.

Sherif Mansour:

It's probably not the best term because I think there's an actual... In the Valley, they call engineers who work on products product engineers. I think. But let's go with it for now. He was basically describing many product managers, but someone who's an engineer who is more focused on that. And the analogy we came up with was the engineers can specialize in a bunch of different things. We can have performance engineers, we can have AI and data science and ML, we can have frontend engineers, backend engineers. They all work on different things. Everyone cares about the product. But one of those attributes which they could do or focus on was caring more about the customer outcome above all else. And so, I think all engineers desire to do that. I'm not saying that. But to the point where I think that they're always looking for ways to make sure they're building the right thing without actually building the thing.

Sherif Mansour:

And so, we identified several teams at Atlassian, dozens, where it was clear that there was one or two engineers where he or she were almost acting as product managers. They were taking shortcuts where it made sense to take shortcuts from an engineering perspective because of uncertainty or finding ways to prototype things over actually building, et cetera. They were challenging their product managers on assumptions the team had made. Not in a negative way, but a, "I desire to build the right thing with you." Honestly, I think in a whole team, there's only one person in the team that's the best at identifying edge cases and identifying quick wins.

Sherif Mansour:

And it's usually this type of person who has enough business context that knows what we're trying to do, but is living in the code every day to know that, in these scenarios, "These don't actually matter. I can totally ignore this. This is going to be edge case," but also be like, "Well, if this is what we're trying to do, there is this quick win we can build," because they know the how. I wouldn't say that's ever a PM's job, but which actually gets to a better solution to the problem.

Sherif Mansour:

And so, effectively, we created this phrase, product engineers. It didn't exist out there, and I often find with these things, if someone puts out the terminology out there, people can debate it and discuss it in the community. I just felt it was something we had to do, to codify, because it was a cultural thing that we saw help -

Sherif Mansour:

To codify, because it was a cultural thing that we saw helped us scale. We have teams at Atlassian where I would say the leader of the team is probably a product engineer from a vision and a driven perspective, and as a PM playing a support role, because the PM's scaling themselves well, they're focusing on other teams. I think the more product engineers we have as any company, the better you will scale. Completely. It's very hard to hire product managers. I've been doing it for 12 years, and I still think it's a hard thing to do, a hard thing to test, even though we've been trying to improve, but it's also hard in terms of just making sure you have the right person.

Sherif Mansour:

Jerome, I'm curious for you, was there some particular attributes that stood out when you read the blog post first away? Where you were like, "Ah, I can totally resonate with this more than the other one?"

Jerome Salimao:

Yeah, the exact thing that really was like, "Oh, that's me," is always asking why, like, "Why are you doing this? Why are you doing this instead of that?", or, "Why can't we try this?", or, "Why don't we have this other data point?" I feel like I would always annoy our PO at the time. He was great, he was excellent, and I think the idea, actually, of the shared brain is why I think it's so important to have people, engineers like me on teams. I'm not saying I'm amazing, but having people on the team to ask these questions or to challenge people... I think challenge is good, and I think sometimes, not arguing, but sort of disagreeing on things is also healthy.

Sherif Mansour:

Yeah. The creative conflict process. Yeah.

Jerome Salimao:

Totally, and I feel that, and I felt that. In that blog post, I was that guy on the team that's always asking why, like, "Why are we doing this? Why is this important?" Yeah. So I just found that super helpful. So if anyone, if there are any other engineers out there that maybe have an interest in product, maybe it's a good place to start, because I think it was what I also found super helpful, and I shared the post with our PMs here, was what I thought was really great about that blog post was it gave tips to PMs on how best to work with product engineers or engineers like this, and I thought that was mint, mate.

Sherif Mansour:

Yeah, because I think PMs can find it intimidating. I remember when I first joined the Confluence team, there were 12 people were working on Confluence, or sub 15 or something like that, and I would say... This is typical in most startups. Most of the engineers there who... Confluence didn't have a PM at the time. They're playing the product role anyway, and so they all have a shared brain, they're all highly opinionated, they all have a vision of where it should head, et cetera. So I came in going, "Actually, what do I do here?" I remember feeling quite intimidated and challenged. I actually think that made me a better product manager in the long run after I realized they're focusing on... They're not challenging me as an individual, they're challenging the ideas.

Sherif Mansour:

What I found fascinating, Jerome, is I've heard the opposite feedback from... I guess I've interviewed a lot of customers on how they build products, and fortunately, or unfortunately, I call it the Steve Jobs model, still exists in many organizations, where there is a... Some organizations with the culture where there is a visionary person, and you get this in most companies, but it is command and control. It's like he or she says, "We're building this solution," and everyone just follows orders.

Sherif Mansour:

That model does work. Look at the Steve jobs model. I just think there's not many Steve Jobs' in the world, and in reality, the team is more powerful than the individual, but yeah... A lot of people have said this blog post has challenged some internal cultural norms. I've spoken to a few people that work at some very big famous consumer and B2B SAS companies, and most of the engineering teams and the PMs follow orders from a stakeholder that gives a solution, and that's how it is. My work, for some, it's just... Man, that model doesn't scale very well if that person goes or something.

Jerome Salimao:

Yeah. I think the worst part is... I'm not sure, I never met Steve jobs, but from what I hear, he was quite difficult to work with. The culture and the teams... From what I hear at the time, I hear the people that did work in the glory days of apple at the time, apparently it was quite a challenging environment to be in, so I don't know. I feel like this shared brain idea actually sounds... It sounds like a place to work, honestly.

Sherif Mansour:

Yes. I would say it's harder. It's harder because there's more people problems. Someone always reminds me... Actually, our founders... Building software is largely a people problem. It's getting a collective group of people aligned on something commonly to get an outcome, and too many times, we think of the building software as a body shop, as in someone has an idea, get some engineers to just build it for you, and in reality, it's not... People's personalities come out of their products. The decisions are made, and trade offs are made, and it happens that way.

Jerome Salimao:

Totally. I feel like we have time for one more question, and it's someone you sort of just hinted at a second ago, the idea of PMs scaling themselves.

Sherif Mansour:

Mm.

Jerome Salimao:

Do you see that as a way... Does that imply that PM's work across multiple products, or what did you mean when you said scaling?

Sherif Mansour:

Yeah. The desire of scaling yourself, I think, has to come from building a better product. Let's be honest you, I think there's another desire, which is like, "I want a promotion. I want to move up the ladder," and so there's that desire as well, and maybe you need to play off both desires to get to the outcome, but generally speaking, I think the ones that do it well are like, "Hey, the best way I can solve this problem for customers is to get my team along on the journey and a team involved."

Sherif Mansour:

So I think that's where the desire has to come from. Over time, what that might look like on a big product, you may have a PM that's responsible for multiple feature areas. To give an example for us, Confluence has 12 PMs or something, and they work in different areas of the product, et cetera, so they might work in multiple areas, or for smaller organizations, there might be a PM taking on multiple products, et cetera, but you still may have a PM allocated as a point person for a stream of work, but they may not be playing the captain role as much. An engineer might be playing a captain, they're playing more of the support role of like, "Hey, let me know how I can help," and those are areas where either...

Sherif Mansour:

There are often areas where the team has a shared brain, and that means as a PM, they can move on and help another team build a shared brain, and they may still be responsible for two teams or be the go-to person for that PM, and expand their scope that way. So I think that's where the desire needs to come from, but it does mean that they can own multiple areas of a large product or own multiple products over time. Yeah. Was that what you were getting at? Sorry.

Jerome Salimao:

That's exactly... It sounds very interesting. It sounds way, way down the line for me. Yeah.

Sherif Mansour:

Jerome, I will say that I often find people... Every project I've worked on, you go through the same cycle again. So at Atlassian right now, I'm working on a new product, and I joined this team, and we're a new team, there's only five of us. You go back to square one, right? So every new thing you go on, you go back to square one, you go back in, you get your hands dirty deliberately, you're trying to build a shared brain together, and then you move to this stage where you're like, "Okay, there's context. We're now growing as a team. How do I give everyone the same context so that they can make faster decisions, better decisions, and all that?" Personally, I've done this loop 20 times over the last 10, 15 years, whatever. It feels like a repetitive loop that keeps happening over and over again.

Jerome Salimao:

Yeah. That sounds exciting.

Sherif Mansour:

Yeah.

Jerome Salimao:

Cool. I think we're just about out of time. Was there anything else you wanted to chat about?

Sherif Mansour:

No. I guess there's a clear theme on this podcast, folks interested about moving to product management or just starting in product management, particularly from engineering roles... I want to remind folks that have the anxiety of making the switch, there's no secret magic to it, to my knowledge. There probably is. There's no like... I can go to university and get a bachelor of product management. I think it is definitely something that can be trained in anyone, without a doubt, but you can see that... You flock to a growth person and they see everything as finals. "There's an acquisition, retention," et cetera. I think you'll talk to a product person, and some of them will also see everything as a product. You can see your life as a product. There are different versions of you as you grow up, and there's different chapters and different problems to be solved in different stages of your life. You can see your existing job as a product.

Sherif Mansour:

So if you start to incorporate that mindset in a lot of what you do, I think you can find how you can grow in product management without having to necessarily be in it, but also frame and work with future employers to frame how you are effectively already doing some of this job, which is what a lot of the folks that are non-technical product managers at Atlassian have done, is that they've demonstrated how they're almost effectively doing that job right, in some way.

Sherif Mansour:

But yeah, I just leave people with that. I think people would get intimidated going, "Oh, it's like an ivory tower kind of thing."

Sherif Mansour:

Oh, sorry, Jerome. The last thing I'll say is, without a doubt, this is probably the most stressful role I've ever had. Just do like, "Hey, last few minutes of the podcast, maybe talk you out of this thing."

Jerome Salimao:

Yeah. Talk me out of it.

Sherif Mansour:

Because it's never ending, and you have no authority, no one reports to you, right? So you are trying to influence without authority in everything that you do. It's definitely the most stressful role I've had. It was also the most satisfying. You need to learn how to manage your stress, and you work that out over time, because no one ever gets to the deathbed and wishes they worked more hours. So it's about finding that right balance, but yeah.

Jerome Salimao:

Yeah. Awesome.

Sherif Mansour:

If you're not freaked out, keep looking into it.

Jerome Salimao:

I am freaked out, but I'm going to do it anyway. I think that's [crosstalk 00:46:56] good idea. That's how we grow. So thank you so much for doing this. Honestly, it's been so good.

Sherif Mansour:

Well, thanks for having me.

Jerome Salimao:

Next time-

Sherif Mansour:

Thanks for sharing your story as well, Jerome, I think people sharing, "I'm going through this journey," makes it feel other people can go through this journey too.

Jerome Salimao:

I hope so. Yeah, I hope so. I hope people listening... I hope even if one person out there hears this and it helps, I'll be pretty stoked, but yeah, thank you so much, and definitely next time, you're passing through Wollongong, let us know. We'll go for a beer. We'll get Nick and Dave to pay.

Sherif Mansour:

Sounds good. I'm all up for it.

Jerome Salimao:

Awesome. Thank you so much.

Sherif Mansour:

See you mate. Take care.

Jerome Salimao:

Catch you later.

Sherif Mansour:

Bye.