Episode 123: Navigating Conflicting Methodologies in Product Management with Teresa Torres

This time on Dear Melissa, Melissa Perri holds an interactive session with Teresa Torres, Product Discovery Coach at Product Talk.

In this episode, they answer questions on navigating conflicting methodologies, the importance of hiring a skilled product manager, and achieving strategic alignment and execution in large enterprise companies with multiple product lines and strategies. They delve further into the importance of standardizing processes, such as product strategy cadence, road maps, and discovery tool kits, to facilitate coordination and collaboration.

Have a product question for Melissa? Submit one here and Melissa may answer it in a future episode.

Q+A:

Q: Dear Melissa, as a new Product Manager, how would you handle working with Senior Designers who are strongly opinionated, want to track everything, and convince that there is only one correct method for problem solving? 

A: Sounds like you have somebody who is very strong in their beliefs working on your team, and this does happen a lot, but I think it goes down to really understanding who that person is and why they believe the things they do. So I'd say maybe take a step back, take a breath, because this can be extremely frustrating to work with people who are like, no, my way is the right way, and I don't want to listen to anything else. And sometimes their way is the right way. So I think we do need to acknowledge, like, hey, maybe the way that they want to work is good for this situation, in which case, pick your battles and do whatever they want to do right. If their methodology or their way of working works, don't fight them, just do it, right? It's not about ego. It's about getting things done. 

Now, in other situations, though, you might have something that works better, and maybe more often than not, you might have a different way of working that you've seen work better in another organization or somewhere else, but this person is like, no, this is how we do it here. So now you're going to have to figure out why. Why do they like the thing that they're talking about, right? So start talking to them. Be like, okay, great. I'm really eager to try your methodology, your problem solving thing. Can you tell me about why you think it might be better than this other one? Tell me about how it works, how you learned it. Try to dig into what's good about it and why they think it applies to that context. And try to figure out also why they fear new methodologies, right? Ask them like, hey, would you consider maybe trying something new? Here's why I think it would work in this context. It's a little bit different than the one you just described. We're doing X, Y and Z. 

We might be at a different stage of product development, in which case this might actually work better. I'd approach it like that and just listen to them, but be open about it, right? I think if you're dismissive to people who are very stuck on their one way of working, they're going to be dismissive right back to you. So you do have to say, like, hey, I really want to try some new things. I wonder if you would be open to it, but explain to me why not. What makes you scared, right? What's holding you back from trying this, from expanding our way of actually doing this types of problem solving? And listen to them. There are some designers who have read a ton of books, got stuck on their methodologies just the same way that product managers have gotten stuck on their methodologies too. So I'll say this is not a unique thing to just designers. This is a thing everywhere. I've had people be like, no, this is our only way of doing development. No, this is our only way of doing product management. No, this is our only way of doing, like, market research. This happens all over the place. So this is a good life lesson and good skill to practice for everyone. 

So I'll say that, but take a step back and try to bring it back to the context in which you're operating. Understand if their problem solving method might be good for that context or it might be bad for that context, and you're going to want to explain, but you're going to want to stick to your guns if it's bad, and try to show them how you can be doing things differently with a better or different methodology. I do see a lot of designers, too, just get scared that they won't be involved in the whole process. So if you said they want to track everything, I don't think it's bad to track everything. I wonder what they want to track, right? Are they just documenting things so that we can actually have a record of it and see it later? Are they tracking all the design changes? Is that what's happening so that they don't make that mistake? What do you mean by track everything? Right? I would kind of poke into that. But if they're thinking about only one way of problem solving, they may have had situations in the past, too, where they've been pushed out of problem solving by Product Managers and they might be grasping to their way of working so that they're involved. I've seen that happen as well, too, where Product Managers are like, no, you just do the design. You don't do any of the user research, the UX components that's product, right? Like, you're just a designer. So that's happened as well. So I would really try to get to the root of it. Like, why do they think their methodology is better? What context have they applied it before and figure out, too, how you can kind of make them the hero or bring them in closer to collaborate with you and quell those fears? Because usually when people are sticking to something and saying, like, this is the only way, it might be one, the only way they know how to do it. So that's something to remember, right? 

They might have only one methodology they know how to do, in which case they're going to be like, no, this is the way we do it because don't know any better, right? They don't know what else to do. So in which case you could say, like, hey, it's kind of similar, but maybe we take a little different take on it and try a different methodology. But a big part of this is actually building trust. And I think that happens in a lot of these situations where we get into culture wars about who wants to do Scrum versus Agile versus continuous discovery habits that we'll be talking about later and all those things. People start to identify with these processes and methodologies because that's the way they learn or they believe it's the right way to do it. So if they firmly believe that's the right way and the only way to do it, it's good to go back to first principles. And sometimes we forget that. We forget about the first principle motions when it comes to these methodologies and why we're here in the first place. So I like to rip up methodologies in a lot of cases and just say, hey, let's just talk about where we are and what we're doing, right? What do we need to learn? Where are we in the process? All right, how are we going to learn that? Don't shout a methodology on me. Like, literally, what are we going to do? Are we going to talk to customers? Do we got to go talk to two of them or not? If we're going to think about this problem, should we be doing testing? What kind of experiments are we going to do if we're into roadmapping? How should we collaborate on it? 

Strip away the terminology and I think you'll get a lot further. And I do this very frequently. I've had people coin my process that I talk about in the book saying it's the escaping the build trap process, but I firmly don't even believe that's like a registered process. I think that's just how we build great products. But I'm not wedded to any specific methodology. I'm wetted to whatever is going to get us to the answer fastest and then in the best place. So that's what I think we all have to come back to when we get into these wars. It's like it's not about your problem solving technique or mine, it's about solving the problem. So let's strip away all these tools, all these techniques, everything, and just talk about solving the problem and what we're going to do. Maybe try that approach because I do think you get a lot further there. Instead of saying like, hey, XYZ process is better than your ABC process, if you're fighting that way, you're just going to get into a war about nothing. So kind of step back, take a deep breath, because I'm sure you're frustrated and I've ran into a lot of people like this and I've been frustrated too, and just ask questions, why do you believe that? But not in a confrontational way. You have to say to them too, like, I'm on your side and I just want to build this, but I want to understand why this works. So please help me understand that and let's just figure out how to solve these problems better together. So maybe try taking that diplomatic approach, even though it might be frustrating, and see if you get a little bit further that way. 

Q: Dear Melissa, I work for a global Fortune 500 company with many product lines. In the past three years, we have been on a transformation journey in adopting Agile and DevOps ways of working across our technology organization, as well as forming a dedicated digital product management organization, allowing us to shift from dynamic project teams to stable product teams. We are leveraging very lightweight scaling framework that is not safe. However, we continue to see a lot of coordination, friction in prioritizing and delivering cross team and cross division initiatives. I am curious what you have seen to be effective approaches to getting strategic alignment and execution in a large enterprise company that has many products and product strategies, whether it's prioritization approaches, team topology adjustments, or any other tools or techniques you have brought into these situations. 

A: So what you're experiencing is exactly why Denise and I are writing the product operations book, because what you're finding is that you don't have one consistent way of how you work in product across the company. Many companies, when they go through a very large scale transformation using what you talked about, DevOps and Agile, they leave product management till the last thing and then they start scaling and they're asking exactly the same question you are what do we do to coordinate? And that's really what product management is about. It's about setting a strategy and deploying it throughout the organization to figure out what we should be building and making sure we're all building the right things at the right time in the right teams, right? So that's really what we're looking out for, product management. And always it gets left to the last thing. It's like, oh, we did all the tech stuff, now we should throw some product on top of it. And the answer to this though, is not usually to go adopt Safe or something else because that's almost solving the same problems that you're dealing with at the moment. From a technology perspective, when you look at product management, there is a pretty standard way that people do it across the board in companies, some people do it better than others and that's why it might look different, but we're all kind of converging down to similar processes. 

Now the biggest thing is in these organizations, what happens is you leave product leadership almost always till the last thing to think about. So what you need to be doing is really centralizing your product under one person, which is why I advocate for a Chief Product Officer at the top. So somebody's got to be thinking about what is your software product management strategy. From there, you deploy it down to the next levels and that can be in different business lines across the organization and then they deploy it down. But now you can start coordinating. So if you don't have a person actually running this and thinking about, hey, we need product operations, we need to set up the teams in this correct way, all that. It's going to take you a lot longer to do this because you're transforming kind of internally, but you're not bringing in the good product knowledge that people have been doing for years. So that's what makes this transformation a lot harder. So it's usually good to bring in some people who know what they're doing at this level and help mix it up. So typically you're going to need a product strategy cadence and review. 

How do you set product strategy, how do you deploy product strategy, what artifacts are you making, all that stuff. Then you're going to want to think about what do we standardize across the board so that we can all collaborate together? Those are things like roadmaps, like you shouldn't have 18 formats for roadmaps. But it's also things about what do we talk about to get people together to do those strategy reviews. If we do have cross initiative problems that we're actually solving, how do we bring those people together to talk about it? So you're setting the cadence and building the framework for how your organization actually works. You also want to do things like standardized discovery toolkits and look at what else will cross different teams and different people to help communicate what product is doing out of the organization, but also within the organization. So somebody usually designs this at every organization and there are a lot of stuff out there that you can grab and just borrow and bring in. Like people have been doing roadmaps in different formats. Just like take one that works for you and put it in there. You're going to want to think about also introducing a software for that. A lot of times we'll get Jira for our software and we're like, oh, we're done, that's not good enough. 

Jira is not a product management software and it actually sucks at everything product management. So you're going to want to look at something that goes on top of Jira and helps pull that information out. So you need a good roadmapping software, a good product portfolio software, and there's a bunch out there that you can start to look at. I really like Dragonboat that sits on top of Jira. There's things like product board, there's a bunch of other things out there that does product portfolio mapping that's going to help you with this cross initiative problem. So really look at what tools are in place because you probably have a lot of good stuff. From a technology DevOps standpoint, it sounds like, but not from a product management standpoint. So we need to consider product management not just as like the piece of Agile that we forgot to implement. It's like it's actually a whole discipline. So it needs the same type of rigor and the same type of introduction that you just did for that agile transformation needs to be applied to product management. And I don't see a lot of organizations doing that. It's like, oh yes, we forgot about it now let's just put it in until they realize it's a problem and then that's when I get called and then I come out. But I would really look at what are the pain points we have here, bringing somebody who knows how to design a product management organization and I would embed those people in your team. Like, I'm not sitting here telling you to hire me as a consultant. I'm saying hire somebody who's been a product leader before because they'll be able to do the things you're talking about, like in their sleep. They've done it before, they've brought these things into the organization. 

So that's why I'm saying we really need some higher level, good product people scattered throughout the organization that can help bring that rigor in and can help work on it. And usually they'll create something like a product operations team who will standardize it across the organization and that will be good. So that's the type of things that you need to be looking at when you're trying to figure out what do we need for product management? Because all of the stuff that you're talking about is really in that discipline. It's not a technology discipline. It's not a DevOps discipline. It's not an agile discipline. It's a product management discipline. So those people know the methodologies. They know the framework. So I would really just try to hire in people who've done this before throughout the organization because they will level you up and they will help with this, and that's going to be really important. And that's also why a key product operations hire in an enterprise level becomes so great and so key to making sure that you're all working seamlessly together so that's somebody that you might want to think about bringing on to help guide this in your organization as well. 

Q: Dear Melissa, I've been working in product management for years and I feel that since I've read your book along with others, there are so many things that can be done and that I'm still in diverse when it comes to knowledge. Of the several books I've read, three are Escaping the Build Trap, your book. I love the concept of Product Kata, and I try to apply it. The Lean Product Playbook by Dan Olsen. Continuous Discovery Habits by Treresa Torres. I just finished it today. My problem is that your methodology and Dan Olsen's complement each other very well, but the continuous discovery approach is quite different from what you propose. Do you think both methodologies are complementary or maybe they're very different things to apply? So what's your first reaction to that?

A: Teresa Torres - 00:16:46: 

I'm a little bit surprised by it because I feel like our content is really complimentary, maybe even more so than any other two product books out there, other than like Marty does a good job of inspiring everybody with, here's some big ideas. That's not a dig. I love his book, but for the books that are getting more into the how, like, this is what you should be doing, this is how you can think about things. I find they're really complimentary. So I'm a little bit surprised by that. Maybe we could explore this by getting into the Product Kata, because I think there's a really easy connection between our work there.

A: Melissa Perri - 00:17:19:

Yeah, I was too. I think I slacked you the question as soon as I read it because I was like, I don't think these things are at odds at all. I think they work very well together. So when he talks about the Product Kata in here, what I try to describe to people as a Product Kata, which is based off of Toyota Kata, is it's a continuous improvement framework, which is continuous discovery. Right? And I feel like that continuous nature of the framework goes really, really well with what you teach. And in The Product Kata, what you basically do is understand the strategy coming down from the company. You then try to evaluate it for where your piece is. So, for example, if you're a Product Manager on a team in a slightly larger company, you're going to be given some goals. You're going to be given some direction around what kinds of problems do we want to solve, not necessarily what features we want to build. So now that you have that context, you basically say, all right, where are we now? What's our current state of our product that we're looking at compared to that context from the company? And if you don't know it, you got to go out there and do some work to figure out what it is. So you got to measure what it is. You got to see where you are in your goals. You got to understand what customers are doing now, which is a discovery thing that you should be doing. So once you figure that out, you basically set the next goal.

So you break down that really large goal that might be financial-focused or like business-focused into something more product-focused that we can achieve faster. And then we start to Kata. So we basically say, okay, in light of this goal, where are we now compared to it? Do we know enough about things? Do we have to answer more questions or did we get some questions answered? And do we have to build something like where are we? What do we know? So I basically make people write out questions that need to be answered and then they prioritize them and they pick which question they want to focus on first. And then they run an experiment or they go talk to customers, or they build a prototype, or they build a version one and release it, depending on where they are in the process. So very early on, it's heavy discovery work tools, and then later on it's probably going to be releasing an iteration and then measuring it. And then you cycle again. So you say, okay, we released it, we got some feedback, we learned, and now where are we compared to this current state? So I feel like that works super well with what you describe with the continuous discovery habits, but maybe you can shed some light on how you think that fits in or what you encourage people to do there.

 Resources:

Melissa Perri on LinkedIn | Twitter

MelissaPerri.com | CPO Accelerator