Mistakes We Made as Product Managers
Just because you are a product manager doesn't signify that your opinions carry all the weight, in actuality your team works with you and not for you. This is just a sneak peek of the many mistakes we make as product managers. We all make thousands of mistakes and as a product manager, inherently, part of the role is making mistakes. We should constantly be learning from them, trying to be better, and improving all sorts of different attributes of being a product manager.
Join Parv and Alex as they chat about:
… and so much more!
To Connect with Parv:
To Connect with Alex:
Always make sure to communicate very frequently, even if you think it's the most simple, mundane piece of information, it could be a relatively high-impacting piece of information for someone else.
If you don't understand the product, there's nobody who's going to have that knowledge. You're the PM, you should hold as much of the information as possible.
While we have talked about what product management is and what a product manager does, there are certain things about being a pm that people don't necessarily talk about. On today's episode, Alex and I are gonna talk about how even though being a pm is fun, it can be pretty taxing often or not working as a PM means that there will be a lot of moments where you will be working alone. And so we really want to bring up that topic, and especially with the current climate and the pandemic, I think this is a great topic that we should be talking about. So with that, Alex, what do you think about it?
Yeah, absolutely, I think so. Pre pandemic, when everyone was in the office as a PM, you're normally the only person working on a team. But you're working with a team, you're working on a project with people in the same room, you're able to converse with them, talk to them, oftentimes, you're co located with other PMS. So you're able to easily look over to your left or look over to your right and CAPM and get feedback. But now with the pandemic, as a PM were more isolated, were essentially kind of were siloed off. And not necessarily just having casual conversations with our pm beers are mostly just embedded on these teams. But we're not like UX or engineering where there's maybe three or four people on a project. It just us, it's just one single pm typically assigned to a single project that's working with the rest of the team on it. But because of that it's a little more isolating, you don't have someone that you can really turn to who knows the project and can get feedback on. There's always your manager you're keeping in the loop, but not necessarily a peer that you can just turn to and get feedback on. Yeah,
I mean, it's so funny, right? Because when you think about product managers, they are usually working with so many different people across the organization, you're constantly talking to like design, engineering, legal privacy, compliance, like so many different folks around. But somehow it can still be quite isolating to be a PM, it can be considered sometimes a lonely profession. And you brought it up so well, like when you're part of different teams, you always have like, let's say, a couple of engineers working on a feature a couple of designers, a couple of people on the data side, but then hardly do you see more than 1pm on a team that can I feel
sometimes get taxing? Being honest, I surely have failed at some times where I'm like, I wish I had another pm who I could just like bounce ideas off of a talk to usually, you can make that happen with peers around you. But on a team, it's sometimes hard to make that happen.
Yeah, absolutely. I don't think in my career, I've ever seen a project with multiple PMS, it just that even normally a pm ratio on a team is like one to 10. So PMS are relatively few and far between. And you're not really going to be working on a single project with another pm ever.
I'm trying to think about other positions within a team. Is there anything else that is usually like that? I mean, you do have teams where you have like a single person on like data engineering or design. But I feel like there are still a lot of teams out there where you have multiple folks, when big organizations, for example, but pm like that's one where I hardly see that. And I'm trying to think there's any other actually, but nothing comes to mind right now.
Yeah, totally agree. I think the pm does own so much of our project, at least in their area, we in terms of strategy and requirements and coordinating those requirements across all the different teams, you don't see multiple PMS, and it might actually kind of start having people step on each other's toes. So if you do see multiple PMS, it's normally each of them owns a large project area, or part of that product. And then they're kind of all stacked, and then they're under one more senior PM, who's overseeing all the different parts of that product. But again, that product is going to be a large endeavor, it's not going to be something that's too small. No, that's
true. And I think this is something that when I was starting out as a product manager, and I used to reach out and talk to other folks in the field, it wasn't something that came up that often. Of course, pm is a fantastic career path. For those who want to wear multiple hats. It's fun, it's engaging. But this was something that never usually came up in terms of like some of the cons of the role. Maybe not a con, but it's still something the aspect of being a little isolated, and at times lonely. And I think it is something that we should talk about more in this career path as well. I've seen a lot of folks out there who have started talking about this and bring this up within the project man in space and happy to link out some of those posts in the Episode Notes. But yeah, I think it's time that we start bringing up some of the issues with the pm role.
Yeah, I totally agree, especially after a year and a half of really not seeing anybody and not having a peer group. It just really brought this to a head. I feel like and that's why a lot of
having a peer group. It just really brought this to a head. I feel like and that's why a lot of discussions that started around this. Maybe not issue but just reality of the role. And it depends on where you are. I think bigger companies typically have PMS and silos. So you'll have like a group of PMS that all sit together but don't really work together too much. They'll have some projects that kind of overlap a little bit, but you're not going to be sitting on too many meetings together even though you're co located. But then in smaller companies you'll often see There's a lot fewer PMS, but typically they'll be working on kind of pods or squads, depending on your nomenclature. So that squad has a PM, but also has all of the functional groups it needs in order to accomplish whatever its mission is. And so that case, the PM, yeah, there are PM, and they're the only pm on that role. But they're so embedded in the team that the rules kind of fall away. And it just becomes a team that's working on a single project. So I think in that case, it's one of those ways of breaking down this barrier. And you have a team that understands the thought process of how they got to where they are, they're all kind of wearing different hats, because we just work together so well, for so long on these longer projects, you kind of get an idea of why we're doing what we're doing, you can kind of get a better understanding of what each person's role is, and kind of where you can help out. I think, especially as a PM, typically PMS have some type of specialty, whether it's design, whether it's business, whether it's marketing, whether it's programming, and I think on these pods, the pm will sometimes be that swing player who's going between these different specialties, and kind of sitting on the engineering team or sitting on the design team and helping out wherever possible. So in that case, it makes it a lot more lively, a lot less isolating. But of course, that's something you don't see in a lot of the bigger companies.
Yeah, and I think what you mentioned here about bots, that's a great way of sort of breaking that barrier and lifting some of the issues around being lonely as a PM. But taking a step back, I want to talk about what could be possible reasons why this might be happening as a PM. And of course, like the first one that really comes to mind, which you brought up as well as, and it's been exacerbated with COVID. And the situation is sometimes having distributed teams, we have engineering design, and sometimes those groups and pods can be co located even though the team is distributed. But a pm usually could feel lonely when they're working with such a team because they don't have that kind of group around them. And I think with COVID, not just PM, a lot of folks felt that. But I think distributed teams could be a big factor in one of this. What do you think about that?
Yeah, no, I absolutely agree. I think even pre COVID distributed teams were especially where do you have it engineers are in India, and the designers are somewhere else. And then you just have this Pm is just sitting in an office working with these teams that are all over the world. It just furthers that feeling of isolation. Yeah,
that's true. We've been training about the other one. And I think another one that comes to mind is the team structure. I think that's something that, again, depends on organization to organization, it depends on the type of team structure that is being set up by the company. But
I think not having a cohesive team structure for the product group can also be an issue and lead to some of that isolation problem that we were talking about. Yeah,
pm is kind of unique in that you don't really report up that much, or report to the side, really ever, maybe your peers might not know what you're doing unless you specifically tell them. And that will really only come if your friends that you guys are co located and you guys get lunch together. Otherwise, there's not really any reason for the rest of the team to know exactly what you're working on other PRDs except for maybe like a brief sentence or two that you say during team meetings. But that's definitely not enough to give someone an idea of what the project is and what the scope of the work is.
Yeah, I think the way you sort of break that barrier there is sometimes can be like added dependency on to another team, I think that really can bring two teams together sometimes are two PMS a bit more into conversation. But sometimes PMS have individual mandates that they're driving, and there's just a lack of overlap between roles and responsibilities. I'm thinking back to my previous few organizations where I was a PM. And I mean, I had an idea of what they were driving in terms of the team and what their goals were and the metrics were but from a project to project perspective, it was just we were all in our own swim lanes. We weren't really overlapping that much except the occasional dependencies. But yeah, I would be driving my own work and my own roadmap, same happening on the other side with other PMS. Did you feel the same or see the same as well?
Yeah, absolutely. Besides maybe another PM, having like a paragraph and one of your Brds you really don't professionally interact outside of like all the office happy hours and those kinds of events.
I don't think I was ever shared that information when I was looking into the pm career path.
Yeah, I think it depends on where you are, and then also what you like, because I was like a product manager at like a small startup. I was like employee number seven. And the most we ever
seen one. This is the one where you wanted to go as a designer, but then you ended up with
seen one. This is the one where you wanted to go as a designer, but then you ended up with
me as a designer, and then you realize I was actually a BM and then we back into pm lane. So I think that was the funny thing is that I was the only pm. So every product we made like it's isolating because I'm the only product person but I'm also the only person who's defining what these products are. I'm the only one writing the specs. I'm the only one doing all of this. So in terms of if you really like product if you just want to I make products all day long. Being the only pm in small startup is kind of the best possible place you can be. Especially when I think it was like hardware software. So isolating, I think, in that case, I was in an office with, like 10 other people. So I always felt like there's people around me. But when it comes to actually doing the pm work, I would essentially get a hotel room and just lock myself in there and write out all the specs for the projects and the roadmap for the next couple of years. But I think also, personally, that's something I really like, I kind of like the challenge of trying to figure out a strategy, and locking myself in a room doing all the research, reading all the reports, reading all the surveys, all the research we've done, and then consult, like putting that all together into a strategy and then making the presentation. And it just you have so much ownership, which feels really nice. And then you see like the results of that strategy executed over the next year or two years. And if it works, then it feels really good. If it doesn't work, then you just reevaluate what you can do. And you make a better strategy. The next time
when you buy into that picture in my head, I just saw, have you seen that meme in which we have Charlie Day, with all like these pictures across the wall and like lines print across them? Just like trying to create that entire map of information? Yeah, that's exactly what I saw you as right now. And that locked in a room just like, Oh, Charlie Day from, it's always sunny.
I would say that's accurate.
I think sticky notes and posted. So one of the best friends of BM. Oh, yeah,
if you can see my room right now you just see like a post it notes all across my back wall of all my tasks and all that I scrub through the different projects.
Of course, you bring up a good point about even though you're the only one working and you're
Of course, you bring up a good point about even though you're the only one working and you're kind of individual in that sense, and isolated from other PMS, that could also be a positive for a lot of folks out there where they really enjoy working in their own lane and being able to focus on an idea and bring that to fruition. And of course, you do still get torn apart by a lot of different conversations that are happening. But then when it comes to the actual roadmapping, or ticket creation or other smaller activities within your team as a PM, you can do that individually without having to go through a lot of conversation with other product, folks, as you said, like you enjoy that. And that can be a great benefit. Yeah,
but I mean, definitely isolating if you're okay with that isolation, and then it could be actually a good way to really master product, or at least get a lot of reps.
Yeah, that's very true. Another one that comes to mind, and we'll have to get a discussion on that. One is not all companies and organizations, especially smaller ones have a defined career progression chart, right for product managers. And I think that in some way also creates this confusion around like, how do you progress? Where do you go? What's the right path? And and even then, there's not much to look at around you sometimes, which can kind of feel isolating as well.
Oh, yeah. Yeah, totally agree. I think pm like sometimes, it's not really clear what the next step is. And especially at smaller startups, a PM, what does it mean to be like, the only product manager, then delete all the other product managers is like, you cap out pretty quickly. And then you just always try to start taking up more areas. So I get my experience, like I was in charge of design product, and then marketing, because that's the only career progression you can do. It's not going further and product, it's going more horizontally and taking over more parts of the organization really depends on the company, I think, I think that was a small company for bigger companies. There's also a little bit of ambiguity around the career progression. Yeah.
I mean, bigger organizations, especially a lot of orgs, are doing a great job at defining career paths and for product managers now. But even then, I feel like I constantly get this question of like, what's next in a role? How do you progress as a PM, going from, let's say, associate PM 2pm to senior PM, what comes next as a lead? Do you become a principal, potentially a group going forward director VP, like, there is more and more details around it right now, especially in bigger organizations, but with smaller ones, I still struggled to see a well defined path moving forward. And when you look around with others, everyone on the same board, there is not
much to discuss about in that space with others. You can't bring that topic up that easily because everyone's a little unaware of what's happening, which is harder than you know, being able to talk about something for sure. So I think that could also have some impacts some time.
Yeah, yeah, definitely agree. I think depending on the size of the company, you don't know where to keep going. And yeah, I think a lot of PMS will just try to shift at that point. Once it's not clear where you can go from there. A lot of people will just leave and try to find a new role to learn something new. I think that's part of the reality of why a lot of PMS move is that after you get mastery or you've kind of maxed out what you can do in that specific company, then there's not really much to do besides doing the same thing you've already done and most PMS are pretty curious. They want to keep learning they want to keep doing new things. So the easiest way to lose the Pm is by I always make them do the same thing every single day for multiple years. The next
one that I want to talk about, I think is we've mentioned like as a PM, you are constantly building relationships with a lot of folks in the organization, when you go out talking to, again, a bunch of different people in different functions across the world, but a big thing that you're doing is making trade offs. You're saying no, you are not always being the Yes, man in a room. And I think that has a huge pressure and impact on a PM.
Yeah, for sure. I think the biggest thing about pm in general, I think you're just making sure you have really solid relationships with the team, because your entire ability to to get anything done, ever is just solely based on your relationships with the team. And a lot of times you have to say no, but you have to be able to have a strong enough relationship that can withstand saying no, or getting them to do things that they would otherwise not be able to do, especially with engineers, begging them to stay up all night and work on a feature, I get extra feature that you want to get in. But it's not resourced out properly. So there's lots of situations where you just need to make sure you have really strong relationships with your team that you're working with.
And I think that, you know, that constant trade off in saying no, that sometimes does impact those relationships. No one wants to hear a no. And when you're saying that, that often as a PM, sometimes that can lead to relationships getting severed within your working days. And again, like that's something that sometimes can lead to that feeling of like, isolation or
loneliness in the sense that you're constantly trying to trade off things make relationship work, but sometimes saying no, and then that just sometimes doesn't work out. So I think that becomes a tough one again, to manage. And again, it's so hard trying to talk through that decision with someone else. And like, Hey, I have this problem. What will you do as a PM, each
situation is so individual for a product team or for product manager that it's hard to sort of have that trade off discussion with everyone else. Sometimes you just end up saying no, and hope that the relationship still survives.
Yep. Yeah, I think so much of the pm role is like negotiating with folks, I guess you kind of get to a certain point where you're able to get a little bit better at this without salary and relationships, that's really important to just make sure that you're able to keep that Friendship first. Because it's like, when you say, No, it's maybe a one time thing for a specific project. But you're gonna be working with that person for many, many more projects to come. So the relationships always the most important thing.
Yeah. And that just goes back to the point that we've been making in previous episodes, as well as that. Being a PM, it's really important to build and maintain good relationships is just not even pm, I think that just take you far in life, but will definitely also take you far in your product management career path.
Yeah, I think that's also one of the hardest parts about COVID. There's people that like you're normally could have, like, really, like, I was an intimate but like, very, like close conversations where you're trying to get something done. And you have to do it over a phone. So it's tough ever more difficult.
Yeah, you're right. It's hard to have those candid conversations and really get into the meat of like, what we're trading off for, like, what's the pros, what's the cons, it's sometimes just being able to talk through a problem with someone face to face and have that discussion is so much more helpful. And I think that is something that kind of you lose out, especially as a PM working from home.
Yeah, I think of all the roles, piano is like a really difficult one to do. I think remotely. That's my experience, just because so much of its relationship building, and zoom fatigue is a thing, honestly, like you want to keep that camera on and be there for every single meeting. But it does get tiring. Yeah. And it's like, eight hours of meetings every single day. I don't know, I think we just worked a lot less in the office in retrospect. And then when it's as easy as just like flipping on sending a zoom invite, then you end up having a lot more meetings. Because before it's like shuttling to all the different offices or whoever your engineers were the rest of your
team, room to room. And with Zoom, it's too easy to move. So you end up having a lot, a lot of meetings. I think like this past week average, like eight hours of meetings a day and a half hours. So it's a thing.
That's what I'm not looking at your face right now. And I've turned off my video for this recording, because I do not want to do that right now.
I've had like one company that was like no videos ever. And then one company that is all videos all the time. All video all the time. It's so much more tiring. That is true.
I also agree that there's a benefit of that, but oh, yeah, and
that was yeah, one on ones. It's fantastic, I think, cuz you got a little bit more emotional information. But then it's like, there's like five, six person meetings. You just wish you could turn off the video.
Yeah, and all these things that we've talked about. They really can build up on each other and really have sometimes a negative effect. take a toll on one's mental health, especially a pm with all that you're driving and responsible for what's happening around you like these small things can sometimes add up, potentially make it feel like you're way more isolated than you need to be, then you can sort of protect against. But I think even with all of this, that we've sat and talked about, there are a few ways that come to mind in which we can make sure that we don't fall into that trap, don't make PM, a lonely profession and break out of that isolation circle. That usually happens quite frequently. And I think that brings up to your point that you brought up earlier, which was the board structure, right. I think that was a very interesting thing that you brought forward around having those like different boards, which have like self sufficient teams.
Yeah, I think the pods are I have all the ways I've worked with teams pods has been my favorite. Because it feels so much more collaborative, it feels like a team that's actually working on a single mission, as opposed to what it typically the way BM typically works, where
they have like three or four projects, they're working on the same time with multiple teams. Whereas a pod, you're like, super singularly focused on a single mission. And you're all in on that, which is a unique way to work, but also really rewarding. Yeah,
and I think another way of looking at that as just like, forming smaller and more tight Scrum teams, sometimes around projects or around deliverables, or even metrics, where you have that self sufficient group that you can connect with both through work, and not just for pm tasks, but also for just general other work later things as well, then, the thing, one thing that really comes to mind is also just talking to other PMS. I think that's a big one that I initially was kinda hesitant to do. You know, networking is always feels weird, especially to me. But I think that is something that can be really, really helpful. In a situation like this, if someone is especially feeling isolated as a PM, you are not the only one out there, if that's the feeling that you're feeling, and then talking to other PMS, that can just be so much more helpful. And it doesn't even need to be inside the organization, even ones from other companies.
Yeah, that's super key, especially because like pm is relatively rare person to find relative to engineers and a lot of other folks you'll see and at least the Bay Area and in tech in general. So finding other pm that you could talk to about all these kind of pm specific issues, that other people won't really feel sorry for you. Go, you don't have to code all day, you just get to talk. Okay, I think both of the trade offs for pm will be able to kind of understand, and you can also get tips and then learn a lot more, which is also fantastic. Especially because I think Pm is something like as we've gone through in previous episodes, just not that well defined and having kind of a buddy to try to ride through all the reams of information that are out there and figure out what is your kind of take on being a product manager.
I recollect a moment, I think two years ago, I was at a friend's house and I met another pm at that location. And it was just like talking through some of my day to day. And just like how, you know, it was getting a bit to me in terms of like the some problems that I was facing at work. And they were like, Oh, my God, I can't believe you're facing the same thing. And we just bonded instantly over that brothers and arms kind of feeling they're with us facing the same issues. And so it really can be super helpful. If you go out talking to other PMS inside and outside the company. With inside it's you have a much more similar context with the organization and the backgrounds that can be super helpful. And if you're facing an issue, most likely the other PMS will have also either faced it or might be facing it. So it's definitely worth reaching out and having a chat. And then as Alex said, like, going out and talking to other PMS. I think that's such a good point that you bring up.
Yeah, I think it wasn't until like, maybe three years into my career that I actually met other PMS. Actually, when we met. That was the most PMS I've ever seen in my entire life. Oh, yeah.
PMS. Actually, when we met. That was the most PMS I've ever seen in my entire life. Oh, yeah. Like 50 people, I think, and they're all PMS. And they're all that was so fun, though. Oh, yeah,
I thought so. I remember we walking to get coffee or Oba and just like chatting about your experience in mind and just like catching up over like, issue that we've been dealing with. And just that was such a good and helpful conversation. Yeah, absolutely.
Totally agree. Just having like someone else in the same field is so helpful, just to kind of have something to complain to you and they go.
Yeah, that's very true. I think another one that comes to mind, which is kind of related to the first one is ask for feedback within your organization with other product managers. I think when we're working on our deliverables and our artifacts, as a product manager, it can be hard to get that feedback or connect with other PMS because it's, as you said earlier, it's very driven by your own mandate and your own responsibility. But I think it could be really helpful and I've actually done this recently in which I met with Other folks on the pm team and then just sort of shared my artifacts that get feedback. And I think that was one of the best feedback sessions actually had as a PM. Have you tried that before?
Yeah, actually, when I first started at our old place, essentially doing pair pIanning. So I have a essentially a mentor. And then we were working together on a specific so I would make all the Brd and then she would review it, give me feedback, answer all my questions. And so that was incredibly helpful. I think that, especially because before that, I've never really, I think most
PMS haven't really had formal quote unquote, pm training. So how do you write a PRD? How do you do all this, I would just write bullet points, like, all the things have to be done. And so like, walking through a Brd or PRD, with like, another pm and getting that feedback, and asking those questions was incredibly valuable. And probably one of the best learning experiences I've had as a PM.
Yeah, for those listening Brd business require document and Brd is like a product requirements document? Yeah,
they're used somewhat interchangeably. Yeah, depending on the company you go to so. But
they're used somewhat interchangeably. Yeah, depending on the company you go to so. But they're just a requirements, Doc. Yeah.
But no, that's so true. And I think you bring up this fun term that I wanted to throw out there and talk about is, I've heard of pair programming, and pair programming. I think that's such a fascinating thing, when I think about it, and you just brought that up as well. What do you think about that? Do you think therapy having has a future? Do you think it's something that could be established within product management?
I think it's fantastic for onboarding and mentoring. I think it's incredibly expensive. From a business standpoint, the opportunity cost of losing 1pm, to a project to help another Pm is super high, especially because when there's not many PMS, I think it's one of those things where it's good to have 1pm, then share feedback. And then you can have kind of like a Venn
diagram where there's some hour overlap, and they compare notes. But I think paired PMA is just because the opportunity cost of it is just so incredibly high engineer is going to affect a certain amount of value output, but a pm might have like 10 times that value output. So it's like almost losing 10 engineers, I don't even know if you compare it because that's a higher level. But there's just a lot of opportunity costs to accompany.
Yeah, and I think while I like the idea and theory, and I really want to see if it's possible to do and there are ways of achieving this, but just the fact that the mandates are so different than the work. And the metrics that pm the driving are so different that it bringing two people together, is your right is expensive, trying to onboard each pm onto a completely different roadmap and the thinking process and a vision could be overwhelming for a product manager. But I do see some benefits in as you said, like during onboarding, having that kind of relationship with another PM, where it is kind of a back and forth. And sort of like that feedback, continuous feedback and iteration. I think that could be super helpful. And I think you said that, it didn't really help you out as well as your onboarding.
Yeah, because I was coming from a startup where there's no real process. So I think bigger companies have a much more process oriented kind of structure. And then they also have, I don't know what a good name for it is. But essentially, there's this approval process for all these projects. So it's not just writing the requirements is also getting through these approval processes. So for bigger companies, there's a lot more kind of just process involved. So having a mentor to help you go through that process is invaluable, because there's all these artifacts you have to generate. But you don't know what the artifacts are, you don't know what is expected. What part of the instructions people actually follow. Because I think there's a lot of
these things that are kind of outdated. And so you have essentially a peer mentor who is able to shuffle you along through these kinds of bureaucratic processes that a lot of companies have.
How do you think about the help that a buddy can provide you because I know I've had a buddy, as I've on boarded, and multiple organizations. And I think that could actually also be a really powerful way of combating some of the isolation that you feel as a PM, maybe just keeping that buddy process from onboarding and like, lengthening and up to, let's say, first one, two years, or three years, or maybe even having a buddy with like, 2.5% or like 5% Time dedication to having some conversations with you and working on roadmap. So like, documentation and artifacts?
Yeah, I think it's a fantastic idea. I think having a buddy, someone in your peer group who you can show all this and get feedback is incredibly valuable. I think it's one of those things that is, it really, like kind of disappeared during COVID. A lot of this would happen organically. You're
just kind of like you see your colleague, they're not doing anything. They're just eating a sandwich and watching YouTube videos, you know, like, Hey, you can look at my PRD while you eat, and like, share, and that kind of thing just doesn't happen during COVID. So I think like the buddy system works, it works really, really well in a pre COVID world. I don't know how well it works in a remote world.
Yeah, just heads up. I'm not watching YouTube videos that work. Alex, I don't know what you're doing.
So just you gotta watch all the tech Here's to make sure you have oh, yeah, that's true.
Yeah. But no, that's a good point, I think you have that affordance when you're in the office or just like a call upon a friend or a colleague, and just take them to a meeting room and just talk through stuff. But that does become much harder being remote and virtual. But I still feel like there is some merit to this concept of having a buddy, I do also agree and want to be cognizant of like, sometimes roles and responsibilities, and just your sort of workload can get so overwhelming that focusing on another PMS, but could be a lot. And so I think that's where we need to make sure that if we do set up the process of having a buddy, we need to have really
clear definition sometimes of like, what's the involvement, what's the cadence, and what's the type of feedback or information that you want to share? I think that could potentially help in a remote system or a distributed workforce. But I think it's worth trying out.
I think any type of help that you can get and your guidance is just incredibly valuable and worth trying out. And to see how it works.
As we've been saying, project management can get isolating, it is something that can be taxing. Just the nature of the role is so diverse, you're wearing so many hats, you're having so many conversations, yet there are times where you might not feel like you're part of a team, and you're constantly disappointing people by saying no, but everyone's going through that it's something that's part of the pm role, and it doesn't necessarily need to be a thing. I think as we work towards defining this role, more defining the structure a bit more, I think this is something that we should really start thinking about and start making sure that we can solve for. And if you see this happening, definitely bring it up. Have those conversations set up those times, and I think work towards making sure that we can find a solution within your organization to solve for this
bring PMS as a lunch even less isolated.
That is so true. I'm hoping I can grab a drink with Alex after this. I'm done with my workday finished off my tickets for today and maybe I'll text you after maybe we just go grab a drink. Yeah, look forward to it.