← Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Why Product Management is Broken and How to Fix It | Anton Zaides
00:38:38
Substack Week: Why Product Management is Broken and How to Fix It With Anton Zaides In this , we dive deep into the current state of product management with Anton Zaides, a seasoned software engineer and leader. Anton shares his perspectives on why...
Loading summary
Transcript47 lines
- [00:02]
Pasco Duarte
Hi there, Pasco Duarte here, your host. I wanted to share a story with you. You know how sometimes Agile just feels like following another checklist when like processes and frameworks feel more important than what we are trying to achieve and sometimes even like handcuffs. I was talking to a customer of the Global Agile Summit and he used a term that kind of stuck in my he said, I have Agile fatigue. And I've heard that a lot from people since then. But here's the thing, it doesn't have to be this way. So we started thinking and at the Global Agile Summit, which is happening this May, we're bringing together practitioners who've actually done that, who've broken free from this, you know, install the framework kind of mindset. We want to focus the summit on real life, first person stories of agile all succeeding that inspire you to action. We're talking real experiences, practical solutions, and of course, amazing insights from leaders like Gojko Adsic, who will be one of the keynote speakers, and Jurgen Apelo, who will be one of the keynote speakers as well. If you're ready to leave the Agile fatigue behind, just join us in Dalit. The early Birth tickets are now available@the globalagilesummit.com and mark your calendar. We will have workshops on May 18th, that's a Sunday. And then the conference itself will happen on May 19th and 20th of 2025 in Tallinn, Estonia. So let's make Agile exciting again. And remember, go to agile globalagilesummit.com that is, and get your early birth ticket. Now. It will only be available until early March, so grab it now. And now onto the episode. Hello everybody. Welcome to a very special bonus episode. We have with us for this bonus episode, Anton Zeides. Hey Anton, welcome to the show.
- [02:16]
Anton Zeides
Hey Bast, nice to be here.
- [02:17]
Pasco Duarte
Thank you, absolutely. So Anton is a seasoned software engineer and leader with over 15 years experience. From game development in Unity 3D to leading DevOps and scaling startups, Anton's journey is marked by rapid growth and in 2023 he began sharing his insights and experience for engineering managers, getting over 15,000 newsletter subscribers in under one year. He writes a newsletter called Leading Developers that I warmly recommend, so check it out. The link to his substack newsletter is in the show Notes. Make sure you subscribe and leave a comment saying you've heard Anton here on the podcast and he wrote a very interesting article. We'll dive into the article in a second. The article is called Product Management is Broken and I think it's got a few points that we need to explore. But before we go into that, Anton, tell us a bit more about your background and why did you start sharing writing publicly about product development and engineering?
- [03:22]
Anton Zeides
So in the last four years I've been working in a startup where I'm director of engineering now. And in the end of 22 we had, I would say a leadership course, right. A six week course for engineering managers. And it was by an organizational consultant. And honestly it was one of my most terrible experience in courses overall. I had nothing against her, but she never worked in a startup, she never actually managed people and everything was models from a textbook. Right. You know, urgent, not urgent, you have Johari's window. Everything that's like theory. But nothing changed afterwards and we were seven of us and we all agreed it was, I would say, useless. And my company paid a lot of money for that. And then I started to look, you know, search for actual content for engineer managers, by engineering managers. People actually experience that and there was not too much. There are a few books that I read that I enjoyed and I thought okay, let's, let's start to share. And yeah, I started with LinkedIn and after six, seven months moved to newsletter because I wanted deeper content. Not just social network is quite hard, need to be very, very on spot and newsletter has more space. So that's been my journey and I got great feedback from people like in my company and audience in general. Well, I like to share the honest stories like you do in the podcast. Like my exact experience, what I failed at, what I succeeded, not like general theory. And I feel that that's something that I missed as an engineer leader.
- [05:00]
Pasco Duarte
Yeah, as, as we were talking about in prep. That's really a. One of the core essential principles here on the podcast. Right. That this is a podcast by doers for doers where we share, of course we also share theory, but we also share a lot of first person real life stories which is really the focus of the podcast. And in, in a recent article, or perhaps not so recent, but you wrote an article called Project Management is broken and the link to the article is in the show notes. So make sure everybody that you check it out because there's a lot of great insights in the article that we're going to talk about today. And in your article you assert that product management isn't working, that it is fundamentally broken. Can you elaborate on some specific issues? Maybe some real life stories that you've identified that tell you that product management is indeed broken.
- [05:57]
Anton Zeides
So yeah, broken is of course a big word. Right. And maybe in some Places it works better. But I talked with a lot of people before I made that article. My friends, coworkers, people in other companies that the experience is the same. There are situation, I would say three manifestation of how it's broken. First of all, people develop features that are never used. I had it, a team in my department worked for three months on feature that was canceled the day after it was released, right? Not a week or a month. The day after the customer success saw it, they said oh that's awful, that's like the day afterwards, right? And it was, I would say, humiliating for people.
- [06:40]
Pasco Duarte
Yes.
- [06:40]
Anton Zeides
And it's not like we didn't work in agile, right? They released every two weeks. There was something to show, but you know, people didn't look at it. Once there was release news, people actually tried it and it was completely, completely not what they wanted. I would say the other scenario is just software that getting more and more and more complex, right? You add feature, you have this feature, bloat, whatever you call it, you work on the same kind of things and just add more and more and it's impossible to navigate. Developers who joined my company, they have no way to actually use a product. They don't know where to start from because it became so complex. And people who are from the inside, they kind of need to learn one feature at a time. And you take the whole picture, it's very, very hard. And the third manifestation is, in my experience, product managers have no incentive to innovate. Their main incentive.
- [07:36]
Pasco Duarte
Wait, wait, wait, wait. Okay, so I want you to explain a little bit more what you mean by innovate in this context. So they have no incentive to innovate, let's explain that phrase and then tell me exactly what you mean by innovate.
- [07:49]
Anton Zeides
Okay, so usually a lot of product managers, they need to deliver on the roadmap, right? They need to, maybe in some cases they actually decide what to put in the roadmap. But in many cases there are pressures, right? Stakeholders, customers, you kind of trash that have a roadmap and they need to deliver on time. And if by innovate I mean doing something that is I would say lower chance of succeeding, right? Not something that you for sure know and you're doing, working on a few months for something that's a bit harder, non trivial, something that you don't know how it will be received, creating, I would say building software to discover a problem, right? Instead of doing discovery by just talking, so you talk to someone, you have an intuition instead of putting like an exact feature on the roadblock you do like discovery of three different things and you know the two of them will go to the garbage. Right. You risk a bit of development time to try to come up with a better solution instead of I have seen like, you know, thing I had the most is phase two on the roadmap. There was a month of phase one for a feature and then a month for phase two, but the scope is already decided in advance for phase two without phase one releasing, without any feedback loop. So I would say that's one part. And the second part, as I experienced in my company, I work in an agriculture tech company which is a very, I would say non trivial place to work. And there are many directions you can go there. And we have a very innovative CTO that has some, you know, edge computing that really I don't want to get in too deep into Architect. But some ideas, they take a lot of time to develop and he never can convince the VB product to actually try some of that because it's hard, it's a lot of risk. We don't know if it work. And it's much easier to just add another feature, another feature, add to the product, do the same things. So I'll categorize in a natural innovation as doing something that is higher risk and non.
- [09:58]
Pasco Duarte
I really like how you define that because I haven't heard innovation described many in that way before. Right. Like innovation as taking a higher risk, therefore being assured more failures, but in the hope of finding a much bigger upside in some of those things that you try out. And you said something that I want to explore a little bit more as an example of this, which is you said there's this visionary CTO who has some really great ideas that would take time to develop and try out and he can't convince the Chief Product Officer to try any of those because of course of the time and the risk that it involves. Why do you think that dynamic develops in companies?
- [10:43]
Anton Zeides
I think as everything it's incentive, right. What you're measured on. And the CTO needs to bring that innovation that what actually he enjoys. And really smart guy has a PhD and they kind of, you know, have great ideas. And the Chief Product Officer is measured on delivery on the roadmap. I know it because I talk to him a lot. And he said, well, those are just the intuitions of the CEO. This is something that customer actually requested. This would be always my first priority. Right. And nobody measures the Chief Product Officer on business outcomes in our case. Right. And I think in many, many Companies. That's part of the shift I hope to see and start to see that product managers are not. They don't care if the feature is how it is sold, how it is marketed. If they deliver what they promised on time, they succeed, they get high performance rating, they can get promoted. And that's kind of misaligned incentives. Right. They don't. They don't have variable salary based on sales of features. Right. It doesn't work. Same as engineers. They are in the group of engineers. They just need to work and deliver on time instead of being accountable for. You know, people like to say product managers are the CEOs of the product.
- [12:04]
Pasco Duarte
But they really aren't. Right. Because they.
- [12:06]
Anton Zeides
They almost never aren't.
- [12:08]
Pasco Duarte
Yeah.
- [12:08]
Anton Zeides
Have you ever heard a conversation between a real CEO and the product manager and how it always ends?
- [12:14]
Pasco Duarte
I remember once we were working on a new product and I was kind of half engineering leader, half product manager for the product. And I remember how hard it was to create the bridge between business development, which had all kinds of crazy ideas, Right. Because they were talking to customers directly, and then the team itself. And one of the. I think the biggest tools that I was missing was the idea of creating a business on its own. Right. Like. And when you said product owners are. Or product managers are almost never the CEOs of the product, that's because many of us lack the understanding of what it is to actually get a business together. Right. Because getting a business together is not just about deciding what features to do. It's a lot more. It's interface with the customers, it's the business model. It's talking to the cfo, it's talking to customer success. It's a lot of things that not all of us are ready to do. Right.
- [13:16]
Anton Zeides
I completely agree. It's all of that. It's market, it's sales, it's not easy. And. Yeah.
- [13:24]
Pasco Duarte
And that probably leads to what you call the glorified program managers rather than through product managers. Tell us a little bit more about that. When you talk about product managers being just glorified program manager, what do you mean by that?
- [13:40]
Anton Zeides
So I can give you specific examples, Right. That you have a product manager and he got, I would say, a lot of requests from the executive team on features. Right. There was a meeting where everybody shared it. He organized it in a nice way, and they voted on the priorities. The executive team each got a vote, whatever. And then the highest priority one were put into the roadmap and he just got one vote out of, I don't know 10 votes and nothing that he really cared about got inside. And then he needed to deliver about a roadmap. And he focused, I would say 5% of his time to talking with customers. Right. And all of it also in zoom, never visiting them in reality. And his focus was very detailed Jira tickets. He was in every daily meeting stressing about dependencies between developers who is on vacation, something that's very low level and can be left to the engineering manager. Because he felt like his main responsibility is actually to deliver on time, which is classic project management. That's what project managers do, just make sure everything delivered on time, sync between stuff like that. And that's what he did not challenge the features, not think about the smallest scope we can do and then kind of discover if it works on validation. There was roadmap agreed for a year and then he kind of worked with it and was very happy when we delivered on time, stressed when we are not. And there is a lot of, I would say product management missing in this scenario described.
- [15:25]
Pasco Duarte
And this of course raises another problem because as we think about like the product manager or let's call the product person being more of an end to end character, right? Like kind of understanding more of what we would call a product CEO responsibility, then we also need to understand that they need to kind of step out of the day to day details. So they need to create kind of a collaboration and understanding with the team and frankly delegate a lot of the detailed decisions to the team and the engineering leads, right?
- [15:59]
Anton Zeides
That, yes. And I think it's not that they are asked or expected to do the things I say. Like in my experience I wanted, that was my things, right? I wanted them to go outside. It's just easier for them to do those things because there's a lot of certainty there. It's the thing, I don't know based on their experience, it's the thing they know how to do. They know how to manage a scrum team or how to, you know, Prepare and do PRDs and stuff like that. And they escape from that. It's not like they are so overwhelmed, they don't have time. I offered my that product manager, right? You can have a month of I will take care of everything, let's align. I will do everything the day to day, I'll make sure we're on time. Just take that month to brainstorm, think of better ideas, visit customers, stuff like that. And it never happened, right? Because it's just so much easier to work with the day to day than kind of change things. And learn new things, as you said, how it works in marketing, how it works in sales. It's very, very hard. And only the absolute best product managers actually want to do that.
- [17:01]
Pasco Duarte
In my experience and especially, and I don't know if that's your experience Anton, but at least for me that's even more clear from product managers and product owners that come from an engineering background. Because it's not that it's just easy to do all of those detailed team centric tasks. It's also because it's what they know, it's what they've been doing all the time.
- [17:26]
Anton Zeides
Also ones coming from project management background which is also quite. And then you have like as you said, two backgrounds which are the most common ones and those are the easy things. And then I would say the best product managers, as you said, are ex founders that actually try to do something on their own and have this passion to create. And I worked with one of those and she was really, really great, right, because she had that passion on her. She tried to create a failed startup for a couple of years and I think that's, that's if I had to choose. That's an ideal background for a product manager. But it's not impossible to come from another background. It's just much harder and requires actually wanting to do it and not just, you know, falling to your habits.
- [18:12]
Pasco Duarte
And that actually brings up an interesting analogy, right? Like instead of calling the product owners and product managers the CEOs of the product, we should call them the founders of the business. The product is just a medium to develop the business. Right. And I think that that's a useful metaphor for our product owners and product managers listening to think about the product as a medium to create value for customers and therefore extract value for the company. Right. And it's not that the product is the goal, it's customer satisfaction that is the goal. And when I think about the tools that we use, I mean you already mentioned a couple of tools that I have to say honestly I think are making it very hard for product managers to succeed. And Those are the PRDs or product requirements document. Just the requirements word already scares me. And then the roadmap, because roadmaps are very much like Gantt charts. They are linear planning ideals, fiction if you will. That doesn't really help to manage a business on a day to day. When you talk to founders, you know that they don't manage their businesses with PRTs and roadmaps. Yeah, they might ask someone to build those, but they don't do that. And when we think about product managers that take that perspective, we also need to think about, okay, what would help them to find the success for the product. And you talk about some of that already today. And also in the article, when you talk about discovery, right? Like talking to customers and understanding what they are struggling with, we have a whole product management framework that is just based on that idea that we need to find what the challenges are. But then that also brings the need and perhaps you can help and share your experience here. That also brings the need to have a much better collaboration between product management and engineering management. Because there's a lot of decisions now that used to be done by product managers that need to start to be done by the team and their technical leadership. So how do you think about that? Because we really need to offload some of that product management and product owner work, right?
- [20:29]
Anton Zeides
Yes, I agree. And I think for me as engineering manager, right. And as a director of engineering, it all starts with actually trusting the product manager to take the right decisions, right. Feeling that the ex their expertise is, I would say, worth it. Because I don't know if it's the only profession where there is no real disciplines, right? Let's say imagine lawyers, right? You have divorce lawyers, you have real estate lawyers, you have whatever lawyers. Let's take real estate lawyer, put him in a criminal court. He cannot do that, right? He need two years to learn that exact profession. And I have product managers coming from ad tech, coming from cyber, coming for gaming, to the agriculture industry. There is nothing alike. They need to learn from scratch. And then as engineering manager, when you don't really trust your product manager to make the right decision, it's very hard, like I would say, to build that relationship. And most engineering managers are actually willing to take that stuff if the product manager will actually use the time to learn and go to the customers. And you mentioned the discovery. One thing that I feel a big problem is zoom actually starting from COVID it started in the first year, it didn't have another choice. But our main customer is in the United States. I have flown more than all our product managers combined to the United States. Not because there is no budget, right? Some of them never visited because they feel a zoom meeting is enough. And I don't know if you had that experience of actually sitting in the office of a customers, especially in B2B. I'd say six months ago was my last visit. I drove to the middle of Iowa, right Mid US A few hours, right? For one hour meeting. And it was the best meeting I ever had because a real scenario, right? I wanted the person to show how they use our system and then they didn't have some information and they took out the tablet and checked something there and got back to the system in a zoom meeting. I would never have caught it. It was something that was missing in our system, real something, a real pain for them. And I had another question that they couldn't answer. They just shouted in the hall and someone came and answered it. And I understood like how the information in the organization moving and that's things that don't really happen. And I think like if I try to do that because I feel the product managers don't really care about that. So those I would say are all kind of combined, right? It's a mess. There is no division between us. But if I was trusting the product manager, definitely I would be happy to take all those things and focus on the technical.
- [23:12]
Pasco Duarte
And I think we're kind of shifting already. That's a great story by the way, because what you just described I have seen so often, especially in B2B businesses that you visit the customer and you get insights that you would never get otherwise. But we're shifting already towards solutions. And in the article you do propose a set of ideas that kind of build up to a solution. You talk about having more of a functional organizational structure. Some would call it end to end with product and engineering working together and moving away from more like general or you even called it Jira secretary work. Tell us a little bit more about that.
- [23:54]
Anton Zeides
Yeah, I think it really, really depends on the organization, right? And for me, ideally the product manager shouldn't be involved in the day to day. Most of the There is like I would say two circles, right? You have the engineering circles, you have the customer world, right? Engineers are in the office, customers are out there. And product managers, you saw in the article, like with the shield between those parts, product managers in my opinion should be in the commercial world. That's a heavy commercial role with some aspect of engineering, of course. But they should be talking to sales and marketing more than should be talking to engineers and leaving engineer managers to actually deliver on that. You mentioned the prd. I'm okay with writing the prd. Explain to me the problem. Let's brainstorm together. I will do this dirty work that you can actually focus on the vision and stuff like that. I think you mentioned the founding founders never doing this stuff. It's a great analogy, right? It's perfect because they have the people doing it for them and the engineer managers, people Say that until I would say even 100 people organization, the founder should be the product managers and then who does the other work? The engineering managers. And it works. So I think like it's part of the solution. But I think like for that you need to go back to actually product managers being more involved in the commercial side and also involving engineers in that. I think that's the second part of the article that there is this I would say myth that engineers should never talk with customers. Right. And should never be involved in those decisions because they don't know or they will say the wrong things. And that's something that I feel we need to.
- [25:42]
Pasco Duarte
You even talk in the article about kind of a concept that you label as product engineer. So what do you mean by that? Is it, is it like you're. You're looking for a product manager that is more business and sales centric and then a more holistic product engineer. So someone who could translate those visions into, you know, whatever features, user stories, whatever. We use PRDs even, although I don't like that and focus more on the interface to engineering. Is that what you mean by the product engineer role.
- [26:19]
Anton Zeides
In partial? Because I think in some places it completely replaces the product manager. But I think that works only up to scale. There are startups, you know, post hoc, one of the good example, they have really good content and they share the journey. They hire only product engineers. And by that they mean engineers that decide what to work on. It's not like you don't have a product manager. The engineers are doing the discovery, they are doing everything. And actually they also do in ux. So you kind of have someone like you, you know, I don't know if it's the right name in English, the broken telephone game where you say one row to the person to the right and then moves. The more links you have in the chain, the bigger chance something will be broken. And if you have an engineer that's doing everything, like with founding teams, a new startup, it works. But obviously it works only in very, very small teams and startups. Right. You cannot have thousands product engineers running around doing whatever they want and taking decision without like no business knowledge. So I think for early startups I would say yes, hire product engineers and let people, engineers want to make those decisions. And once you are established and you have, then you can add more layers in the chain. But in the bigger ones, yes, I think product managers like everyone will shift more to the business side. Product manager will be almost fully managed there and the engineers to fill those gaps. You Mentioned, they also need to get a bit closer there. They cannot just care about the technical details because if you have this pressure, like engineers care about technical debt, product managers push for features, you have this power struggle if the products move to the commercial side. Engineers cannot care only about technical debt because it will fail, the product managers won't be there to supervise them. And oh, you cannot do the three factor now. It must be like the engineers too should care about customer happiness and business outcomes. And then they also kind of shift. And if you involve them, I found that they really, really care. Like, engineers are happy when customers use the product. They're not happy. Some of them are happy with beautiful code and stuff like that, but most of them happy actually solving a problem for someone. And if they're in the basement, nobody tell them what they work is. How does it help? They're not motivated, they're not part of that problem solving. And then they care only about the technical side because that's what left for them to care about to make the best software they can, not the most useful.
- [28:53]
Pasco Duarte
I think that's a great point. And let me emphasize that engineers are happy to know more about the customer. Product managers and product owners can help a lot with that by digesting that information and bringing that information with evidence and so on in a way that engineers can then grasp. They can help by creating a direct connection. So, for example, taking engineers to actually visit customers and see how the product is used in practice, which, as you said, also motivates engineers. And I think that us as engineering leaders, whether we are team leads or engineering managers or scrum masters or agile coaches, we can create that environment because we can talk to both sides and we can help get to that at that point. In a recent book, they had.
- [29:45]
Anton Zeides
The.
- [29:45]
Pasco Duarte
Book called Shift from Product to People that they talked about usability theater, where you actually gather all of the engineering team and you replay usability tests and then have discussions within the room so that they can start to understand better what the users are struggling with. I thought that was a great and very practical way to do it, because you really need to see, literally you need to see the customer to understand how they use the product.
- [30:13]
Anton Zeides
In this case, it was seeing like recordings or actually customers using the software. Like, how did it go?
- [30:18]
Pasco Duarte
It was both. It was either live in another room because of course, the user cannot be influenced by having like, you know, 20 people looking at them, obviously, or just recordings. And especially recordings are very useful if you have many of them, like, I don't know, 10, 20, or whatever. But of course if you're, if you want to have a little bit more insights, you need to have some interaction and some follow up Q and A with the user. So that's also a possibility. But what other practices, especially in the B2B side where you are, Anton, what other practices have you seen that can really help to bring engineers more close to understanding the customer reality?
- [30:58]
Anton Zeides
So the ones you mentioned I think are very underrated because there is a feeling that data is enough. Whether it's recording from Dog Rocket, even If you have 100 of them or a mixpanel or whatever, all of it is cold. It's just data. It's very hard to get satisfaction that the user behind it enjoyed it. So yeah, definitely taking them to meetings and engineer manager for me are also kind of a bit of a business role. They must visit the customers. It's not negotiable. Engineers, if they don't want to, they can not do it. But engineer manager must talk with customer. The second tip I would say is give the spotlight. Especially you know, in Slack, you have kind of release news, you can new features and whatever. And the product managers very often do that, right? They are the one communicating to the business side what was released if the product. Because they are, you know, that's their spotlight. But if they feel confident giving that to engineers, that the lead engineer works in that feature and they will actually send that message, it's not only about the recognition of the message, then the customer success people will have question and the engineer will answer them and they will develop relationship with the business because they will be facing that business and then kind of things roll out. You have more relationship with sales and stuff like that. Salespeople telling you cool, but I want to present it that way. And then they understand what usually the product manager is answering offline, right? In direct messages, in calls they're not part of. So product managers, even if they never deliver good news, it's okay for me as engineering manager I will say I will deliver the bad news, you will deliver the good news. Every new release, every cool things that the team did, I think it's the same giving people the spotlight. And even with sales or customer success team, let the engineer present it and be their guide and help them prepare. And if it works, you'll get the credit as product manager, it's okay, nobody needs for you to actually talk to get the credit if you have enough confidence. And we tried it a few years ago in my team with one product manager and it worked great. Engineers really enjoyed. Even if it's just emojis. Right. You send the message and people kind of react and you see who reacted and it's nice to have it and.
- [33:23]
Pasco Duarte
Those things really work and that we know that feeling heard is an extremely important aspect of feeling motivated and engaged with the product. And Anton, for those of us who want to dive deeper into this topic, we'll for sure put the link to your article Product management is broken on substack. We'll put the link to that in our show notes. But for those of us wanting to dive deeper into this topic of how to improve product management and engineering collaboration, what would be an article, blog post or video that you would have to recommend?
- [34:04]
Anton Zeides
So I I follow two main newsletters about that. One is John Cutler who talks about product management and there is a specific article about that in Medium. I can show you the link where it helps you have a conversation with your product manager and kind of define who does what. Like help you ask the questions to define your relationship better. And you do like an exercise separately you get the same table and then each of you fills what they think the product manager should do and what they think they should do and the other way around. And when you combine it, it's. It's very funny to see the difference. It never aligns. Right. It was. It has a good image on that. I'll show you. So I think that that's a great start as a conversation from both sides to have a discuss and see where your expectations misaligns. Because even if I tell my product manager I want them to be more, I would say business oriented once they see the data that from one to 10 they think there are seven on business orientation, I put two or whatever it kind of creates. It forces you to address those. Those issues. I think the more obvious one, I'm sure you heard about the Marty Kagan books, all three of them. I recently finished Empowered, which which I really enjoy and I think I'm surprised how many how like little I would say people don't really read about the profession Engineer management don't really read about how to do engineer manager. They just learn from experience. And product managers too. Like they don't listen to product management podcasts. Like your listeners are probably the exception. Right. The people that actually want to improve in their profession.
- [35:43]
Pasco Duarte
Literally because they're listening to this.
- [35:44]
Anton Zeides
Right, Exactly. So that's a good audience. But I'm sure they know their friends who don't like they will not use their free time to listen to something that Makes them better at work. Only like the better people, I would say, in the profession do that. So I think, like up reading three books, I would say is a very low effort to be better at your career. And there is Lenny's podcast, which I think that it's the biggest podcast in tech. He also has a newsletter where he brings product leader and engineering leaders and they talk about how it works for them. He brought Airbnb CEO Brian Chesky, which I think started the whole storm of what's broken Product management. I don't know if you talked about in period podcasts where you kind of lets people think he fired all product managers, when in reality they moved to be product marketing roles. It was a huge uproar. So he talked about it in any podcast. What did he do? How did he change the product manager role in Airbnb? So it was, for me, it was the trigger to think about, you know, maybe it doesn't have to be this way. Maybe there is a different way to change how it works. So if I have to sum it up, I would say John Cutler and Denny's newsletter and podcast and Marty Kagan Books.
- [36:59]
Pasco Duarte
Absolutely. We'll put the link to all of those in the show notes, so be sure to check it out. And of course, check out Anton's newsletter. Leading Developers. The link is in the show notes as well to make sure you guys go there and give his newsletter some subscriptions. So don't forget, take action. There's a lot of great stuff being shared on a regular basis. Is it on a weekly basis, Anton, that you publish every weekly?
- [37:24]
Anton Zeides
Ish. I would say it's a free one. So sometime I'm taking a break, so.
- [37:28]
Pasco Duarte
Yeah, yeah, of course, of course. We all need breaks every now and then, so make sure you check it out. Leading developers on Substack. And Anton, if people want to connect with you, is Substack the best way? Can they also connect with you on LinkedIn?
- [37:44]
Anton Zeides
LinkedIn would be perfect. Yeah. Substack is also good. I'm answering both of them. Anton Zeitis on LinkedIn. Yeah, whatever feels comfortable.
- [37:54]
Pasco Duarte
Absolutely. So we'll put the link to the LinkedIn page as well. Anton, it's been a pleasure. Thank you very much for your generosity with your time and your knowledge.
- [38:03]
Anton Zeides
Thank you so much. It was a real pleasure.
- [38:08]
Pasco Duarte
We really hope you liked our show. And if you did, why not rate this podcast on Stitcher or itunes? Share this podcast and let other Scrum masters know about this valuable resource for their work. Remember that sharing is caring.