Software Delivery in Small Batches

A long-form weekend conversation on the vision, objective, strategy, and roadmap aspects of product management with Saeed Khan. Saeed is a product consultant based in Toronto and also a member of the Flow Collective.

Show Notes

Learn More
ā˜… Support this podcast on Patreon ā˜…

Creators & Guests

Host
Adam Hawkins
Software Delivery Coach
Guest
Saeed Khan
Product Consultant. Focus on building great products, processes and people.

What is Software Delivery in Small Batches?

Adam Hawkins presents the theory and practices behind software delivery excellence. Topics include DevOps, lean, software architecture, continuous delivery, and interviews with industry leaders.

[00:00:00] Hello and welcome to the Weekend edition of Small Batches. I'm your host, Adam Hawkins. Our normal episodes are short and focused on a specific topic, small enough that you can listen to them whenever the weekend editions are a bit different. There's more time, less structure, and more exploration. On the weekend edition, I explore software delivery through conversations with industry leaders.

[00:00:31] This weekend I'm speaking with SAE K about product management. I know SAE from the Flow Collective and a recent post of his on LinkedIn really resonated with me a lot of the time. On the show, we cover the best ways to build software. SAE and I talk about the side of product management that actually precedes building software.

[00:00:53] We begin with the framework for product management and continue on. All right, enough from me. Let's hear from Saed. Well, Saed, welcome to the show. So happy to have you here. For the listeners who may not be familiar with you, why don't you introduce yourself in your own words and the type of work that you do?

[00:01:15] Sure. Thanks Adam. So I'm Sait calling. I'm based in Toronto, Canada. I work as a product management consultant, generally speak. That means I work either with software and technology companies or technology organizations in larger companies. And really what I try and focus on is helping them build better products, but also better product organizations.

[00:01:37] So a lot of the work ends up being working with the team members, working on better skills, better process, better organizational alignment, and then through that work they can then build better and more successful products. A lot of my focus is either on the early stage where strategy, road mapping planning, or the later stage, which is really once a product is released, operationalizing it, and really optimizing that product for whatever markets they have.

[00:02:11] Right. So for the listeners that probably don't know this, but you and I have actually been talking on and off through the weekly meetings of the Flow Collective and in the Flow Collective, there's a mix of a bunch of different people. You got product side consultants, engineers, et cetera. But you and me are coming at.

[00:02:29] The area of building products and building businesses. You coming from the product side and me coming from the engineering side, you know, a lot of the talk on the podcast so far has been around like, okay, we have something, we need to build it. What does it mean to actually build this, say in a good way without really giving more?

[00:02:50] Focus to like what comes before. So the signal to me that I was like, Okay, I really gotta talk to you about, this was something you have posted on LinkedIn, and I'll put a link to this in the show notes, but it was just a slide that had a hierarchy of, I think, was it. Business like vision objectives and strategy and then product objectives and then like roadmap.

[00:03:13] And it just landed with me so perfectly because it seemed to convey a good mental model of what it meant to do product well, but then also revealed to me like where I had been flooding the gap was like in my career. So can you tell us a little bit more about this post and like why you structured it, like.

[00:03:36] Sure. Yeah. So the post, if you think of layers at the very top, I had, like you said, business vision, objectives and strategy, right? And so every company should have, in theory, a vision. They almost always have some form of objectives, and hopefully they have some strategies to achieve those objectives. And so when I wrote it, I think most of the work that I do is obviously from a product perspective.

[00:04:00] So I did really elaborate that far. But underneath it, I elaborated so. Product vision and then product objectives, then product strategy, and at the very bottom, product plans and, sorry, product roadmap and product plans. Yeah. And then there was a line down the side that just said constraints. So essentially you start at the top.

[00:04:19] The business defines the context overall, and then every product supports that. So the vision of a product should support the vision of the company, right? You don't wanna say, Hey, we're a business intelligence company, and then you've got some gaming. Product on the side, right? So the product vision support the company vision, and then the objectives, strategy, roadmap, and plants all support that.

[00:04:42] And when you get to the bottom of the plans, like your plans are not just, Hey, what should we build? It's what did our roadmap direct us to do while that came from our strategy. So, and that came from objectives and that came from our vision. So there's this alignment. And the way that diagram came about was that in the work that I do, so when I work with software companies, People know all those terms, right?

[00:05:06] Everyone talks about vision and objectives and strategy and roadmaps and plans and, but people didn't have a clear picture of how they fit together properly. Mm-hmm. and how they could be used together to move forward together. So as an example, the most obvious one is the word roadmap, right? You ask people what the word roadmap is and you'll get very different answers.

[00:05:29] Oftentimes the roadmap is the plan. What are you building? Let's look at the. And so that's an obvious one, and you wanna separate roadmaps and plans, and we can get into that even strategy. Ask someone, what's the strategy or strategy is to be number one in the market. No, that's an objective, right? The strategy is how you could become number one in the market, and then so on.

[00:05:52] So all these things fit together. When people talk about business, they talk about business vision, objective strategy, et cetera. For some reason it seems clearer on the business side, but the analogs are there on the product side, and it makes sense to really think about them explicitly and then identify them and work through them.

[00:06:10] And so that's the origin of that. And really, when I've used it, maybe the same way you saw it, Adam, people go, Oh, okay. It makes sense. And just to be clear, like it's a f. In a framework, all frameworks are wrong, some are useful. It presents a certain point of view, right? And it's a point of view that I fight useful in the work that I do.

[00:06:33] I don't claim it's right for all situations, but it's a sense making tool and it does make sense for a lot of people. So that's the ultimate use of it. I like that you used the phrase sense making. Because I don't know how exactly it's defined, but sense making refers to a way to make sense of the world around us and how we act.

[00:06:57] So from this framework you put together in your mind, it's hierarchical. So like if you imagine the diagram, like at the top, there's a vision, and then the constraints flow downward. So you begin at the top and work your way down to the bottom. Correct? Yes. Ideal. Okay, so then ideally, right, you have a vision, You figure out, okay, what are our objectives?

[00:07:23] What's our strategy? How are we gonna do that? Okay. And then what do we need to do to actually implement the strategy? And then is it roadmap for how to do is at the bottom, or do I get to order roadmap? And then plans, plans. So can you talk a little bit more about the difference between roadmap and plan?

[00:07:41] So I'm coming at this from, let's put the engineer's shoes on here. I'm sitting in my sprint and or whatever it is I'm doing, and the PM says like, Here's the roadmap. And the roadmap is just like, I don't know, it could be anything. Who knows? It's just like the list of stuff that we're going to be doing.

[00:08:00] But yes, how am I supposed to make sense of. Okay, let me start with kind of a couple simple definitions and then I'll, like, can elaborate. Mm-hmm. . So when I say the word roadmap, a roadmap is a statement of priority and direction. So, So kind of like a vector. Kind of a vector. What's important and what's important to take you somewhere.

[00:08:21] Okay. Mm-hmm. . So a plan is a statement of commitment and delivery. And so you can see the difference between, just in those words. Mm-hmm. , and they're intentional. A plan, we are going to achieve something very specific and we've scoped it out, or we've done whatever homework we need to do and we're committing to something.

[00:08:41] Right? They'll, you can commit to whatever you want, but contrast that to the roadmap again. Priority and direction. So, hey, I wanna fly to San Francisco or fly to Hawaii to meet you, Anna. That's the objective, right? Right. And I wanna do it in the next three months and blah, blah, blah. That's sort of the priority of it.

[00:09:01] Mm-hmm. . But the actual plan is I'm gonna book a flight on Hawaiian Airlines on this date, and I'm gonna fly through San Francisco and I'm gonna stop and meet a friend. So like it's all the details that you've worked out. And so the idea is that the roadmap is really an articulation of strategy. And when we say roadmap, there's lots of different kinds of roadmaps, but when people generally say the word roadmap, they mean product roadmap.

[00:09:24] Mm-hmm. and a product roadmap is the product centric portion of your overall. Yeah. Your business strategy in this case, right? Your business strategy, Exactly right. Yeah. As an example, let's say you have a company and you have a strategy to expand internationally, and you say, Okay, you know what? Over the next couple of years, we're gonna expand into Latin America.

[00:09:49] So what does that mean? Well, we have to open an office there. We have to look for some resellers. We're gonna have to figure out how we're gonna support our customers there. There's gonna be some marketing, obviously it has to be done, et cetera, et cetera. And oh, by the way, we probably need to localize our product in multiple ways.

[00:10:06] One of which is language. So you've got this strategy to expand. You wanna grow. How are you gonna grow? Well, we're gonna expand it to Latin America. There's a whole bunch of things you're doing in your company. And in your product. And so that thing to localize your product, to support that expansion is strategic.

[00:10:25] It's important. You gotta do it. And so that's the strategic part that you put on your roadmap. Now we're not saying it has to be done by a certain date and exactly which languages and what border and all that. That'll come into play and we'll figure that out. Yeah. But we probably wanna say, look, if our goal is next year, We're gonna generate X amount of revenue.

[00:10:46] Our plan is to generate X amount of revenue, then we better get started on that localization soon, right? Yeah. So that's kind of this difference, is that the strategic stuff is part of your roadmap and then that feeds down into your plan. Cuz your plan is, hey, one of the things we ought to do is do this localization, but we got all these other commitments as well.

[00:11:06] Those are all in the plan, right? They're not on the roadmap cuz that's not the strategic. Right. So one of the reasons why I really like this hierarchical model is that it allows anybody who's engaging with these things, be it from product engineering, marketing, any place in the value stream to able to answer why at each level.

[00:11:30] Yes. About like the relevant thing, right? So I'm sure you've observed this in your own, in like in your own work, but you already mentioned the conflation of roadmap and plan and people, they see things and there's stuff that's just injected in here and nobody can even say why it's even being done in the first place.

[00:11:51] Right. And if you don't have, say, All these different areas, maybe like all teams are gonna have some concept of what's happening like in the next sprint or 30 days, 60 days, whatever. That's just a fact of life. But maybe what's not true is the stuff above that, like the business vision, the strategy. So like if you working with a team who's in this state, what advice can you give to that?

[00:12:18] So let's go back to this model, right? Vision, objective, strategy, roadmap, et cetera, right? You said it correctly. It's a why, and the why is really. A way to prioritize, right? It's telling you what's important. And so as you prioritize based on why you're keeping that connection across the level, so when you get down to the bottom, the why, you can cascade up and you go, Oh, because this thing in the roadmap.

[00:12:42] Because this thing as a strategy, because this thing is an objective. And so you can connect the dots, right? And that's, I think, really important because then you know you're going in the right direction, right? The work you're doing is important. If you're not having that connection, then you're doing prioritization some other way.

[00:12:59] Mm. So you have to ask yourself what's the why in our case? Cause there is a why someone's deciding is it cuz that's what sales said or the CEO said, or someone made the arbitrary decision that something's important. Or maybe there are some valid reasons, but they're not visible. So I think, I think understanding the why is really important.

[00:13:21] And then I. Really having a clear understanding of towards what end. So again, even if you don't have all that other stuff lined up, what overall objective are we trying to reach? Is it just delivery? In some cases that's all you have, but Right. Something else. Is there a revenue target? Is there business target?

[00:13:40] Is it tied to acquisition? Is it tied to something else? That should be clear. Most engineers I've worked with, they wanna understand the why cuz they wanna know that they're working on something. I. Right. Like I'm gonna spend my time and I want to know that this time is me spent in a way that's meaningful to the company.

[00:13:58] Right? And this is where I talk about engineering and product management. This is a big area where there's contention because the two have to work together, right? The product manages often the biggest source of input into an engineering group in terms of the work that they. And often the clarity of thinking isn't there for product management.

[00:14:21] I'll befriending. I've heard a lot of stories about not so great product managers and, and I've seen in my work some of the requirements and some of the documents that are shared and some of the comments of the documents and you know, it's like, yeah, I agree with engineer. Like this is really terrible.

[00:14:39] And the point is that you wanna get all that out of the way. So why are we doing this? Well, there's this higher reason, right? It's not my arbitrary decision as a product manager. Cause I talked to some big custom. So I think the advice came back to your question, Adam, is find out the why and then get some clarity on how that why helps the business and then work towards shifting to this structure where you can connect the dots easily.

[00:15:08] And I think that works for not just engineering, but that works for marketing, that works for sales, right? Everybody needs that alignment because whatever comes out of engineering and product has to be marketed and has to be sold. And they need to know, yeah, why did we build it? So while you were talking, you mentioned that.

[00:15:27] In some cases we have lacking in product management. The answer to some of those why questions is not always there, and that's definitely been my experience in some cases, definitely not all, but there's cases where there's a gap, and I think we could recognize that. But the question is, where is that gap?

[00:15:45] And based off of this hierarchy of vision, strategy, roadmap, and plan, Inputs, like what sources of information do we need to be forming those things or like making good decisions at each level so that we can do better in product management. So I don't think there's a single place where there's a gap, right?

[00:16:08] It's really situational. Mm-hmm. , I think it could be, and I'll see it from the product management side, but it could be. A gap in skills and knowledge from a product manager. So they're not understanding either what they have to do or how they have to work. It could be a gap in the ability to communicate.

[00:16:27] I've seen people who, yeah, they can define things, they can do the research, et cetera, but there's some, just their ability to really communicate and get the message across. The engineering isn't there. Maybe there's a technical expectation from engineering that isn't met by the product manager. There could be trust issue.

[00:16:45] If you ever go into a company where there have been some of these issues between product management and engineering, let's say, and the previous product manager left and you're there, but you're there in the shadow of the previous product manager, and so they're gonna look at you as like, Well, here's another person we have to deal with, as opposed to getting a fresh start.

[00:17:07] So it really depends. I think sometimes it's organizational as well. I will work in. Companies where the engineering teams were not only very technical and very technically adept, but very technically minded. Mm-hmm. , but also they had a lot of influence in the company. Right. And so I remember one company and I overlapped, was the outgoing product manager and he gave me the briefing about how to work with certain engineering leaders and he said, look, and I'm paraphrasing cuz this was a long time ago, but it was something.

[00:17:43] He does not want a product manager telling him what he should build and what do you do? At that point? You have to work with a person and so it varies. What I've seen though, on the flip side is that I think most engineering teams want a credible partner in product management, and I think this is where, quite honestly, I don't think engineers wanna be hard asses and.

[00:18:08] Tell product managers go away. We know what's fascinating. Most of 'em are mature enough to understand that yeah, there's a value that product management brings and we want to benefit from that. But there's an expectation of knowledge, insight, depth of analysis, and those types of things. So you have to figure out how to find that match and understand what's required and build up trust.

[00:18:31] And I think the. Is the key factor. And once you can do that and you're speaking the same language and working in the same way, there's a lot of freedom you can have. And I just think back to my own experiences in a couple of companies. There's a bit of a honeymoon period in the beginning. Okay, you're getting up to speed, we'll give you slack, but a month or two in, it's like, Dude, what are you doing?

[00:18:52] Do your job. And it's a hard job, right? Product management is a hard job. Engineers are tough customers. And I'll say this, I think the onus is more on the product managers to understand how to do that work. Yes, there has to be some slack engineering, but I'm working with an engineering as a product manager.

[00:19:09] I'm working with marketing, I'm working with sales, I'm working with support. I'm working cross-functionally. Mm-hmm. . So I can't expect every group to bend towards me. Right. That's unreasonable. Right. So I bend towards them. And so that's what I mean by saying that. I'm not saying that engineering gets special treatment, it's just.

[00:19:28] I need to work the way that works well with them, but also I can work marketing, et cetera. And that's tough for a number of reasons. And I think a lot of product managers who are new and who don't understand that and who don't maybe understand the culture of engineering or can speak as fluent in the technology struggle, and it's a hard problem to solve.

[00:19:48] So I think the flip side of that though, The product manager shouldn't be left alone in that. I think that the product of leadership, so their manager or the head of whoever, yeah, needs to be able to find a culture and needs to be able to support the product managers in the work that they do. And I think quite honestly, that's often lacking in many companies for various reasons.

[00:20:08] You're saying the support. From just say generally speaking, product leadership, as vaguely as we could define it, right? Yes. I think support in general, cuz most product managers, even if you have a product manage organization, most product managers are individual, contributes working with other groups.

[00:20:28] It's not, there's a little. Product management team that works with other groups, right? It's three product managers on three different products working with other groups, right? Yeah. So I think that's part of the challenge. And then the other one is, yes, absolutely from the top down, right? That I think there's a real dearth of strong product leadership in many companies.

[00:20:49] I've seen it in some extreme cases. It sort of makes no sense in some places, but it's also tied to a misunderstanding what product management is. So as an example, would you ever hire a sales VP who had never been a salesperson and never done sales? You might, but you probably regret it really quickly.

[00:21:09] And the same with marketing, and the same with engineering. And yet I've seen many cases where there's a head of product or a VP of product who has never done product before. And yet is supposed to support these people who are doing a tough job, and they think that it's possible for some people to learn how to be that leader and to give the right support.

[00:21:32] But just like every other function, right, there's skills and knowledge and patterns. You need to be able to recognize those and support those and help people. And if you don't hem the background, then how are you gonna help them, right? Like if someone's struggling with discovery work and you never formally, what are you gonna do to help them?

[00:21:57] And again, I don't wanna disparage anyone cuz I've seen people succeed, but I think it's a really tough place to be as a leader. Managing people whose job you've never done and don't understand at a details. Yeah, so I got one more question on the product side before we change gears a little bit. Talk about the collaboration side.

[00:22:18] So site, let's say that I'm a product manager. I'm listening to this and I'm thinking, Okay, I'm really digging what these people are talking about. I get this hierarchy, business vision, strategy, roadmap plan, and I'm sitting here, I'm the PM on a team and I'm trying to put a plan or roadmap together, but those higher level things are not clear to.

[00:22:41] What should I do in this scenario?

[00:22:46] get clarity. Yeah, so work your way up. Like you can function without a clear vision, like a clearly defined vision. Like you kind of know where your product, let's say you have an existing product, you kind of know what your product does and where it's headed and the kinds of things you need to do. And what you wanna do is say, okay, and again, we're talking strictly from the engineering, product management relationship side, right?

[00:23:10] We're not talking. More cross-functional work. Mm-hmm. . So if it's a question of what should I build or what should I research and work with engineering to build, work your way up. Say, Okay, like we talked earlier about objectives, so what are the objectives? Right? What are we trying to achieve? At least have that as some defined direction you could head.

[00:23:31] But then even if it's not clear, like even if it's just a revenue target, well your product has to make 10 million. Mm-hmm. , well, we only million last year. What, what are, what are you gonna do? But get some clarity on that. But then break that out and say, Okay, what are the ways we can do that? And you're not gonna do it all by building stuff.

[00:23:51] Like you just can't build your way to growth. It's not like, Hey, we added 87 features, We're gonna grow by 62%. It doesn't work. So you have to have that conversation with your managers and say, Okay, what is really the goal that we can actually. And then let's talk about the how and some of the how will definitely be product, but some of the how will be sales and marketing and licensing and pricing and a lot of things that have nothing to do with working with engineering per se.

[00:24:22] Yeah. But that, Well, discussion has to be, It has to be had, right? Because otherwise you're just in that feature factory of building stuff and delivering it. Someone else takes care of it afterwards, which I think it's for a lot of people, it's the reality of their job, but also it's not an inspiring world to be in because you're just so disconnected from success.

[00:24:45] Right. And someone asked me once, they said, What's the goal of product management? Hmm. How do you measure product management? And it's a tough question if you really wanted to get super analytic about it. The way I look at it is like product management is about driving product success and success is defined by whatever success metrics are important to your company.

[00:25:05] And it could be growths, it could be customer acquisition, it could be revenue, profit, retention, whatever. Like it totally depends on the product and the market, the maturity. But you wanna have some sense of that. And once you. That what's success? What are objectives? What's the how? Then you can frame some of the other discussions and it doesn't have be a big formal process, but it should be some clear discussions with your managers.

[00:25:33] Because if everything is just coming top down, a, here's your next task, here's your next task, here's your next task, great. But you're not, I mean, I'll say this and I don't want to, to spread your, but you're not a product manager. You're a delivery. Again, that's the reality of John. There's many people who have a title of product manager who work that way, but product management is about driving success and you're not driving success unless success is successful delivery.

[00:25:58] Hmm. So there's two things you said that I think are good segues into. The next thing I wanted to talk to you about, the first one was putting the how before the what? Like we're just gonna do this, but for what purpose? Unknown. Right? And then the other one is the difference between being a product manager and a delivery manager.

[00:26:18] I see those two things as being related in some way. So the first one is the difference between being a product manager and being a delivery manager in the delivery manager case you're working. At the plan level, you have constraints and you're saying, this person is tasked with making sure X, Y, and Z happens by a certain time and delivers A, B, and C.

[00:26:41] Right? There's not that much to. Discover in this case, right? You're just in a sense making thing. Here's something that is a more, say, controlled or known environment. Go off and do it right, Versus a product manager may be operating at the level of the roadmap or the strategy is thinking. Okay. What do I need to do?

[00:27:03] What questions do I need to answer to get to the how I'm going to do this? Then how does that filter down into the roadmap, into the plan? Right? Yeah, and this sort of comes back to the mental model of say, engineering, right? Like on the podcast, like in the Flow Collective, we talk a lot about. The nature of like the work that we do, knowledge of work, a lot of, there's a lot of uncertainty that we optimize for learning.

[00:27:27] We try to break down problems. We admit that we don't know and we take like a discovery mindset. We work in small batches, we work iteratively quickly, and we try to like incrementally build larger things based off of. An increasingly confirmed body of knowledge. Like we sort of confirmed through experiments, we can do all kinds of things to confirm our understanding of the reality.

[00:27:51] Like it's a sense making thing. Do you feel the same way kind of about product managers? Yeah, in general. In general. So, and you say a couple things, so Absolutely. I think in general, product management is about making bets. Mm. And some of 'em are small and some of 'em are big. But you're making a series of, let's call 'em smart.

[00:28:11] I'm saying that because there was a tweet today by someone I know who talked about marketing as being a discipline of making smart beds, and I thought, Yeah, that's absolutely true. And then I said, Wow, that's actually how I think about product as well. Because you're doing things then there's uncertainty, right?

[00:28:28] Nothing's certain in terms of what will be successful. You have data, hopefully evidence to support your decision. But ultimately it's a bet. And some of them are small and some of them are big, but they're all bets and you afford and, and hopefully you're making, you know, winning bets more than you're making losing bets.

[00:28:46] So I think that model makes sense. The other thing though, about product Manion, and here's another quote, which is that, and I believe my friend Steve Johnson, who's also brought up convention consultant said this, but I've used it many times and I've been trying to find out where I heard it, and I think he's already said it, but it's said, sales here responsible for this year's revenue.

[00:29:05] Product management is responsible for next year's revenue. Mm. And I like that quote because it just frames the way you have to think, Right? Which is that you're really thinking about the future, right? There's little that you can do now today to impact the revenue. Like your product is your product sales and selling it, marketing's marketing it, and you're saying, How do we get to that next big thing or that next milestone we need from a product perspective.

[00:29:33] And so that next year our revenue, which is hopefully significantly more than this year, can be attained. And so that's, I think a difference in the sense that it's hard to work in small batches way in the future. Right. If that makes sense. Like I'm doing little things now, but Right. I have to think. And so it's a bit of a dichotomy, but I think it's part of the challenge that that things we're doing today, we will know if we made the right bet at some point in the future, and often it is next year.

[00:30:05] Yeah, I think that's where sort of the tension is between, Yeah, we have say a larger long term vision and this could. At an unknown indefinite point in the future, right? Versus there's the day and the week and what are we doing to either continuously move and the challenge is like, yeah, I have this vision, but how are you gonna get there?

[00:30:25] How can you break that down? How can you actually make consistent progress towards this thing? To where like, Yeah, we wanna make a big bet. But it's not gonna happen overnight. Right? What really boggles my mind is like Apple, they made their new cpu, Apple silicon changed their architecture, like a total unfathomable amount of stuff to consider in building this thing, right?

[00:30:50] Yeah. Who knows how long those timelines work. They did it and Wow. But like what can we learn from that And like how can we think? But I get distracted a little bit, but the next area I wanna talk to you about is more like on the collaboration between engineering and product, right? Sure. And one of the questions I asked earlier is, What information do we need at the different levels in this model to collaborate effectively?

[00:31:15] So I've definitely experienced this and I'm sure you have product and you have these people are trying to decide what they're gonna do, and engineers are talking about things like, Okay, we have technical debt and this and that, and we have these things that we want to make. How can the combination of product and engineer.

[00:31:32] Make sense of these things so that with engineers, you know, maybe it's an implicit why we should do these sort of things, and we just say we're gonna do this or whatever. And the same thing on their product side where maybe engineering, they just receive a ticket or something and says, Okay, do X, Y, and Z.

[00:31:49] Yeah. But the why is unclear. How can we make sense of all these different things that we're all trying to factor into our decision making? Oh yeah, that's a hard one because I don't think there's an easy way to describe that because it's a moving target and mm-hmm. , everybody has a different perspective on it.

[00:32:12] So here's how I look at it, right? A lot of the work of product management is not about the technical stuff, right? It's actually about creating common context and alignment of direction with different groups, right? So cross-functional. Management. Engineering is the one that gets most of the attention, but helping sales and keeping them at bay, so to speak, right?

[00:32:39] Making sure that marketing understands what's being done and is leveraging the work that product and engineering are doing to maximum benefit, right? Helping other groups who are onboarding customers or supporting customers and keeping them aligned. This is something that a lot of product managers actually don't have the opportunity to do in some cases or don't understand that they need to do.

[00:33:03] Right. Which is that when I said product success earlier, mm-hmm. product success is not about just the product, so to speak, right? It's what is done with the product and by who in when and in what ways, et cetera. And you can play like the telephone game and have handoffs across teams, but you know the end result that always leads.

[00:33:26] And so even though product management is thinking about the future, and like I said, next year's revenue or whatever, when you think about the company and you think about the company as a system, product management is the earliest thinking group in terms of things that should be done. You're working on the least tangible part of it.

[00:33:46] Marketing markets a real product. Sales sells a real product. Support supports a real product, right? Product management thinks. What is that real product that these other groups will work in? And so there's a lot of thought that needs to happen and a lot of information. And I think that the first consumer of that work is engineering.

[00:34:05] And so the thing that you wanna do is when you get back to your question about all these things, sense making is have a really great collaborative common context, communicative relationship with engineering. I would say this, I've had, maybe I was. But I've had great experiences with engineering teams, with one exception.

[00:34:26] Mm-hmm. . But my first job as a product manager, my first. Wonderful deaf managers that I worked with, and we just, I'm still friends with them today, like 20 odd years later. Wow. Seriously. So met them in the late nineties and they still, you know, on LinkedIn we'll ping each other and pandemics aside, we'll meet for lunch once in a while kind of thing.

[00:34:46] But those relationships need to be built and they need to happen, and then you need to bring people along together. Right. The days of handoffs, product manager went and did the, the requirements gathering and then handed off whatever, 80 bazillion juror stories or whatever. It was in a long gone. So you wanna build that common knowledge together.

[00:35:04] You wanna understand each other's world and you wanna move forward together. A lot of times there's scrum teams and you've got product owners, and then you also have product managers and maybe the product owners in engineering, but the product managers in product management or whatever, some other org.

[00:35:20] And they might have different goals and they're measured by different metrics and things, but you need to figure out how they can work together and be collaborative, like truly collabo. I used to phrase aligned goals. Mm-hmm. that we want them to have piece aligned goals and then saying the discovery work, they work together and the planning work, they work together, the road mapping, there's some collaboration, et cetera.

[00:35:42] And once you get into that set of relationships, all those questions you had start becoming easier to answer, right? Because we're working towards the same goals. You're working with cognitive context, you're sharing knowledge back and forth. And again, I don't know if I was fortunate. I have those kind of relationships in a lot of companies, and so I've seen some of the not so good side, but maybe I've been, That's been a minor part of my career.

[00:36:11] Hmm. Wow. Lucky for you. It's like one of the things that. No, it's not sarcastic, but if you work in the industry long enough, you'll work on a wide enough variety of teams. You'll find that some teams are clearly better at other things and work better in different ways. And yeah, it is. A lucky experience that people just get to have one of those in their career.

[00:36:36] Right? Maybe that doesn't necessarily hit like all of the different areas of like this collaboration, but to have, Wow. Say you meet one team who say is just like really good at testing and like really cares about quality and knows like it's just on it, right? You have another team who is like just bang on user research, knows what to.

[00:36:56] And just to get some signal of say what good looks like, because sure, we can read about it, we can talk about it and all this, but until you're actually there in the team working in such a way where you're like, Wow, this is what these people were talking about. This is what I was missing. But you know what?

[00:37:14] I'll say this. You used the phrase, what good looks like. You have to make good, you have to create good in your environment. Right? And it's not always possible. There's some toxic cultures. I've seen them where there's politics and powerplay and agendas and lack of skills and, and it's just not gonna get fixed.

[00:37:36] Right. And. The org is being held together by a few heroes who are right just making stuff happen. And one of those heroes leaves and something breaks. And so I think in most cases, and I try and get people to benefit doubt, right? People wanna do good, they want to do good, they want to work in a good environment.

[00:37:54] So by thing about you have to create good or you have to make it happen is figure it out. Figure out the right way to work with the people that you're working with and hopefully, Reciprocate and say, Okay, yeah, how can we work together and be good? But one of the challenges is that there are a lot of product managers and I, I'll be critical about product management.

[00:38:16] There's a lot of product managers who are put into situations. That they're not ready for. And again, going back to that issue of support without the support, and they're fake until you make it. Like they're, they're not making it . They're, there's a lot of fake and they're not a lot of Macon. Yeah. And that lasts a long time.

[00:38:34] Even if they leave that toxicity or whatever that happened. So, But I look back, I mean, there's one company where we had two products and two major product teams, and one team was awesome. Everything about them. They were such a pleasure to work with in terms of communication and the quality of the code they wrote and how the product performed.

[00:38:54] And their team, really great guys, really great people, but the quality of their code was terrible. The product was buggy stuff wasn't really designed well and it was weird cuz it's not a huge company. And we spent a lot of time just working with them really closely to figure out. We did a bug fix only beta for five months.

[00:39:20] Wow. Five months. Yeah. People would die to hear that if they could know they could actually just fix bugs for five, five months places I worked. But think about how bad the situation was that Oh yeah, that's what happy done, but we have to manage sales, right? Like we meaning product, new engine. And I went to sales and I said, Look, we're not delivering anything new for at least half a.

[00:39:44] Because we need to fix bucks and here's what we can do to help you, et cetera. And we went to marketing and we, you know, so as a product manager, I took that off and the team got the time to fix all those problems. And yeah, we came out of it better, et cetera. But those are kind of things like, how do you make good?

[00:40:03] Well, you do what it takes. And some product managers aren't ready for that. Some product managers don't know how to do that, Some cultures wouldn't allow, that's not ready for it. There's a difference between like individual aims and systemic constraints. Yes, Yes. So you we're talking about bugs. How much do you think that product really needs to know or understand about engineering?

[00:40:30] So on a systems level, , the interface has to be clear. If I say, you know, you're tightly couple or loosely coupled with them, what's the interface with them? I think those are things just at that. Obviously we're not systems, so we're human beings and, and we're nots, et cetera. So yeah, you wanna understand them.

[00:40:51] You wanna know a bit about their world. I'm old enough to remember when nightly builds were a thing, right? And like you'd come in the next morning and the build was broken for some reason, right? And then, But I never built anything. I've written coat 25 years ago and that was the last time I ever wrote coat.

[00:41:09] But you wanna understand their world, you wanna understand their challenges, you wanna accommodate them as needed. You know, think just the story I told right about the bug fix thing, right? Like we sat down and had that talk. What the hell is going with this product? Cuz like support is just getting bug after bug issue after issue.

[00:41:26] Come in and we've got unsatisfied customers. Okay, fine. Like we're not blaming anyone, but how can we fix this? Right? What's the path forward? And when they told us we need three or four months, well, at the first point you're like, And then it turns into five months. But you know what? Like three to four turns into five, fine.

[00:41:43] You know? Yeah. It turned into 12. Different story, different story. But I think you need to understand that world need people speak the same language and you also need to be able to say, Hey, I don't understand what you're saying, , but you have to be able to do it and be frank about it, and then hear them and then understand, Right.

[00:41:59] So I think just getting that common language, understanding the dynamics, understanding the challenge they face, and then sharing that back. I think a lot of engineer. Don't understand all the bullshit, quite honestly, that product managers deal with. Mm. I did bring the dev manager over to sales to tell the sales group, Hey, nothing for four or five months.

[00:42:20] Right, Right. Like, I went up and did that cuz that was the thing I had to do. And so you wanna just have that kind of relationship and understand each other and, and again, you know, it's aligned. Objectives. We're working towards the same goals. Let's forget how we can work together. So it's hard to say. I mean, I come from a technical background, so I understand software, I understand software architecture and things like that.

[00:42:43] So I didn't have to struggle to understand the world of software developers. But I think some product manager who come from other disciplines and don't have that background and work in technical environments, right? Mm. They can struggle. Now you don't have to understand. How to write code unless you're the product manager for an API product or something.

[00:43:05] Yeah, you're a prime manager for a coding product. Exactly, exactly. Yeah. But if you're a product manager for Salesforce application, that front end and it's has nothing to do with the backend force.com. You don't need to understand that. But you do have to speak the language and or you have to have this support structure that can help you there.

[00:43:24] Right. So as an example, in one company I worked, we had product manager, which is what my role was. Roughly speaking, and we had technical product managers and the technical product managers were much more closely tied to engineering. And it was a server virtualization product, so it was a very technical product.

[00:43:43] And then we just worked together and if I needed some of the technology translated, the technical product manager could do it, right? I know what a device driver is, but don't tell me. I need to understand the details of device drivers. Yeah. Okay. So, so let's say that you come into, you know, you're a consultant, so you work with a variety of companies, you see a variety of teams.

[00:44:03] Let's say that you are, you come to a client and you see, you know, you got a product team, you got the PMs mixed team, you got, you know, engineering. What are you looking at to sort of gauge the health of the collaboration between product and engineering? That's a great question. That's a really good question.

[00:44:22] I listen a lot. What I'll do is I'll come in and I'll do a bunch of interviews and I'll have one on ones people and I'll talk to them about their process and so on. But I listen for certain words and. I don't think it's a conscious thing. Like I don't have a list of 12 keywords to listen for. Mm-hmm. . But you hear it when you hear words like them and they, and we do this, and you pick up the language or tell me about how you did this, and then they'll talk about it.

[00:44:51] But there's a lot of vagueness about the collaboration that should be going on and on on both sides. Right. So engineering and product manage. So those are the kinds of things that give me insight. I mean, I do it in a formal way. I have a formal process that I follow, so I, I don't just do it in a very subjective way, but at a high level, those are the kind of signals I hear.

[00:45:14] I'll tell you another one that is just kind of a bit of red flag is when I talk to engineering and then I hear a lot of, We're agile. We're agile. Like people point out that they're agile, and on one hand I'm just like, Why? Even, Why do you feel you have to tell me? My corollary, or whatever you wanna call it.

[00:45:31] My, my theory is that your agility is inversely proportional to the number of times you say you're agile, , so you know your actual level. So the more you say you're agile, the less likely you're probably agile. It's like Thailand and Game of Thrones. Taiwan Ry has this quote, it says, The king does not need to say he is the king.

[00:45:51] Everyone knows it, right? . Exactly. Yes, exactly. Yeah. So you can hear it very quickly. Like you talk to people who should probably be collaborating with each other and you get complete different stories about the world they live in, right? Yeah. And you just go, Well, really your counter card doesn't see the world in that way.

[00:46:15] The other thing, when you look at objectives, what's success mean to you? And again, people who should be collaborating have very different definitions of success. Yeah. So I'll just say this, and I don't want to sound kind of aloof or anything, but it comes across very quickly, right? Mm-hmm. , there's problems.

[00:46:32] I don't know what those problems are. I can dig deeper and get to them, but you hear them very. Okay. Yeah. So in an increasingly strong trigger for me is people who make assertions about the world, but with no information to back it up, right? Yeah. Like, Oh, we're gonna do this feature and it's going to generate like X amount of revenue, or this number of signups, or whatever it is.

[00:46:57] And then you'll ask a question like, how, And they're like, Well, it just. Yeah. Yeah. I don't, I'm skeptical of that. Sure. There's an idea here. Yes. But like by what method? How, what information do you have to actually confirm these hypothe? Yeah, it's like on both ends of the collaboration between engineering and product, both ends can be overly assertive about what they will do without sufficient understanding of why they should do it, how they will check their progress, et cetera, et cetera.

[00:47:30] Right. And yeah. When both ends make the assertions, like without the real understanding, that's where both. Can really get out of whack and lead to that negative like spiraling of the lack of trust, right? Where. Engineering only sees products who want to do features or whatever it is. And then engineering is like, they never give us time for the technical debt or the bug fixes or whatever.

[00:47:54] And then it's like they and them and Exactly. You already see exactly where the whole thing is going. Yeah. Just from this framing of the collaboration, right? Absolutely. Absolutely. And the other one and I've seen is just the spread of titles in the org. Like I remember going to one company, And they had product managers and project managers.

[00:48:17] And delivery managers and Scrum masters. And it was just like, I think I, in a group of about 20 something people that I interviewed, there were a dozen different titles and I was just trying to like, how did this happen? And it happened because they evolved over time and they had an old model and then they moved to a new model.

[00:48:37] But you can't just get rid of the old people so they can repurpose them, but they still had their old title, et cetera. So you see that and you can tell like, okay, they're trying. It's not like they're not trying, but they're struggling to find an optimized way of working. And so you see a lot of legacy type of practices.

[00:48:58] And then sort of knew like, Oh, we were this. Then we went for Agile training, and then we implemented Strub, and then we went for some other kind of training, and then we did this. And you can see the history of all the training that they did. Yeah. Yeah. All the roles are carried forward. Yeah. Okay. I got one last question for you before we wrap up here.

[00:49:19] And it relates to like the tools of the different domains, right? Engineers by design need to. Analytical, right? Like we strive as much as possible to be empirical, think scientifically, use facts, data analysis to drive decisions, right? And I think there's maybe a hope from engineers that you'd see the same sort of values reflected in product managers, Not delivery managers, but product managers who need to try to like make sense of the world.

[00:49:51] Yeah. Inside engineering we have our tools for empiricism. You know, we have production operations, we have SLOs. We use metrics like to really understand what's happening, like what are the tools of empiricism in the domain of product management. Excel, , I'm kidding. Um, so I think the tools have evolved a lot over the last decade.

[00:50:16] When I started, it was Excel, but that was a long, long time. But now, just as a example, there's a lot of product analytics tools, right? So companies like Pendo and Amplitude and Mixed Panel and so on, right? That primarily for SaaS companies, that they can give you really good detailed information about user behavior inside of your application, right?

[00:50:37] And that's a huge step up from just web analytics or whatever was there before, because they're. Focused on product use scenarios, not just web pages and things like that. So that's one of them. And I think those products have really changed how a lot of product managers think about their job because now they do have real user data.

[00:51:01] Now that's after you release your product, right? That's when you built something and it's actually being used, and I think, which is great, it's. Something you need, but there's the other side, which is before you build your product. Mm-hmm. And I think there, it's still working. So the discovery work that's done right, how do you go out and do good research and then produce really great evidence and insights that can drive decisions and good decisions to then build things?

[00:51:31] I think that's still murky because the nature of that worked is not a. It's qualitative in a lot of sense. So there are tools, right, that help in qualitative analysis and they help you structure your thinking and share and collaborate. I think those are things that that help, but I don't think that tools solve the problem.

[00:51:54] I think the problem is really the discipline. That, not just product managers, but I think product organizations and companies need to have to say, we are gonna make evidence based decisions on what we will build, Right? So if we go back to the beginning of our objectives, strategy, roadmap, plans at every level.

[00:52:15] Even at vision, quite honestly, at every level, what is the evidence? Like, Hey, we have this vision. Okay, what's the evidence for that vision that this is the kind of idealized future you wanna have? What market trends and what other things are feeding into that right? Objectives? What is that? Where did that come from?

[00:52:32] Is it just some random number or is it, there's a clear growth path that we have. So this idea of evidence and rigor in how. Present and think about that. Evidence I think is really important and I think it's still lacking in a lot of places, but I think it's maturing. It's really weird for me, I'll say personally because my very first product management job, so it was 1997.

[00:52:55] Mm-hmm. , I took my company and I didn't know it cuz it was the first product management job I had. But boy, that company was well. Ah. And on one hand I learned a lot at that company because we have data. We had downloads of evals, and we had data about what country and where and when, and what they did and what source came in and all that.

[00:53:19] And we could do all that. And then it spoiled me because, you know, I never had that again for about 10. But those are the kinds of things you really wanna get people thinking about, Like, how can I really be rigorous at every step of the way and really make evidence-based decisions? It's not necessarily just database decisions, but evidence-based decisions because evidence is broader and evidence can come from different forms.

[00:53:44] So I think that's a discipline that product managers need to bring to the table and companies can support them. And there is some tool link, right? Like historical analysis of sales data and funnel data and things like that. I think product manager should be looking at that because it can give them insights into what's happening, who's doing what, et cetera.

[00:54:03] But yeah, think about it that every step away and then challenge yourself to really step up. Don't just go. We're not a data centric, wherever centric company, you say, Hey, how can we become one of those companies and what can I do to impact that change? What a great way to bring it back to the original entry, appoint in the conversation.

[00:54:23] And it reminds me of a, one of my favorite quotes actually from ding, which is short, but information is not knowledge. Yes. And we have access to so much information, and what I'm hearing from you is, A product manager or somebody who wants to figure out how to really move the business forward, can make senses information to create knowledge and use that information, Find evidence, format, and a knowledge.

[00:54:49] Build a vision, create a strategy, create a roadmap, and execute it via a plan. Yeah. If I can just finish our one thing, There's this whole debate, and you can find it about our product managers, the CEO of a product, and yes, no, whatever, right? And what I say. Even if you're not CEO of the product and like 99% of product managers are not CEO of the product, that doesn't stop you from thinking like a CEO and apply that and think about it.

[00:55:15] If I was ceo, what would I do? Yeah. Well say thank you so much for coming on the show. It's been a pleasure to talk to you. Is there something you'd like to leave the listeners with before we conclude the episode or like them to go somewhere or anything? Yeah, so people can find me on LinkedIn, I think is probably the best place.

[00:55:35] I tend to post regularly, and I'm pretty focused on product related issues. We can put my LinkedIn link, I guess, in the notes. Mm-hmm. and otherwise on Twitter, I'm Site W Conn, although my Twitter content tends to be more political than product related, so you might be disappointed if you're looking for product related tweet.

[00:55:56] So don't you have an archive of blog posts going by way over a decade? Something like that. You have a lot of writing on this stuff. Yeah. Okay, So thanks. Remind me. So I have a lot of blog posts on media. Mm-hmm. , That's where I publish most of my new work. And then I have an old blog, which it's on product management.org, but I'm not actively updating it.

[00:56:19] And every once in a while I'll, something will happen and I'll go, Oh yeah, I wrote about. 12 years ago, we'll bring that forward and surprise. It's still relevant too. Nothing's changed in 10 years. Is it still the same problem? It's the different manifestation. Oh, you know, I think we're just in a weird loop of living the same world over again, but just.

[00:56:37] We advanced our calendar, but everything else stays the same. Awesome. Okay, well thank you so much for sight. Thanks Adam. You've just completed another episode of Small Batches. Find links to connect with SAE and i@smallbatches.fm slash 79. Also consider applying for the Flow Collective. We have a Slack group and hold weekly lean coffee discussions on all things flow, lean and more.

[00:57:02] There's a link at small batches FM slash 79. Just tell 'em small. You sent you. Anyway, I hope to have you back again in two weeks for the next regular episode. Until then, happy shipping.