Improve your Product Management with Ellen Gottesdiener
Episode 38
How do we improve in the area of product management? In this episode of Programming Leadership, Marcus and his guest Ellen Gottesdiener, President of EBG Consulting, discuss ways companies can better oversee the development and lifecycle of a product in its entirety. Marcus and Ellen also discuss her Agile Product Planning method, best practices in the area of product management, and effective decision making methods with product management within your organization.
Show Notes
- A working definition of product management (1:15)
- The product lifecycle (1:45)
- Answering the question, “What’s my product?” (8:30)
- “Outside-in” thinking over “inside-out” (11:30)
- Ways to address product production backlogs (15:33)
- Managing the work vs. the product (19:19)
- Engaging a product engineering team (21:58)
- The role of story in product development (28:35)
- Product development without a structured value system (33:47)
- The decision making process in product development (40:49)
Links
Transcript
Announcer: Welcome to the Programming Leadership podcast where we help great coders become skilled leaders and build happy, high-performing software teams.
Marcus: All right. Welcome to Programming Leadership. I’m Marcus, and I am so happy to have my friend and guest, Ellen Gottesdiener, here with me today. Ellen, thank you for being on the show.
Ellen G.: It’s a pleasure, Marcus. Thank you.
Marcus: Ellen, I love watching your work from afar and yet, we haven’t met in real life yet. I’m excited because I believe that’s going to happen, but what I am excited about is the idea that you’re putting forth in the area of product management, and I get a lot of questions on how do we do product management better, how do we do it and golly, can you imagine, how do we do it Agile where we don’t have to plan everything up front? As we were talking about just before I hit record, I have a feeling that you have a perspective on that. So, before we go there, do you have a working definition of product management that you like?
Ellen G.: That’s a good question. I think I would say… My working definition is going to come from my brain right now. I think it’s the art and science, the discipline of overseeing a healthy product throughout its entire lifecycle.
Marcus: Lots in there. So, we’ve got a little art and a little science and the idea of healthy products. Obviously, we could contrast that, and through the whole lifecycle. It’s not just about more and more features?
Ellen G.: No, no. Not about the feature factory. Absolutely not. So, the classic product lifecycle, which comes from Kotler and Keller years ago in a marketing book, is a curve that starts where the product is introduced, introduction. Then growth. This is your growth stage. Then it’s a maturity, and then decline. So, that’s the classic curve of a product. Now, every curve will look slightly different, but in the introduction, this is where you could say that the space of Lean startup is where you’re trying to figure out whether this is really the product that you want to build. There is a market for the product. You’re making investments. You’re not really making money yet in the product. Then as you move into growth, the growth phases where you’re really trying to get your product market fit, and you’re going to start to get revenues at that point, and when you’re in maturity, this is a product that’s in maturity. The product management goal is to make that product stay in that phase as long as possible because that’s where you’re getting most profitability with the product. But by that time, you’ve got competitors, and you have pressures to do things like feature creeping because of parity pushes from the marketplace.
Ellen G.: So, you have to watch out that you’re going to have a bulky product that’s got more features and complexity than you really want. That’s where you’re looking at innovations and technologies and trends and so forth to keep that product healthy and alive and then eventually, a smart PM, product manager, will recognize when there’s no more market for the product. Maybe your competitors have taken over, and it’s not healthy anymore, and it’s time to retire that product. So, a product has a long lifecycle, and like a project which comes and goes, a product sticks around. PMs, product managers, depending on the product and the phase of the product’s lifecycle are going to behave differently and focus on and make different investment choices and collaborate with engineering and the organization slightly differently based on the stage that the lifecycle is in.
Marcus: I’ve got this little graph I’ve drawn based on what you said, and it looks like a bell curve, right?
Ellen G.: Yes. Mm-hmm (affirmative).
Marcus: We’ve got some stuff at the beginning, some stuff in the middle, and then a tailing end. I like what you say. A couple things come to mind. It seems like in that beginning, we’re all about getting up the curve as fast as we can. So, there’s a lot of probably executive pressure to get to market, get there faster, get more features. It’s about whatever it takes to get more adoption and usage, and I have this impression, like we want to get up as fast as we can like an airplane shooting or a rocket shooting up as fast as we can. Is that true?
Ellen G.: That almost sounds more like the growth phase because-
Marcus: The growth phase, okay.
Ellen G.: … in growth phase, you move into growth when you know you have a viable product where you know there are customers for that product, and you’re losing money because you’re investing in the product. You probably have a very small team and a few customers. Maybe you certainly don’t have very many customers, and you’re doing what Eric Ries talked about in terms of pivoting, persevere, pivoting. So, you’re doing a lot of discovery, a lot of experimentation. The product’s usually not going to be scaled from a technology platform point of view. These are very early days, and depending on what you read, 90 or more percent of products fail. They don’t really get out of that phase-
Marcus: Holy cow.
Ellen G.: … from a startup point of view. Yeah, it’s within numbers range, but roughly 90. It could be 80 or plus 90 depending on studies, but different research studies that I’ve seen with that number. Maybe the number isn’t as realistic because a lot of products just died, and they didn’t want to report it. I don’t know, but it’s hard to bring a product to market. It really is hard, and it takes a lot of persistence. Obviously, it takes revenue. Yeah, so, what you were describing sounds like we’re out of that phase and now, we’re really trying to hone in and get that product market fit. A good product with a good-paying marketplace that fits some niche that will be sustainable.
Marcus: Then the next phase you described as one where we are profitable and we’re maintaining. We’re staying. Maybe our investment goes down, or we’re reaping the benefits of a lot of past investment. We’ve got a market. We’ve got a good adoption. Sure, we have some churn, but we also have new people coming on. So, we are sustaining, and you mentioned that one of the goals of product managers in that phase is to stay there as long as possible.
Ellen G.: Yeah, right, right, because that’s because the delta between your investment and your profitability is going to be higher than the delta between your revenue and what you had to put in to build the product, and support and maintain the product is going to be the greatest. So, you want to keep it there as long as possible.
Marcus: Then the last phase is where you’re retiring it. You’re acknowledging that. Okay, so, I’m curious. Do people ever get confused about what phase they’re in?
Ellen G.: That’s an interesting question. I asked that question. I was doing a keynote earlier this year called What is Your Product? I did a poll, and I had them manually using a polling tool put in where they were, and it was all over the board, but people answered immediately. Now, one of the things that I’ve found with that is that they’re not sure what their product is.
Marcus: Ooh, that’s surprising.
Ellen G.: Yeah, yeah, yeah, yeah. So, some people might be thinking of this particular software application that they might be supporting or adding some features, and they’re not thinking broadly about the product. So, they’re making their assessment from maybe a slightly stilted point of view. I like to think of a product more broadly than a single vendor application.
Ellen G.: Particularly in a large organization, if you asked your customer, “What’s my product?” They’re not going to say, “AngrySoft’s transaction monitor.” They’re not going to tell you a vendor tool that’s a component element of something broader. They’re going to say, “Account management,” or, “It’s handling risk management,” or, “It’s investing my pension,” or, “It’s allowing me to plan vacations.” That’s the customer’s perspective. That’s really what your product is. So, yeah.
Marcus: Now, okay, so let’s pretend I work for AngrySoft. I might even own AngrySoft, and I have built the world’s greatest application monitoring platform, which all of us nerds out there know what that means, right? You install it on your servers, or you have some dashboard. I actually don’t know exactly what it means, but it’s important, and when I meet people at conferences, I say, “I sell a application monitoring product,” and they nod, hopefully, because they don’t want to say, “What’s that?” But what is it? You’re telling me that the people who buy this might not go to their boss and say, “Hey, good news. We now have an application monitoring product.” That might not be the thing that they are most excited about that’s going to happen after the purchase.
Ellen G.: Yes. I mean, it depends on your perspective. Are we talking about an internal customer or an external customer? When my example was meant… I liked the new name of the company we came up with here, Marcus, AngrySoft. We’ll have to go out and get the domain name for that.
Marcus: Absolutely.
Ellen G.: If AngrySoft is part of the infrastructure that supports some broader product from me as an external customer’s point of view, I don’t really care about AngrySoft. Now, if I am in the infrastructure of an organization, then my internal customers might care about that, like the app devs, right?
Marcus: Mm-hmm (affirmative).
Ellen G.: They’re going to care about that as part of an overall platform offering, but that by itself, AngrySoft’s tool is just one of several or many. I mean, I’m going to have database applications. I’m going to have the bowels of the infrastructure. All those tools all together, allow me to provide a platform for an app dev to build a banking system, right?
Marcus: Mm-hmm (affirmative), which is the product of keeping your money safe or securing your future, because I really don’t care about another thing that looks like accounting in my life for a banking system example. I care about something deeper than that.
Ellen G.: Right, right, in terms of your goal as a customer.
Marcus: Yeah.
Ellen G.: Right, so you want to move your way out externally. This is one of the things that I think is a little bit of a struggle particularly in the Agile community where people are coming from a technology perspective into Agile and Lean because they think inside-out, not outside-in. So, we want to go outside and think about the true end customer that is buying, acquiring, and being supported by your product and take the customer’s perspective, which gets it into a broader perspective.
Marcus: Without revealing names, can you tell us a story? I feel like there’s a beautiful story about Agile teams that are struggling to move in that direction. Do you have some examples?
Ellen G.: Oh, lots. I’ll take one of a client that I worked with earlier this year, and their need was to… They for a number of reasons including time to market wanted to turn their technology infrastructure to their technology organization. They wanted to be Agile, go Agile, and part of their goal was to say, “Okay, so they’re fairly large. Where do we start? Let’s figure out where to start. So, what product do we start with?” We think we have… I think they thought, if my number’s right, that they had about 28 products.
Ellen G.: So, it is a mid-size organization, many millions of dollars in revenue, 28 products. Well, the long and short of it was they really needed to have an understanding of what are our products because first, we need to start with that, and then we can figure out where to go deep into that product area and wow, that has a lot of implications for product management, for backlog management, for planning. So, let’s get our act together here.
Ellen G.: I work with a colleague on this, and we pulled together some key people in a facilitated session and had agreement from the CEO ahead of time about this whole session and about how decisions will be made. That’s another topic, decision-making, very big topic, and he came with his directs at the end of this week. But part of the pre-work, I asked everyone to make a list of what you think what your products are and just list what the products are, and this is where they had in the high 20s, maybe low 30s, and we did a number of exercises beginning with that list. Just having them sort them into “is a product, is not a product, not sure,” after giving them a definition of product and some examples that were neutral.
Ellen G.: Then we had people with cards moving around and cross-affinity groups, and they were moving, and things started to converge and the list got smaller. Then I’ve led them through a series of other activities to have them take an outside-in point of view without getting into all these activities. But over a couple of days, they started to… These were business people and some technical people, okay?
Marcus: Mm-hmm (affirmative).
Ellen G.: These were people that had… They knew where the bodies were buried. They had been in this organization a long time, and they’ve really understood the products. So, in the end, they realize they had five products.
Marcus: Five products. They started with something in the mid-20s, and they ended at five?
Ellen G.: In the high 20s. Yeah, yep, yep.
Marcus: What impact did that have on the organization? Maybe even in that moment, what was the realization like?
Ellen G.: Well, I remember distinctly one of the business people was very excited about this because she could see the implications for simplifying how they run their whole operation, their business operation because… This is true because I have other stories rattling in my head about this, because if you align how you’re organized, and that includes your technology teams to what the product is, you’re simplifying things so much. This is where some of the idea behind a feature team, a true future team where there are just basically product areas for a single product.
Ellen G.: So, that was from a business perspective, a simplification of the business that she was really pushing the CEO, “See, see, see?” She actually gave a lot of the readout to the CEO and his directs because of the potential for a lot of simplification from the business perspective, let alone with the technology perspective. From the technology perspective, one of the things you got to do when you realize what your product or products are more broadly and more holistically is you got to start having all these team backlogs. Every team having its own backlog.
Marcus: Well, that sounds very Agile. Is that wrong?
Ellen G.: Uh-huh (affirmative). I mean, it’s not a matter of Agile or not, but if it’s one product, you have one backlog. The teams may be working in areas within that backlog and in certain feature areas or product areas of the backlog. But if I’m the product manager, and there’s 10 backlogs because there’s 10 teams or even 20 teams sharing a backlog, I could see my hair on fire every day running from team to team trying to help them prioritize their stuff, but wait. There’s a dependency between your backlog and this backlog, and how do I prioritize that set of requirements actually is for the same customer? I’ve created a nightmare for myself as a product person.
Ellen G.: So, you have a lot more simplicity and flexibility when you have one backlog. It makes this idea of having one backlog per team and one PO per team. It’s overkill. You got all these people that are playing these coordinator roles running between teams and teams and backlogs and backlogs that’s just causing more chaos to the overall system, if you will.
Marcus: So, let me envision the world you’re describing, the positive side, not the crazy one you just envisioned because I’ve lived in that one. So, a product, and I’m going to use a product. I’ll say, “One product has one backlog,” and let’s say there are four teams, and they’re value delivery teams, right? Each of them has a developer and front end and back end and QA, right? And each of them can fully push out a feature.
Marcus: But one team deals with one part of the system generally, and another team’s an expert with another part of the system generally. Isn’t there still sometimes a problem about keeping all the teams busy? For example, if there’s a lot of work in one area, like I’m just trying to think about logistically because I’ve been in this situation where I’ve thought to myself, “Oh, crud. Well, what will the database people do this sprint then? I’ve thought about a lot of the other stuff,” and then I end up making up something, or I say, “Well, here you have your own backlog.” I can’t believe I just admitted it.
Ellen G.: Then I’ve seen that too, Marcus, and that’s describing exactly that you are managing the work, not the product. You’re trying to manage people around getting them busy and doing work. So, if there is one area of the product that really needs attention, let’s say you got a competitor, and you have to build some parity capability, or you have an innovation that you need. Cost of delay is going to be really high if we wait. All hands so to speak on. Well, you have that flexibility. If you haven’t bifurcated teams so that they only work on this one backlog or one area. So, eventually, engineering management is going to start looking at moving people around different teams, getting them exposed to different areas of the product, so they become more domain experts in the entire product.
Ellen G.: They may start out with expertise in one area, but if I’m a product manager, I don’t want to have to worry about, “Well, this team only knows this one little area. They’re not busy.” It’s like, “Wait a minute. We have customers out there that need this, and our market’s pressuring us. I don’t have any flexibility if I’ve worked in this other scenario.”
Marcus: So, the different concerns, managing the product and managing the team and the workload and their priorities. I can see how conflating them can really cause a lot of problems, and when your team is a fixed cost, and they’re not cheap, right? I feel like it’s… The analogy that’s coming to mind for some reason is if I bought a car, and I had one of those satellite radios on it, but it costs me $10,000 a month for satellite radio. I would probably think, “I have to run satellite radio all the time to get my money’s worth,” and when my wife and I were in the car, and she might say, “Well, I just want to have a conversation.” No. We have to run the satellite radio, otherwise we’re wasting money. What a silly thing to say, huh?
Ellen G.: Yeah, yeah. No, that’s a very interesting analogy. Do you want to tell me a little bit more about that car ride?
Marcus: Well, we have a lot of car rides in my family. Let’s switch gears because I don’t want to talk about the car ride, although my last thought on this is I wonder how much code got written just to keep people busy, and that makes me sad because the people who write that code really want to contribute positively, and they’re just given work. I bet there’s a lot of folks who know it too. It’s not a secret.
Ellen G.: Yeah, yeah, and that’s another aspect of great product management. That the engineering team or delivery team or dev team, whatever you want to call, the makers, are not order takers, but they’re co-creators. So, great PMs completely engage the engineering team in the domain and the customer. They have them listen in on customer interviews every week and get them involved in prototypes. So, everyone on the product team isn’t it put in a slot because of their role, but they’re on the product team, and they have the head and the heart of the customer in their mind all the time, and this is another reason why a good product management, you don’t need to have a PM for every team because eventually those engineers are going to be… They’re experts in the customer and in the domain, and they often have really smart ideas about how to innovate for the customer. So, then that relieves the product manager from being an overseer, and they can do the more strategic work, right? They can do more competitive analysis, market analysis and trend analysis and engaging the right people, organization, and the work that usually involved in roadmapping because they can rely on a great dev team that understands the domain. They don’t have to babysit. In fact, eventually, on a day-to-day basis, they could allocate decision making to the team on what to build. “Okay. Here’s the theme. Here’s the goal. Team, figure it out. Figure out what do we need to build to get there.”
Marcus: Yeah, I’ve worked on teams where I was given that kind of power because I had that kind of context, and I remember feeling wonderful. As a developer, I knew what the customer needed. I talked with the customer. Yeah, product management was around, but the reality was is they would often defer to meet. “Well, you had that conversation and how much? Okay, maybe that’s something we should really include, and can you scope it out?” I did not feel pigeonholed as just somebody who was a glorified typist or a technologist. I felt a part of what was being built.
Ellen G.: That’s exciting. That’s fun.
Marcus: It was. It was probably one of the best things I’ve done. Let’s switch gears here because you mentioned Agile, and Agile is a big topic these days as it continues to be. The industry is still trying to figure out what it means in some ways, but do you have some tips and traps maybe you’ve seen about Agile and product management, where it’s working and where it’s not?
Ellen G.: Yeah, sure. I think that some of what we just were talking about is where it’s not where there’s a PO for every team, and the product owner is a glorified slave master and backlog monkey, going through the backlog and reordering things and saying, “Here’s what we need to do, team,” and maybe not as connected with the big picture and the strategy. That’s unfortunately a common pattern. It tends to though be more true with companies whose products are… They’re not product companies, right? So, they’re building their product supports, the operation of the business. It’s being used by internal customers, right? A product company, often, they have less of that problem where they have an overabundance of product owners, but I have seen that, but it’s less so in a product company because they have naturally a more external focus. So, that’s one common issue with Agile and product management. The other thing is that I’ve seen in a lot of Agile transformations, there’s a lot of focus just on the team and not on product and product management. So, there’s not a context for that backlog. There’s not a strategy. There’s not a roadmap and particularly, in larger organizations, the different parts, sales, marketing, service, operations, dev, finance, HR. They’re not all connected and singing from the same song sheet and that actually has when you think about it, that’s not Agile per se. That’s just good product management.
Ellen G.: But Agile teams get stuck in that. So, you hear developers saying, “Well, why are we doing this?” Or, “That doesn’t make any sense.” It’s hailing back to what we were talking about before being connected to the bigger picture. So, that’s one thing. I think another is that although they say they do this, doing short tests of the validity of features is missing on many teams. So, they just take, “Okay, we’ll build that feature,” and they don’t question what is the outcome that we’re trying to get to to get to that feature.
Marcus: What are they missing by not doing that?
Ellen G.: Oh, they’re missing building the wrong product or over bets-
Marcus: That’s not expensive.
Ellen G.: Yeah, right, or building the product in a more bloated way. So, I guess another thing, which is dear and near to my heart because we wrote about this in the third book is that people get so hung up in the Agile community on user stories, and their focus is on writing those darn user stories.
Marcus: They’re like manna from heaven, right? Given to us by the gods, sent to save us.
Ellen G. Yes and yes, and they’ve become a nightmare on some teams where they have bloated backlogs with all these stories, and everything is in a story format. Then when they pull in a story, it’s not ready because the story… Now that I’m going down into a little detail about story-
Marcus: Please do.
Ellen G.: But a story is as a user, I need to take some action, so I get some value. Okay, fine, but what data am I using? What business rules need to be enforced? What type of customer? What’s my environment of use? What is the platform, the hardware and store software platform? And how about those poor, lost and forgotten quality attributes? You know those little things like usability, security, reliability, availability, testability that can make or break your product? Those-
Marcus: The abilities.
Ellen G.: Some of them are ilities. Yeah, and those are not… I know user story. So, teams think, “Oh, we’re doing stories, so we’re doing Agile,” but they haven’t had conversations holistically about that chunk of functionality that’s supposedly valuable.
Marcus: I heard once that a story was a promise for a conversation, but I don’t really see them used that way. They feel to me like mini-BRDs like business requirement documents, or they’re either too little, or maybe I was describing too much, right? They’re, “Oh, this story has got six attached documents to it,” and it’s essentially like a waterfall project in and of itself. Is there some middle ground there?
Ellen G.: I think the lightest weight, a way to represent a requirement, the most Agile lightest weight is just with tests because a test is a requirement and a test example scenario, they’re… What’s the term? They’re a Möbius strip, right?
Marcus: Oh.
Ellen G.: And a test and a requirement. I’ve worked at pharmas. If you go to the FDA pharmaceuticals, not farmers, pharmaceuticals.
Marcus: I had a feeling.
Ellen G.: The FDA is looking at traceability. So, if you say you’re going to build something, give me the evidence. What do you need to see? Forward traceability is a test. This is the requirement. Give me the evidence test. So, you don’t even need all these requirements document. I’m being extreme about it, but the most extreme thing would be the tests. The tests are the evidence, so that’s at one extreme, I think, and then you described these monster documents.
Ellen G.: The middle extreme is it could be in the form of a story if you wanted, but it just could be a one-liner supplemented by some tests and maybe sketches of the data or a UI for the interface. We’ve listed out the platforms. It can be very lightweight. We call it a discovery board where any piece of work whether it’s something you’re doing in the next sprint at the Now-View, I like to call that, or something coming up in a release that would be on a release plan, the preview or something chunkier and bigger for the product roadmap.
Ellen G.: The Big-View. Now, if you preview Big-View, you can explore that piece of work, that requirement, using seven product dimensions, and we have a space on the discovery board for each of those seven dimensions, and we might… For some of them, you would use a visual model like a data model, or maybe you just mock up some tests for the user dimension. At the Now-View, it would be a screen mockup and so on. I mean, without getting into all the different tools, but you want to try to make it visual, and that really helps the conversation.
Marcus: So, it sounds like product managers, who don’t want to have too little, kind of the Goldilocks syndrome, and don’t want to have too much, should be thinking though about these various ilities, or I think about them as perspectives of what they actually want rather than making assumptions. “What are the rules? What is the experience the user should have?” All of the different things you mentioned that I think a lot of times, or I wonder if product managers sometimes say, “Well, the developer, they just know how to do that.”
Ellen G.: Some things they do know how to do, but there’s also options for all of these things. So, you need to discuss collaboratively the options, right?
Marcus: I love that.
Ellen G.: And slice the options for value. I ended up calling that a structured conversation because you’re structuring the conversation by exploring, evaluating, and confirming. So, you explore options, and we use those seven product dimensions to do that. You evaluate using value as a slicing mechanism, and then you take a subset of those options, and that’s your package. That’s your requirement, but the conversation is not over until you confirm that you have a shared understanding, and that’s where things like tests and scenarios or both come into play. So, you want to have good structured conversations and make sure you look at those requirements holistically, and that’s where the seven product dimensions help.
Marcus: Yeah. I’m reminded, like some trends I see with engineers are they… Engineers tend in my experience to have their own sense of what quality means and what doing a good job is. If we don’t have that structured conversation where we tease apart value, and we talk about what’s in and out of scope and why we think something should be there. If we don’t have that, then they’re probably going to build it… I hate to say this. You can just yell at me, but build it the way that’s the most satisfying for them as the builder or the way that either… By satisfying, that could be prevents them from getting yelled at because their boss wants it now or makes them the most proud, or I think there’s lots of attributes that people bring to their own work that we don’t talk about.
Ellen G.: Yeah, yeah. I have a story about that.
Marcus: Oh, good. I love a story.
Ellen G.: I remember working with… This is a healthcare organization, and we were using the discovery board and doing a release planning, and we had the lead architect there, the product manager. We had a good group, cross-functional group of people there, and we were looking at what needed to be built for the next release. Now, this product is highly regulated because it has claimed data and a lot of personal healthcare data. So, there’s laws here in the U.S., HIPAA laws that you have to conform to. If you don’t, you’re up the creek, and it’s very expensive, and you get your name in the press. Not good.
Ellen G.: So, at the beginning of our work session, we went through all the why, the vision, the value. We looked at the product partners from the customer, business, technology, and in value, from a business point of view, the PM pointed out that the data security and privacy was really non-negotiable. Okay, so fast forward. We’re working on some of the capabilities that might be in the scope for the release. I think they were using three-month releases at this organization, and people were working at this board across the seven dimensions but in small groups, and the lead architect was at the area on the board for the dimension that we’ve called the environment, which is the hardware software environment. So, he was with two other people and listing on the board SQL server and… Sorry. I’m trying to remember which other databases in this organization. There were key databases that they used. Oracle, of course. It was Oracle and SQL-
Marcus: Of course.
Ellen G.: … Server, but then he added Hadoop, and people pronounce that differently, right? But-
Marcus: They do, but I know what you mean.
Ellen G.: Okay, the cloud database. So, we pull everyone together, and everybody’s sharing what they came up with, and he’s listed… He’s had this, Hadoop. The PM, product manager, was not from a technical background. He’s like, “What’s that?” He explained what it was and said, “This would be really good to use in this release because of storage savings. It would save a lot of money.” So, she looked over. She had her arms crossed and was her head cocked to one side, and she looked over to the left side of the board where all the value stuff was listed, including the privacy security, and she looked at that. She looked at him. She looked at that. She looked at him, and she shook her head no, and she just said, “No,” with her head, and then she said, “We can’t afford to experiment with that, with this data, with this next release, okay?” Now, I can guarantee you, because I knew from some of the past with this group that if they hadn’t had that conversation, if those 10, 15 seconds hadn’t occurred, that team would have gone off and experimented with Hadoop, and the risk was too high, and that product person wasn’t in the position to be able to make a decision if they hadn’t had that conversation. So, it would have been fun for the team, and certainly, he had good reasons. His reasons were very good, but you have to balance. The risk was too high.
Marcus: His intentions were good, and it sounds like it came from a place of, “This is a really good technical solution, and it will save you money,” right?
Ellen G.: So, it was even more than that, Marcus, because he explained this to her, and everybody was like, “Yeah, we get that,” because it was in the Northeast area where it’s really hard to get really good tech people, and they wanted to be able to attract people. So, if they’re using this cloud-based database at that time, it would’ve been very hot. So, he was thinking also about attracting and retaining talent. He had really legitimate reasons, but she couldn’t risk it.
Marcus: I think that’s great, and I’ve been in situations where I came along, and the developers were using something like Hadoop, something new, but it was too late. We didn’t have the 15-second conversation up front. So, then it got used. It got built on, and then they were like, “Well, do you want us to just throw this away?” “Well, no, that’s much harder. Don’t go backwards,” and then it feels like you’re stuck with it. But the person in that situation was conflating values, right? The values of retention and being able to hire. Those are important but also privacy and risk to time to market, and if it’s brand new, that brings risk. So, I think that it sounds like product managers really need to sit at this intersection. They don’t have to know it who do biz, but it sounds to me like you’d better have the skill of asking why until you can understand well enough to say, “Show me how it aligns to the value that we decided up front,” the things that are important.
Ellen G.: Yeah, and it also points out how hard product management is because you have to-
Marcus: It is.
Ellen G.: … balance the perspectives of the customer, the business, and the technology and make tough, tough choices all the time.
Marcus: I’ve heard technology groups, and I’ve been in programming teams that told the business analysts that we call them at the time, and I know that’s different, but they were playing the product manager role. We would say, “You told us what features. Never tell us how to do it.” But of course, that’s a silly thing, right? Because what gets built and how it gets built are both important conversations. So, we have to slice value and have conversations about the meaning of and the impact that all the decisions make.
Ellen G.: Yeah, absolutely.
Marcus: All right. I want to turn the question to something you mentioned earlier, decision making. Decision making, especially in the area of product management, like what is involved with that? Are there some best practices around that?
Ellen G.: I have found that for high-stake decisions, collaborative decisions are higher quality and lead to better implementation. So, many years ago in my ancient pasts, I learned from guy named Sam Kaner who wrote a book called The Participatory Guide to Decision-making, and he explained in his book, some Agilist and coach may be familiar with his work, different decision-making styles or options and how to check in for agreement. So, I’ve modified it over the years and working with technical people and engineers and doctors and different analytic people. But essentially, if you have a high-stake decision, and you want to make a participatory decision, you basically have a choice of consensus, or a decision leader decides with participation. Now, the other decision rules would be basically somebody dictates a decision, or you flip a coin, an arbitrary decision, or you try to do arbitration, and those are usually some version of win/lose versus win-win and are less collaborative.
Ellen G.: So, the best participatory decision style options would be consensus, and a decision leader decides after discussion when it’s a high-stake decision. If it’s everybody will eat meat on their pizza, and it’s a difference between pepperoni and sausage. Okay, you can flip a coin, right? But for a high-stake decision in terms of the architecture or what the goals are for the next release to anything that is of any stake, you want to get different perspectives. Now, one of the problems with consensus is that it means, in Greek consensus, this means of one mind. How do you know you have consensus? You don’t have a way to really know unless you have a way to test for it. At the same time, if it’s a decision leader decides after discussion, how does that decision leader who ideally is somebody as high as necessary but as low as possible in the organization, how does the decision-
Marcus: That’s good.
Ellen G.: … leader know that they’ve gotten good input into some proposed options? Well, what I have found really helpful here is using a gradient of agreement to test where people stand on a decision. So, this usually will happen in a facilitated session. We’ll look at options. We’ll talk about maybe do some analysis around them, do some prioritization. We’ll have defined the decision rule first, and I usually end up talking with the ultimate decision leader and about this whole scenario that I’m talking about, this tool for deciding how to decide. That’s the pattern. I call it just decide how to decide. A consensus takes time, and it takes more time, and it also disempowers the ultimate decision leader potentially, and it’s a defaults and a democracy of people to go to voting. But that’s another decision rule that’s really crapping one for corporate environments. People vote often not for logical reasons, and there’s all kinds of politics as we well know around voting.
Marcus: As we do.
Ellen G.: So, consensus or decision leader decides after discussion. Now, what we want to do is after we looked at options, let’s use a gradient of agreement to check in. I use a gradient of agreement of four, a scale of four with one meaning, “I’m all in. I agree.” A two means, “I have reservations,” which we give voice to, “and I will support it, but I want to express my reservations,” okay? A three is, “Go ahead without me.” It’s like, “I don’t want to be involved,” and a four means, “Block. This will hurt the organization, the common good, et cetera.” So, we want to check in where people are along that gradient of agreement. If I’m the decision leader and the decision rules decision leader decides after participation. So, we’ve talked about this, check in, and I’ve got somebody that is a three or higher that’s saying, “Don’t involve me or I block.” “Wow, that’s important for me to understand. What am I missing? What’s going on here? Fill me in.” But if the decision rule is that, that person can then just, “Okay, well, I’m ready to make a decision,” right? So, I’ve had that situation where Patty was the PM, product manager, and we had spun around some options about… This was a release planning for a regulated product, and somebody on the team who was new, a business person, was a three, meaning she didn’t want to be involved.
Ellen G.: So, she was new to the team, and Patty recognize that she didn’t have some content knowledge around this. So, she said, “No. I’m ready. We’re going to move forward with this, and I’m going to spend some time with you offline to explain to you. Let’s move on.” So, they just moved on. She made the decision. It was clear what the decision was going to be about, what the rule was when we use this process, and it went very quickly. So, we have transparency, and that builds trust as well because we know how we’re going to reach closure, and we’re not going to have these sidebar, coffee-room, water discussions. “Oh, I didn’t really agree with that.” Everything’s out there. It’s transparent.
Marcus: Yeah, I always hated hearing from somebody, “Well, I never thought that was a good idea,” after the fact especially. Like, “Things didn’t go well? Oh, yeah, I didn’t think that would work out for you.” “Well, golly,” and then I would have other thoughts that weren’t so nice sometimes. So, Ellen, it’s been a real pleasure to chat with you again to see you again. Of course, I get the luxury of video. Where can people find you online and engage with your work?
Ellen G.: Yes. They can find… My website is ebgconsulting.com, Ellen Boy Girl Consulting, .com, and it’s got lots of blog posts out there, and they can find out about the services that we provide and some upcoming events that we have going on, and we also have a website for the third book that I co-wrote with Mary Gorman, discovertodeliver.com. Now, also, I want to mention in addition to a bunch of resources, you can actually download a PDF version of the book from that site.
Marcus: Oh, great. I love that book.
Ellen G.: Yeah. Okay, great. That’s great.
Marcus: I have the paper copy. I love that book. And of course, I love your book on requirements, and we have… Well, I’m just a big fan, so thank you-
Ellen G.: Thank you, Marcus.
Marcus: … so much for being on the show today.
Ellen G.: It was a pleasure. Thank you.
Announcer: Thank you for listening to Programming Leadership. You can keep up with the latest on the podcast at www.programmingleadership.com and on iTunes, Spotify, Google Play or wherever fine podcasts are distributed. Thanks again for listening, and we’ll see you next time.
You may also like...
