Podcast Interview: Digital Product Development
Please note: This is a transcript of an interview for The No Nonsense Agile Podcast. Listen to the above podcast for the full experience.
SUMMARY KEYWORDS
organisation, product, people, agile, team, leaders, idea, product manager, building, behaviour, important, moving, talking, companies, role, work, engineer, organised, customer, retrospectives
SPEAKERS
Sam McAfee, Murray Robinson, Shane Gibson
Shane Gibson 00:12
Welcome to the no nonsense agile Podcast. I'm Shane Gibson.
Murray Robinson 00:16
I'm Murray Robinson.
Sam McAfee 00:18
And I'm Sam McAfee.
Murray Robinson 00:19
So, welcome to the podcast, Sam. And I think the main topic for today is going to be product and product leadership. So could you tell us a little bit about yourself and your background? And how you got to this point?
Sam McAfee 00:36
Yeah, yes, sure. So, I have been involved in software and digital product development for a little more than 20 years, I got my start here in the Silicon Valley area, during the last bit of the.com, boom. So my my background of the mobile product trio of product design and development, I'm on the development side of the stool. So I did a bunch of web development in the.com, boom, I managed to sort of survive the crash. And I had another decade or so of my own small boutique Web Development Agency, which was a wild ride of building a shop that developed software for other people. And I got exposed to Agile pretty early on. And so I didn't have a technical background, originally, I went to school for social sciences. And I had a bunch of friends who were engineers, and they all kind of pushed and cajole me to get a tech job in the.com, boom, so that I could pay rent. So that's kind of how I sort of like walked backwards into technology and got sucked in. And those folks were already kind of hit to extreme programming and some other things that were going on. So I would say I got exposed through my buddies to agile, pretty early on, you know, probably like didn't really look into it or take it that seriously, until I had started to hire people from my team its maybe like, 03-04 and trying to look on the internet for how does one organise software project teams. I just said one of your trigger words, but we can come back to that later. So I got into agile stuff pretty early on, I've been, you know, I've never kind of never looked back. fortunate. I didn't have to unlearn any previous methodology, it's always just been the way that I've worked. And kind of went through a path of being really as an engineer really into the the technical practices first learning. I mean, I was at the time learning how to be a good software engineer. So learning, you know, design patterns, and TDD and all that good stuff. And then later more into the process more into how does one get a team together? How does one get the team organised? We certainly used a lot of the approaches that were around at the time around team charters and things like that, for getting our teams kicked off for these client projects. And along the way, got exposed to some other frameworks and methodologies that are sort of adjacent cousins like lean and Kanban. While Kanban is part of agile, but sort of real kind of lean thinking. I dove pretty heavily into the literature around Deming and Toyota and a lot of that old school stuff, which I found really compelling and got really excited about and so I've been a fan of that stuff ever since. And after the the agency, the agency that we were building, did pretty well for about 10 years survived the great recession. It gradually got dragged down. And I had a few adventures as a senior technology leader of one sort or another in a couple different organisations. So that was, you know, me as an employee in an org, Director of Engineering here, founding or CO founding technical person in a small startup there lots of different experiences like that. And at that time, I was pretty deep into the lean startup movement as well, going a lot of those, those conferences and events and talking to people that were doing work there. And so for a long time, I've been involved in really bridging the gap between the lessons of agile and the lessons of customer development and figuring out, you know, what does the customer actually want, and really trying to integrate those two ways of thinking. So that's That's been a passion of mine for some time. The last five years or so, I have been working on my own coaching and consulting business once more called Startup patterns. And what we've been focused on is helping companies with product development to going in and coaching teams and working with, with getting the engineering product and design functions working in a more integrated, balanced team capacity. And that has overlapped a lot with an interest in leadership and organisation design and organisation health as well. So I, you know, the surrounding tissue of an engineering team that's practising agile and what happens when they run up against other aspects of the company that might be operating in a very different way. And so how do you kind of resolve some of those conflicts? Yeah, so that's, that's pretty much me in a nutshell.
Shane Gibson 06:05
Essentially, because you've still often you see somebody come out of social science, going to engineering, then going back into more of a leadership, social science type of role. So yeah, interesting journey from that point of view.
Murray Robinson 06:17
Actually, Shane. I'm a bit similar to that. Oh, yeah. Okay. I did a Psych and stats degree. And my friends persuaded me to go into technology because it paid better, which I did. And then I had I had kind of similar backgrounds, probably less startups, but I've been in startups, too, I've probably been been a bit more on the project management and analysis side of things. Shanes laughing because he hates project managers.
Shane Gibson 06:54
Its that word again. I dont hate project managers, I hate project management behaviour. Lets be clear on that.
Murray Robinson 07:02
Thank you. Good point, we had a whole discussion about that. Yeah, so so that's really interesting. What? So what makes a good product development team? Do you think?
Sam McAfee 07:18
Ah, okay. Well, I think it's a number of things. My favourite qualities would be cross functional. So like a team that's balanced with all the necessary specialties that you need. Dedicated, that they're, they're working all together all day long on a thing, and not spread across a number of different concerns. And so those are really important to me before the pandemic, I would have said, co located but we've had to really adapt a lot. I used to get a lot of debates in the old days about remote teams versus co located teams, and so on and so forth. And I wouldn't say I've changed my views. But I've certainly also managed to adapt to like a remote only situation. But it just puts more emphasis on how important it is to be cross functional and dedicated if you can't be co located. So that's been really important.
Murray Robinson 08:28
And to reduce the communication barriers, because I've done a lot of stuff remotely with teams in India. And when you work with, through different parties, like you're engaging somebody who's engaging somebody else who's being managed by somebody else in India, which is tends to be the way it goes, it's all those extra communication layers. Create a lot of friction and problems. Yeah,
Shane Gibson 08:57
I yeah, I'd actually say it's, you have to change the way you communicate rather than anything else. You have to fundamentally refactor it, reimagine it, the things that we used to do when we were in the same offices with people to communicate, don't work. So you actually have to mentally think about the ways you communicate when you communicate, what you're communicating what the purpose of those communications are.
Sam McAfee 09:20
Yeah, very much so very much so.
Murray Robinson 09:23
And it's all about one team. For me. I think that's, that's what I tried to achieve isn't how do we get one cross functional? product focused team?
Sam McAfee 09:34
Yeah, yeah, absolutely. I mean, a lot of places you go, where they're just getting into agile, that, you know, people being part time on different projects, is, you know, one of the biggest the biggest hurdles to getting getting moving in the right direction. Yeah, so I think that that dedicated team, at least in big enterprises is kind of the number one, you know, drum I find myself beating the whole time working with them. It's a hard one to overcome.
Murray Robinson 10:08
Yeah. So what what in your experience is the state of agile product teams in, in the corporate world?
Sam McAfee 10:19
Oh, boy, well, I wish I had nicer things to say. And start off on a dark note. You know, it seriously, I think there's been, you know, agile's been around what, you know, arguably a little more than, you know, 20, 25 years depending on when you start counting. And a lot has been done. Like, there's been a lot of great strides in how teams work when when they're able to work in an agile way. And I think that, while it's true, that the word agile or agile as a, as a thing, has spread into kind of mainstream corporate language. I think we're a long way from, you know, significant adoption of anything that really looks like agile, there's a lot of agile programmes, and there's a lot of people saying that they're doing it. But most of that, that I've seen, is lacking in the real principles that agile started with, you know, the human stuff, some of its the technical stuff, as well. But really just people working together on a team to try to produce value for a customer and working in small pieces and being flexible on the plan. That's really, you know, ultimately what it is. Are these companies that are doing Agile really doing that? I would say mostly No. So I think we've come a long way, but we still have a very long way to go.
Shane Gibson 12:01
So you know, there's the old saying about doing Agile,versus being agile. Yeah, when you look at a team or an organisation, you think part of it is there are companies whose sole focus is building products, that's what they do. And there there are companies that just happen to try and build products to support, the thing they're really about, is that where it's at, you know, that, you know, the companies that do nothing but build products really invest in it, because that's what they do. Whereas all the others, you know, it's just a side factor, right? It's like a finance function, something they have to do, maybe, but it's not the core business, does it affect the way the organisation behaves in terms of their product development?
Sam McAfee 12:41
Yeah, I think it does, I think that there are a couple ways to look at the phenomenon that you're describing. It can be a product, focus, that can definitely be true. And even that's been a moving target a little bit as the the kind of thinking around what product is, and what product management is, has been evolving, you know, even in recent years, and in new and exciting ways. But I think that that's still kind of gelling what people even mean by product, and you know, is something a service if it's offered digitally? Or is that a product? Like, that's a matter of debate? I think we're some of the places where I would actually draw the line that I think is related to what you're saying is, the companies that are, are sort of natively digital kind of, you know, let's say like born after the first wave of the internet, you know, that like post, post Google kind of era? You know, after the FANG, I guess, would, can we still say FANG, or is it meta now? I don't know. But yeah, like after the sort of like, the internet, native companies that are, are fairly like digital at their core in terms of like, what they're doing and their business model. And what they offer, are, they behave really differently, internally and externally than companies that have been around for 100 years, that might be you know, whatever industrial service, you know, healthcare, finance, manufacturing. They've had more mixed success, some some successes, but more mixed success in adopting agile and I think it's related to that. You know, Marc Andreessen, quote, software eating the world that there is a level at which, you know, digital capabilities are unavoidable. Like, all companies have to have them to some degree, and they've been able to shift from the old school way they were working to this digital world with really mixed success, so that that's kind of you know, what you're saying about product companies. That's what it made me think of is that that kind of divide in the timeline, like folks who came up after like the 90s just tend to be built and organised in a different way than some of the older companies.
Murray Robinson 15:17
Yeah, I have worked for a lot of different companies, giant telcos, and also startups and digital agencies and so on. And I find that corporations, their leadership team talks about innovation a lot. But if you have an innovative idea, you just get stomped on immediately. So it's like, if we wanted you to have a good idea, we would have told you what it was on the way in the door, right. That's the way big corporations work. But at the same time, they're constantly talking about innovation, and they use the words a lot, I find that there's a lot of theatre in, in corporations, there's agile theatre and innovation theatre. And, you know, it's all just, just words, and, you know, a hackathon. What is a hackathon, but just some sort of performance really. It doesn't usually achieve anything. So, you know, why is it do you think, what's going wrong in the leadership of these companies that, you know, there's all this talk about agile and innovation and products and customers? And yet they seem to behave the opposite?
Sam McAfee 16:33
Yeah. I think it has a lot to do with the, the, the mentality of the leadership of these organisations. And you know, whether they're more in their mindsets or more in an old school, industrial kind of model, like Frederick Winslow Taylor style, command and control way of factory model, yeah, the factory model, and it was successful for a long time, you know, people got some benefits from it. And, and even as manufacturing, moved away from it, you know, from mid last century through to the 80s, or 90s, you know, moving to more like a lean model. It's that factory model thinking was still hanging around in the management layer, and in the corporate culture. And so, a lot of leaders have just, you know, maybe they don't know any better, they just sort of come up in that world. They learn how to manage from their previous manager. So there's a lot of cultural baggage in some of those older organisations.
Murray Robinson 17:45
Plus the structure in those organisations is set up around functional silos, where when one specialty group does something and hands it to the next, which is the same as an assembly line concept. Yeah, so structural issues as well.
Sam McAfee 18:00
Yeah, and I think there's a mindset in a command and control culture, that is really hard to get rid of. Yeah, when we were talking earlier about what makes a good product development team. One thing I forgot to mention is, is autonomy. You know, the idea of the self organised team requires leaders to relinquish a lot of their control that they would traditionally be used to, you know, moving away from being directive and prescriptive, and more enabling and empowering their teams to operate and be nimble. And so that requirement of leadership that if they really want to do do innovation, they really want to be innovative. It requires them to empower their teams to be creative and flexible, and sort of, you know, give them a clear goal for sure. And give them you know, some some resources to use to get to that goal and some constraints to adhere to. But more or less, get out of the way, right, and let them let them be creative and let them work together and try to try to solve the problem, try to bring business value to the market, you know, check in periodically and maybe ask for support when they need it. But leaders have a really hard time at a psychological level, relinquishing that control. You know, that there's, there's something about the fear of giving your folks more responsibility. You know, when it's really it's like, yeah, the CEO, it's your head on the chopping block if it goes horribly awry. So it's not like an inconsequential fear. But still, I think it takes a lot of mental shifting, for leaders to start thinking at the executive level, what Agile really means and what it really requires. hires in terms of changes, and the way that you organise your people and the way that you give them assignments and all that sort of thing.
Shane Gibson 20:09
And I think it's, you know, we talk about leading from the top. And often we use lip service for that, right? We say, Yes, you've nodded and said, we're going to do an Agile transformation. But actually, what a leader at the top needs to do is change their behaviour. Yeah, so yeah, we take something basic, like daily check ins, you know, visibly showing that the leadership team are checking in on a daily basis about the health of the organisation, even though they're probably doing it in other ways that aren't so visible, make that change of behaviour visible. So everybody else knows that checking in daily as a team has value, right? It's the way we should behave. And I think you know, you, like you said, trigger words. I think managers have control problems. I think leaders tend to be able to, you know, be more serving more, set the goals and get the team going. But yeah, it's a transition. I think the other thing for me is, for somebody to go from a controlling managerial style of behaviour to a leadership style, it takes relearning, right, we have to unlearn and learn the new behaviour. And I think you mentioned that you were lucky, you went in with this agile thing. Like, what else is there until you move? But corproate went Holy shit, where did that come from? Um, so often, you know, we can do things like increase the visibility of what the team are working on, to make managers become more comfortable that the team are going right. So yes, it's kind of over controlling, because you're now showing them lots of stuff they should just trust you on, but you make it visible, and then they'll trust you more, that you're getting the job done, and then they'll become more serving in my experience. Right. So that's a good technique.
Sam McAfee 21:51
Yeah, that makes sense.
Murray Robinson 21:52
Yeah, I agree. We talk a lot about servant leadership, we want leaders, as he say it to provide vision and context and, you know, explanations and really then serve the team by, you know, setting them up for success listening to them, removing blockers. But, you know, we don't see a whole lot of that. There's a lot of leaders who are authoritarian, or their politicians, awful lot of politicians, or theyre bureaucrats. And those sort of people seem to be able to climb the ladder quite successfully. In a lot of companies, even small ones, I would say, it's not just the big ones. I've seen people do that very successfully as small ones, too. So I think we definitely agree with you, though, that it's a shift to servant leadership. And it's something that people can do, I did it myself, when I first became a project manager, I was told that I was responsible for the outcomes, and I had to make things happen at certain time periods, which, which was actually very stressful. And so I tried to make people do things, because that's kind of what I what I heard. And, you know, I got a lot of conflict and push back. And I had to learn how to be much more supportive and much more of a servant leader how to let go, really?
Sam McAfee 23:22
You got it. You said it. Yeah, I do a lot of coaching of technology leaders who are kind of straddling that boundary between the engineering team and sort of the management structure, the rest of the organisation, and a lot of what we do is talk about building influence, and managing up instead of letting go this idea that you can, you can make people do things by coercion, but rather, how do you use psychology and communication styles and tools to try to build understanding how to use empathy to build understanding that the people that you're talking to even if you're doing it up, right, so like talking to a senior executive, a lot of people don't really know how to do it. And they fail to understand that a lot of times, the executives used to not even being asked for their, you know, how they feel how they're feeling about something? Or what's your perspective from the top, like, you know, they're not being asked questions much about where they're at. And so it can be surprising to approach one of your leaders and then they might be happy to have you ask them, you know, how's it going, like, is there anything you feel like we need to be doing to support you? Because Because not everyone assumes they have all the answers and they look so confident, but it's actually really scary up there. It's kind of lonely. And so building a good relationship with senior leaders involves, you know, having a little bit of empathy for them on some level. And I think also what you mentioned Shane is really important about the visibility because a lot of times those controlling behaviours basically come from, like, I'm not, I don't know where we're at, I'm not getting the reports, I don't I can't see anything. Why is it taking so long, nobody tells me what's happening. And I'm going to come down there and tell you guys what to do. Right. And so I think if you can, if you can preempt that, by creating structures where they get the information that they need, at the level of granularity, that's important to them, they don't need that giant reports, they just kind of need to know, you know, here are our KPIs. And like, you know, anything you want us to be aware of, otherwise, we're just gonna keep cranking along. Yeah,
Shane Gibson 25:38
I think also. So, you know, you made the comment about, you know, moving from colocation to remote only, if you think about the change, you know, a lot of leaders I've seen used to walk the floor, a lot of managers on the floor, but they walk the floor and see why you're doing that do those, but a lot of leaders, we just walked the floor, right, that does feel the vibe, get a sense. It was a way they they got visibility of some things, and when your remote, how do they do that? How do they, you know, get the vibe of the organisation when they no longer can, can do that with groups of people, it's an interesting change,
Sam McAfee 26:14
it's been really particularly hard during during the pandemic, for sure that a lot of people have had to get really creative about how to maintain those, those human connections,
Murray Robinson 26:26
I find that technology managers and leaders generally have had little to no actual training in people management, and even managers just generally. So for example, they don't know how to do one on ones or why you would even do them, or they don't know how to give feedback. They don't know the basic techniques of people management. And I like to give a little shout out to the Manager Tools podcast here, because they are they are fantastic at this, giving this sort of stuff very slow and steady, very helpful if you haven't had it before. But, you know, I, when I was managing other managers, I tried to get them all to spend half an hour doing a one on one with their direct reports where they the first half would be for the other person to talk about what's going on. And then the second half would be for the manager to talk about, you know what I was saying, and some people did it, and it worked really well. And then others just refused and just dropped it? Well. So yeah, so uh, but generally, my experience is the state of people management in technology is pretty terrible. And if you if you leave a place, because of that, you're going to go somewhere else, which is going to be the same. So learning how to manage your manager is is helpful.
Sam McAfee 27:57
Yeah, it's critical.
Shane Gibson 27:59
So looking at it from a product lens. So again, taking taking the idea that companies that are new, you know, tend to start with a product mentality. And so you'll see cross functional teams, but if you walk into organisation has been around for a while you , while you have a IT team, and you might end up with a new digital team. And I see a lot of struggle from a product development point of view there because they are obvious, often in two silos, you know, the digital team really becomes a product team, these things they can do, things they can't do. And then the IT team really aren't cross functional and embedded with the digital team, they become a service provider. And that causes a whole raft of problems. Have you seen that?
Sam McAfee 28:42
Absolutely. Yeah, I've seen it a number of times. It's, um, yeah, it does align well, with the older organisations, as you're saying that, you know, it, I mean, it kind of growing up out of, really out of finance in like the 70s 80s. Right. So yeah, there is definitely some siloing there. And I think that having the, this the way the silos are organised in terms of budget, and attention, and like, what their initiatives are, and having that be totally separate from, say, you know, the marketing team or the, you know, digital marketing or trying to do something on the web that connects to some backend service and like, those are two totally different silos that have to work together. So they, they find a project manager to, like, you know, try to smash it through. Right, so Yeah, something like that. Yeah. I've seen a lot of that. It's, it's scary stuff.
Murray Robinson 29:50
So, so, how do we go from the solid structure to the, you know, cross functional product team, you know, how to how do we integrate user experience design and software developers unite together in one in one team.
Sam McAfee 30:08
Yeah, that's a really, really important question. So first, we hire McKinsey, right. So we tried that that didn't work. Okay, back to step one. So first, I think the way that I look at it, you know, I think a lot about the, in the traditional model, the hierarchy of a particular silo is and how the reporting structure works in that silo is tightly coupled to the work like the organising of the work. So like a manager might actually assign work to a report. And I think that what what I've seen, that works really well in in more successful and more modern, modernised companies is that the reporting structure in a particular functional silo, whether it's engineering, whether it's, you know, marketing, whatever, is more about people development, for that functional skill. And the work is this wholly separate organisational layer that you can superimpose and look at them both. But the work is organised according to totally different principles. And so there's nothing saying that because you are in the, you know, the operations team, and you work on, you know, you know, some of the servers and whatnot, that you can only do things that your boss tells you to do, like, if you're going to be you can be on a cross functional team with some other folks working on a product. And the work you're doing is determined by, you know, the backlog and the product roadmap and all that good stuff. And so I think that that initial principle of, of allowing companies to consider separating the two concerns of managing people is about developing people, really, it's like, you know, yes, an engineer might report to an engineering leader, and, and maybe their one on ones are more about, how are you developing as an engineer? Like, what's your gonna? What are your career goals? And, you know, are we giving you enough opportunities to learn and that sort of thing? It's not, you know, status reports on the work that you're doing, because we've got all these other frameworks and tools and rituals and agile over here, where we already are covering that stuff, right. Like we have our, you know, sprint reviews and backlogs and retrospectives and whatnot. So I think that that split of concerns is probably the starting point for me, of how orgs could start moving a little bit more in that direction.
Shane Gibson 33:01
Yeah, you get a hell of a year from the so. Yeah, it's changing the way I kind of think about it now, as there are people who are responsible for directing the work to be done. Yeah. And then there are people who are responsible for supporting people. Yeah, yeah. And the careers and the lives, those kinds of things. And they are two different roles. Now, sometimes the same person does both roles. But for large organisations or large teams where we started to scale, you have to split them out, because they are two different focuses. And if you try and do both, and you can't you end up only focusing on one, and that's typically not the supporting that people want. Right? For sure. Because it's hard, right? It's much easier to watch that that's been done.
Murray Robinson 33:45
Well, also, if your engineering manager focuses on, you know, the tasks of engineering, then they're going to be very, you know, siloed and defensive and not wanting to hear from designers and not wanting to change anything, and they're trying to commit to things that they promised three levels up, and it's just, yeah, it's bad. So we had a whole podcast on matrix organisations in the Spotify model, where we talked about changing these functional managers roles into a into a capability building role that was on the side of the organisation with the work being controlled by autonomous product teams to achieve a goal, but with the functional managers still there, but providing that mentoring, coaching, training, support, hiring, you know, salaries and so on. Because if you're just in a pure scrum team, for example, if you just just did Scrum teams, there'd be nobody supporting you, or coaching or mentoring you and people still really need that.
Sam McAfee 34:51
Yeah.
Shane Gibson 34:55
Yeah, I see burnout and Scrum, right? That's the do the team sprint. Good. Keep sprinting for the rest of your life. See how that goes for the team? Yeah, they get a little bit burnt out after a while. So I've got a leafield question. And it's kind of being triggered by this journey that you went through. Why was software engineering kind of the lead for agile ways of working in product development? Right. So So why why was that the thing that taken the lead out of all the other practices?
Sam McAfee 35:27
Wow. That's the hardest question. Wow. Um, you know, I, I think, I think probably, because, beyond a certain point, software really requires really a team endeavour, like, their individual, like, I felt some stuff as an individual, like when I was, you know, younger, like, yes, it's possible for a solo coder to maybe like build a tool or a product or some kind of, you know, useful framework or something, but, but most of software is is team built, like, it's, it's a collaborative piece of knowledge work. And the thing is seeing that there are you know, principles with groups of people having to collaborate and work together. That, you know, really, I mean, they show up in other types of work, but they really stand out in software. So I think that that, for me, I think that's, you know, originally, and I can remember, before, you know, UX, or even maybe product management was much part of the Agile conversation, I think, been around long enough to remember that, like, putting UX and agile together was like a radical thing, you know, 10, 15 years ago. So I think like, even just starting with the engineers, you know, committing code, we commit back then I guess we did have version control. Yeah. You know, you know, putting code together with different people wrote, and it all has to work. It's more is a ???. So I'm gonna segue here for a second with engineers and their skills. A lot of times when I'm working with teams, you'll run into the engineer that believes, you know, so shocking, that believes that their job is primarily typing, rather than conversation, which always drives me a little crazy. Maybe it's because I'm an extrovert, I don't know. But I'm like, Hey, a lot of the important stuff happens with your mouth talking to the person next to you about the code, not the actual typing, right. And so like, I think, when you start looking at pair programming and other kinds of methods, where people are really doing a lot of collaborative work, you know, the typing is the last 10%. Right? Like, it's, you know, I think, like, at this point, I've been an engineer long enough to say the algorithms are fairly straightforward. It's working with other people. It's hard. Right? So I think that's partly why I think that's, you know, and agile really kind of kind of wraps that principle in any language that that makes sense. So for me, I think that's probably what it is.
Murray Robinson 38:24
Yeah, look, I think software developers a lot of really smart problem solvers, because you have to pay to be a software developer. And they see themselves being blocked all the time, but I things going on in the organization's and they are independent thinkers. And so they try and solve that problem as well. But moving on a little bit. I want to talk about product managers versus product owners. And what is the difference between them because I think people get really confused about this. I hear Scrum, people now saying product owners should be product managers, but I think a lot of software people don't actually understand what product managers do, like the breadth of the rolls.
Sam McAfee 39:13
Yeah, yeah, that's a really important question. It's funny, I'm a little scared because like, this is, you know, one of those debates that can get a little rowdy. I, I don't want to get in trouble after this. I'd say but so. So you know, take it, take it with a grain of salt. This is just my viewpoint. I so the way that I understand it, is, you know, as I was learning Scrum, you know, back in the day, like the product owner, is, unless I'm mistaken, defined in scrum sort of before anywhere, like that's where the term comes from. It's not it didn't exist before that, right. It's a scrum thing. And if you look at how Scrum is taught, and you look at the guide, or you go through any of the courses, the the product owners role, it's sort of described as this interface boundary between the team and the business. Thats the traditional way that it's taught. It may have evolved more since since I was really looking closely at it. But you know, I run into product owners all the all the time, and they still sort of behave that way. And I think that, where, where I've, I've, I've been working over the years with some really great product managers, I've had that privilege. And I've I, I've had lots of good conversations with some of my colleagues who are, you know, leaders in the product management space. And a product manager is someone who is really thinking holistically about the business model of the product, like, who is the customer, and what's the value, and really has a more holistic understanding of how it's all supposed to fit together. I mean, most of the time, when we're making software, we're making it because we're automating some kind of human process, or replacing a previous automation, that to, to provide value to either make money or save money or, or provide a service of some kind. And so I think that the concept of product management is one where it's balancing an understanding of empathy with the customer, or the user understanding, at least at a high level, the the materials and tools that are being used, like, you know, knowing something about software development, knowing something about the kind of material that you're working with, whether it's web or mobile, or whatever. And knowing something about businesses and business modelling and how to prioritise based on value and those sorts of things. It's a very holistic way of operating that I think, is is broader than the narrow focus that's, that was traditionally defined by product ownership. So whether product owners are something that we need, I think, depends on the context of the organisation and kind of what level of maturity you're you're in, it may be that it's sort of a role that, you know, if you have no sort of agile process, and you're really just trying to get started, and you want to do Scrum, than just do Scrum, like, follow the guide, do the thing, work for a few years, and then evolve your way past it eventually, right. Like, there's something to be said, for training wheels, right. So if we're doing that, then let's just do it, and have the roles and follow the process and then use retrospectives to gradually grow your own thing. But I think that you're when we were talking about the human reference, the the show on the matrix organisation, in thinking about cross functional, you know, whether your squads or teams or whatever, we're calling them these cross functional units, I think that, you know, the having some consistency across those functions, I think is, is, is part of that, that whatever that guild system, where it's like, all the engineers still get together and say, We're gonna use Elastic Search, and we're all going to use it because like, we've got some standards that we want to adhere to, or whatever we're gonna all use, such and such, you know, a front end, we're gonna use React, and not Angular, whatever, whatever those decisions have to be made. So that people can be somewhat, you know, consistent. And you can maybe if you want to move to a different team, you're familiar with what's going on. The same with UX, like UX should have live, you know, standards, whether it's Google material, or whatever. And so the product people also have to be engaged with each other across those functional teams and talk about how all these products fit together. And, and to me, that's, that's beyond the capabilities of what's been articulated as a product owner role. And so I think that that's, it's maybe a path on the evolutionary ladder towards like, sort of true, I don't know, teal organisations or whatever model you want to use. Eventually, it'll it'll you'll jettison that that constraint and move more towards product management. I think.
Murray Robinson 44:44
I like what you said about a product manager being responsible for the business model and the product from end to end. I've been a product manager, like a proper product manager a couple of times in my career, and I think the product managers responsible needs to be responsible for the holistic product, which includes user experience research, business case development, market research, and prioritisation working with the product development and product engineering team being part of that team, if possible, you know, developing the business processes for customer support and service, working closely with with sales people and service people, talking to customers regularly and bringing all that feedback back that I think of it as being like, a CEO for the product, within, you know, a bigger organisation, and it's, it's a strategic integrating role that, you know, sets direction and priorities and provides a lot of communication linking everybody together. That's, that's the way I see it. Do you see it like that, too?
Sam McAfee 46:03
Yeah. Yeah, that's a pretty good way to way to describe it. That's, I think I agree. And I think that there's a lot of, it's really, it's really a, a balance of a lot of different skills, right? Like, got to look at metrics and analytics dashboards and like, have a little bit of statistics knowledge and have a little bit of how to do it. Can you do a p&l from the product? Can you look at like, what's our revenue supposed to look like? How much is the team costing, like, there's, you know, kind of at least like Small Business Economics involved, that you need to know. There's the user research part, like all the things you mentioned, it's a lot of different complementary skills for different kind of backgrounds, different parts of the brain, frankly. So it's a really broad Oh, and then lastly, like, being able to influence and as you're saying, like, make relationships with the sales team and coordinate with other product managers and sort of, you know, negotiate for different access to the resources, so that you can help the team make sure that they have what they need, like those sorts of things. So it's a pretty important role.
Shane Gibson 47:18
So it sounds to be a bit like a startup with two co founders, and you're the co founder, who's not the engineer?
Sam McAfee 47:25
Yeah, basically.
Shane Gibson 47:29
I was just thinking, we should change the term for product manager, the product leader, right? Because they're not managing shit. They're leading everything. So I like Yeah. I'm just gonna, I'm a product manager for now. Sorry.
Murray Robinson 47:49
But I think that I see on LinkedIn and various media, I see there are some well known product management training people and gurus who say that there must be a clear separation between product and engineering. And they must be in two separate teams. And I think it's around this idea, there's old idea that product managers are mostly responsible for research and business cases. And then they they get something up and then it gets sent off to somebody else to do. And then they do the marketing for it maybe, I just think that that is so old fashioned and so problematic, because in order to do that, you'd have to get your product perfectly right up front, conceptually, so you could give it to the engineering team to be to build it. And I think one thing we know is that that is not possible. That, you know, we know from the whole lean startup movement, that a large amount of the number of the things we think about products and what people want are actually wrong. They're they're all just assumptions, like, most of your requirements are really just hypotheses about what people want. So it's absolutely critical to just do the smallest thing you can to get feedback from real customers and users, you know, and even today, I see a lot in Agile teams. And even in Agile product, cross functional product teams. This idea of hypothesis testing is is still really uncommon.
Sam McAfee 49:29
Yeah, yeah, absolutely true. Yeah, as I mentioned earlier, I'm big, big fan of that movement. And, and I think that that concept, while old fashion about the separation between the product manager, and the team is still really common, maybe ramping even. I might use the word wrap and it's like it's all over the place. And what I've seen With really successful teams that can produce products that customers love and can grab traction and scale, you know, really pretty quickly is when the team, the cross functional team is, is that Venn diagram that we sometimes see around, you know, like, you have the whole, feasible, viable, desirable and overlapping circles. And you can can put it in terms of engineering or, and UX, and product are all responsible for spearheading decisions, and each of those three circles, but they all overlap at the edges, right, like an each one of those roles knows enough about the adjacent role. A good developer understands enough about product management and enough about design to really be able to be collaborative, with their, with their partner functions on some of those decisions. You know, I, I'm a big fan of having designers and engineers pair whether, you know, work on a feature at the designer sit, or maybe we're doing it virtually now, but, but you're still, you know, working together in real time tweaking the UI and making those changes. Because it's all about fast feedback, which which leads back to your your point Murray about, about hypotheses and how, when you're building a new product, there's a lot of uncertainty, there's a lot you don't know. And it is unrealistic and impossible for the product manager to have all the right answers in their head. And then to just sort of spoon feed like, okay, work on this story, okay, work on the story, you know, like, I'm going to put all of the stories in JIRA tickets, and then you will execute them team. Like, we really don't want to be working that way, right? We really want to be working autonomously, collaboratively, you know, talking things through, you know, stopping work and going to the virtual whiteboard and changing our minds and taking in new data and information like, oh, we just deployed this feature, and look like our numbers on the analytics dashboard are tanking, like, let's roll that back. And they we have to rethink what we're doing here. And so the successful teams are, are teams that are able to iterate quickly, right? So the iteration loop is, is equivalent to the speed of learning, the faster you can iterate, the faster you can learn. And the teams that can do that. Try to remove any bottleneck in the speed of iteration and one of the bottlenecks is waiting for the product manager to tell us what the right answer is. That will slow everything down. You don't want to be doing that.
Shane Gibson 52:53
Yeah, I pick up your point about forward planning, right. So it's a balance. So I'm a view that, you know, putting two years worth of stories into JIRA is just dumb. Even worse, is using that information to try and have a guess about when things were actually finished and make them is probably as dumb. But we do need somebody thinking holistically, we need somebody thinking, especially if were scaling right, especially if we have multiple teams, squads, units, working together on a product that becomes a scaling issue. And therefore the role of a product leader to sit there and, and have a more holistic view is really important. But they're not writing every story that's gonna be done for the next two years. And sometimes you see that happen. Yeah, so yeah, but let's not do that one.
Murray Robinson 53:42
What do you think about product planning? So in Agile, what are we talking about? We're talking about product roadmaps, product canvases, product, product plans, what would you recommend?
Sam McAfee 54:01
Well, I am a fan of canvases of various kinds. And I was a big fan of the Business Model Canvas when it came out. And we've had lots of other useful canvases that have been developed over time. And so I think, you know, connecting to changes brought up about having a vision. I agree that there's an inevitable tension in bringing a product to market and making it successful between having a vision and thinking ahead. You know, like, agile isn't against planning, right? Like, you know, that like you can think ahead like here is, here's the customer segment that we're interested in, that we're passionate about. And we want to solve problems for them. And maybe we don't know exactly what the solution is, but we have them in mind. And we're going to iterate through a lot of different ideas and So we're successfully serving that market. Right. So keeping that long term perspective, is sometimes at odds with the idea of iterating. So it's, it's absolutely true that if you only rely on iteration as your guide, you just like kind of reacting to the data from the latest release, with with your, you're driving in a fog, you have a short sort of visual horizon, and you're just going to going to find the local maxima, really, you're going to expend all over the place, and then you'll never kind of get past that level. So there has to be, you know, a long term vision for where we're trying to go. Right. And so, I think it's a balancing act, you know, really lives in the product manager, but also like leadership, you know, CEO, and sort of just owners of the business to sort of say, you know, here's broadly where we want to go, you know, we're starting with a product, but maybe it needs to be a platform someday with multiple products on it, or a suite, or blah, blah, blah. But that's going to be down the road. And so for now, we're just trying to get this one product, right. And then we're assuming that we'll be able to build some adjacent things that will also serve that market. So that long term short term thinking and trying to keep those two things in your head at the same time, is, is really important. I don't know, I might have gotten off track, I'm not sure.
Murray Robinson 56:23
I would agree with you on that. I what I like to say is, out of all these 1000s of pitches that you could have of your product, probably boiling away in different people's minds. What is so one most important thing that we could test? Now, you know, what is the things that we think is maybe the core of it the most important to the customer that, you know, we can we can just do a smaller version of it. In a month or so let's say Yeah, and just say, did I really want it? Are we you know, smoking too much? Wacky tabacky?
Sam McAfee 57:03
Yeah, yeah. I mean, it's just an idea in our head, right, until they're not only using it, but probably paying for it, right? Like, what is the customer actually willing to take out their wallet and part with their well earned cash for the privilege of using our service? Right? Like, how, how can we actually validate that it's it, you know, it's solving a problem, it has to solve a really existing, painful problem for a sizable reachable market that's worth building a business around. And that, that takes a lot of baby steps of getting things in front of them and getting feedback. And, you know,
Murray Robinson 57:42
and probably has to do it a lot better than the existing solutions that are out there can't just be like 10% better. I've heard. I think Andres Andreessen Horowitz saying that it needs to be 10 times better at solving the problem because of this such a big barrier of people moving to something new.
Sam McAfee 58:00
Yeah, yeah. Yeah, definitely. Definitely, the switching costs, there's an interesting framework that we sometimes use in workshops, and when we're helping teams think about, think about getting started with their, their product around the pull and push forces for both the old thing, and then your, your ideas for your new thing, really helping them think through, you know, what would make a customer want to move away from their existing, you know, what are the irritations why they'd want a new solution anyway? And what are they kind of tied to? And? And what are the attractive aspects of your idea? And what are some of the hindrances of them adopting it? So you look into like, model all that out, you know, with sticky notes or whatever, it helps people really think through what you know what to take into account as like, what's going to be the biggest risk that might block adoption, right? So that, you know
Murray Robinson 59:12
To do that wouldn't you have to really understand your customers well? And, you know, maybe even talk to them, maybe even invite them into the room to do this exercise with you?
Sam McAfee 59:23
Ideally, ideally, so like, all those things might be an assumption, right? And then we might go go find out or maybe we do that exercise after we've done some initial initial research, so we're kind of basing it on conversations we've had, but yes, your point is very, very well taken.
Shane Gibson 59:40
So you're just disappointing me now. I always thought it was just, you know, you extraordinary pretty picture and the product owner making the engineers coded and then, you know, overnight success.
Sam McAfee 59:51
tried that. We tried that, but it turns out that hasn't worked so well. So now we're trying to do else.
Shane Gibson 59:57
And then when it does work after 10 years, you change your name and become Meta right? Yeah. So we kind of, we are into an hour. And as we always do time goes really fast. So I thought, yeah, I've kind of come up with my thoughts while already thinking about his of where we've gone. So I really like the conversation around product leaders that the idea of them being holistic, reinforces, you know, conversations we've had before around. Often it's when you're scaling that you need these new roles. But I do like the idea that actually, even if you're small, you still need that, that long term vision that roadmap there, you know, what are we working towards, but let's deliver something now. I kind of like the idea that maybe the product owner is more about immediate value and the product leader or product managers about future value, but I'm not sure that actually, that is a true statement. So I'm going to ruminate on that one. I like the the idea of you know, people directing the work done versus paid people supporting the people doing the work. They're they're very important roles. And we often forget about one. One of the ones I picked up with, as you talked about React and Angular, just, you know, leaving it out here that there's a whole new version called Svelt that we use in my startup that we love. So for those Rangler act people come to the new world. So just a shout out to the Svelt team.
Sam McAfee 1:01:18
I dated myself, right.
Shane Gibson 1:01:22
That's fine. So Angular, React and Angular are still number one and two. And, yeah, let's not get in a religious argument about how you count that one. I think we also had a quite a good thing coming over many of the podcasts around when an organisation was founded, and how that changes its behaviour. You know, industrial, your organization's versus digital, but I've never really thought about about colocation and remote. So I'm really intrigued, you know, 90s onwards, we got used to co locating with the new, cool ways of working, but 2020s, we're going to get used to remote. So is there a new generation of workers that are remote first. And this whole idea of actually being co located is just going to be weird to them, as it is for us for things that came out of the 70s. And the last one, is we talk about factory thinking coming out in the 1900s and their behaviour. And I think we need to differentiate it between systems thinking, which is still important understanding how the system works, and we can optimise it. So some lean stuff, because often see now with agile practices, we often forget about the system. And we think it's just a bunch of people doing shit, and not a system to be optimised to make things better. Right. So retrospectives is a great way of figuring out what we're going to change next, but often, we don't. So those are those are the things I kind of picked up from from the chat Its been awesome. Murray, what about you?
Murray Robinson 1:02:52
Well, I found that I agreed with everything Sam said, and our experiences are very similar, Sam, I think that you know, that there is a lot of leadership required, and leaders determine the culture through what they reward and punish. And then everyone follows them because they want the rewards and to avoid the punishments. So ultimately, it's leaders who define, who can help make an organisation successful, what not, and you know, everybody can be a leader. And if you're in a management position, you should try and be a servant leader. I'm interested in how to scale this model, what I'm thinking of is that if you had say, a bigger product that needed 100 people to work on it, you would have like a real product manager at the top, who was given power and authority and budget. And then you would have maybe set 10 teams and the teams would have product owners and and you would have like a, you know, product owners because they're focusing on working with a team to get stuff done within the shorter term and but product, a product leader at the higher level, because they need to be able to be able to look at the big picture, but obviously working very closely with everybody. And that's and maybe then you've got some integrating roles. You know, maybe there's some design in the teams and some bigger picture design and architecture working more closely with a product leader. Does that sound right to you?
Sam McAfee 1:04:46
Yeah, yeah, I think so. I like it. And I think that what, what it makes me think of this because I know orgs that are that are trying to put something like this together trying to do it trying to figure out what what's important, what matters just occurred to me that there's a time element that I think a lot of organisations miss, which is that transformation takes time, like a lot of these behaviours are very, very deeply integrated, because of the incentives that you just described, you know, the, the incentive structures are very strong. And so we need to have a little bit of patience, in, in how we approach, changing the way we work, especially if we're kind of putting this new model in place, and we're going to try it. And it's not going to work so great for a while, right? Like, it'll be halting and fits and starts. And that's how this goes that should just be expected. And so I think there's a, there's a kind of rushing to be agile, that that that that folks would probably do well to, to let it let go of that. And, and for us to really be successful. If we're really going to embrace empathy and autonomy and all that stuff, then we have to like put our model together, and everyone has to be involved in helping to figure out what's working, what's not. I mean, that's, you know, retrospectives and the rest of it. And in order to do that, you need to slow down and take the time to work together to look at our process and look at what's working in a lot of these organisations that I see where they're struggling with this. They're so under the gun to produce and produce immediately, like let's install agile and then get going, right? Because you've got quarterly earnings to hit or whatever it is, right? You're we just really need the air cover from leadership to say, Okay, if we're doing an Agile transformation, you know, it's like, you know, training a whole team or a whole league in an from one sport in a new sport, right? Like, it's gonna take a while to learn the skills and the moves and the plays and get it right. Like you can't just like snap your fingers and do that over and, and a
Murray Robinson 1:07:07
lot of experimentation as well. So, you know, it really worries me these companies coming in and installing safe or installing, you know, Spotify started out talking about that, or will go on forever.
Shane Gibson 1:07:24
She just could you just give me a new joke. Now, the only time you need to instal cyphers when you're a bank, and you got a shitload of money, you want to look behind.
Murray Robinson 1:07:35
Hey, Sam, it's been great talking to you, how can people you know, interact with you or get your advice or, you know, learn from you?
Sam McAfee 1:07:45
Yeah, there's two main ways. I hang out a lot on LinkedIn duel. That's how we met. And I'm very easy to find Sam McAfee. Very easy to find on LinkedIn. And I really encourage connection requests, people who want to talk about the topics that we've been discussing. So please, if you're listening to this, and you want to talk to me, don't be shy. LinkedIn is an important platform for me to communicate. And then our our work and our materials and my main blog, where I do a lot of my writing is at startup patterns.com. That's kind of our home base. So either of those two places, plenty of ways to find, find us and get in touch with me.
Murray Robinson 1:08:31
All right. Oh, it's great.
Shane Gibson 1:08:33
Excellent. Well, let's get to and hopefully we'll catch you later.
Sam McAfee 1:08:38
Yeah, thanks. Thanks so much for having me.
Murray Robinson 1:08:40
Thanks, Sam its been great0. That was the no nonsense agile podcast from Murray Robinson and Shane Gibson. If you'd like help with Agile contact murray@evolve.co That's evolve with zero. Thanks for listening.
