Download Presentation
About Luke Hohmann, SAFe Fellow & Co-Founder
Luke has been involved with Applied Frameworks since its founding in 2003. He later went on to start Conteneo, a collaboration software company which was acquired by Scaled Agile in 2019. While at Scaled Agile, Luke served as a SAFe® Framework Contributor and Principal Consultant, with significant contributions to the SAFe Agile Product Delivery (APD) and Lean Portfolio Management (LPM) competencies and the SAFe® POPM, APM, and LPM courses.
He is an author and cited as an inventor on more than a dozen patents. His books include Innovation Games: Creating Breakthrough Products through Collaborative Play (2006), Beyond Software Architecture (2003), Journey of the Software Professional (1996), and the upcoming Software Profit StreamsTM (2023) co-written with Applied Frameworks CEO Jason Tanner.
About Marc Rix, SAFe® Fellow
Marc helps large organizations leverage the game-changing power of Lean, Agile, and DevOps at scale. He has been practicing Agile for over 20 years and is an internationally recognized thought leader, consultant, trainer, adviser, and speaker. Marc lives in the US and is a member of the Framework team at Scaled Agile.
Transcript
transcript created with Otter.ai – please ignore spelling and grammar errors
Laura Caldie 00:11
Hi there Luke. Hi Marc. It is great to see you both here. Thank you. So we are going to get going in just a minute lets give folks a moment for zoom to let everybody and I can see the attendee count is still trickling up. So while we do that, quick check on audio, I think, Luke, you are in Boston today and Marc I’m assuming you’re in Colorado, but I don’t know that for sure.
Marc Rix 00:55
I’m in. I’m in extreme west Boulder, which is Maui Hawaii.
Laura Caldie 01:02
Oh, I’m so sorry to hear that’s where you are? Poor person. So you and Luke are almost as far apart as you can be.
Luke Hohmann 01:13
On the face physically. We are about as close we were united in product management and safe six dot o, Laura. Okay, well, that’s
Laura Caldie 01:21
a good segue into I’ll let you two both do your own introductions. I’m sure I can’t do them justice and you guys will probably give us a better summary. So Marc I will turn it to you first and then Luke, you can wrap it up.
Marc Rix 01:34
Great. Thanks, Laura. Great to be here. I’m Marc Rix I’m a safe fellow and methodologist with Scaled Agile. I’m on the framework team. I have been with the company for about four years. Before that I was in the field, working as a partner of SAFe on on big enterprise scale implementations of agile and before that I was actually a customer of safe running a lean agile Center of Excellence at a large financial company.
Luke Hohmann 01:58
I’m known in the Agile community for a few things, but I’ll pick the serial entrepreneur and I’ve written a couple of books with another book coming out next week. We launched software profit streams next week. I’ve been doing Scrum and Agile for quite a long time, and SAFe not quite as long as Scrum. But I’ve been doing SAFe for quite a long time and I was also for a while a member of the framework team. I’m now the Chief Innovation Officer at Applied Frameworks and I still try to make contributions to SAFe, often secretly sending stuff to Marc and Marc is like oh, okay, and Marc is a great friend. And a colleague who collaborates on all of those elements including what we’re going to talk about today, which is product management and SAFe. So our goal is to review some of the distinctions between competencies, functions and roles within SAFe 6.0. We’re going to then dig into the product management responsibility wheel. And then from the wheel, we’re going to talk about each responsibility and we’re going to go back and forth as we talk about the responsibilities. Marc is going to bring the SAFe 6.0 framework perspective plus some of his actual field experience. And what I’m going to do is I’m going to talk a little bit in addition to those core SAFe 6.0 responsibilities. We’re going to talk a little bit about how we think of profit streams. And then we will very much try to leave room for discussion because we know you will have questions and you can put those questions in the chat. And we’ll make sure that they get answered or in the q&a.
Laura Caldie 03:42
Yeah, I’ll just interject here quickly. So obviously, this is being recorded and we will send the link to the recording out when we’re finished with this. But for folks, it’s easiest for us if you put the questions into the q&a. And I’m going to go off and be monitoring that in the background. And I’ll let Marc and Luke continue to have this conversation that I know we’re all super interested in. So with that, I’ll leave it to you and I’ll be looking at the chat. If there are other things that if you have questions, put them into q&a
Luke Hohmann 04:11
and we’re going to start with Marc talking about save 6.0
Marc Rix 04:16
Wow, SAFe 6.0. It’s here. It’s launched. It was about two years in the making, and we don’t we don’t redo the framework like this very often. So it kind of came out as a big bundle of goodness. So there was a large batch of really really interesting changes not just the framework itself but products behind it. Learning Aids and lots of Marceting material as well. So a lot went into it. That’s not to say that you know, we do just occasional big batch releases, we have been continuously delivering value. Over the course of those two years in the form of smaller updates. One of those smaller updates was really, really important updates to these two articles, product management and product owner and say, and they were just kind of codified in the safe six data set and interwoven into the rest of the framework. So here at this level, we see the big picture which has a new look and fee,l it’s got new branding colors, so we’ve pretty fired it a little bit and it looks a little bit different but it looks largely the same. So there are a lot of nuances in here that are new and safe that we don’t have time to go into in this webinar, but just notice some of the key differences. We’ve rearranged some things, we’ve moved some of the icons around and we’ve changed the color of a lot of things. We do have an article posted what’s new in safe, that’s accessible from Scaled Agile framework.com. That goes through the litany of changes that had been released. But here we want to focus on these three components, Product Owner product management and agile product delivery. And here we just want to make the point that in SAFe, we have functions, we have core competencies and we have roles. The core competencies are the seven things that enterprises must do. We must do very, very well. In order to achieve business agility. We have assessments behind each one of these product owner is a role unto itself that is occupied by an individual and I think we’re all very familiar with the product owner role, especially in Scrum. But we’ve taken that role a step further and applied it to non scrum methods as well. So every agile team really has a product owner that has a customer facing responsibilities and is responsible for helping the teams deliver value and with whatever method they’re using. Then we have product management. Notice that we don’t call it product manager, we call it Product Management. This is a function that can be an individual or a team depending on the context and depending on the scale of the solution. So that’s really all I wanted to cover at this level. Luke, do you have anything to add?
Luke Hohmann 06:52
Marc for our viewers who may not be as familiar with the evolution of SAFe 6.0? The introduction of SAFe 6.0 it is new, it’s shiny and sparkly and new. And it is very beautiful but the laying out the changes made the color schemes I think it’s a noticeably more visually appealing big picture. So I’m really excited about that. Marc. We’re we’re any competencies added or removed from SAFe 5.1 to SAFe 6.0 or were the competencies kind of pulled forward in a consistent manner from SAFe 5.1
Marc Rix 07:28
The competency set was not changed. So we have the same seven that were there before. But one thing we did do was we moved continuous learning culture from that side down to the the lower right hand corner so now that’s part of the foundation of safe so the foundation that sort of underpins the philosophy of safe it’s grounded in Lean and Agile thinking contains continuous learning culture and lean agile leadership. That was big, the big change there but content wise, those are rock solid.
Luke Hohmann 08:00
And just for closure, I think you and I could have added this and this particular webinar is focused on product management. I refer our viewers to which solution management also be considered a safe function because it’s typically fulfilled by a team or is solution management a role. How would you characterize it just for completeness and to draw everyone in because we do have some people who are on the webinar that are probably dealing with a solution train as opposed to a single art. Could you elaborate on that before I move on in the slides?
Marc Rix 08:37
Yeah, absolutely. So that product management pattern scales like a fractal up to the next level, that large solution level, right. So right about product management, sort of along that dotted blue arc, we bump into solution management, which has a lot of intersecting responsibilities and capabilities as product management. It’s also a function that can be fulfilled by one or more product or sorry, solution managers and anybody else that can round out those capabilities.
Luke Hohmann 09:05
Okay, great. So for everyone on the webinar, there’s a couple of things that I do want to reinforce. One more time, the competencies are stable, and were placed a little differently but the content is very stable. And the notion of the distinction, or the distinction between functions, competencies and roles. You’ll find those in other places in the framework, but we’re going to really be talking about product management. Marc talked to me about the left hand side which is now this notion of the responsibility will tell us about this and then how does that actually interact with who people collaborate with?
Marc Rix 09:43
Right so one of the big changes, big improvements that we made to SAFe 6.0 was we clarify the roles and responsibilities of every role. So now every role in SAFe, and we saw them as the little purple people along that left hand vertical bar of the big picture contains this responsibility wheel. So this clarifies the roles and responsibilities of those roles. And they’re fairly exhaustive but of course there’s flexibility in how those are achieved, and there’s a little bit of overlap among the roles so that shows where there are collaborations between the different roles. Here on the left hand side we see the responsibility wheel for product managers, and we’ll be stepping through this area by area starting with exploring Marcets and users. So this was our attempt at simplifying the roles, responsibilities, and clarifying the roles and responsibilities of each of the roles in SAFe but without oversimplifying them. So we still recognize that there are a lot of things that a lot of complexities that people in these roles encounter every day. They need to work through. They need to bring their own judgment, they need to use their big brains to apply these roles and responsibilities in contexts and organizations to achieve the best results for their environments. This is a great starting point for understanding the things that people in the product patent management function need to do.
Luke Hohmann 11:12
Yeah, and I what I like about the on the right hand side, when you look at the collaborations, if you have people who are still learning all of the nuances of SAFe 6.0, if we go to the individual articles, you can kind of see the other collaborations and you can actually put them together and start to see a map of how people can collaborate to create the best outcomes. Similarly, I want to point out the product owner article has a similar responsibility wheel and so does the RTE article and so does the system architect. So the level of consistency in the framework is now benefiting all of the individual places that people find themselves going. One of the nice things about the big picture is if you’re using SAFe 6.0 you can find yourself in the big picture. And then when you access the article, you can see okay, how am I doing relative to my collaborations? And sometimes it’s as simple as saying, Wow, I haven’t really, as a product manager, I haven’t talked with my business owners in a while and I should probably do that and then over on the responsibility. Well, you can see that reinforced with exploring Marcets and users or collaborating with customers to make sure that you’re fulfilling the collaborations and the responsibilities and it’s kind of a nice structure for all of the different individuals associated with a successful implementation of SAFe.
Marc Rix 12:39
Right. Oh, yeah. I love how you describe that as a map, you can start to sort of see a map of collaborations to the framework. And that’s absolutely right. And I’m really glad that you said that because that was one of the intents right now we can start to see a lattice or a network of relationships that really makes accelerated value delivery possible. These roles, these functions don’t operate in a vacuum. There’s collaboration and interaction all over the place, and we think this helps map it out.
Luke Hohmann 13:07
Yeah, and I think that’s one thing that people sometimes don’t quite understand. About. The big picture is that the big picture is a representational overlay on an interesting and complex set of knowledge. There are other representational overlays and one of those would be this collaborative overlay, like who collaborates with whom? How are the collaborations most naturally structured to create the right outcomes? As you said, in the last slide, those outcomes at every level how do we deliver value at every level? And that is not what the big picture is for. But if you look at the articles and you look at these imagery, you can see the consistency for each article. And so there’s these other representational formats that are embedded in the articles and embedded in the framework. And that’s, I think that’s something that’s really exciting. If we were to dig into our first one, let’s talk about exploring and what Marc said is we’re going to kind of go around each wheel. And we have a little Google icon for our map so we know where we are. So here we’re talking about exploring Marcets and users’ Marc. These are the four things that are in the article. We’re not going to go through the article itself but talk to us a little bit about these four key elements.
Marc Rix 14:25
There’s so the cycle starts here. And first of all, there’s a reason why these responsibility wheels are wheels, their circles, their continuous virtuous cycles, right? There isn’t a definitive start and an end but these roles and responsibilities have worked together to deliver outputs and outcomes that deliver value and contribute value in a lot of different places. But there isn’t a start and end like there’s a start and an end to a project. This is continuous and virtuous throughout the product life cycle. So if we start here, if we drop a pin on exploring Marcets and users, this is where product management works to understand what’s going on in the Marcet. What are the trends? Where’s the puck going? So if one of our jobs is to be able to sense opportunities and threats in the Marcet and help steer organizations towards success, and the solution is the products that are really going to move the needle on, on business, agility and customer engagement and retention and loyalty and revenue and all of those really great things that are going to give us a competitive advantage in the digital age. Well, we need to be able to kind of see around corners, right? Well, where does that start? For us? It starts here with the ability to explore Marcets and users. What are the macro trends? What are the micro trends going on? So there’s a lot of research and surveying that happens here. We’re conducting primary research secondary research, understanding what the analysts are saying reading reports. Gathering our own data from our own systems, whether it’s big data, or our system analytics or application telemetry, bringing that in, we’re using that to apply Marcet segmentation because maybe not all of our users in all of our regions have the same thinking and behavior. So we need to understand where the problem is, where the trends are happening, what Marcets and segments that we want to address and which ones we don’t want to address. What are the Marcet rhythms and events in other words, what are the big cycles in the Marcet maybe a seasonal trends, holiday trends you know, those kinds of things that that we need to plan for in the Marcet that irregular cycles or or industry events, you know, trade shows, or competitors releases that we need to start planning around and have on the on the roadmap, and of course, understanding end users needed and we’ll get into understanding the needs of customers and users a little bit more in depth in later wheels. But this is kind of where everything starts. And in agile in general, we really believe in hypothesis driven development or what is the hypothesis. Let’s go test it let’s go validate. Let’s go validate it, but the insights that produce those hypotheses need to come from somewhere and this is where it is.
Luke Hohmann 17:13
Yet I I think it’s important to highlight just briefly this notion of the Marcet events and Marcet rhythms. In SAFe we know that we can release on demand and releasing on demand is kind of a combination of organizational and technical capabilities. But just because I can release on demand doesn’t necessarily mean that it’s the best time to release or the best structure to release for our users. And I think that was one of the subtle points. Marc, when I was reading some of these SAFe 6.0 articles, I was actually quite pleased to see that there was some subtle language about when we say release on demand, we also mean that you’re releasing in a way that provides genuine value to users. And the way I like to describe it is I grew up in Buffalo. I know you’re living in Maui. Well, if you’re living in Maui, you can put swimsuits out for sale. Anytime because people go to Maui, there’s always a need for swimsuits, but I grew up in Buffalo, and no one’s buying swimsuits in January and buffalo they’re buying snow shovels. And so could I release swimsuits in Buffalo shore fast fashion retailers can basically drop out clothing at any time, anywhere. Would I have any validity in that Marcet or any need within that Marcet to put swimsuits in January? No but in Hawaii, well, tourists come in, they may forget their swimsuit. It’s always nice if you can always go swimming. So the idea of this notion of Marcet rhythms and Marcet events through this research really gives business leaders the opportunity to position themselves for greater success. So I love the fact that we’re starting here. And we’re understanding that for us, when we think about Marcets and users we kind of frame our world and profit streams in terms of the entire solution lifecycle. And this is also in SAFe APM where we’re looking at that notion of research and on those new solution development, which is prior to launch. We’re really looking at how value is quantified and what should the pricing model be for our solutions that are being offered to the Marcet through a price. Then after I’ve launched, I’m driving up the S shaped curve of adoption. The research is looking at what Marc was talking about, like what are the trends and how are things changing and how do we look around the corner and what are those feature needs? So there’s a full solution lifecycle that’s associated with this step. I’ve mentioned profit streams. So there was a point in our conversation that we have to define what we mean by a profit stream and we think of the profit stream as the evolution of a value stream, meaning it’s a profit stream is a value stream that is specifically designed to create a sustainable business. Typically, this is not associated with the development value stream, but this is typically more associated with the operational value stream at the end user. So we have to actually quantify the economic value so we don’t have to even we have to go beyond just saying we’re providing value, we have to actually put a number on it, because that number is going to inform the pricing and licensing choices we make and therefore the revenue and the costs, because I’ve got to have enough revenue to create a sustainable business and not of course, not just once, but over the evolution of that solution. So when we talk about profit stream design, we think of three kinds of sustainability. We think about solutions sustainability, we think about economic sustainability, and we think about relationships sustainability, if you’re delivering value through a value stream over time, then you have a relationship with those customers. They can be internal customers, they can be external customers, when you’re moving into the world of actually selling solutions. Well now the relationship that you’re creating is with those customers who are actually paying you money. And so that relationship evolves and it includes additional elements, things like support, or customer care. Those elements are part of that relationship sustainability. So we wanted to kind of put a placeholder in the deck so that we can start to integrate, how profit stream design, and how profit streams build on top of what is happening and say, when you think about the next solution, this is where I think it can be really interesting. When I have an S shaped curve of adoption. Over time, I’m going to have the solution be replaced with a new solution. Well, if I’m in a growing industry, my job is to motivate customers to adopt the new solution because I’m still going up that curve or growing up the curve. If I’ve got a very stable industry, well, that might be more characterized where competitors are taking Marcet share from each other. And if I’m in a declining industry, a smart company can still make a profit. But now my emphasis and how I’m using things like development value streams, where my implementation of safe is gonna be a little different. I might be exiting an industry, I still may be releasing modifications to my solution or new solutions, but I’m doing it in the awareness that my industry is actually declining. But I can still make a profit. And that’s the word that is throughout all of these pictures is how are you making profit over the course of the solution lifecycle, we want to make a profit, ideally at every step of the way. Sometimes it’s a little tricky. Because in the very first release of an offering and Tony Fidel’s new book bill talks about this quite quite eloquently, where the very first release of the iPod wasn’t profitable, but by the third release, they knew it would be and they had designed unit profitability into the initial model. So this is some of those things that go into this understanding of what we mean by profit. Let’s bring it back to the next part of the responsibility. We all have this notion that I’ve done my exploring of Marcets and users. Now I really want to connect with the customer.
Marc Rix 23:41
Right so I love the extra color that you put on the exploring Marcets and users segment, especially in relation to profit streams and you know, in SAFe we emphasize value streams, you’ve taken that a step further with profit streams, but fundamentally they follow sort of the same profile, right? We’re delivering value at the end of the day with profit two streams. That’s that’s hard money, right? That’s profit back to the company with value streams. That value could be in the form of many different things. But I think what, what I took away from what you just said, Luke, was that with exploring Marcets and users, we really need to understand what the Marcet is doing because that changes the shape of our curves and changes the nature of the phases that we are in the product life cycle, and it changes, sort of the dynamics and the profiles of our of our customers and Marcets. All of that is shifting constantly. So we need to understand what our Marcets and users are doing out there before we even begin to think about solutions.
Luke Hohmann 24:43
Yeah, that’s all baked into the very first part of the wheel when we’re talking about exploring Marcets and users and SAFe. That SAFe is in a sense, the largest possible perspective, because we’re talking about it could be internal users and Marc, one of the examples that I’ve used in my SAFe classes is, let’s say that your ups and the driver comes to your door and they have that terminal that you sign. Well, UPS source that terminal from symbol technologies, but they put their own spin on it and because they make enough of them and they have their own software. So that’s an internal customer. And you have to go through the same set of research we have to know for my drivers. What language do my drivers speak do my drivers need? terminals with different capabilities depending on what they’re delivering. And what if the driver is driving in Alaska where they’re wearing gloves and what if they’re driving in a way where the terminal might be subjected to saltwater or corrosive elements or what if they’re driving in Arizona where it could get hot on the dashboard. So this notion of exploring Marcets and users in SAFe is inclusive of who your customer is. And with profit streams to your point, we narrow it to the external customers who are actually paying money but both of these competencies exist. So talk a little bit about connecting with the customer.
Marc Rix 26:12
Connecting with the customer. So I think this might be one of my favorite areas of the product management model in sales, and of course, we didn’t invent this. It’s got Design Thinking baked in. It’s got the idea of customer centricity baked in. We didn’t invent these things, but we brought them in because we firmly believe in them. And I think in a lot of ways this represents the secret sauce of Product Management. This is really the secret weapon. So if you really understand your customers, you know them better than anybody else. You will win. I think that’s the game we’re playing right now. Right? Who can attract and retain customers who can turn you know prospects and leads into loyal customers? There’s some magic to that, there’s some art to that, there’s some science to that and I think that comes from really connecting with the customer and understanding their wants and needs. And that’s what this part of the responsibility wheel is all about. So, first, of course, we need to have a customer centric mindset. We want customers to be at the center of every decision we make. We want to be able to justify every decision we make through the product life cycle based on what the customers want, and need. We need to be able to empathize with them right we need to understand their wants, their needs, their desires, their pains, their gains, their fears, what are they going through, empathize with them, you know, put, product managers should be able to put themselves into the shoes of and the minds of their customers, not just from a research standpoint, but from an interpersonal standpoint, right. We believe we believe a lot in gumbo. Let’s go see how our users and our customers are interacting in their environment and their solution context. And Luke, you’re going to be talking a lot about solution context here in a moment. So we’ll get more into that of course, we apply design thinking so that we really make sure that we understand the problem, and that we understand the right solutions that we’re building so that we know that we’re marching toward solutions that are desirable, viable, feasible and sustainable. And we’re going to involve that customer or those customers. And users continuously throughout the product life cycle. It’s not just during the analysis phase. It’s not just during discovery. It’s not a one and done event. But we are connected with the customer throughout the entire development lifecycle and throughout the entire product lifecycle.
Luke Hohmann 28:24
I want to point out when you were speaking I like to write down a couple of the keywords that you said and because these keywords are so critical to how SAFe works, but also profit streams when you talk about what customers want and need. And sometimes the distinction between a want and a need is that sometimes customers need something and they don’t actually know that they need it. They don’t understand the need and that’s part of the job of product management is to say, look, through this research and through this notion of a customer centric mindset, I’m actually identifying something they don’t even know they want, but they need it. And I think that that’s really exciting. I think the other element that’s really important here is in the previous discussion, you talked about the data that your systems might collect. That is actually a form of involving the customer continuously because if you are building telemetry into your systems, and you’ve got those customers using them, leveraging that Telemetry is actually a form of customer involvement, because it may not you especially if you’re building, say a solution on a web service that’s got 3 million users, you’re gonna talk to 3 million users and even a survey 3 million users. But you can look at your web logs, you can look at your analytics, you can look at your telemetry, you can look at your feature toggles and some of the other technical elements of solutioning. And those are all mechanisms whereby the customer is being involved. That may or may not be directly, but that indirect involvement is still continuous. And I think that that’s really exciting when you look at some of the other parts of the framework in terms of the technical practices. Let’s keep going and let’s talk about connecting for us connecting means understanding value and this is in say folk that thing that I want to particularly point out is we find at Applied frameworks that organizations working on value streams, often over emphasize tangible elements of value. And often, inadvertently, I don’t think it’s explicit but they inadvertently de-emphasize the intangible or the soft benefits. And an example would be We recently worked with a company, full cast to help them on some of their pricing and licensing. And one of their competitors is a large Silicon Valley company. And they said, Oh, we’re not sure we can charge as much as this other company, because we don’t have quite as many features. And he said, well tell me about the features. And those features were on the tangible side there were actually hard things the product did or didn’t do. And I started talking to the team and they said well, why if that’s the case, why are people buying from you mean of all you can say we are probably less feature rich than our competitor? Why would people buy from you? And like oh, well, we’re easier to work with. We’re more responsive. Our customer support team is more responsive and helps them. We’ve got services that go in and make sure the onboarding is more successful isn’t great. Why aren’t you valuing any of that because your customers clearly are and you could see these light bulbs go off that they were not recognizing the quantifiable aspects. of intangible value. And that’s an important part of this notion of how am I creating customer centricity? Well, it’s not just functional value or tangible value. It’s intangible, it’s soft, it’s that indirect or subjective value that is part of the equation. The second thing is to talk about a solution context. And this for me is one of my all time favorite parts of the framework because you just don’t see solution context, talked about in other methods. And when you and my favorite story to tell about solution context was one time I was talking with Dean about the design elements of solution contexts. Dean said, Look, if you’re building a weapon control system for a ship or a destroyer, you can’t control the ocean. And I said, Well, yeah, you can’t control the ocean. But as a product manager, I want to think about what I can control. And so when we think of it from a profit streams perspective, we think of it as I might have something in my solution context, so they can move into my solution and thereby provide more value. Or I might have something in my solution context that may not be quite are in my solution that may not be quite right. And I can move it from my solution into the context. And that may be to create more options for my customer. So the important part of a solution context is not just that your solution lives within a context. It’s that product managers through their research needs to know what parts of the solution context are amenable to design thinking. And then applying design thinking is to create that boundary between the solution in the solution context to design it to the advantage of the customer and the advantage of the business. The other element that we add in profit streams is the provider context. And it’s designed to be a reflexive or a complimentary part to the solution context, where we’re looking at those elements of value that are not necessarily part of the solution, but they are part of what you’re providing as the context. And this could be where that intangible benefit lives that notion of better support or better onboarding or a better website. Some people would say, well, support is part of the solution. Some people would say it’s part of the solution context. debatable, but the point is, is that you don’t have a solution without a provider context, offering that solution, and that’s part of the design of what you have in terms of, it’s part of your palette of design options. Let’s move on to defining product strategy, vision and roadmaps.
Marc Rix 34:32
Excellent. So we’ve explored Marcets and users, we’ve connected with the customer we’ve started to connect with the customer. We have a hypothesis that if we build something that will be of benefit or if we explore solutions in this area, it would be beneficial. We have a hypothesis that we could generate value or we could generate profits from an idea, right? Okay. Now it’s time to get real. We need to make some decisions. We need to go forward, right? We need to do just enough analysis, just enough research. Just enough connecting with the customer before we can actually start building something because after all, we’re agile, right? We need to do this fast. So we need to get to decisions. Even in an environment where there may still be a lot of unknowns there. There’s a lot of uncertainty left and of course in Agile we talk about the cone of uncertainty all the time, we’re not going to wait to build something until we have all of the blanks filled in all the answers. We need to pick a direction and go and this is where product management helps the organization pick a direction and go. So we need to make some decisions. We need to place some bets; they’re educated bets. But things are still a little bit foggy. So we use product strategy, vision and roadmaps to help align the organization and put stakes in the ground and set a direction. And in doing that we’re aligning strategy to business objectives. We’re aligning strategy to execution, we’re aligning business strategy and technology strategy. We’re making sure that there’s an equitable value exchange, which means that if we’re doing this for profit, we’re delivering value because we understand our customers and what they need. We also need to think about what we need in return. What do our enterprises need in return? Is that higher NPS scores? Is it higher customer satisfaction? Scores are at lower cost. Is it more revenue? So there’s gotta be a bidirectional exchange of value there, right? We’re customer centric, but we also need to be business centric, too. We are kept on so a big part of this is creating and communicating a compelling vision through this fog of uncertainty. How are we going to rally the organization and start to build this out and start to go forward with the site with this idea? When there’s still a lot of unknowns, we need to be able to educate and inspire teams around us in the organization, right, those that we collaborate with and those are accountable to and put together roadmaps that show how we’re going to incrementally involve evolve into that vision because these things don’t happen overnight. But we need to have a roadmap for how we intend to get there. But those roadmaps need to be flexible because we need to allow for change along the way.
Luke Hohmann 37:19
I love this. And what I think is kind of important here is that even though the responsibility wheel has a natural clock clockwise structure, the reality in practice is that as I’m exploring Marcets and users, I can start to develop a little bit of my vision like I’m starting to see and I’m starting to feel this vision. And then I apply some design thinking and I start to build out additional information. So what I like about this is that when you think about and what Marc said is, look, we need just enough and we’re gonna move fast. Yes. And we can start to create this vision right up front, but then we can kind of crystallize it and that clear and compelling vision isn’t just for our customers. It’s also for our team building this. They’re humans, they want to be inspired and they want to know their work matters. And so this notion of the vision and the roadmap is really both an internal rallying tool and an external reason for people to want to work with us. Now, Marc mentioned fog and we love that metaphor
Marc Rix38:30
Sorry if I stole your thunder.
Luke Hohmann 38:32
Yeah, no, no, it was a perfect setup. I thank you for it. When you think about how do you navigate fog, there’s a couple of options. If I’m hiking and it’s foggy, and where I live in San Francisco, it’s pretty foggy a lot. So the fog is starting to wonder like, how am I going to get there? Well, there’s really two kind of useful ways to navigate through a fog of uncertainty. You can create a Northstar that solution vision and you can use that to guide you. Or you can kind of rise above which is that in some ways, exploring Marcets and exploring users is rising above so I can understand the lay of the land and then create a roadmap that will help me navigate. We think of this as complex enough that you need multiple tools to get there. The strategic perspective is the industry life cycle. What industry Am I in? And is the industry itself rising and how fast is it driving? We’ve gone from nothing to 100 miles an hour and generative AI and of course the industry life cycle of telephony is still here. It’s been around for decades, cars have been here for decades now. We’re seeing a new sub industry of electric vehicles or electric cars kind of springing it. So these industry life cycles happen. There’s the solution lifecycle, which is where my solution is relative to the industry. Then we have a couple of other elements. We have proven the product tree, which is a way of organizing and emphasizing growth. And we have the solution roadmap, which is also aligned with the safe solution roadmap, which is I’m capturing my plan commitments, milestones and releases, typically for one to three years and if you read the safe roadmap article, it’s very pragmatic. Yes, we want to minimize commitments because commitments can reduce agility. However, there are commitments that we need to make in order to serve our Marcet if there’s a regulatory change. And I’m in the healthcare Marcet. I have a commitment to my customers to honor the regulatory change and my customers are going to want to see that commitment on my roadmap. So when we think about roadmaps, we want to be pragmatic. They’re their important tools. Then, of course, we have the solution backlog and we have that Northstar solution vision. When we think about the equitable value exchange, then we talk about profit over time. This is what I was talking about earlier. I might have the notion of starting my development, and that dotted line represents the launch. Imagine that launch Word was just a little bit over to the dotted line. The notion of my costs right off the bat the moment I start my development, I’m incurring costs and the costs are going to occur over the solution lifecycle when I stop selling my offering, I still am incurring costs until it’s fully decommissioned. The cumulative profits start after this sales revenue has covered the amount of my initial investment. So these different curves and these different flows are part of where that profit stream comes in. Because that equitable value exchange or offerings in the Marcet need to incorporate the notion of time and profits over time. Talk to me now that I’ve got my I’ve understood my Marcets and users, I’ve connected with the customers. I’ve got a vision, I’ve got my strategy, I’ve got my roadmap. Now I kind of get stuff done.
Marc Rix 42:11
Got to get it done, ready to be done. And you know, we’d like to say in Agile if it’s not in the backlog, it doesn’t get done. So if we’re gonna get stuff done, it’s got to be in the backlog. This is something I learned very early on in my agile career. I had to be trained in this but once I was trained in it, I’ve never backed away from it. So if it’s in the backlog, it may get done doesn’t mean it’s guaranteed to get done. But if it’s not in the backlog, it’s guaranteed not to get done. And I know Luke, you have other forms of backlogs that you’d like to talk about, but maybe that’s a different webinar.
Luke Hohmann 42:46
Well, okay, I’ll add it in. I have what I call the dream log, which is my aspirations. And that’s good. It’s okay to have a dream log. And then I have what I call the hidden log or the dark log. And in the dark log is when an organization is transitioning to say, they sometimes are doing work that is not visible, as though the product people are working with their development teams. And they’re saying, How come we’re not moving faster? And how come we’re not getting things done? And what they don’t realize is that the teams are fixing bugs, or they’re dealing with deployment issues, or the deployment process is too long, but it’s not in the backlog. And so it’s not visible, and if it’s not visible, it shouldn’t be done. But to keep the company running, many times the development teams will do the dark log. And that dark log is that hidden work and we want to make it transparent and to Marc’s point, it is one of the single best practices of any form of Agile is to make the work visible on the backlog. Now Marc over here, you’ve got something that I think is actually quite important, and I’d love to talk a little bit about this notion of supporting the architectural runway. Why would a product manager kind of care about that technical stuff?
Marc Rix 44:06
Well, let’s talk about what an architectural runway is first. For those listeners and viewers who may not be familiar with it. So the architectural runway represents essentially the infrastructure that allows us to develop and deliver solutions fast. It’s one thing to have an idea about a groundbreaking solution that we think is a great idea that the Marcet needs and we’ve done all our research, we’ve come to this point we realized Yeah, if we build it, they will come. Well, sometimes the question then has to be can we build it? Can we support it? Can we actually get it out the door? Do we have the infrastructure? Do we have the runway, do we have the pipeline? Do we have the people in the skills to be able to get it done? So when I think about design thinking and the need to create desirable, viable, feasible and sustainable solutions? For me, an Architectural runway really helps to define the feasibility aspects. So if we are asking questions about can we feasibly deliver and support this idea, sometimes we need architecture or runway, which is you know, that infrastructure that enabling infrastructure to allow us to be able to build and deliver it. So if product management is coming up with big ideas and committing to solutions, that we can’t feasibly deliver and maintain, we have a problem.
Luke Hohmann 45:25
So that could manifest itself in things like, hey, I want to offer my solution in a different country. And then through analysis, the technical team says, Hey, that different countries have different data laws. It has data sovereignty laws, and our solution doesn’t support that. That’s where this notion of architectural runway, in terms of the capacity, the capability to be efficient. In delivering that value delivering those features comes into play. And I think that that’s really one of the highlights of SAFe is that we really look at that as part of where we’re at making explicit investments.
Marc Rix 46:07
I think another example, yesterday for winning really quickly that I think is a hot topic. Right now is AI everybody’s thinking about AI these days, right? So I see many of our customers and partners now clamoring for solutions to AI related problems or they need an AI solution, because they want to compete and everybody else is doing it right. That’s a natural reaction to what’s happening in the environment right now. But one of the questions is, okay, if we want to build AI solutions, we need some intelligence here. We need predictive analytics here. We need something in this realm. One of the questions that should be asked is can we support that? Do we have a machine learning pipeline? Do we have the cloud infrastructure that will allow us to do that? Do we have the datasets that will allow us to build and operate those machine learning pipelines and those those AI solutions, just as another example,
Luke Hohmann 47:00
yeah, it’s a perfect example and it feeds right into the next slide. Perceptions of value of the features that we’re building and the features that we have built and maybe build again, change over time. This is kind of a lot of words and I wasn’t sure how to exactly simplify it. But on the left hand side at the top, we have this notion of there is and I’m going to try and draw a little bit on my screen right now. Here, this is the minimum amount of value the customer must have. And this is the maximum amount of value my system or solution can produce, given the technology I’m using and this dotted line means that I am okay. I am I don’t need to go above that line to deliver value to my customer and so this says I am delivering more value than the minimum required therefore my solution is okay. The problem is that when things like AI get introduced, the introduction of a new technology that increases performance can say that this minimum bar that the customer had now is up here. Chat technology has made dramatic improvements. The old chat of three years ago is no longer good enough. I have to have a chat GPT Power Chat. Customers expect more overtime on the consumer side. We expect better TVs and faster and cheaper phones and tech infused clothing and better lives on the business side. We expect improved worker productivity, we expect lower costs, we expect greater performance and so we have to be able to take those insights and take those elements and improve them over time. Now the next thing that we have to be aware of, in terms of our work here, is that we have to figure out how we prioritize our work. We’ve got features, and we talk about prioritization and wisdom. When we think about prioritizing work in a profit stream, we kind of organize it in three basic buckets. There’s work that’s designed to bring in new customers. There’s investments designed to leverage the profit engines of existing customers and we define a profit engine as repeated transactions or larger transactions with the same customer. So the profit engine is what drives repeated transactions or larger transactions. And then of course, there’s operations. Those investments are typically technical investments that are designed to lower our cost model or lower are typically lower our cost model or improve our efficiency. So we think of these three big buckets when we’re prioritizing for profit. The last part of the wheel is delivering value. We’ve done all this work, we built some stuff. Now we deliver the value.
Marc Rix 50:03
All right, this is where the rubber meets the road. Right? Have we done our job? Are we delivering value? I don’t know about you, Luke, but I’ve been in so many situations where we thought we had a really great idea. We built it and sometimes that took 12 months 18 months, right? This was back in the old days. We deliver it and nobody shows up. So we want to avoid that. That’s so avoiding that situation is largely the reason why we do all of these other things. We understand the Marcets, we understand the users their wants and their needs and sometimes to your point Luke earlier, we need to help them understand what they desire, so we can build that desirability into the solution. Right? Okay, so we’re delivering value. Now. It all comes down to this, did we deliver and are we getting the results? So in SAFe we have a continuous delivery pipeline, right? And that’s divided into four segments. So this kind of represents the path from idea to delivery. We go through continuous exploration and a lot of the early parts of this we’ll connect to continuous exploration of what’s the hypothesis, we need to collaborate with others on understanding the problem domain so that we can start to craft a solution domain and some solution concepts and ideas. Then we move into more of a build phase where we’re doing continuous integration and continuous deployment, ci CD and DevOps capabilities come into play at this point, product management is still involved in that and guiding and then we end with a phase with a continuous delivery pipeline called release on demand. And that release on demand step is kind of what we bring into focus here at the delivering value step. To deliver value means that we need to release but we’re not going to release and walk away. The release event itself. Could be a button click. It’s the flip of a toggle, it may be the switch from from blue to green and the infrastructure. So the release event itself should be pretty non dramatic. But that doesn’t mean we’re going to release and walk away. We need to understand where the value is coming from. We need to be able to quantify that measure so we’re going to release it. We’re going to support it so the product management has a job and helping the organization support that solution in the Marcet. That’s where enabling operations comes into play. We also need to be able to measure the effects. What’s happening, you know, what, how are our systems responding to this? How are our users responding to this? How are customers responding to this? are we generating the value that we define this kind of connects back to your previous slide right are we getting are we are the profits starting to roll in? Are the cost reduction starting to roll in? Is user acquisition or customer acquisition starting to roll in? Whatever our hypothesis what was about the value that we needed to create or derive is starting to play out here. We need to be able to watch that monitor and measure it and learn from those experiences so that we can feed you know relentless improvement ideas back into the cycle.
Luke Hohmann 53:02
And this of course, links what we did when we talked with the beginning about exploring Marcets and users and starting to understand those rhythms and events, and then putting those into the roadmap so that we can communicate to the organization Canada, this is where we’re headed. This is the opportune time and here we can put it into action as you said, where the proverbial rubber meets the road like we’re really driving this forward. A couple aspects that we bring into the are a couple of extensions that we make into this notion of delivering value is imagine I’m delivering value. Well, delivery of value is an event and that event can be recast as a trigger. So what kind of triggers exist and how do I respond to the triggers? Well, time is a trigger. And when we look at time, this notion of cadence, this notion of delivering many, many safe shops, they’re just on a cadence they release every sprint are they release every pie, but they’re on a time based cadence. Sometimes there are external triggers that motivate us to make changes or release value. And sometimes there’s those internal triggers, in the sense that we’ve decided that we’re going to adopt a new supplier technology, that that new supplier technology is a trigger that we can release more value. As I start to look at the value that we’re releasing well, over time, presumably if I’m creating more value for my customers, maybe I want to adjust my pricing and if I’m releasing more value into the existing solution, maybe I want to package it differently. We don’t have enough time to talk about these in great detail. So I just want to talk about adjusting packaging. Think of your solution as that shaped box and I’m adding features I add some more features. I’ve got even more features, but sometimes simply stuffing more features into a box does not meet customer needs because eventually it gets too much of the goes. So what we sometimes need to do as solution providers or as product managers, is we need to look at that box that has these features and say hey, wait a minute. We got to pull these apart. And I’ll give you an example. We worked with a company that creates construction management software. They were a startup and they’ve been growing very well and they hit a million dollars in annual recurring revenue. And they got their first VC investment because they hit that kind of magic threshold. Well, what happened was the company had been in business for three years, and they just kept on putting more and more and more features into their solution. And they were actually paradoxically starting to see a decrease in conversions. And what we looked at was we realized that the solution had accumulated features that were for plumbers for small contractors for large contractors, and all it needed to do was take one packaging and create three packaging, one for small contractors, one for midsize contractors, one for large contractors because they have different needs. And by adjusting the packaging through the accumulation of features over time, they were able to increase sales again. And so there’s options that you get when you’re working with sales that enable you to say, look, we’re adding more value, we may need to package our value differently to better meet the Marcet needs. So there’s a six step process to adjust packaging. You want to understand the triggers, create a snapshot of where you are, gather the data needed, if you have already gathered that data, design the new packaging and pricing, develop the implementation plan and then go ahead and implement those changes. So as a kind of, there is a process to doing this not just saying hey, let’s change the packaging. Okay, we’ve got time, Laura, I hope we still have time for maybe one or two questions that are either in the chat or in the q&a.
Laura Caldie 57:11
Um, yeah,
Marc Rix 57:12
I think that’s about as many as we have.
Laura Caldie 57:15
We do so early one. Katherine has been patient. I’m just wondering, she asked about customer centricity mean the focus in the PM article. Can you describe why designer or designer is not mentioned in the key collaborations area and what’s your personal I’m adding this What’s your perspective on the role of designer?
Marc Rix 57:35
Yeah, absolutely. So thank you, Catherine, for adding that in. Yeah, we don’t explicitly call out designer as part of the product management function as part of the customer centricity function only because designer is not an explicit role and SAFe, so where you see the graphics the the visualizations that show SAFe roles can I can to other SAFe roles, the only reason designer isn’t in there is because designer is not an explicit role in safe. That doesn’t mean that designers don’t have a place and SAFe they absolutely do. And we believe in Lean UX. We believe in good product design, we believe in human centric design. So designers are a very, very important part of the cycle who should be you know, linked to the product management function somehow either directly or indirectly and yes, definitely have a customer centric point of view and mindset and set of activities. That add a lot of value to the cycle.
Laura Caldie 58:32
Luke, is there anything you want to add or should I move to my dark blog question?
Luke Hohmann 58:36
No, I agree with Marcing customers interested in design and design. I think it’s also challenging for the framework team and I’m not a member of the framework team anymore, but I will, I will kind of channel some of my former Mojo on behalf of the framework team. Safe is used in an enormously large number of contexts. And in some of those contexts, the design role isn’t as prominent and so when you look at the different roles that a given enterprise might need to have it can get overwhelming, and that’s not the purpose of the framework, right? The purpose of the framework is to say these are the most essential aspects that are most broadly applicable to the most. The broadest number of enterprises. Any given enterprise might have a unique need for emphasizing a particular capability or role and that’s pretty common. Yeah, but let’s go on to the to one of the other ones Laura,
Laura Caldie 59:36
okay, so there’s two, maybe this one’s quick. How do you balance opposing features? One example could be performance versus a feature.
Luke Hohmann 59:45
I’ll field that one because it happens all the time in my work. The first is that you’re going to apply WSJF to create an economic prioritization. And the second is after WSJF has been applied and you know what your priorities are, you’re going to look at your capacity allocation. Guidelines to make sure nothing’s star. So when you run the WSJF algorithm, it is possible that the first 15 items in your backlog from WSJF are all new features and no architectural investments. The way I think of it is to make sure that you’re making a balanced investment, your use capacity allocation. So you’re going to go down your backlog and say how much capacity do you have for these new features? And I’m done. Now I’m going to look at my capacity associated with technical commitments or technical investments, and I’m going to pick those up in priority order. It’s not changing the priority, but it’s making sure that you’re creating a balanced investment in your solution and that that notion of capacity allocation guidelines, those are in the safe articles, it’s really quite, quite important.
Laura Caldie 1:00:48
Um, we are at the top of the hour, but just for fun, I’m going to throw you one more question. And then for everyone who still has them, it’s worth your time to type them in because when we send out the recording, we add some answers to the questions that we weren’t able to touch upon. So feel free to throw us some more because you’ll get them in the follow up. So the other question, it was just about that I mentioned that we talked about the dark lag. The question from this person is how to make the integration workstream not just look at as a technical solution, but more as a product itself.
Luke Hohmann 1:01:24
Well, the former architect of the continual wee platform and is now part of the architecture team is safe in terms of the virtual classroom and safe studio, and his name is Dan O’Leary. And what Dan taught me is that when technical leaders collaborate with product managers, they can almost always show how technical work or integration work is actually creating value for customers. And so from that perspective, what he taught me was that you could always find a way to make the integration work look like and not just look alike, but really be reframed as directly benefiting the customers. And so, I think that that’s just a minor kind of semantic, and with a little bit of work you can get there.
Laura Caldie 1:02:16
All right. I think we’ll call it a wrap on that. I appreciate your time Luke and Marc. This was really interesting for me and I know everybody else on the call found value and parts if not all, if not the whole thing. So I hope we can get together again, we will be sending out the recording to this shortly in the next couple of days. And like I said that the questions that were not fully answered, we’ll take a crack at those in the follow up email, Marc or Luke, any parting words before we let you go?
Marc Rix 1:02:45
Just thanks to everyone. Thanks, Luke. Thanks, Laura, for having me over. And thanks for thanks to everyone for tuning in. This has been great.
Luke Hohmann 1:02:51
Thank you everyone.
Laura Caldie 1:02:53
Have a good one.