18: How Agile and Scrum ruined product management, and other things (ft. Melissa Perri)

Transcript

Melissa: So, how do you learn, how do you instill a product culture when even your leadership doesn’t know what that means?

Intro

Peter:  I’m Peter Merholz.

Jesse: And I’m Jesse James Garrett,

Together: And we’re Finding Our Way,

Peter:  Navigating the opportunities and challenges of design and design leadership.  

Jesse: On today’s show, despite some audio difficulties, product management consultant and educator Melissa Perri joins us to talk about the view of design from the product management side of the table, the true value that product managers bring to the process, and how designers can collaborate more effectively with their peers in product management.

Peter: We’ve heard from many people and we’ve had our own experiences of challenges between product and UX. I’m curious what you’ve seen in relationships where product and UX, or product and design, are working well together. What is the agreement there? How do they divide up the work, divide up decision making is often a big issue. Who has the call to make certain decisions? What actually works for a healthy relationship between people in those roles?

Melissa: You have to be partners. I’ve seen lot of bad archetypes and it comes down to being partners and seeing yourself as equals, the two halves of it. And the product managers, I try to explain, you are going to be working with designers super closely.

There are certain activities we are going to divide and conquer. Either one of you could do it, but you have to come back and talk about it together. And then there’s certain other things like wireframing, where you should just let your designer do it ‘cause that’s their job, because you need to be going to do the roadmapping and yeah, and making sure that it’s technically feasible to do things, and making sure that we have the launch plan with marketing in place, and making sure that you’re presenting up to the executives, and getting buy-in for your stuff and then scoping it into the business case and figuring out the goals. 

And, the designer could be part of that too, but you have a lot of work over here, and I see that where, where product and UX start to get tense, is because the product manager is trying to do all the design work and all the wireframing and the journey mapping and everything like that. And the designer is, “That’s literally my role.” And it’s because the product manager doesn’t understand that their role is actually all this other stuff that I just listed, not necessarily just the wireframes. Like the basics of wire frames. Yeah. Important.

Just so you understand how users flow. It doesn’t mean that you should necessarily be the one doing that all the time.

So I think there’s this discrepancy between, what should I be doing? versus what should I know how to do or be aware of? A good working relationship I’ve seen on a team level is when a product manager and a UX designer are working really closely through discovery. We plan our research together. We plan our personas together. We are developing these things as partners, right? Yeah. And then as we start to move into the solutioning phase, the designer is going to lead around really understanding what that’s going to manifest as screens or experiences, where the product manager, giving input from a business perspective to say, these are how we have to think about these solutions to meet our objectives, to make sure that we could still function as a business.

But you’re also having that healthy tension where you’re like, let’s just make sure that we’re doing right by the user as well. So what can we do to solve users’ needs, that will move business goals, is always how I looked at it.

Jesse: I feel like I have had a lot of experiences with product managers who did not themselves have a clear idea of the value that they brought to the process. And, as a result, I find that I have a hard time articulating the value that product management brings to the process of creating products.

Technology’s there to build the thing and design is there to shape the thing and research is there to understand the people who are going to use the thing. And when I get to PM, I start to have a lot of question marks about exactly why that person is at the table.

Melissa: So as technology gets more and more complex, you’ve got a lot more parts of the company that you have to bring together to launch a successful product out there into the market. It’s not just about designing a great solution. How do I make sure that solution gets launched?

Well, it targets the right people. It gets marketed. Well, all that information gets carried over to how do I make sure it’s priced well, how do I make sure that it’s still sustainable over time? And then how do I prioritize the order of those things, to account for things like that. The cost of delays, scoping, moving into new markets, unlocking the potential of the revenue.

There’s all these different things that you could possibly do, but now you have to evaluate it from a perspective of, there’s money out there. How much money is there out there? Do we have the capacity to actually take that money?

Because we understand the needs of that market, we can do it as a team, and we have a good plan on how we’re going to go out and discover that, and test it,  and actually get into it. So, it becomes a very business-focused role at the top. And sometimes design plays a critical role in manifesting those things.

But that strategy of, Where do you want to go? And what does it actually take to build to get there? That’s where I see product really coming into play. And then the order, in the focus of how to do it. 

When I come into companies to help with a product transformation or something, the biggest issue that I see is nobody’s focused. Everybody’s trying to solve 15,000 problems at once. I always do this thing when I come in. I talk to all the teams and I’m like, What are you working on? I start to map it out. I’m like, okay, let me write down everybody’s highest priority.

And I’m like, Why are you working on it? And then I go up to the next level and I go up to the next level and go all the way to the top. And then you could see at the top will say, “This is the most important thing we can do.” And I’m like, “Cool, 10% of your people are working on that. Why? Right. Like why 10%?” Because all these things come up and nobody’s really forming that strategy of how do we tackle this market, enter this market, or just grow in general. In a disciplined way, placed with an intent. And I think what product does is bring intent into the process at every level, to keep everybody focused around what are the most important things, and product at the top looks very different than products on the team level.

And I don’t think you need, I tell companies, too, I don’t think they need 7,000 product managers. I think a lot of people honestly have too many product managers in their companies and they need more designers. I would say that in a heartbeat.

Peter: I’m laughing ‘cause we talked about this a couple of episodes ago and, I see this again and again: companies having too many product managers and they keep hiring more. And my sense is, product managers are a promise of possible new value.

If you have a product manager, they can now help you create new value. And so if we have more product managers, there’s more opportunity for new value. I don’t know if that’s why, but I can’t understand this desire to just keep hiring product.

Melissa: It’s not that. It’s agile, it’s scrum, that did it. Those companies are the ones that call me. They’re like, well, we have 2000 product managers and none of them have ever done product management before, so we need you to come train them. So, that’s, like, my email inbox literally every day.

And I’m like, so why do you have 2000 product managers? First of all, what are you building that warrants having 2000 product managers? Because you are probably spinning up stuff in solutions that don’t, actually, aren’t a product. So they were a project and he put somebody on it like a project manager. You have to spin it up. And now they moved on to the next thing. So you’ve got like a hundred products just sitting there that nobody uses, or like two people use each one of them. And this happens, especially in the enterprise, all over the place. But what happened is, when scrum came out and everybody started adopting scrum, they all had teams.

And scrum basically said, we need at least one product owner on every scrum team. So they said, okay, well we’ve got 10,000 developers, so, okay. Let’s divide that by five and seven. And that means we have to have that many product owners. But that doesn’t mean that you need somebody there just running every single user story you possibly think of. And most of the time they make those user stories up because that’s how they teach them in scrum.

This product owner role, the way they teach it, too, is very not like the way that I teach people how to do product management. ‘Cause you become, like, a backlog jockey where you’re just, like, writing stuff and handing it out to teams and I’m like, that’s useless, that’s not a product manager to me. It has no value whatsoever in it. 

How do we really pull a strategy together? Where we look at it from a business perspective, a customer perspective, and a technology perspective, make sure it all works and then break it down so that we prioritize it and then enable the team to go after it. And that’s where I think the value is on having a product where I’ve seen them bring value to the team.

I think if you have a great product manager on your team, they’re critically thinking about every single aspect, they’re crazy systems thinkers. And if you are building, especially, a software product and a software company, product touches everything.

It affects the way that you make money in your financials. It affects the way that you would market it. It affects the pricing and packaging, it affects the technology, it affects the design. It’s that piece that brings it all together.  And a lot of people in the other roles, or in functional silos where they’re not thinking about it holistically, Is this a thing that we can usher out, that’s going to be successful in every aspect, not just successful the way it solves user needs, but also the way it makes us money. Or the way that it’s technologically sound, where we can build on top of it for the future. And that’s where I see product managers thrive is when they do that job, not necessarily when they’re managing a backlog.

Music break

Jesse: I notice a parallel here between flavors of designers, where you have some designers who are going to be very deep in the concept development, the exploratory strategic kind of design work. And then you have other designers who are going to be very tactical and they’re going to be about crafting perfect artifacts and that kind of thing.

And it sounds like there’s a similar continuum, or tension, in product management between this, it sounds like, a product strategy kind of a function versus, as you described it, the backlog jockey, which is, frankly, the flavor of product manager that I have more often been exposed to, which is really a requirements wrangler. and not someone who really brings a point of view.

And I think that’s the thing that I’m trying to get at, is what is the perspective or the point of view that product management brings to that collaborative process. You talk about holism, and it’s great to have one person who is aware of all the different facets of a problem. How does the product manager bring that sense of holism to the entire team?

Melissa: A lot of it’s in the communication. It’s also managing their expectations of the executives. Where I see a lot of people struggle is talking them through the choices that they have to make as well from a prioritization perspective at the top.

They’re not aware of the trade-offs, and a good product manager presents that from a holistic perspective of, there’s trade-offs in pricing/packaging, there’s trade-offs in the way we market this, and trade offs in the way we design it, so they’re really taking that and speaking that language of the executives, or they’re bringing that perspective back to the teams to help them understand what needs to be done with the solution. 

I see that flavor of design you’re talking about, that’s very strategic. Like, I’ve met them, I’ve worked with them, and they’ve been some of the best designers I’ve ever worked with my life. And I think those people are usually more on the strategy side things, working with the product managers.

And that’s where that relationship really comes out to play. I think when you get into the solution side of it, that’s where I still think you need some oversight around the solution and figuring out how it manifests, or how it could affect other pieces. But, from the perspective of what do our products really look like, and how does it function as a system, into like the user’s interactions and stuff like that, I think that’s pretty much the designer’s job. That’s what they’re there for.

And I encourage my product managers to just get out of some of that stuff and let the designer lead. They should be working with the developers. And you just want to make sure that it’s not going to adversely affect the business needs, or the requirements of other teams, or the dependencies that are around other parts of the organization.

The purpose of the product manager, to me, is to help scope out and prioritize what we’re working on, with intent.

And that’s the piece, the intent behind why we do things, because you could build 50,000 things if you wanted to, but what’s the right thing? 

So discovering what’s the right thing to build is not necessarily a one-person job. I think it’s involving the team in it. And I think the product manager’s purpose is to be the person who can help steer that, and make sure that we’re all tracking towards it and helping represent that right thing back to the board and executives.

So, I think the view that I see product managers bring in there is, How do we unlock business value by solving customer value? And that’s the bridge that I see them bring. Whereas designers I think can definitely be in tune with the business and I’ve seen a lot of them do that. I think they get very focused into the customer value piece and I don’t believe there is any business value without customer value, but it’s what are the layers and the levers that we can pull as a business to help them lock that customer value and make it profitable for us.

The pushback I see from the product side against designers is they’re, like, well, they’re only focused on the customer value, but you know, we can’t run a business, we would have no jobs here, if we only looked at doing what’s best for the customer.

You could have the best customer value in the world, but if you’re not pricing it or packaging it correctly, it could completely kill your company. 

How do we take that customer value and package it into a solution that’s also desirable for our market and feasible and viable, bringing those things back together there.

Peter: I appreciate your use of the word intent as what the product manager brings, as it connects to a definition of design, I think, that comes from Jared Spool and we used it in our book, Org Design for Design Orgs, which is that design is the rendering of intent.

In the past I had thought lot of designers being responsible for the intent as well, but I kind of like this idea that someone’s responsible for the intent, and then design is, How do we take that intent and make it manifest in some way? And you’re locating the responsibility for intent with product management.

As you were defining your ideal product management state, it reminded me of what I would consider almost more old school product. Like we’ve almost lost our way. It had been well understood 10, 15, 20 years ago, and then it’s gotten corrupted over time into these backlog jockeys and that kind of thing.

The role that you’re talking about of product manager is fairly senior. It wouldn’t make sense to have someone with that pricing and packaging, and executive presence and vision, et cetera, et cetera, on a team of eight people, you know, paired with a designer and working with five engineers. That group can make a feature. They can’t really build a product. 

And so what is the relationship between the product manager, that role as you’ve defined it, and the teams doing the work? Is there one product manager working with four teams, five teams, eight teams? Are there still product people on those teams, product owners, or do we not even need that? Is it more you just call them scrum masters, in terms of what you need for a JIRA jockey? You don’t pretend there’s a product person at that level. 

Melissa: If you had asked me this maybe five years ago, my answer would have been, well, there needs to be a product manager on every team. Like, would have wholeheartedly said that. I think the issue is that there does need to be a product manager on many teams right now.

And the reason is just the maturity of the way that we work together. I think if you have a mature team with software developers and designers who, given good direction and intent by a product manager, can then look at things and work together to scope out how work gets done and take the lead on it… don’t think you need a product manager. 

What I think it really comes down to is the maturity of the team and the ability for the product manager to build context with the team and capacity for the team to understand that context and feel comfortable with it enough to make their own decisions.

One of the top things that product owners on the team level have told me is that, “I don’t have time to work on the strategy because all I do every day is answer questions from the developers.” And if you are answering questions from the developers that often, it means that you failed at your job to build context about what you’re building with them, so now they have nothing to really go off of. So of course, they’re going to come back to somebody and be like, “What am I supposed to work on today?” Because you haven’t given them enough of a vision. 

And that’s why I think companies gravitate towards having one product manager on every team, because now the team’s like, “What do I need to work on?” And the product managers were responsible for that, in the scrum terms, and then they just start putting lists on backlogs that are not scoped. There’s no boundaries around it. 

Jesse: Yeah. I think that context-setting is really important because, to your point, a checklist is not a vision and, it can be easy, for I think the product manager especially, to get into this cycle of just feeling like your role is to be the one to keep answering those little detailed questions.

But I notice that that context, I have found often, has been provided by design because design has described the various features in context with one another, in a holistic experience and experience vision that they’ve crafted and are delivering.

And I think that I find that context a little bit harder to come by for myself when it is formulated less from an experiential point of view and more from a functional point of view, and in a lot of ways that mindset hasn’t really left us, in terms of the way that a lot of folks do their jobs.

I wonder about where the experiential and the functional come together and how you see the role of a product leader versus the role of a design leader in the articulation of that context to help drive those day-to-day decisions.

Melissa: Yeah, I agree. 

I always approach it from an experience perspective. Like that’s just how I figure things out, inward to outward, first taking the point of the user. I’ve seen other people in product approach things from more of a financial perspective to see how the business model works. And I’ve seen people do it from a functional perspective of what are all the requirements in this market that’s needed, or from a market perspective. So part of this, I’m saying, is biased by the way that I think,  compared to the way the other product managers are thinking.

But one of the pieces I see in that is, there is a functional requirement perspective from a product brain that you would bring in, where I’m going, “Okay, this market is characterized by these types of people and this is what the needs are and here’s our product over here, and here’s the gaps of the functionality that’s needed to solve those types of needs.”

One of the things that we would do is, having one of our user researchers, super senior designer, very much in the discovery phase that you’re talking about, when companies were exploring their product strategy and figuring out where to go, should we do what she called deep insights with them, where she would go out and we’d break down your hypothesis together. And we provide the context and the direction around it, and she would go deep with the customers and come back with a synthesis of, here’s where the gaps really lie. And this is what’s not holding up.

So, we’d partner on these two things, then, to go, “Okay, you’re discovering all these gaps. I’m thinking about the financial implications of going after one thing versus another thing, and how we prioritize those gaps.” And then once we get to a good point, we start to synthesize that and then deploy it to the team so that they can surface up what are the right solutions to actually solve those problems that we’ve now prioritized at the top. 

Jesse: One thing that was always a part of our practices at Adaptive Path, and has been a part of how a lot of folks have done this work, has been to use prototyping in some form as a way of validating concepts before you get to a fully-baked product strategy. Before you get to that level, where you’re ready to hand something off to a team.

I’m curious about whether that’s ever been a part of your process. And if so, how that has played out in that dynamic, how a vision gets created and held, in that partnership between product leadership and design leadership.

Melissa: Yeah, a hundred percent. For instance, one team, we’d have a director of product. I think we had three product managers underneath there. And they reported up to a VP of Product in a big corporation with many product lines.

The director of product and the VP of product we’re brainstorming, like, what can we do for our product line to introduce a new upsell or feature set? What’s the problem that we haven’t solved there’s actually a lot of money in? And the product director goes out, and research does a lot of market research first to understand if some of these potential ideas actually hold any water. 

Okay, we’ve got some data saying they do. All right. Let’s bring in the design director. Both of these are now pairing together, and we were starting to say, what’s our customer research hypothesis? Are we going to go out there and talk to your existing customers or new customers to figure out if this hypothesis that we found in the market actually holds water?

Go out and do our user research, right. Come back and say, there’s something here. Cool. Now we’ve got the beginning of business case, saying that if we solve this problem, there’s money here. There’s something that we can actually upsell.

Now, how do we figure out what the solution is? To go say, I need a little bit of money to test this, from the executives.

Now we gotta figure out how to solve it. And this is where the design director might grab some designers and say, “Okay, let’s prototype, let’s start iterating around solutions and testing them out there with customers. And the product director also got four other teams they’re working with overseeing, but they’re spending half their time making sure this business case is really coming to fruition, doing some more research, really helping this side, but they’re also enabling the team on the other side. 

Peter: You’ve explained the process here for product development.  You’ve talked earlier about matters of scrum and agile. And I’m wondering if you ascribe to any common product development process, two week cycles, three week cycles, this, that, the other thing, ‘cause what you described, I don’t know if 

I would say it’s waterfall, but you want to figure out what you’re doing before you do the next thing. And one of the challenges, I think, some UX types like myself have, is my desire to think before acting.

Melissa: I feel like anytime somebody is like, “Oh, I need a week to think,” people go, “Oh this is waterfall.” And that’s just bullshit, honestly. I hate that concept because here’s what I see when people take scrum religiously.

When I was leading a transformation at this company, we had 5,000 software developers and 350 product managers I was training who’ve never done it before. And they had adopted this really strict form of scrum. And they were like, well, we have three-times-a-year releases, and we do two-week sprints. And at the beginning, after the first release, we get a sprint zero, which is two weeks to figure out what we’re going to do for the next three months.

I was like, “How can you shove all that into two weeks?” Like, you can’t do that. And they’re like, “Oh, this is the only time that we can’t be delivering.” And I was like, “That’s dumb.” It should just be an ebb and flow where we’ve got this time;  we don’t know what we should be doing.

We have higher levels of uncertainty. Okay. Let’s go make that a little bit more certain. Now let’s go test, let’s iterate on it. And then when we feel high levels of uncertainty, now we can break that down into an iterative cycle to release it. And I think agile works really well if you have some level of certainty around the solution as the right vision or direction to go after.

I think it’s all about shortening the cycles of how long these take, the mount of time that you should spend in the research phase should be proportional to the risk of what you’re actually building. So if you’re building an entire new business line, like, so you were doing the Apple iPhone, you think Steve jobs gave people two weeks to go, “You figure that out.” Like, no. Right. 

Peter: It’s more like 10 years.

Melissa: Right. So it’s not that they’re spending 10 years in a, “Ooh, let me just do some market research” mode and like check the numbers out there. They’re prototyping, they’re putting it out there and they’re making sure that it’s awesome before they go spend all their money launching it and doing all these big marketing campaigns. 

And I think that’s what people don’t understand. There’s things that companies do internally that you will never know about. They want you to think that it’s magic because that’s their selling point, just observing something from the outside and being like, they just do big bang releases, that’s not how that happens. 

Same thing for agile. You just watched people do scrum. It doesn’t necessarily mean they’re successful. 

Going back to, you were saying about, Where did product management go wrong? It came out of all these companies doing a big bang, agile transformation. And they took all these subject matter experts or project managers, and they said to them, “You’re now a product owner.” And they were like, “Oh, we don’t know what that means.”

And, starting about six or seven years ago, that’s where a lot of my consulting came from. And when people now can look and say, “Oh, there’s no good product managers out there,” they’re looking at some of those places. 

Never been trained. They have no product leaders to learn from. I’ve been in organizations with 2000 product managers and nobody, including senior leadership, has ever done that role before. So, how do you learn, how do you instill a product culture when even your leadership doesn’t know what that means?

And that’s where we’re getting companies, I think, misunderstanding what product management is. There is no value in a backlog jockey. I think there’s value in bringing a partner to the team to help determine what the intent is, like we were saying, it’s just that, I think companies adopted these practices, thinking that it was a holistic, and some of these agile consultancies, honestly, sell it like the panacea of the world.

They’re like, “Oh, just adopt scrum. That’s going to make everything great.” And you’re like, “No, that’s just one piece of it.” Like there’s so many other things that it takes to build great software. And you’re just looking at one piece of it and thinking it applies to everything. And that’s where I think we get into trouble with all this.

Peter: You had a quote in your book that I love, which is, “I’ve trained dozens of teams who are using the Scaled Agile Framework (SAFe), and I have never seen it work well.”

Music break

Peter: Something your question leads to, was a question that we got a little while ago where, there’s this one design leader in particular, who’s like, “I’m working with product owners who don’t know their job. They’re just essentially order takers for someone else. And so now I, as the design leader, have to figure out why we have these requirements, ‘cause I want to build something that people will use.” And this design leader found herself having to fight this internal set of expectations in order to do what she thought was the right job.

So I’m wondering, based on your experience, what have you seen that allows the conversation to change? How have you gotten companies to let go of this dogmatic view of scrum or agile in the way that you’ve been describing and embrace other approaches? In part for those who might be listening to this podcast, like things that they could try within their organizations to push back when they see that things are evidently not working out. But no one knows what else to do.

Melissa: Especially if you’re on a team, a lot of people just feel powerless. They’re like, “I’ve got no pull here. I’ve got no sway. I’ve got no authority to do anything.” I say the best thing you could do is go ask people what they expect to happen from a metric standpoint when you released that, and then measure if it really did, because now you just started a conversation about it.

Usually all it takes is that first question. What do we expect to happen when this launches? And then what timeframe like, do we expect 10,000 users to signup, do we expect to increase retention by 40%? And is that a six month thing or a two month thing? When you start having those conversations, leadership usually goes, “Oh, I never thought about that.” And then people will start asking those questions, which is great. So I think if anybody’s not managing towards those outcomes, just starting to ask, like, okay. Cool. That sounds great. No pushback. See everybody get angry. I used to be angry like this too. I just get mad at people telling me what to do. Yeah. I’d be like, I’m not going to do it. Like, you don’t even know what you’re doing. Right. And that’s not the right approach, although I’ve tried it, so I can vouch that it’s not the right approach. But your approach is more like, okay, cool,  I’m on board. What is this going to do? What do you think will happen? What are your expectations? It’s just gets the conversation going that you can start roll down into those gaps and it makes people more aware of what they’re doing has a lack of intent.

It was funny. I was just talking to another professor yesterday about reframing things. ‘Cause he was teaching it from a sales perspective and he’s like, “Have you ever had to go into a sales meeting where somebody’s asking for something, and it’s not really what they need, and how do you reframe it?”

And I was like, “That’s literally my daily life.” Um, cause everybody comes to me and they’re like, we want to do a product transformation and we want to train all of our product managers and I’m like, “Great. So what have you done to enable that what they’re going to learn is sticking.”

They’re like, “Oh, what do you mean?” And I’m like, “Okay, well, what kind of product strategy do you have going on? Great. Like what’s the most important things that you could be building?” “Oh, we don’t know.” I’m like, “Okay. So I’m going to teach them that they have to look at that first to figure out how they should be scoping down their work and what they could do in line for the goals, so without that, they’re probably gonna come to you. Like I could train them, but they’re going to come to you and ask for that. So are you prepared to answer those calls?” “Oh no.” “No worries. Okay. So let’s work on that first.”

Peter: At some point, you have to wonder how these companies are in business.

Melissa: Well, it’s a lot of them found really interesting problems. It’s a problem that they’ve managed to solve somehow, that’s just good enough for the moment, that people really need it. And they’ve made a lot of money doing that.

If you’re a startup, and you’re starting this from scratch, you don’t have any runway so you are spending the time to get it right, because otherwise you never make it out of startup phase.

If you don’t do the research, if you don’t find that product market fit, you are never making it to the next phase. 

But when you make it to the next phase, a lot of companies are like, “Oh, I don’t know what to do next.” So they just start spinning their wheels. And they forget to go back and do what they did in the startup mode, which is all that research to really figure out and define what comes next. Because I think they panic, and if you hit the growth stage, taking VC money, they’re like OK, you’ve got five years to IPO. And you’re like, “Oh, I’m making $5 million a year right now. How do we get to 150?” And you’re just throwing ideas at the wall, ‘cause you panic and you don’t go, “Well, how did I get to 5 million? Let me think about it. How do I get to 10 million? How do I refactor some of these things and strategically think through it,” they’re like, “Oh, we just build and we just build.” And I think a lot of people associate more features with more money. 

Peter: Well, right? ‘Cause they can assign a value to it. Even if fictional, but they can put them in a spreadsheet.

Melissa: Yeah, I was talking to my students at HBS, they build teams and companies and stuff. And one of them said, “Well, we got like one beta user and I think they’re great and we’re going to build some more features for them. And we’re trying to figure that out.” And I was like, “Why more features?”

Like what – what’s that do. And they’re like, “Well, we just figured that they’d want more features,” “Well, did you ask them about the features you have? Like, are they using those right now?” They’re like, “Oh, we didn’t actually think about that. I just thought if we had more features, we could charge more money,” and I’m like, “Oh, so for like, what’s the core problem you’re solving, right.”

“Well, yeah, that’s right.” Okay. 

And then they take a step back and they go look at it. But I think we kind of adopted that mentality at scale that more is better, more is more money and doubling down on your core problem that you solve and making that really awesome gets lost in the sauce.

Jesse: Yeah, it feels like if prioritization is going to be such a huge part of the value that you deliver, you have to build up your own prioritization filter for yourself. That’s what you need to be able to bring to that. 

Melissa: To me, like, what you were saying, just that the prioritization framework is product strategy. And when I get a lot of product managers who go, I don’t know how to prioritize those things, because you’re missing that product strategy. And a lot of people go, “Oh, our product strategy, we know where we want to be in five years and we know what we’re doing tomorrow.” And I’m like, “Okay, but what’s in the middle of that. Product strategy is that thing that connects that longterm to what are we doing right now? And what do we have laid out for the next two months?

That’s the piece of the prioritization framewor that’s almost always missing in every company.

Jesse: You’ve mentioned research a few times now, as one of the key drivers of that prioritization for you. I mean, obviously the business concerns are there. But I’ve heard you talk about research a lot more than I think I hear most product managers talk about research informing their decisions.

And I’m curious about what you see as the ideal relationship between product management, research, and design as design and research are often very closely aligned, but it sounds like research needs to be driving product management at least as much as it’s driving design, if not more.

Melissa: Oh, a hundred percent. Yeah. I don’t think you can make decisions without understanding what problems your customers have or where you fall short right now. And I don’t think enough companies spend that time really getting into that. If I was going to build a team from scratch today, the first hire I would do is a user researcher.

When you’re a product leader, you don’t have time to go out and do that yourself, So you have to build that relationship into your team and that role to make sure that you’re getting the insights.

I always look at it as, you’re taking all these different inputs and synthesizing them into a direction. And it’s not necessarily synthesizing it into a solution, it’s synthesizing it into a direction. And that’s the intent. 

So I’m looking at qualitative user feedback. I’m looking at usage data. I’m looking at business financials. I’m looking at revenue, cost drivers of what our current products are. Yeah. Or we’re spending money and where we may need to shift spend. I’m looking at trends in the different markets and competitor analysis, and I’m taking all of that information and I’m synthesizing it into, Where do we go next? 

And that’s not, Where do we go tomorrow? That’s where do we go for the next six months? Where do we go for the next year? And that’s that missing middle piece that’s usually gone from companies, to connect the strategy back into what are the teams doing on a day to day basis.

Peter: One of the challenges I’ve seen is, as companies grow, they have product teams. How those teams are defined will vary by company. Sometimes they are actual products that they’re putting in the market. Often they’re different aspects of some larger service experience. If you’re Lyft or Uber, you’re going to have multiple quote “product teams” working on the rider experience. There’s not real products there. It’s all one product. but, you can’t have a team of 200 trying to work on one thing. So you break them up into teams that are able to kind of digest the work. 

And so these product teams get siloed, they focus on what’s in front of them, their metrics, good product teams doing it the way that you would recommend, in terms that they know the outcomes they want to drive towards, they’re doing experiments to get to those outcomes, et cetera, et cetera. 

And so I’ve seen the role of design to almost run contrary to that siloed product organization and have design really just live across the experience, so that designers aren’t quote “embedded” in product teams, designers are responsible for some end-to-end experience and they intersect and interact with these product teams that necessarily have to have their focus in order to do their job. I’m wondering how you see that relationship between the focus of the delivery of these teams that needs to deliver, especially as these companies grow, these end-to-end services that can get quite hairy and complex.

Melissa: Yeah. I’ve worked with companies that were that way and then I’ve seen it organized more through product lines. I think it depends on which type of products you’re building. Where you’re talking about, it seemed to work super well in the services type businesses that you’re talking about.

I’ve seen other places where it’s not a huge user journey all the way through, and you can break the teams up around jobs-to-be-done. These teams are probably not seeing super specific scope and it’s not so technically complex. The team is almost an experience team, rather than a technical team. 

I find when we do org design with product managers, they typically look to put them around, major jobs-to-be-done, around different products, and if feature sets get too complex to manage, we’ll start to break those jobs up into multiple teams to solve it. 

So if you go into each one of those jobs-to-be-done, are those different feature areas? And designers building for that. They’re not necessarily impacting everything across the area, but when you have a totally intertwined journey, where your products plug into that journey, that’s where I see design sitting across everything. It makes total sense.

Jesse: What do you wish design leaders understood better about the role of product management? That if they did understand it, it would improve their relationship with product managers.

Melissa: Ooh, that’s a really great question. I think one of the things is, how much the other systems come into play in making a successful solution. That it’s not just about getting the screens right and experience right for that perspective. That is a piece of building a successful company.  I teach a CPO accelerator group for product leaders trying to become executives. And I was just telling them, your job is no longer just the success of your product at that position. It’s the success of the company. And I see that’s the tension that a lot of people get into with design leaders too.

I think it’s any leader who’s not seeing themselves as beholden to the company’s success, not just their individual solution or their individual feature success or their product success. And I think when both people are in that mindset, the product leaders, the design leaders, they’re both like, I know I will have to make trade-offs with parts of my design to meet the business’s needs, but I also will sit here and advocate for the customer as well, but I’m not going to be unreasonable. I’m going to work with everybody through this because I know it’s best for the company. That’s where I see these relationships work. And I say that, too, to my product managers for salespeople, because product and sales butt heads like crazy.

I’m like, okay, now you’re an executive. You gotta go sit with that VP of sales and know there may be a feature that you weren’t going to plan. But eventually you might have to bump that up just to make sure this company can survive. If that’s the thing that it really takes, we have to be willing to work with that.

We don’t get to operate in a perfect system. It would be great if everything was perfect and we didn’t have to worry about money, and we didn’t have to worry about anything. We build awesome products that people love and not have to worry about the implications. But, at the end of the day, the company has to survive. Otherwise we won’t get to build anything.

Peter: Thank you, Melissa, for joining us. This was great. I actually learned a bunch, and I suspect others will too. So we’ve talked about your book, Escaping the Build Trap. We’ll make sure that everyone knows about that. Where and how else can people find you?

Melissa: if you want to check out my website, it’s MelissaPerri.com. I run a company called Produx Labs as a consultancy, and an online school for product managers that teaches them what to do that’s not scrum, um, productinstitute.com. And I now have a new class for executives where we’re teaching them how to build great product strategies and really move it to the C suite, at cpoaccelerator.com.

Peter: When, when do you sleep?

Melissa: Never. I was up at like four, o’clock this morning. ‘Cause I was like, I have so many ideas! 

Peter: I, yeah, I was just, I was getting tired, just hearing of all the activities and professional things that you’re doing. Well, that’s awesome. So again, thank you so much for joining us and, take care and see you on the internet.

Melissa: Thank you.

Jesse: As always Peter and I want to hear from you. You can find us on LinkedIn. You can find us on Twitter. He’s @peterme, I’m @jjg. You can also find us on our website, http://findingourway.design, where you’ll find an archive of all our past episodes and full transcripts.

We’ll see you next time.