The Not Unreasonable Podcast

Melissa Perri on Escaping The Software Build Trap

July 28, 2019 Season 1 Episode 39
The Not Unreasonable Podcast
Melissa Perri on Escaping The Software Build Trap
Chapters
The Not Unreasonable Podcast
Melissa Perri on Escaping The Software Build Trap
Jul 28, 2019 Season 1 Episode 39
David Wright
Melissa Perri on Escaping the Build Trap
Show Notes Transcript

This episode is about how to build an organization that itself builds great products, especially great software products. I am absolutely not exaggerating when I say that this is the most important and under appreciated topic in the world today. It will some day be impossible for a company to thrive without these skills and we as a society are still figuring out how to organize human enterprises into productive software-making machines. It does NOT come naturally and I believe Marc Andreessen when he says that software will eat the world. 

That means that if your organization doesn't learn how to produce great software it, too, will be eaten and you along with it. 

Melissa Perri lives at the cutting edge of software process design and runs a consultancy devoted to building great product leaders. This of course applies to non-software products but the day is approaching when there is no such thing as a non-software product. Listen to this episode and continue on your journey to being a better producer of software, either as a coder or as an enabler of the programmers that build the products your company sells!

Thanks for listening! Show notes at notunreasonable.com

Melissa Perri:
0:00
Banks are pretty similar in the way that they structure. And it all comes down to like that they don't sell a software product and they think that when they think about products they are like, oh no, no, but that's the business side, not the tech side. You got to separate them. More and more those things are one in the same because you can't really ship a valuable financial product without having software that actually helps you scale the delivery of it and better that for the customer experience.
David Wright:
0:25
Welcome to The Not Unreasonable Podcast. I'm your host, David Wright, an actuary and reinsurance broker. This is a show of interviews with people who have something to teach us about managing our businesses and ourselves. There's a lot to learn out there folks, so let's get to work. This show is brought to you by Beach where I work and have worked my entire career. We are a global reinsurance intermediary and we pride ourselves on creative thinking, deep analysis and client service. Those three qualities are actually intimately related because you can't spend the energy digging deep into a problem unless you really care about the client. We find that when you really do understand the problem, the solution becomes obvious even if it seems a little bit unorthodox to the outside world at first. The nature of insurance is to take solutions we know and trust and try to force them on to the problems of the day. We just don't settle for that. You can see further at beachgp.com. If you're an actuary, you, like me probably dread the professionalism continuing education requirement. I think that the best time to satisfy this is in podcast time while on your commute, while walking your dog, while mowing your lawn, while doing the dishes. Head over to notunprofessional.com where for the price of a CAS webinar, you can get content dedicated to Continuing Education for Actuaries, especially professionalism CE. That's notunprofessional.com. Thanks for listening and thanks for supporting The Not Unreasonable podcast. My guest today is Melissa Perri, CEO of Produx Labs, a consultancy that advises companies on becoming product-led organizations. Most of its focus is on software products but I think the ideas here translate much more broadly. Today, we'll be discussing products, product management, and Melissa's book Escaping the Build Trap: How Effective Product Management Creates Real Value. Melissa, welcome to the show.
Melissa Perri:
2:30
Thank you. It's good to be here.
David Wright:
2:31
The core insight in the Build Trap, my words tell me if you agree with him, is that a company's focused on the wrong metrics when evaluating their own performance. So what are they measuring and why is it appealing to them to measure things like this? So it seems to me that there must be somebody who wants to fall into the Build Trap, otherwise nobody would fall into the Build Trap.
Melissa Perri:
2:48
I think what really happens is that, as you scale companies, like when you start off as a startup, you're going, "What problem am I solving? How do I create value for my users?" And you're really focused on value. And you can't survive if you're not. Honestly, they go out of business really fast. As you scale and you get more money, you've got a longer runway. And this pressure to deliver really gets on you and it goes all the way up until you become a corporation. In corporations, it's not survival mode. It's more of like ship, ship, ship ship so we could deliver more value. And what happens is these organizations start to think about quantity. Like how much are we shipping instead of like quality and what value are we actually providing? So we get this misconception that the more products we ship. The more software we put out there in the world, the more value that we're actually providing. But that's not actually true.
David Wright:
3:39
Where's the original scene? So one of the things we talked about, well, just before we started the recording of the conversation was that there's definitely a difference in finance circles, in their perception of what's going on in software companies. There are different disciplines, yet the finance people come to own a lot of software organizations and software processes. Is it just that you have, let's call it a plurality of views of how to run a company and maybe the wrong people are influencing the wrong decisions? Is this simple as that?
Speaker 1:
4:14
I think that's very true of where it is right now. If you look at it like the very large corporations that are making these digital transformations they call them these days, you've got companies that were not originally software based.They've been around for hundreds of years, 40 or 50 years. Software was never how they scaled. Instead, they scaled through services and through people to deliver the financial products or the insurance products or whatever you sell. And at its core, what they sell is not actually software, it's a credit card. It's a car insurance. It's these different things that are not actually software. If you look at Google, like what they sell, it's actually software rates based on that. These two types of companies where it's software based and non but software base coming up in different times in different ways. And the companies that were not software based are realizing that they can't keep up with the ones that are software based in innovating on top of them because they can scale so much better and so much faster to get delivery of value out to customers through software. So now they're going, "If we want to compete, if we want to be innovative,." The whole world lives online now. Like you've got your phone in your pocket and that's how you want to manage your credit card. You don't go to banks anymore. Everybody wants to live on the Internet. So these corporations want to like keep up with that. They have to figure out how to innovate through software. And I think that's really where it is today.
David Wright:
5:36
Well, one thing that came to mind as you're talking there was how similar the pitfall is, which is, is there something inherently distracting about software? So think of it this way. So you were saying there that organizations were used to delivering value to customers without software, they aren't software companies. But one of the really important observations I think that you made in the book is that even software companies aren't really software companies. The whole point of your intellectual framework here is that you're not focusing on the software, you should focus on the value which is something that I suppose these enterprises lose sight of when software wanders into their view.
Melissa Perri:
6:10
I think so. Google doesn't sell software, they sell the ability to search. It's the value that you get at the end of the day. It's a method that they deliver that in is through software and that's why it scales really nicely for them.
David Wright:
6:23
So what should a software company measure?
Melissa Perri:
6:26
It should really be measuring the value and the outcomes that help drive the business. So when you think about any kind of organization, there's customer value and there's business value. And what really drives business value is delivering the customer value. So the business value, that's making money.
David Wright:
6:43
Someway it's easy to measure how you're making money, you've revenue.
Melissa Perri:
6:46
Or do you have revenue? Are you growing? Are you saving costs? That's also an important part of it.
David Wright:
6:53
For your clients you mean or yourself?
Melissa Perri:
6:54
For yourselves too. So that's how you scale your business. They should be measuring things like that, which is good. And a lot of them do measure those things. But the trick is like connecting that back down into what do the teams actually do on day to day basis? And that's where they fail. So a lot of places will go, "Oh, well we shipped 20 features last quarter, so we're doing really, really well."
David Wright:
7:16
We can measure that.
Melissa Perri:
7:17
Yes, we can measure that.
David Wright:
7:18
You got them up on a spreadsheet.
Melissa Perri:
7:19
Super easy.
David Wright:
7:20
Twenty, big number.
Melissa Perri:
7:20
It's like, "Just count." It's so easy to measure. And then you go, "Okay, so what did those 20 features do?" Did they make more money? Do you have more people signing up? Do you have like less people leaving, which are all the things that actually drive a business. And a lot of times they can't really pull back those outcomes into those features that they ship. And that's because they're focusing more on shipping than actually what they're shipping those features actually do.
David Wright:
7:46
How do you measure that because this can be a very, very difficult problem. And the reason why I think you backslide into this Build Trap is that whatever management of the organization can't figure out how to measure anything else so they can features ship. You've consulted these companies, what do you suggest they do?
Melissa Perri:
8:02
Actually, it's not so hard to measure them. So a lot of times it will be difficult to make a one to one prediction. And there's a lot of bets that you actually have to do in software when you're building anything. Like if you're going to launch a new product, even if it's not a software product, you got to take it a little bit of a bet. And what you have to do is gather all the data that's possible that you can get to show you that it's lower risk. Like show you that you're on the right path, you've lowered your risk by gathering these data. And that this thing is pretty likely to result in what you think it will result in.
David Wright:
8:34
So you're making your prediction? You're saying, here's what I think is going to happen.
Melissa Perri:
8:39
Yes, and then what you do is you test it. So then you put it out there and then you measure it and you make sure. And if it's not going the right way, then you iterate on it. So what organizations typically don't do at scale, which makes it hard to measure these things is that they don't have a systematic approach to connecting those topline business metrics or bottom line business metrics, it doesn't matter. But down to what the teams are doing. So they're not going like, I believe if we launched this feature or we create this new business line, or we do that, it will result in these outcomes for the business. They're not really connecting it there and they don't take that all the way down into the teams. So for example, if you have like a team that's shippinga dashboard for users, like what do you think that dashboard is going to result in? Do you think it's going to drive them to take more actions in your platform? If it drives them to take more actions in the platform, what does that result in? Are you creating revenue through the actions that they're taking? Are you retaining them because they're using the platform better and they're getting more value for it? Like what do those things actually relate to at the end of the day? And you can measure those with different methods. There is quantitative methods that you can look at to really pull in, are people using it? So you've got products that are coming out like Amplitude and Pendo that show you people are actually using things and taking the steps that they want to in your product.
David Wright:
9:57
Using your software.
Melissa Perri:
9:57
Using the software. So that's telling you like if people are using it or not. Then you can go do follow-up with the qualitative research of, do people actually get value from this? People are already measuring retention in these companies. Like how long do people stay with us? Do they leave? You can start to measure that and see are people tending to leave sooner than we thought after we released something? Are people churning? All these metrics go into really making a healthy ecosystem of the right products that we're building. And those are the things we should be measuring making our decisions off of. It just takes a little bit more effort to actually measure those. Did we actually ship something?
David Wright:
10:31
Well, just drawing as I read in the book and thinking about this, I was trying to figure out what's the common denominator amongst all products. And feature is an interesting hypothesis possibility for that. So you can measure it and every product's features has more features. The link gets broken here, but presuming for a second, the more features the better the product or rather put it differently. The more features that are used, the better the product. And so the skip there is between usage and not. And so maybe they're kind of atomic unit of value in software is people's attention. Are people paying attention to this feature and using this feature and that if there's a way to aggregate that and roll that up. Am I on the right track there?
Melissa Perri:
11:13
I think so. The way that I look at it, you have different features inside the products. Now a feature may not be packageable and sellable in and of itself. So that's why we have products. So features are part of a bigger product. So if I were to sell you like a keyboard on your phone, that's not enough for you to do anything. The phone itself is a whole product. That's what makes it valuable. So you have to package that and put it out there. You can release different features that will enhance the value of the overall product but the features themselves won't be able to stand alone without the wrapper of bringing them all together. So it's together in the right combination of that solution that makes it really valuable for the product. Now we measure the health of products by looking at definitely usage, but usage is a leading indicator that people were actually paying attention to your product, which is right. But then what I look at is how many people are actually coming into our product and then how long do they stay with us? And the retention part I think is a gold mine of most products. Unless you are, you know, I'm trying to even think of like an example of a company where you don't want people to actually stay with you. Like you can do--
David Wright:
12:25
It's sounds for example your organization. So this is weird. But your job is to train leaders and then release them into the world.
Melissa Perri:
12:31
That's true.
David Wright:
12:31
So you don't want return customers that means it didn't work.
Melissa Perri:
12:34
Yes, we want them to come back for like things that they might need later. But if we've done our job well, we want you to be running really, really well. So we are designed. I guess we're a good example. It's like, we want you to come back for different things, but if you're coming back for the same thing over and over again--
David Wright:
12:49
That's a problem.
Melissa Perri:
12:50
That's a problem. That's a good one for consulting. I think the for some products, sometimes we get into a misconception of attention versus time. This comes up a lot. For example, if you have like a very utility software, for example, DMV, renew your license. You want somebody to be able to renew their license in five minutes and be done with it. You don't want them to spend 20 hours on the site. And a lot of times people will look at how much time people spend on their products instead of can they accomplish the thing that they want to do.
David Wright:
13:28
Yours is more in that case.
Melissa Perri:
13:29
Yours is definitely more. For anything that's like a workflow app or utility app that's in and out, I just want to accomplish my task and move on.
David Wright:
13:36
I think part of the book that I found most interesting was embedding observations about countrary in customer value and the difficulty of integrating that into a whole org structure of a company. So how does, let's call it a senior level executive, know that their teams are and obviously over a longer time spans revenue is going up from this profitable. That's great. We got that. But so let's say you got a board meeting or whatever or recorder and they're asking me how you're doing, what did they say? Where did they point to?
Melissa Perri:
14:06
So this is a big thing that we've been doing with a lot of the companies that we work with and we call it product operations. And I've done a lot of large scale transformations in corporations and there seems to be the missing link. Like we go in and we train all our people and how to do things. The leadership stuff will put the strategy in, but then nobody's actually measuring it and looking at the progress. So when we think about product operations, there's a bunch to it, but there's one key piece that's called data and insights that we do. And what we do is we go and we pull all the stuff that people are doing together and talk about the outcomes and put it into dashboards so that leaders can look at it and say, "Okay, so last year or this year this was the strategy for the company. These were our big objectives that we really to hit, I call them strategic intents. And the strategic intents in our strategy framework are very much like business focused objectives, like returned to a growth stage company or increase our margins to like 80%. It's very tactically focused. It could be also we want to enter a new adjacent markets that will increase our merchants or like help grow us, stuff like that. So it's very big business decisions. Usually market facing different customer segments.
David Wright:
15:20
Something that finance guys can understand.
Melissa Perri:
15:23
Exactly. Some of the finance guys. So if you tell that to any leadership team, there'll be like, yes, that's what we want to do. Or this is how we want to differentiate ourselves from competition, like very focused high level there. Then the next level underneath that is called initiatives. So that's where we start. We look at the strategic intents and then we say, okay, let's say that we want to go into this new market to start to diversify where we sell and we want to grow our business and it leads to revenue growth. How do we do that through the software we have? Do we have to create completely new software and platform? Can we repurpose some of the stuff we have? We just have to fine tune it for this different crew. And those become the product initiatives. So they're higher level goals that we want to hit and things that we want to accomplish in order to reach those strategic intense. So now we're connecting the business down to what do we actually have to do to get it done. And then the teams break that down even further into something more tactical and more short term. That's like, okay, if we want to accomplish our product initiative, we're going to have to do x, y, and z to build out the software and release it and that should get us there. So then each level of that strategy has different goals that are associated with it. So you would probably have leading indicators which is what I call goals that will show you that you're getting to the higher level goals. Like you can't really measure the revenue until you launch it. That might be six months out. But there's leading indicators that show that you're on the right path. You can have a Beta test, you can get adoption in the Beta test, you can measure people doing retention on it which means like you just release it to a smaller segment of people and make sure that they like it. So you can do all these things shorter term faster to show that the bigger goals are on track. And what we do in product operations is we go about and connect all those activities together so that you can look as a leader at it and say, okay, we are on track to launch into this new market. We've shown that through Beta tests, 500 people adopt it. The comeback, frequently. They're retained with us. We've gone out and done research with them. They're very, very happy with it. They want more. They want to sign up more people, they want to send out more stuff. And that's showing that we are on track to reach these goals. So it's about like really connecting it through the organization and rolling up the stuff we're doing with the teams into revenue and costs matrices on top so that the leaders can look at it and start to make decisions.
David Wright:
17:42
So what does the company do before reading your book, before setting up product operations team, just as an aside, as I'm listening to it, the thing that's coming to mind for me is, boy, it's complicated. There's a variety of metrics you have to pay attention to. You have to have an event once and then measure them and then communicate them back up again. So there's a very intensive amount of work to do there. And of course you are suggesting that organizations should have an entire group of staff that are dedicated to only that. So that makes a lot of sense. Imagine resource you need there. What does a mcompany do without that? Is it just the count features? Is it simple as that? When you're walking into an organization you consult for, what do you tend to see?
Melissa Perri:
18:19
I see a lot of bad things. If it's a very large corporation, what they typically do, is silo off technology into its own department. Sometimes that's under like a digital transformation office or it's under an IT office or it's just hanging out over there. Like it's over there. And then the business is over here. And I asked them like, how do you plan your strategy? And they're like, "Well, the business plan is a strategy and then they just tell us what to build." And that's almost always what happens. It's 99% of the cases that I see. And what's happening is those corporations are not thinking of software as a strategy. They're not seeing it as a way to deliver more value and tie it into the business. Like the way I think about all those corporations, that were not software based and have these financial instruments or these insurance instruments or whatever you sell, is that software is a wrapper around it that helps you deliver that solution in a better scalable way. So it's easier to deliver value to your customers. You can now do things you couldn't do before with humans with it. Having AI in there to predict what people do, make it a better product, position it better for people. Make it easier to access your account and make you pay your bills. Like you can now surround each one of those products with a lot of technology that helps deliver value and produce value more for it. But when corporations separate that, they don't see that.They look at it as, like this product is the business. It's the product that we sell and software is just the way that we can plug in and ship it or sell it easier. They're like, well, I would just sell it this way. And they don't connect the strategies of the two and they don't think about them as the same thing.
David Wright:
20:02
So let's say the first call they make isn't to you, so different consultants who walks up and says, Agile can solve your problems. So let's get these integrated teams together. Maybe describe it a bit about what that kind of advice might sound like and what your criticism is of it.
Melissa Perri:
20:15
This is something that's happening everywhere right now. Agile transformations, since I started consulting about five years ago. And before that I saw this too. But I Agile transformations were all the rage. What Agile does at ts core is basically helps connect the business and technology right in two teams but its very team focused, it's not organization focused. So the whole premise was we're going to bring people from the business into the teams with the developers so that they can iterate faster through the product, understand the requirements better and ship things faster.That will actually satisfy the customer.
David Wright:
20:55
The Scrum teams.
Melissa Perri:
20:55
The Scrum teams. Well, it doesn't really matter. So like Scrum is just a flavor of Agile. There's also like extreme programming too. So Scrum is the predominant thing that everybody uses. So a lot of times people think Scrum Agile, same thing. It's not. but agile is more of a philosophy and a way of working that's about bringing the business and technology together. And I don't think that's opposed to anything that we do with product management. But if you look at how people practice Agile and the different flavors that came out of it, Scrum XP and like that, it's very tactical about how do we get the work done. It's very focused on development.
David Wright:
21:29
Shipping features.
Melissa Perri:
21:29
Shipping features and it's about the rules that you play in that team to bring people together. It's not about how are we building the right thing. How do we ensure that we're building the right thing? It's got very little to do with business strategy, technology strategy in the way that it enhances it. It's very much about how do we get our work done in a faster way. So when people go through Agile transformations, what they do is they fix all the teams, but they don't fix the system in which the teams live. So still, you get the same thing at the end of the day. Like you might be shipping features faster, but you're not connecting the good work that those teams are doing backup into the business strategy. And that's why Agile transformations are like going Agile. It's just not enough. The philosophies in the organization are good. Like what they bring to the organization about getting value out faster to customer, satisfying the customer. We're bringing business and technology together. All those things are great. In practice, people don't make the full transition. They go okay all of our software teams now have like a product owner on it and we're done. And that's not really what's needed. You need to connect all the things that you do from the business down into how do you deliver it through technology.
David Wright:
22:35
There's one interpretation of that whole framework. And at the beginning maybe it's was, I don't know, some part in your book, I was feeling a similar sentiment, which was the knowledge of the customer lies with the bottom rung of the organization, like the customer facing portion of it. And that kind of feedback is incredibly valuable. Now, what's interesting to me about your call evolution of the framework is that actually the people at the top do have value too. And so the organization is something more than a bunch of descend bodied Scrum teams or whatever the team names are who are close to the customer. They're able to build the features but there is an integrating component which is necessary still, which can get overlooked. So what value does the strategic intent give to the teams if they can talk to the customer and say, if a customer wants this, I understand what they want, I'm going to build it. Who else needs to be involved and why?
Melissa Perri:
23:24
So what strategic frameworks provide is direction. And this is the biggest gap that people get into when they think about autonomous teams. So Agile does promote autonomous teams. I think autonomous teams are good. The problem is they don't give them any kind of direction. I've been to companies that have 4,000 Scrum teams. If you look 4,000 Scrum teams all individually and never consulting with anybody else, make up their mind about what to build, you're not going to have a holistic company. Like there are going to build everything. So when we think about autonomy of the teams, it's not that they've just decided everything about what to build, it's more about you give them enough direction to send everybody in the right direction. And at the leadership levels you have to make that choice. And every time I come into work with the C-suite of these, like these organizations, even as big ones, they say, where do you want to be? Like, what's the plan for this? You've doing the same thing for 40, 50 years. Like what's the next phase? And the next phase can't just be, we're going to be digital. That's not a vision. How are you going to compete with these companies that are coming up out of startup mode and taking a lot of market share from you. They don't scare them right now because they have a lot of money, but give it, give it 10 years, give it 20 years. People are going to be searching for something that is easier for them that really matches them better. And these companies can innovate faster because they're smaller, they're more focused and they have very good direction. So corporations need to put that direction. And that doesn't mean that we are all only working on one thing with 5,000 Scrum teams. It means that we're balancing a portfolio that can look after the stuff that we actually have going on. They're doing well. So maintain what we currently have. Take that and start to differentiate a little bit with it, build new products on top of it and then innovate. Build things that we will get us to the next seven years, 10 years in the future. So we're actually exploring that. And that's what Amazon does really, really well. Amazon doesn't do a million things well. They don't have a great corporate culture, but they do really do portfolio management super, super well. And that's where you get things like Alexa because they're looking at how do we differentiate ourselves? How do we innovate, right? And they make a point to have teams that go out and explore those different areas and they test and they learn. So leadership has to make the decision that they're going to invest there. So they're in charge of setting like the vision for where the company is going to be. Are we going to keep doing what we're doing? Are we going go on a different path? What kind of path do we really want to take as a corporation. Like why are we here? Why do we show up to work every day? What's the value we're actually going to produce here? And then what they have to do is start to think about how do they want to invest in that plan. So do they want to spend 60% of the budget that they have, maintaining products and 40% looking at new innovation? Are they doing 80% to maintain the current products? Most of the companies that I see in these corporations, 100% of the money doesn't really go to innovate. Like it goes to maintaining what they already have. Nobody's looking at innovation. Nobody's figuring out how to pull that in or they'll set up like little startup teams that are kind of like separate and nobody really figures out how to include them into the strategy.
David Wright:
26:30
So I think that one of the main vehicles for integration often the bigger companies is the budgeting process.
Melissa Perri:
26:36
Exactly.
David Wright:
26:36
And you think about what is ultimately the source of control for the senior management organization is that they've got the money and they can give you the money and they can choose to give you more or less money. And you have some interesting ideas on budgeting and I wonder if you could talk a bit about what you think an improved philosophy of budgeting could look like for a large organization. Because if they're not telling somebody exactly what to do with the budget number of attached to it, in other saying, you guys, as long as you satisfy these objectives, go figure it out. It's hard to put a number to that. How should they think about that?
Melissa Perri:
27:06
To me, if you push us back into goals, what happens is we typically fund teams at the lowest level. We fund projects. So most of the accounting in corporations is done like a project basis. So there's usually a project management office. People have to come and put like a together an entire business plan about what they're going to build and why they're going to build it. I've seen those things get made in like a day. I'm like, how could you possibly know that you're going to spend $20 million on this thing and that's going to go exactly to plan. And you just came up with this strategy in a day.
David Wright:
27:38
Because I had to. I had no choice.
Melissa Perri:
27:38
That's what they say. And I don't blame the people who do that, that's just a product of the way that they--
David Wright:
27:44
The system.
Melissa Perri:
27:45
The system. So then they bring all the business plans together and then they were like, okay, we'll fund that. We won't fund that, we will fund that. And then they fund it very much into the deliverables. You build me this feature, it costs me $30 million. Go. Like that. So the problem is it's pretty unknown. They're usually not tied to goals. We don't really know what we don't know. So if you haven't tested it with users yet, how do you know that's even what they want? So we're making guesses. So a lot of budgeting processes are made off guesses.
David Wright:
28:16
Well, you have two ways you can work on that. So one, you pat it and say, I know there's an error margin here, and so let's just sandbag this sucker or you go massively over budget. So whenever, both the same time.
Melissa Perri:
28:26
At one financial institution I knew the CTO. It was a very large corporation. He actually started as like a director of engineering and he worked his way up to being the CTO of Europe and Americas because he was so mad at the budgeting process. And what he found was that his team would get relegated, a couple million dollars to build something. And they would realize that they don't need all that money to actually build it. But the problem is if they didn't spend all that money that year, they would never get that much money again or they only look at what people spent in the past to figure out how to budget for the future.
David Wright:
28:59
When we do next year? What we did last year?
Melissa Perri:
29:01
Exactly.
David Wright:
29:02
I've seen it.
Melissa Perri:
29:03
And so they're like, well, we could've saved $5 million this year of our project because it just didn't take that much money. So let's do that. And they were like, oh no, let's just go spend that $5 million building a bunch of random stuff just so we can get $5 million next year too. This happens everywhere. And what should be happening though is more of it's breaking them up into systems of first of all, is this in discovery mode or delivery mode. So we're looking at that. We're looking at the different projects and the initiatives that we're doing. Instead of funding the projects that we're doing, fund the product. So if you are in a credit card division of a company and you are looking at the travel notifications or the notification products, the fraud department. Like what are you going to give the fraud department in the credit cards. Like what can we improve there? What's there? And we have to get ahead of that strategy before budgeting season actually does begin and come back with a plan in that fraud department that's like, here's some questions we need to explore, but we're not sure if we should actually build a product from it. That's discovery mode. So we want to give those teams some funding. Like little bit of funding so that they can go prove if that's something that we should actually be doing. Then there's things that we're like, we know we need to build this because we have all this data and we've actually proved it. Those ones you could say, let's take this funding and do it. But if you fund it at a higher level, if you say like, we're going to give the fraud department $20 million this year, now you can change course a little bit in the different projects in the teams as you go because you can start to see if it's working or not. So if the discovery mood gets into delivery mode, you're like, okay, have a couple more people go. And instead we do it by project. So if that project fails or if the project is not the right thing do, we have to keep going with it instead of funding it by products. And Agile does promote stable teams as well. So you have stable teams around the product and you're putting them around the product and they own that. And when you do that, instead of funding people by projects, you get one better delivery because people know how to work together. There's some known knowns in there, if your find their process like they're really good at, they know the product better too. So they can work a lot faster and keep people in those teams. Of course, you mix and match a little bit to give people variety but like you relatively keep those stable around the products. And then you fund those products. And then the person who is usually like the director of product or the VP of product let's say and the VP of engineering, they get together and they start to figure out how do we relegate this money. How do we delegate it into the rest of our teams, to fund these projects. So there's a big thing going on right now about like innovation accounting. Janice Frazier has done a bunch of work with that. I saw everybody on Twitter trying to turn to get her to write a book on it because this is one of the biggest questions. And I think a lot of companies have all these questions about like capex versus opex. How do we do that?
David Wright:
31:57
Because you could run out. Let's say you see this many projects, discovery projects. I do want to talk about that because it gets really interesting to say about that. But if they all turn up green, then it's like, well, kind of out of cash. That can happen.
Melissa Perri:
32:15
And then that comes down to prioritization. What should we build now versus later? So it's not about funding everything. I think we look at organizations and we're like, must fund everything that comes down to prioritization. That's what leaders do. So the leadership, when we look at prioritize what's more important to do now versus later. Sometimes I think organizations too have so much money that they have to spend, that they do everything and they're better off if they did less. Honestly, I will say that like, they're probably better off if they did less because some of the decisions they make to spend that money are not the right decisions or they just look at like, how do we spend this cash as fast as possible. And that's a really good problem to have. I wish I had the problem. But it still is you get into this habit of doing everything instead of just what's the focus and what's the right thing. And then you lack focus around the company. And that's what I see is like the enemy of everybody's strategy. Like if you go into these corporations, you ask everybody what you're doing and why you get a million different answers from all over. And then that's where you don't see the product being shipped that are actually going to drive revenue or lower cost.
David Wright:
33:25
And that is the value of leadership. So back to the question of what do Agile team's missing? I think that big picture leadership might be a way of encapsulating the answer. I think we're running out of time here. We're getting close to it. But I wanted to talk a bit about, maybe a few more minutes. So I wanted to talk about product management itself because it's part of the book. And the way I want to get it in there is to talk about your definition of a minimum viable product. Maybe talk a bit about kind of a general conception of what that might sound like and your refinement of that term.
Melissa Perri:
33:58
So the way that I think about minimum viable products really comes from more of a lean startup mentality. And that's really where I learned. And the minimum viable product was basically the smallest amount of effort that you could do to learn. So that might take many different shapes and forms over the course of validating your product. It could be starting with like a survey or starting with a prototype of something. Experiment. I love experiments different ones like concierge, but it's basically how do you deliver the value and get some feedback that you're on the right path. And as you work up to really testing all your hypotheses earlier, then you start to turn it into code. And then it's about the smallest shippable product that you can actually get that's in software. But the beginning part of it can be all different ways to test and learn. So it's a process of really testing and learning and getting there. Most people think of a minimum viable product as like, what is a small set of features that I can build to ship out a product? That's a late stage MVP to me. Because you still can do many different things to learn from your customers. I see companies do this actually all the time. Like they don't realize that they're doing this, but many, many companies will want to release a new product out there, but they just can't build up the software in time. So what do they do? They hire a bunch of people. So they'll open offices in India for people to process all the documents or do the faxing. All things that they want to automate one day, but they hire a bunch of people to do it in the meantime while they figured out how to scale or validate that or do the software. To me that's an MVP. And it doesn't mean that an MVP is like super cheap, it costs a dollar. You're going to have to invest money into doing that, but what it allows you to do is iterate quickly and you're not investing like $500 billion in building this product and then finding out that it's not good.
David Wright:
35:48
With long lead time.
Melissa Perri:
35:48
It's a long lead time. So you can start delivering value immediately learning about it. And then you start to automate things away. And I see a lot of corporations do that by nature. They just don't realize that they're doing that. And what they do is they never get to automation or they never actually get to the software pieces of how do we automate this? How do we make this faster? How do we make it streamlined? And that's usually the enemy of where they fail.
David Wright:
36:10
So talk to me about testing. So testing is such an interesting concept and I think maybe the deepest, most underappreciated idea in all of this, I think is that you learn by doing. And what's even more amazing, it's something that was really cool we talked about in the book, which was even the customers don't know what they want. And so you have to pull out. That's the part I guess, of project management. So talk to me a bit about that. What makes a good product manager? How do you learn to do that and what is testing?
Melissa Perri:
36:40
So testing to me is really figuring out what your customers want in small ways. So that could be showing them prototyping and their feedback on it. It could be building something super, super small and like letting them use it and getting some feedback there. It's about making a hypothesis about what you think it will do and then really checking that and making sure that it does that. So it's like, we believe that by building this workflow for users they will accomplish your tasks 10 times faster. And then that will produce value for the business because they don't have to hire 50 more people to do these things. How do we go test it? How do we make sure people really enjoy it though and it is helping them. So maybe we set up an experiment where we're saying, the way that we want to make these workflows faster is that we can take away a lot of this manual work and automate it on the backend. So that's where we might have a couple people do the work for the people in the backend. They don't see it. They just think that everything's being automated. It says, okay, like your process has been kicked off in the backend. It'll be ready and you say it's slow software or it'll be ready in a day or something like that. People will do it and they'll come back and it's like, okay, they can move onto the next task. And then you go back and you can measure it and see if it did produce value for the customer if it made their lives easier, if it did things better. And that's what product managers should be thinking about. Like how do I make sure that this is actually valuable for my users? How do we get the feedback from them? How do I make sure that whatever we're building is going to produce the things that I think it should be building from a business perspective and from a customer value perspective.
David Wright:
38:12
And that seem to be your very unique ability to be able to integrate those, be a generalist across these domains. To talk about the product management, like how do you find these people? Where do you get them?
Melissa Perri:
38:22
I will say it's hard. It's not something that you learn in school. And I do a ton of hiring of product leadership. CPOs and VPs of product for the companies that we work with, but also like senior product managers. So we try to help all the companies that we work with get the right talent in. That's a big piece because we don't want to be there forever. We're like, you got to hire people, hire these people and let them do their jobs. And so when I go out and when I interview people, it's really interesting. I would say too because like 10 years ago when you found people who had product manager on their resume, they were usually really, really good product managers and they came out of software companies and they did some of those testing and learning and there were fewer of them on the market. And then since Agile took over and this became a really, really hot job, it's blown up. It's been one of the higher paying jobs over developers recently. And there's just not a lot of people in the market, so it's super competitive. Like when we find people that could be gone in a day like this happens every day to me. But a lot of people have been changing their titles to product managers and they were not necessarily product managers before. I see that a lot. And it's fine if you did the work.
:
39:28
If you were.
Melissa Perri:
39:30
So like I was called a business analyst when I was at Capital IQ, but I did the work of the product manager. And when I went to JP Morgan, I was a business analyst there. Very, very different. I was like, this is not what I was taught at Capital IQ. If you have that and you have the experience, I look at what people actually do. I rarely look at titles because of that. I'm looking for people to go out and talk to the customers, figure out what they want, work with teams to figure out how to iterate that and test it and ship it. And then go back and measure the success of their product and grow that into a business strategy. That's what I look for in people. How do people learn that? Right now there's not a lot of paths. There's a lot of companies and in schools that are teaching courses on it. A lot of times people get into it from going to get an MBA. I don't think that's necessarily the right path. It depends on what the school is for sure. And there are some MBA schools that do product management teaching better than others. But then there's other ones that don't really have product in their curriculum's. They Just have MBAs. And that's where you're really learning how to optimize a business, not necessarily how to build software. People come from all different backgrounds. And I think one, you have to start building a product. So I tell people we want to transition, like build your own website. That you're on product, experiment with it. Like go out and just try something. Build a prototype. If you come to me and you've never done this before, and I could see that you spun up your own little project that was like better dog food and you went out and you interviewed users and you came up with a strategy and you figured out how you were going to do it, even if you didn't ship it, like to me, that shows me you put in the work and you start to logically think through those things. So I tell people that when they don't have the experience, I see people come in from development and UX and from a business who learned how to work with development better, to me, those types of backgrounds don't matter. What matters is that you're curious. You ask a ton of questions. You will push back with data on people. A lot of people I see that aren't successful in product management, they take whatever is given to them and they just run with it. And when I ask them, like, "Did you push back or did you come back to your boss with data?" They're like, "No, I couldn't do that." So a lot of places they don't feel empowered to do that, but people won't even take the initiative. And a lot of product managers that I've trained who've been successful with that, they've said like, "I'm worried that, you know, I can't push back but I want to try, can you help me like formulate a plan on what to do?" And I'm like, "Yes, so let's give this a shot. Like, come back with these reasons. Go get this data or whatever." I had one person who worked at a bank. She went through one of our trainings and then she came back to me and said, "Hey, I think I'm building the wrong thing, but I'm really worried about telling my boss because I might lose my job." And I said, "Have a conversation. Let's just show him with data what's going on." She told her boss, she stood up and she said that and she's like, "I just think this isn't what we should be spending our money on. I think we might be able to do something else." And he said, "You're right. And she got promoted and she now runs like a very huge part of that business because she had the power to go back and stand up and she didn't come back and say like, "You're wrong. This is all the wrong stuff." She just said, "I think we could be doing something better. Why don't we collaborate on it and try to figure that out?" So you need to have that confidence and the ability to really like synthesize the data. Make a plan, come back with an argument and really present that. Like that's what I look for in product managers. So there's ways to get started. We have an online course called Product Institute, which is usually for people who are already in a company where they might be able to practice. It's not as much for career transitioners. Career transitioners, there are places like General Assembly that will give you like a very good introduction to what's going on there. We've had like people in our class from UX backgrounds or from development backgrounds or business backgrounds, they want to learn more about it and been successful there. This is a big problem. This is a problem that I'm personally trying to solve as the educational product managers and something that we're really putting a lot of work into this year to come up with like what makes a good product manager and we train them and get into it.
David Wright:
43:32
The world needs a lot more of them.
Melissa Perri:
43:33
And that's it. It's just that we need a lot more of them. It's going to be a bigger job. It's going to be a more important job. And companies look at this job and they think that it's just tech. They go, product is tech. That's wrong. Product is business. It's about helping you scale your business through making the right moves for the value in your customers. And more businesses need to see that that's what this role is. It's a business function. It's going to help you grow your business and it's going to do it in scalable ways and with the right solutions for your user. And we need more people who can think like that.
David Wright:
44:08
I want to close on actually touching on really the magnitude of this because at the beginning of the conversation, or near the beginning, you talked about how really this is about two sides, let's call it a legacy enterprise organization that has the business side, the tech side, and you got to find a way to merge them in some ways. And I think that the product management people use the words business analyst role you have which is product management. And that's familiar to me as well, where we have let's say buying a new billing system for your company or some equivalent. And it's an internal software project. You talk about internal tools in the book for a little bit. And that is a situation where you need a business analyst, a product manager more than anywhere else. Can we talk a bit about how that translates. It is universal.
Melissa Perri:
44:51
I think so too. It's pretty universal. I think it depends on what they're doing. So like I said, JP Morgan, when I was a business analyst, I was not doing product management. Like I was managing the disaster recovery of servers. It wasn't product management. If you look at like what people are doing in these large corporations, there's a lot of business analysts there now becoming product managers. It's not a one to one transition. You still have to learn a lot of going out and talking to the customers, bringing that back in, iterating, testing and learning. Those types of things, strategic moves on those areas, but it's not a bad domain to get into. But I think that's really where, all these organizations are moving. I will say too from an organization standpoint, when you have really good product managers, you can scale your teams better. You don't need 20,000 people sometimes to run an area of the business. Sometimes you need 50. So there's going to be this shift I think as we get better product managers and as we get better people who are really good at building software like this, where these companies are going to be able to produce more with less because we're going to be streamlining a lot of those functions. So I think that's going to be something that's going to be really interesting over the years come to see like, what's going to happen to these places. I have 45,000 people. Either you're going to spin up a lot new products, which will be really cool or is it going to slim down?
David Wright:
46:18
My guest today is Melissa Perri. Melissa, thank you very much.
Melissa Perri:
46:21
Thank you.
×

Listen to this podcast on