Episode 46: Dissecting the Pluses and Pitfalls of SAFe with Eric Willeke
Eric Willeke, SAFe Principal Contributor, trainer, and Fellow, is a co-founder of Elevate Consulting where he teaches executives how to lead agile transformations. Eric joins Melissa Perri on this week’s Product Thinking Podcast to talk all about the pros and cons of SAFe, and to share their personal experiences with this often polarizing agile framework.
Subscribe via your favorite platform:
Here are some key points you’ll hear Melissa and Eric talk about in this episode:
How Eric first started in the field of SAFe. [2:49]
There is a huge divide within companies who adopt SAFe between what the product managers do versus what product owners do. It's hard getting those two disciplines to work together for various reasons. This divide hurts the product field because it makes it hard to level up people and careers. [8:51]
The role and function of product owners and product managers are essentially the same. Product owners make product-centric decisions for a team of people who want to create amazing technology products. Product managers do the same thing but on a larger scale, and think further ahead. Product managers have more of a roadmap, and more of an abstract view; they see in terms of quarters as opposed to product managers’ monthly timeline. [11:41]
Melissa asks what a product management career path looks like in the world of SAFe. "Is a stack of bigger titles equivalent to career progression?" Eric responds. The important thing is whether collaboration is happening along each point in the 'stack'. Are the people in the smaller teams working with the people in the larger teams and are they doing so effectively? [14:28]
Melissa and Eric talk about why individuals may deviate from the given product management career path. [16:47]
To bridge the gap between the frameworks that are made specifically for digital transformation in companies and software, product people need to consider a few things. These include the products you're selling, the top-level customer-facing service you're offering, and how software helps you do that. The software product people are there to improve the digital transformation and digital enablement experience across the organization. [21:47]
Eric talks about the role of the lean portfolio. [27:30]
Software product people have a breadth of responsibility within enterprises and very little opportunities for innovation. A lot of product management within this realm is learning enough about one side, and what is actually possible on the other side, then bridging those two together to make innovative leaps. [31:50]
Organizations need to provide deep and narrow product visions. You don't want to have ten thousand ideas and visions running around within a company because it's chaotic. Start from strategy, go to prioritization, then look at your teams and who is going to be affected. [33:25]
Eric gives tips on how to decide how many product managers to have in your organization. [36:47]
Resources
Eric Willeke | LinkedIn | Twitter
Transcript:
Melissa:
Hello and welcome to another episode of the product thinking podcast today, I'm joined by Eric Willkie, who is the co-founder and principal of elevate consulting. And I'm excited to have Eric on the podcast today because one of the biggest questions that I get from a lot of people, and I'm sure Eric gets as well, is what's the deal with SAFe. Um, I've talked a lot about SAFe in the past and what I feel like it lacks when it comes to product management. I feel like we've had a lot of discussions in our industry about whether or not we should adopt SAFe. Uh, for those of you who are new to SAFe, a lot of you are probably sitting there going, is this the best thing for me? What should I know? You know, what are the pitfalls of it? Where does it work? Well? Uh, so that's what we're going to talk about today. Uh, Eric is a SAFe trainer. He's a certified SAFe trainer. He's a SAFe fellow, which means that he is a top creme de LA creme SAFe person. Uh, he gets sent in there to answer any and all of the questions, but not only that, he's also a principal contributor. So he helped make the SAFe model. He teaches the SAFe model. So if there's anybody that we're going to ask about it, besides Dean Leffingwell who created it, it's going to be Eric. And that's why we've got Eric on the podcast today to hear all about SAFe, maybe address some of the misconceptions that we have about it, but also see, you know, I'm interested to learn that where it works and where it doesn't work with product management too. So I've got a lot of questions for Eric as well. So welcome Eric.
Eric:
Alright, thank you, Melissa. Excited to hear some of those questions.
Melissa:
So tell us, how did you get into SAFe? Cause I know, I know you didn't start off as a, you know, this is my thing, and this is your introduction to the agile world. So, you know, what's your background and how did you come upon SAFe?
Eric:
I actually kind of fell into it for me late in the game. I was a lean guy. I was a Kanban guy. I worked as an accredited kanban trainer, a decade plus ago. Uh, I've always really just cared about whatever is helpful to create technology and get it out there where people can use that and get value out of it. Um, I bring an architect mindset to that as opposed to a product mindset, but I find at a certain point, those come together and it's really all centered in what's the problem you're trying to solve? Who are you solving it for? And what's going to be valuable for them. And after years of trying a variety of different things, there was a year where the organization I was working for just decided that everybody would be an SPC by the end of the year. And it was part of a marketing activity.
Cool. Went to the last class of the year. And I'll be honest. I was ready to just sit there and check out and not participate at all the whole week. I had my laptop ready to go a whole pile of work, ready to multitask on. And then Dean and Al shallowly started talking about Lee and spent first half of the first day, not talking about SAFe, not talking about process, but talking about why we care and what the principles are and how to look at software differently. I'm like, oh, this is actually kind of useful. This starts to bring the mindset into it. Instead of just giving me another process, I don't need another three tier process. I have a pile of those, but a way to get leadership and people across all roles, thinking about agility differently, that starts to get powerful. And that's kind of what stuck me in.
And I started really paying attention to the details of SAFe and it was not perfect. It's still not perfect. This was a SAFe three. We're on SAFe, five.one now. Um, but it had really good structure and it had a really good surface area on which to build something amazing. And at the time there was a lot of people in my peer group that were arguing about SAFe town saying how bad it was, how it was just another big imposed framework and instead of complaining and then not doing anything else, I decided to lean in and see if it could be fixed. And I won't claim credit for making SAFe what it is today. I was like one of many contributors. Um, but I did work closely with the framework team for a couple of different versions of SAFe. And I feel like it was able to put a lot more of the flow based thinking and the customer centricity mindset into SAFe. If you're willing to go look for it and where I find today, and I'm still in a place where if I find a better answer, I'll move on to the better answer immediately. But where I'm at today is I see SAFe as this phenomenal scaffolding that allows you to build your organization to something that's pretty powerful. And that's, that's where I start with it. And that's the conversation I bring with my clients.
Melissa:
Cool. I think w one thing I just realized we were missing, we should probably define it for anybody who's not heard of SAFe. It means scaled agile framework. And what it really is is this operational, um, would you, how would you describe it? Like you said, scaffolding. I like that term.
Eric:
I, if I, if I have to distill it down, it is the operating system for your technology organization. It's not meant to be your whole company. It's not meant to solve all the problems facing you. It doesn't claim to be the silver bullet that makes every technology problem go away, but it provides a basic structure and scaffolding and they focus on the seven competencies that you need to be good at to be successful as a business that creates technology, um, in there. Then this is the part that I think most people fixate on because it's the big front page graphic. It has a model for team-based agility based on scrum and Kanban. It has a model for team of teams, agility, uh, what you may have heard of as the agile release train operating on a slightly longer cadence. And then it also has a optional layer that is there for the biggest of solutions, the multiple hundreds of people trying to build large cyber-physical systems like Boeing's work, trying to create new aircraft.
And then all the technology that drives them or, uh, three or four large automotive companies tell their stories about how SAFe powers thousands of people that are building a technology for a car. Um, but not everybody needs that layer. And then it has a intended to be very lightweight portfolio management layer that is there to help you focus your investments on the most important things, because you, if you're a multi-product company, the next question is how much do we spend on each product and how do we manage the trade-offs that arise between them and the portfolio there should provide that layer of guidance and oversight without getting in the way. Um, you can probably tell already from my language that within it, there's a lot of ways that each of those layers can go wrong and start to take over. And I think that's where a lot of the challenges let's say, start to show up.
Melissa:
Yeah. I, so I'll tell you the story about, I think I've told you before, but I'll tell you this story about how I learned about SAFe and where it came from. And this was 2014. I think it's probably right around the time we met. Um, I was training really large bank in 2015, but, um, a very large bank that we all know and love. And, uh, they were one of the first banks I think, to adopt SAFe. Uh, they were going really hardcore in the model. I was brought in to train all of the product owners. So, um, I came in and I, you know, I expected product owners to be like product managers like me. And they said, you know, that's what we need to teach them. We need to teach them how to go out and do interviews with customers, understand their customers, you know, uh, figure out what's the right thing to build, do all this stuff that, um, I hadn't been teaching about like MVPs and good product management.
And at the end of that day after training people, um, I think it was like a two day training after the first day. A lot of them said, wait, this is fantastic, but, uh, yeah, I'm, can't do this. This is not my job. Like my product managers go out and talk to all the customers. And then they come over to me as a product owner. And my job is more to write the user stories and work with the development team and break down the, the functionality and focus on the solutions that we're building. But not really to question if this is the right thing to build or, you know, do any of the research that really goes into that. Um, and that was really interesting. They also had like a very component based, uh, system set up for the way that product management was oriented.
So one of the people in my class for example, was the product owner of the log-in API. And I was like, cool, can you log in? And she was like, yup. Okay. So what are you doing now? Like, and she's like, well, that's, that's what I own. So I just basically write user stories all week to keep everybody fed to do that. And I think that's probably not a feeling of SAFe. I think that was a feeling of just the way, you know, they were structured and component functionality modeling there. Um, but the thing that I found over and over again with the companies that I worked with, uh, who were adopting SAFe and, or became like at least a dozen of them after that, uh, is that this huge divide between what the product owners do and what the product managers do. Um, and in fact, they actually had like a AVP or product asked me about it the other day, who said, well, I have, um, a bunch of product owners and I have a bunch of product managers.
Um, and I'm trying to hire product managers that can help the product owners like hone their craft, but everybody's so strategy focused on the product management side. They can't help them with the tactical side of the product owner piece, um, or vice versa. They get everybody's super tactical what they can't do the strategy piece. And I feel like that divide between responsibilities. I, I see it as a, a really hard way to level up people in careers, because if you want to, like the logical step is you go product owner, product manager, and it's like, if you're not doing any of that research stuff, or you're not doing any of that strategy stuff, one, how can you possibly understand what's the most important thing to work on? Um, when you're building a backlog and then two, how do you gain those skills to be able to have a career path that goes all the way up to VP of product or a chief product officer one day? Um, so like I haven't seen a successful product management organization, um, in a company that's run SAFe. I haven't seen something where there's really nicely defined career paths. We're allowing people to gain the skills that they need to go from one to the other. Um, and that's across like every, every company I've worked with, like, I, you always see companies doing things wrong, but that felt to me more like a product of SAFe rather than somebody's butchering it. Um, but I'm curious, like how you see that, what, what is the, why differentiate between product owners and product managers? Um, what does SAFe teach these days about those things? Like if you were to go to a SAFe training or like deploy this into your organization, like, what does the product management career path look like and what do they do at the different levels?
Eric:
Yeah. So I guess to address that, I I'll actually rewind a little bit and kind of look at the why of product management from a SAFe perspective first. And when I look at this from a process architecture point of view, my going in mindset as well, what is the goal of product period, regardless of level, it is to figure out how to convert money into valuable things that users, and more importantly, buyers will adore and therefore give us more money so we can keep doing that. And because we're a technology company, um, we're doing that through either digital products or digitally enabled products, because I don't think there's any other types really out there anymore. Um, and I, so I look at that whole domain and say, okay, the role of product is figuring out what to do next to delight our customers. And more importantly, delight our buyers and create a sustainable flight wheel and all that good stuff that we love on the product side.
So now I look at the stack of product related roles within SAFe. And then I imagine that goal, that large-scale goal to the organizational unit that it's trying to support. So a product owner is a value outcome lead. I'm going to use the sooner, SAFer, happier language here for a moment. It's a value outcome lead for the team level. You're trying to help make product centric decisions for a team of ideally eight ish, very talented people that are wanting to create amazing technology products. If I'm looking at the product manager role, I'm trying to do that same thing for a group of say a hundred and to do that for a group of a hundred, and probably looking a little further out on a roadmap, and I'm thinking much, a little more abstract. I need to think in terms of big feature and product briefings and themes that I want to invest in over a matter of quarters, not in terms of what do I need to do over the next three months if I go up another level and I look at the solution manager role and SAFe, which is a product role, but it's hiding under the term solution.
I'm doing that same thing for a group of multiple hundreds of people. It could be an entire product unit, could be, um, a large scale single system, like a massive ERP system that has hundreds of people working on it, or a new insurance platform, like one company did their entire rate quote issue system. And it had multiple hundreds of people. Um, you're trying to steer a large capability type product across that large group. And to that, you might have to look out years depending on the technology and the contract structure. If you're working for the government, for example, let me go up to the portfolio level. And there's hiding in there a couple other product, like roles that are really looking at our product portfolio and where are we investing across this family of products or this network of products over a multi-year period. And if you're working at that level, it's very abstract and very long range, but the nature of product, it also sets you back into the very tactical as you have to go and sell the next deal or whatever, as you go meet with the CEO of the company you're selling to.
Um, so as I look at those different roles in those different horizons that tells me the different abstraction levels and the different habits that those leaders need to take. Um, and then I look at the architecture stack and I see the exact same set of concerns. And, and that's where the triad structure comes in to say, if you'll see the three roles at every level, we build that team so that you're partnering and working. But if you look just within that pillar, is it always true that somebody is going to go and start at the tactical level and then grow and become broader and then grow and have even more people, or does product habits own, um, individual contributor track versus leadership track question. It needs to answer. Um, I worked with a VP level contributor at a company. I won't name the company cause it's a little bit of a sad story and this individual only had one scrum team, but it was the single most important scrum team for the visibility of the entire company.
And as a vice president level contributor, that person did product and did architecture for that very small team, VP level roles, very senior individual contributor type with a personal reporting structure. That seems like a really valuable advancement down a product path. Um, so I start to question, I think is my long-winded answer here is, is the stack of bigger titles equivalent to career progression. And then within that stack, um, just like within any other technical discipline, the next question I start to ask about the effectiveness within SAFe or the effectiveness of the individual is how well do they collaborate up and down that stack? And I think that's a bigger driver than anything to do with the framework. Is, are the people working at the 10 person scale, collaborating with the people, looking at the fit a hundred percent scale? Are they collaborating with the people looking at the long term horizon scale?
Melissa:
Yeah, I think so. So this is where I get like a little wonky with the SAFe, but also like, this is also where my issue was, was scrum as well. I feel like we're reinventing the wheel here cause uh, there is like a product management career path. Like there are a million SAS companies out there and there's tons of companies in Silicon valley and there's Google and there's Amazon and, and we have a career path in transition and career ladders that are pretty defined for product management. Maybe just not in organizations. I think that are going through digital transformation. It's like, they just don't know about it, but like for the last 20 something years, like we've had product managers on teams and then directors of product, which I find kind of falls into where you would call them product managers versus product owners. Right?
Like that's what we would do directors at and then VPs a product and a chief product officer. But, um, it sounds like your solution management person is like what we would consider like a VP of product or, um, a chief product officer at the top. Right. But it's like, what I, what I see is like when we change those languages and don't acknowledge the career progressions that already exist one, it's hard to get people into these organizations who actually have experienced in product. So what we do is we ended up taking subject matter experts and throwing them into, you know, those roles and being like today, you're now the solution management person, but they're, you know, they're a banker. Like they were, they were never a product person. Um, and it's hard to attract talent. Like, you know, you're not going to get the best VP of product, um, to apply for a solution management position in a SAFe organization because they're going to be like, what the hell is that? Like, I don't understand. Right. And does it, does it actually follow those types of things? So like why deviate from the product management structure that already exists?
Eric:
I guess maybe my question is from a career pathing perspective, w I don't, I don't know why companies are deviating. Nothing is SAFe, says don't use best practices for HR for this area. In fact, I strongly encourage us that, um, wait, the, the last SAFe transformation I Leonard has two ago, we had 3000 people on our products. And that sounded exactly like what you just described. And we were doing SAFe a 3000 person scale. So I guess maybe my biggest question is, I don't know why, why would people not use the industry standard for that? HR would be out getting comps. They should be doing their mapping, kind of doing all the standard HR excellence stuff, aligned to best practice in that domain. And then the role somebody fills doesn't necessarily map perfectly to the state. Like there shouldn't be a direct correlation of, I am serving as a product manager. Therefore I must be a product manager, career track level three person. If it's a critical enterprise, top tier concern, you might have your most senior person. Who's the next era parent for the CTO serving at a hundred percent scale, because it's so important at the same time. If it's a legacy space for you, it's not, you're getting ready to spin it off. You don't really care. You might have a relatively junior person kind of just overseeing it and keeping an eye on it.
Melissa:
Yeah. Thank you. Hold on for one second. I think I'm one of the people I'm trying to let into my office. It might be outside. Well, just double check real fast. No, this is something completely different. Um, I have like the, um, the investor for the company I sit on the board of is you're at Harvard, but he, uh, had to run out and I had a lot of backup, but I thought that was him, but it's not. Okay. Cool. Um, all right. Where were we? So we're talking about career paths. So then so one issue that I see with a lot of car companies. So with that career path though, is they, they take these roles, right. And they look at them and they're like product owner, product manager, solution management, and they all think they're different people. Right. Um, and maybe, maybe it's a product of them not learning SAFe differently, but they don't see it. Like I see them not seeing it as like a career trajectory, like, uh, like let's go up and down this line and go into it. Um, but I agree with you. Like, it probably should. That's where it's there, but it's like, what about why? Like, why keep that language? Like, why keep that language if that's, you know, if that's what people were actually acting on?
Eric:
Yeah, that's a good question. I I've started adopting informally, not part of SAFe, informally, just the, uh, simplified language of, uh, value outcome, lead technical outcome, lead and team outcome lead. And that, to me, scales across every level, every scale it's, it's a nice, smooth one. Um, I think one of the biggest one is just use momentum. It's been a product owner since scrum was created 20, 30 years ago, according to some, the product manager role on SAFe PR goes back to the very first versions when the vision wasn't trying to scale to the entire enterprise, it very much was, Hey, we've got big products that are hard to build and one product owner can own. And so let's look at a team of them and it's, it sounds like a product manager and I think it was born there. And then it stuck. It's just language momentum at this point.
Melissa:
Yeah. But like, so, so when Steve was getting created to let's, let's go back to that. Was there anybody like helping define this from like a purely product management background? Like I know a lot of people had deep agile experience and deep technical experience, but like how much contribution was there from people who were like super experienced software product managers?
Eric:
Um, you know, that's a hard question to answer. Um, cause I would have to go back and ask, like who, who were those shining examples and what was the, where was the discipline of software product management in call it 2007? Because I don't know if those people worked with the inner new Dean back then, but the first white, the first white papers, like for SAFe, I reviewed one for d'Alene systems and software conference back at Bricknell key in like 2007. And it was already a couple of years old at that point. So I'm gonna, I'm going to say the answer is probably not because that wasn't the problem that was trying to be solved back then. And as SAFe as a product has evolved into these new spaces, it's very much trying to adapt and encompass and include new concerns.
Melissa:
Yeah, I think it's like, this is where I kind of see a divide. I think it's just across agile as well as not particularly unSAFe, but, um, just this whole, like product management has been around for a very long time and especially pure software companies. And as our disciplines of agile have now graduated to the companies who are trying to become software companies, we're trying to be software enabled companies. Like we're going this way. And I think agile grew out of the concern that those companies didn't quite understand how to build software. Right. And it's like, how do we promote them to do it? And SAFe is, uh, you know, is also scaffolding for those types of companies. Um, but there was product management and all these software companies like doing well. And there was, you know, there was a Google at the time, there was Amazon at the time, there were like a ton of these, you know, what we would consider big tech companies these days.
Um, but it feels like some of the stuff that came out of agile wasn't necessarily borrowed from those places, right. It was kind of created out of a need for these digital transformations and to teach people how to do that. But how do we reconcile that? Like I know you're never going to get the same kind of culture let's say at least today, maybe in the future, but like the same kind of culture that you have in a pure SAS company where it's like we build software and we sell software in a bank, right. It's just, it's a very different thing. Like it's, hopefully we are learning. And I think we have learned that, you know, embracing software and, and building software can create immense value to, um, other industries that were not primarily like we just software, right? Like we, we can do things we never thought possible before with, um, with, with software. And I feel like every executive understands that every, every type of tech enabled company, but it is very different when we think about like product management with the whole, your product is a software versus your product is a credit card. Right. But how do we, how do we get people? Like where do we bridge the gap between some of these frameworks? I think that were specifically made for these digitally, um, digital transformation type companies, right. Versus things that we've been doing software for a very long time.
Eric:
You actually have me going down memory lane a little bit there. Um, and I think a story might be an order on this one. Um, I'm thinking back, it was actually one of the first other release chains I launched. So back when I was just learning SAFe and coming up to speed on it, and this is a property and casualty group, um, it was their claims group at a very traditional, uh, company long, a hundred year plus history. Um, you walk through their hallways, you see the black and white photos of the first mainframes being unloaded from planes to be brought in. And among the first tech companies, you could say long before software as a standalone thing existed. Um, and it was an executive in the, that was serving as business owner for this train. And I would argue he was one of the most brilliant product people I ever met knew nothing about software.
And this is probably the biggest source of this divide. He pulled me aside, we're in the middle of the middle of this, a hundred percent planning and these big, fancy executive that I only kind of know, he's like, Hey, Eric, come through, come here. I want to show you something. And he took me to this little side door and it was into the training center where they train their claims adjudicators. And you walk me through these rows of damage to vehicles telling me each and every one and what was wrong and how claims agents had to look at it and talk about it, think about it. That was such deep product knowledge for his product, his product wasn't software, his product was enabled in the powered by software and required amazing software in order to amplify his workforce and help him deliver what he wanted to do.
So when I think about enterprise product management, that's, that's the first thing that comes to my head is what are the products you're selling? What is the top level customer facing service you're offering? And how does software help you do that? And that's where you, when you start talking about digital transformation, digital enablement, it's like, yeah, your software product people are there entirely to make that experience better and happier and SAFer and everything else that's necessary. And I, and I think that creates a wildly different relationship as the software product leader in that kind of space versus you have a P and L and a bottom line. And if you don't have customers, you don't have a company anymore. Um, and I'm wondering if we want to spend more time looking at the differences there, which, which could then in turn inform why a, a pure product hierarchy looks different at a SAS and product first software, first company.
Melissa:
Yeah. That's fair. Like w like, so let's talk about it. Let's take a bank, for example, you and I both worked with million banks, um, and the credit card division just gets, it's easy to grok for everybody. You've got your product owners on the team, uh, and then you get your product managers in the middle probably where I'm call like product director, right. Like one up,
Eric:
Right. Maybe you look at this from what are the products first.
Melissa:
Yeah. We'll let you go that way. Um, what my question was going to be is who oversees all those pieces, right? Like from your experience, or like, who's the right person oversee it, but yeah, let's take it. So your, your product is a credit card and a credit card business, but it's usually made up of many different components to be able to operationalize that credit card into a way where you can actually consume it as a user. So
Eric:
I'm spending a, putting an enterprise product perspective on it. You've got the thing that you were actually selling through your branches, that you were enticing people to spin up for. You've got a secondary business division internally that actually owns the credit product. That credit division is actually outsourcing all the processing and transaction management to MasterCard visa. One of the well-known processing companies. So you're, you're in a, your product role is actually one of an integrator with a bunch of internal capabilities and a bunch of external capabilities and a lot of software to stitch that together.
Melissa:
Yeah. And then we also have like the whole, like, you know, if we take a actually being able to use your credit card, we've got all these different surrounding services around it. Right. Um, yeah. Capital, one's got the whole virtual credit card numbers, and they've got their app that you can plug into your browser and change all of your, um, your numbers on it. We've got the travel rewards systems that like plug into your credit cards. We've got the actual credit you can spend, like you were talking about, um, we have the applications where you can manage and pay off your credit cards. We've got the, um, yeah, like everything, like all the integrations on top of it, too.
Eric:
And then just for the modern product, spin on it, your experience has to be fully integrated with the other five lines of business that the customer is buying from in the same.
Melissa:
Yep, exactly. So like, if I log into my application to look at my credit card, I also have to be able to see my banking account or my checking account there, and I should easily be able to pay my credit card with my checking account if I have that and reconcile that, and not have to go through 17,000 hoops or log into 80,000 experiences.
Eric:
So, so given that ecosystem, what, what product would we be looking? Should we look at, uh, start talking about roles and who owns what?
Melissa:
Well, let's start from the top, right? Like you've got the whole credit card division, usually in a bank, there's some kind of like general manager of credit card, right. So that's like a business person.
Eric:
So you've got an executive business owner, some sort that has P and L responsibility and utilization responsibility for the entire credit card system.
Melissa:
And then you've got like, to me, the next level, um, is really like a product person. That's senior enough. I'm I, I would call it like a VP of product, but, um, we're chief product officer of super complicated, but, uh, who's overseeing the entire portfolio of software products that help extend in enable that credit card to actually work. Like not the, not the credit product of like, Hey, you're approved for $20,000, but like, how do all the systems come together and integrate into an experience that a customer would actually want?
Eric:
So if I was looking typical corporate structure these days, um, the executive business owner that we described would be one of the executives that sits in the lean portfolio management function. And they would probably have an entire instance of SAFe focused on that overall set of credit products, because that sounds like hundreds, if not thousands of people to make all that happen and orchestrate it.
Melissa:
And what does that lean portfolio center do? Like what is their job?
Eric:
Um, fundamentally their job is to set the strategic themes for the entire technology side of portfolio, which if they don't match the business strategies, you've got a problem already right there. So they are also like the enterprise architect should be sitting with the business partners, figuring it out at the same time, the business is sitting with the technology group, figuring out what the technology strategy is, um, allocate the funding and the investment dollars available across the various themes you might want to invest again, which take the form of insane value streams that you have a number of release trains lined up against and, um, set the type. There's also the enterprise architecture dynamics that come into that, like what's, the tech will help instability. Um, but I, I would say that the product role at that level is the, where are we going and why, and how does it align to our overall business goals? And then there's kind of a tech product integration type role. And I have no clue what title you've used for this. I'm making this up as we speak, but is working with the equivalent people in the other portfolios because homepage.com or my account screen has to have all that stuff integrated. And those are completely different products and portfolios potentially.
Melissa:
Yeah. So like that person, I guess who's figuring out the, where are we going and why piece, how much, you know, software product management experience do they need
Eric:
That's scale. It's. I mean, I I'm getting into Conway's law, like how people and organizations and technology come together around purpose. Because at that point, if you're that skilled, you don't have a reasonable architectural background, too. It's going to be hard to do your job because you're not going to know what's possible. I see a lot of, uh, digital executives that come in from pure software and SAS places, and they get the digital group and they stand it up and it just doesn't make any traction because they're at best, they become a UX skin group.
Melissa:
That’s it.
Eric:
Doesn't because they can't make the deep structural changes from a surface level
Melissa:
That's been my experience too.
Eric:
Yeah. So I think part of it is like you find the product people devolve or evolve. I'm not sure where the direction is into where the digital experience edge and everything behind the scenes is not product. But then I see a deep, a different role that brings some architectural and capability based thinking in. And I see what I see is very strong product leaders who don't even think of what they do is product leadership. They think of it as component design, or I own this service, maybe service management, as opposed to product management. But what they're really doing is treating some sort of internal product with all the skills and capabilities and mindsets that a product leader would have. Um, like when I find that the enterprise, that's what I am pushing and steering a lot more of these days.
Melissa:
So in that, in your SAFe model, like I'm looking at the diagram, that person that you're describing is that the enterprise architecture is that a solution management person, like who, w w what is their role when you think of SAFe?
Eric:
Um, the type that would be in the, well, it'd be a collaboration between the technical architecture stack and the product stack. Like, I don't, I don't think there's any big, hairy enterprise problems that can, that can be solved without those two roles working.
Melissa:
Oh, yeah. I completely agree with that. Like, I, I think there's just, yeah, I, I don't think product should basically be doing anything without tech. Like you are joined at the hip, this is your person. You like work together on it. But I do see on the side from the product side of it, I think you were talking about this as well. Like if you don't know, what's possible with tech, it's really hard to innovate in a digital system. And that's where I've seen some issues where we just like throw people in. Who've been at the bank for 20 years and say, Hey, you're now the product person like go. And it's like, oh, well, we can't do that. That's like, you know, it's, it's hard because I think there's so much baggage sometimes too, when you're stuck in the same industry for so long where you don't go and I've had this problem as well.
Like I, I've trained a bunch of banks and they'll be like, well, can you give us a banking example instead of like, using something from Google or something from like these different startups or something. And it's like, you can borrow a lot from different companies. If you understand what the purpose is of the technology that they build. Like, if you understand why things are certain, like certainly structured like a platform and what power you get from APIs and all those different things, like then you could harness it and you go, oh, that's possible. Right. And if you don't know those types of things and you don't have to be an expert on, it's not like you have to know how to build an API, you just need to know like, what it does. Um, if, once you understand that, I feel like it opens up so much more strategic, um, thought where we could go and what is possible. And like, what should we place our bets on in the future?
Eric:
Yeah. You've got me thinking and I'm, I don't know if this is going to be a coherent thought or not. Um, but it really is. It has me thinking in a new empathy for the role of software product in a traditional hearing enterprise space, just because the breadth of responsibility and the, like, there's a huge lift and understanding a business at a deep enough level. That's been around for 50 years to know where you can innovate. And then there's the technology ecosystem. Let's be honest. And most of these big companies, it is a decided drag. It's a way that it's 50 years of accumulated technology experience that carries a huge operating cost and makes doing new things very difficult sometimes. And it's a lot of product management that spaces learning enough about one side and enough about the, what is actually still possible on the other side and finding the seams that let you make innovative leaps. And it's, it's almost a, the best fit problem. More than it is an actual visioning process and a long-term horizon thinking.
Melissa:
Yeah. Like I think like when you are in the top level of product management in any organization, like you have to be part visionary. Right. And then partly pragmatic. And I always tell people, like, when they asked me about these things, like, I, I promote pragmatic product management. Let's put it that way. I am, I'm a person where it's like, yeah. Sometimes you have to like, forego that shiny new thing, because it's more important to get revenue. Or sometimes you are going to say yes to the client that you don't necessarily want to say yes to because they're your $50 million a year client, and you need to make money. Right. Like that's, you know, that's the reality of the things that we live in. And I feel like in an enterprise world, the reality is, um, what our systems actually look like and what we're capable of executing on and how do we pull those things apart. So like every company I've worked with, that's been in enterprise as some kind of legacy system that's going to take the next 10 years to detangle, um, and be able to move it more towards a modern architecture, unless they just decided to build it from scratch, which probably should. But like, you've got so many pieces on that too. And you got to come back to, to it and say like, yeah, we do want to move in these modern ways, but then what can we do?
Eric:
You, haven't been going back to your original story about the bank and the product owners. And think, I wonder if there's a conversation that we need to help the industry have on both industries that we represent that is around providing deep but narrow visions. Yeah. Cause I'm thinking about a, an organization like my current client, arguably could have over a thousand product owners. If we look at the SAFe organization, do we want a thousand distinct visions running around? That sounds chaotic and very messy, but how do we create powerful ownership in a very narrow space and then build the scaffolding and the relationships parallel. That's like, okay, but now we have 10 people with these 10 narrow powerful visions that align up to a bigger vision. Then the product manager of which they're still 50 or a hundred up by the way is a rep channeling that a hundred person for the vision into some larger vision. And yet again, it's kind of like the healthy dating of OKR is instead of the numerical cast stating. Anything with product and vision.
Melissa:
I feel like if you tell me, because like, you've done a lot of this structuring, I think at scale, my experience is that a lot of companies, instead of starting from like, here's how this, this is how I would do it in a growth stage organization, right. Like 5,000 people, less that type of thing. Um, this is how I think it should be done anyway. But like, we start from like, here's our strategy, right? And then here's our prioritization of what we want to do and where we want to get it done. And then we look at the teams and we also look at our products. Right. And we decide like what's going to get affected by that strategy. And like, which products are in which products do we need to maintain? And then we just start to draw boundaries around, like who owns what?
And from a product perspective. So it's like you are around these product areas, but you may not be touching some of those legacy systems because the strategy, you know, is not saying it's not prioritized right now. So we don't work on it. We're not, we're not doing it, but there's some kind of ownership around it. Like at least when a bug happens or someone needs to be fixed, we know what team owns it. I find a lot of companies do it the opposite way. Like when they start to structure their product teams, they go, how many products do we have? Oh, a thousand let's have a thousand product managers or product owners, right. To put around them. And then they go back up to the strategy. And that's how you ended up with people. Like the person I trained who was like, well, I work on the login API and I, you know, it's done, but I just keep writing user stories for it. Like when you go in to do SAFe and you're you're structuring teams, or you're moving them into more of these agile components, how do you decide how many product owners we have, right. How many product managers we have and how do you draw the boundaries around those things?
Eric:
Yeah. That, that continues to be one of the hardest enterprise problems to solve. Um, I think John, I mentioned the beautiful mess recently and it certainly struck close to home for me. It's first is to tease out what can you, our line around value? Because value itself is hard to get a handle on, like, if you're owning an eight log-in API, how many different things want to change that? Or is it purely operational? And you shouldn't have a product there anymore. So it's a service and that's part of a bigger product. Um, so one of the things, I guess, getting one more tactical, one of the first things I do when I look at a large portfolio of any sort is to try to define the existing products inside of it. And for lack of a better language, I usually default to business architecture and business capabilities and I call them anything level two.
Okay. That's an internal product. Good enough for now and start to say, what does it mean to own that doesn't have its own distinct strategy and purpose, or is it just a platform? Does it need a, does it need to be a product like platform or can it just be a service that's running and nobody pays attention to it. Start shaping around those. And every one of those, we'll still have somebody in a product owner role, but some of them might just be administrative oversight of a flood. Like one, a classic example. I knew one scrum team that owned seven. It was either 17 or 23 distinct skewed products. Um, had SKUS has been in the market for 20 plus years. Each one, scrum team owned all of them. And all they did was update it a couple of times a year when, um, IBM dropped a new version of the mainframe, very profitable, incredibly high margins. What does product mean in that space? Yes. New mainframe version came out update. Does that in your definition, is there a product there?
Melissa:
It's like, well, there there's nothing to work on strategically. Right. It's just updating.
Eric:
So it's a product with a P and L and a SKU and everything else. Yeah.
Melissa:
But it's like, do we need to actively work on it is the question. Right. So like in my world, what I would do is allocate a team to oversee it. Like, it sounds like you have, but they would be working on strategic things adjacent to it or in something else where like another product might fall under it, but they just update it every once in a while, because I also see this issue and maybe you've seen it as well. Like I get asked this a lot by companies, um, who have large legacy systems. Um, but they're, they're like, well, I don't want to work on all the junk. Right. Like I don't want to work on the stuff where I just have to update it and I'm not doing anything strategic. So it's like, who do we put around that?
Eric:
Yeah. Maybe, maybe that's the other question. Let me start to think about so deep, narrow visions, but also I'm trying to think of the right language for this, but the, the boring products. Yeah. But the products for which the vision is to see no change and do not disrupt this and to make sure it is stapled the cash cows that don't need energy, still need product, but it's not modern digital shiny create the next amazing experience product to the stable workhorse product. Yeah. And is there, is there a good language and conversation and stuff there, or it's like, like I would, I would hate to have seen that product that has described the 23 products. If somebody tried to lean start up anything near them, like keep that lean startup away. They're stable, they're running at 99.9% margin and they have for the last 10 years, please don't screw it up. There's still a product there's still needs a product thinking it's just not in the differentiation space right now. It's not even in the linear competitive space. Yeah.
Melissa:
It's just like keeping the lights on. Let's keep the lights on for that. And how do we allocate for that and how do we oversee it and just make sure it doesn't tank.
Eric:
Um, it would be fair. Maybe 60% of most enterprise portfolios live in that space, but you still need, you still need content authority and you still need somebody providing direction, even in that boring space.
Melissa:
It's totally fair to say.
Eric:
Where does that match up to career laddering and product? I'm thinking in that area.
Melissa:
So when we were talking, we were talking a lot about like, I've worked a lot in the growth stage area. I've worked with a lot of SAS companies. I've also worked with a lot of enterprises. Um, I mostly see enterprises, um, who are going through some kind of digital transformation adopt SAFe. Is there any particular company where this is better suited for them? Right. Like we're SAFe is like a pretty good answer. Like what is the criteria where you're like, all right, SAFe can help you.
Eric:
So I always start with, what problem are you trying to solve? If your company is working great and everybody is well aligned and software and value are flowing. Don't do anything significantly different than what you're doing, because that's not your problem. That's not your enterprise constraint if coordinating technology and not managing products or anything like that. But if it, if coordinating technology spend and getting the right value out the door is the biggest impediment you're feeling as a company. That's where something like SAFe is your answer, because it's all about unblocking above the team level. Now, if your, if your portfolio is running smoothly and you just need to work on team and technical skills, yeah. Maybe you don't do a large scale shift. Maybe you're focused on scrum or lean or XP or anything these days, I don't care what you call it, but get better at technical delivery.
Eric:
Get better at helping developers work together in teams. But if coordinating multiple teams and bringing alignment to focus, there is the challenge I tend to default to SAFe just because it provides a common language and get everybody in the org on the same page and start thinking in terms of the same 10 principles. And that could be, I've worked with a couple small startups that are only eight or 10 teams. And I take the portfolio level right out. I take late large solution right out and just do essential SAFe, keep it simple. Don't try to do everything. Think about what problem are you trying to solve? What's the easiest way to use these. I love the term liberating structures, but these very basic constraints of what's do a 10 week plan. Let's do a two week plan. Let's make the 10 week plan bigger and have more people let's make the two week plan smaller and focus it like start to do those basics. Then it's, you're going to get better. You're going to create control. You're going to create stability. You're going to create some islands of success that you can then grow. And when I say SAFe as a scaffold, that's what the scaffolding is doing. It's giving you some words, language, some structures, and more importantly, a set of principles and values that you can use to start to fix things.
Melissa:
Great. Well, I feel like we're going to have to do a part two on this. Eventually. I think there's so much more to unpack here, but this has been really enlightening. And I feel, I feel like we probably have more similar thinking to a lot of how this happens than I originally thought or originally saw in the early days of SAFe. So I'm excited to see that, that happening as well. Um, but thank you so much for joining us, Eric. If people want to learn more about you and your company, where can they find you?
Eric:
Um, our homepage is elevate dot Tio elevate too. And you can find me at Eric at elevate dot Tio.
Melissa:
Great. Well, thank you so much for joining us and for the rest of you out there listening, uh, stay tuned next week for another episode of product thinking. We'll have a dear Melissa out on Wednesday. Thanks and see you guys soon.