Episode 113: Answering Questions About SAFe 6.0, Improving Alignment Between Project Managers, and Implementing OKRs Successfully

In this Dear Melissa segment, Melissa Perri answers subscribers’ questions about changes and new features in SAFe 6.0, how to improve alignment and transparency between project managers on the same team while meeting the needs of the different stakeholders, and what it takes to implement business OKRs successfully.

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

Q&A:

Q: I just finished a significant dev project in the FinTech industry. There were about thirty-five product managers in the company. I took a role as a senior product manager, and they made everyone go through SAFe. Their commitment to SAFe was about a ten, and their commitment to outcomes was about a two. So what is the deal with SAFe? Have you seen this improved output in any of your encounters with it? It didn't seem agile or lean to me.

A: I have not seen anybody actually succeed in implementing SAFe in a way where we focus more on the outcomes instead of doing the actual process. People turn to SAFe because they want the instruction manual. But the problem with that is they stop thinking for themselves about what is right and wrong and whether we are actually delivering outcomes. And that's my biggest issue with it. But this is a great time to look at SAFe 6.0 and see what's happening here.

Q: I'm a product operations manager at a medium size company operating in the field of digital health. The company has been growing fast in the last couple of years, and the number of PMs and projects has also grown, making it more difficult to collaborate and stay. ...To improve alignment between the main people involved in those areas, we decided to form a PM designer's team. The team currently includes five product managers, including senior and junior PMs, and is led by a Head of Product, as well as three designers and senior designers led by a Head of Design. However, we've been struggling to identify how to set up things to become a well-functioning team. ...On the other hand, the team has an urgent need to align on the product roadmap, but we haven't found an effective way of doing that yet. Do you have any recommendations on how to set up this kind of team while meeting the needs of the different stakeholders? What kind of virtuals and processes could help us?

A: The main idea behind product operations is one of enablement, not micromanagement. When you think of product operations, cadences and governance are a big part of your role, and it's about getting the right people in the right room so that you can review the things that you need. Now, if you have this new product management and design team, the leaders will want some transparency in the roadmap. But they don't need to know everybody's tiny task. Here’s what I think could help your team.

Q: Our tech department is small and in the growth stage, and we have recently implemented business OKRs with key results, but we're not sure what to do next. We don't have the team structure set up correctly. We don't empower the teams. We don't seem to have a product or business strategy for digital products. How would you approach a situation with our product lead and stakeholders?

A: If there's no guiding strategy, how did you come up with the OKRs? To me, they're probably going to be a little messy, and they're not gonna be focused on the outcomes we are trying to achieve. People put the OKRs all on the team level and don't roll them up. You should have three levels of OKRs that roll up to the business goals. So that might be a good place to start with your business leads and stakeholders.

Resources:

Melissa Perri on LinkedIn | Twitter

MelissaPerri.com | CPO Accelerator

Transcript:

Hello and welcome to another episode of Dear Melissa. Well, last week they introduced SAFe 6.0 and made some changes. So, you know we’re going to talk about that on today’s episode. So I’ve got a question for you on SAFe. I’ve got questions on product ops that we’re going to address and then also we’re going to talk about implementing OKR as well. And what do you do once you implement OKRs? So let’s start with one of our favorite topics that everybody likes to keep asking about, SAFe. And we will go to the phones and answer this question. Dear Melissa, I just finished a significant dev project in the fintech industry. There were about 35 product managers in the company. I took a role as a senior product manager and they made everyone go through SAFe. Their commitment to SAFe was about a 10 and their commitment to outcomes was about a 2. So what is the deal with SAFe? Have you seen this improved output in any of your encounters with it? It didn’t seem agile or lean to me. I’m cackling because I think you just summed up SAFe in a sentence. Okay, so like I mentioned at the beginning, they did just introduce SAFe 6.0. So I had to go read it for you. I had to go look and see what was going on with especially the product management functions. Because, you know, if you’ve been listening to this podcast that I care a lot about that and I do care about people implementing product correctly. And from what I see, anybody who implements SAFe has not done this correctly. So let’s go look at what SAFe 6.0 changed. So I’ve read the blog post on it. Honestly, I couldn’t tell too many differences. I did dive into product management versus product owners and they did clear up a little bit of the product owner versus product management misconceptions. So before in early versions of SAFe, they really kept it separate where only product managers talked to the customer. And then the product owners really had nothing to do with the customer value pieces. They were just kind of taking requirements from product managers and breaking them down and building them. That seems to be fixed a little bit because they did add in those descriptions that product owners should be looking at customer value and talking to customers and focusing on them and understanding their needs and thinking and feeling like a customer. So that made me a little bit happy. What I don’t like about this still is they do keep product management and product owners separate as two different roles when honestly, it’s just about getting more mature in your job, right? Like you go from being a product manager on a team to a director of product. And I think what they describe in SAFe as a product manager is exactly what a director of product, a person who’s like a product manager of product managers on teams should be doing. They should be defining the roadmap, identifying the problems and opportunities from a higher level standpoint, helping to scope that and handing those problems over to the product owners to figure out what are we going to build, and steering larger term solutions around completion. So that’s really what should be going there. So I don’t know why this is separated in SAFe. This is really weird and I feel like people pick this up and then think they’re all different roles. The other thing that I noticed on this round too, is they also have above the product manager, what do we call it? A solution manager. So they’ve got solution managers now too. So we’ve got product owners, product managers, solution managers, and then we got the executive team just kind of like floating around on the top side of the SAFe framework up in the left hand corner. This does not make sense to me. That’s usually a solution person who’s like overseeing all that is like a VP of product or a CPO who’s looking at the solutions or the product roadmaps or all the products in conjunction across many things and guiding everybody to deliver those things. So this is super weird that this is, again, yet another role, yet another job description in SAFe. So I have not seen huge strides in any of those things becoming more clear. It feels like we just keep adding things in. Also, it has been six iterations of SAFe and yet designers are barely mentioned on this diagram. It says product management, release train engineers, and system architects are the agile product delivery and then the team and technical agility is product owner, scrum master, team coach, and the agile teams. And I guess designers fall under there, but we need a VP of Design. They should be in here, there should be a head of UX. These people should be crafting solutions and these whole design ideas and systems with everybody and they’re never included in this. So to me that’s super, super strange. And now we have an art flow which is all about starting the release trains and that’s where we’re kind of just like plugging some design thinking and lean UX in in this thing. So, you know, to get back to this question, I know I just kind of broke down a lot of this. No, I have not seen anybody actually have success in implementing SAFe in a way where we focus more on the outcomes instead of doing the actual process. And that’s the problem with SAFe. It was designed to give everybody a role in a little spot where they could control so that big organizations could start to organize around a very, very specific framework and have step by step goals on what to do or step by step instructions. Right? It’s basically handing people a recipe for making cookies. And they’re like, this is how you make software. So that’s what SAFe was designed to do. And that’s why organizations pick it up, because it is the best documented, and I’ve heard this from people, it’s the best documentation of all the instructions on what every little thing needs to do. So that’s why people turn to SAFe is because they want the instruction manual. But the problem with that is then they stop thinking for themselves about what’s right and what’s wrong and are we actually delivering value? And that’s my biggest issue with it. I’ve seen a lot of companies actually recently get rid of SAFe. I’ve seen a lot of them turning away from having as many scrum masters and instead letting the teams kind of self organize around those things. I have not seen anybody who implements SAFe, though, really focusing on the outcomes like you said. So that’s why I laughed when I read this, because I’m like, yes, that’s true, but this is a great time to actually look at SAFe 6.0 and see what’s happening here. I like the ideas they come up with, like PI planning. I’ve seen PI planning be really cool where everybody gets in the room and talks about things we should be doing that we should be getting together across all the teams and saying, here’s our roadmaps. Where are there dependencies? What are we going to have to collaborate around? Especially when we have a lot of overlap in larger companies. But what I feel like happens with SAFe is every time we iterate on it, every time they iterate on it. I’m not involved in this, but every time they iterate on it, it feels like they’re getting closer and closer to just describing what good product management should be doing every single time. And if you are a VP of product or work in a company that’s a high functioning product organization, you’re going to look at this and be like, yeah, that’s what we do. Why did it take you six times to come up with this? It’s because they keep making it other people’s jobs or they just associate it to a new role that they came up with and act like it’s novel and that’s not true. People have been building great products at scale for a very long time. A lot of this stuff feels like it’s reinventing the wheel that doesn’t need to be reinvented. So I just hate that every time we go through an iteration of SAFe, it’s like, hey, and we came up with this new cool thing that’s going to belong to this new role we made over here. And it’s product management. It’s literally what heads of product do. So this is why I don’t love SAFe. I just feel like it forgets it puts so much process into things. It forgets about the outcomes, it distracts people from it. And I haven’t seen anybody successfully adopt it in the long term to produce outcomes. That doesn’t mean that there aren’t people out there using it well. It’s just that I’ve never come across a really well functioning product organization that has implemented this successfully with all the pieces that they have and delivered on outcomes. So if you’re skeptical, it’s probably right that most of these organizations, as you said, is their commitment to SAFe was about a 10 and their commitment to outcomes was about a 2. That’s true. But that’s why people adopt it is because they give them an instruction manual on how to make software and people want the instruction manual and they want to follow all the rules and they think they’re going to be successful doing that. But in reality, a lot of this is taking iterations of what you’re doing and how you’re delivering software and having the self awareness as an organization to step back and say, is this working? Is this not working? And taking pieces of different frameworks and making them your own, that’s what leaders should be doing in all of these organizations. So if you were wondering, SAFe 6.0, I don’t think is much better than SAFe 5.0 or SAFe 4.0 when it comes to product management. But if you do want to hear a little bit more about SAFe, I did have Eric Willeke, who is a contributor to this framework, on the podcast a couple of months ago, we had two parts. We actually dove into SAFe pretty deeply. And if you’re like, is SAFe correct for us or should we be using SAFe? Eric breaks down where he thinks people have had good success with SAFe and where they have not. And I think it’s a really good eye-opening podcast for who should be adopting it and who should not be adopting it. So maybe go check that out if you’ve been wondering. But that’s my take on SAFe. Not much of an improvement in my opinion. All right, second question. Dear Melissa, I’m a product operations manager at a medium sized company operating the field of digital health. The company has been growing fast in the last couple of years and the number of PMs and projects have also grown, making it more difficult to collaborate and stay aligned at the same time, growing means that PMs can now focus more on strategy, discovery and research rather than on project management of the development teams. To improve alignment between the main people involved in those areas, we decided to form a PM designer’s team. The team currently includes five product managers, including both senior and junior PMs and led by a head of product, as well as three designers, senior designers led by a head of design. However, we’ve been struggling at identifying how to set up things to become a well functioning team. For instance, our head of product and head of design expressed as priority having a way to check each team member’s tasks weekly. So we ended up meeting every Friday for an update on the status of the current tasks and to plan the next week. But that felt like micromanagement to some of us and not useful. On the other hand, the team has an urgent need to align on the product roadmap, but we haven’t found an effective way of doing that yet. Do you have any recommendations on how to set up this kind of team while meeting the needs of the different stakeholders? What kind of rituals and processes could help us? So the main idea behind product operations is one of enablement, not micromanagement. So when you’re thinking of product operations, cadences and governance is a big part of your role. And it’s about getting the right people in the right room so that you can review the things that you need. Now, if you’ve got now this new product management team and now you’ve got this design team, the leaders are going to want some transparency into what the roadmap is. But they don’t need to know everybody’s little tiny task. The way you can help some of that is one by putting in a transparent software tool that allows people to see what’s going on. So if they’re asking like, hey, we need to review the tasks, my first question is why the oversight there, right? Do they not trust their teams? Do they not give enough direction to their teams to actually be able to manage their own work within the teams? Are they just missing alignment between the teams, like what’s happening there? Or are they just new managers who are a little bit nervous? So the software tool I mentioned you could put in, it could be anything. It could be like a ProdPad, it could be a Dragonboat, it could be a Jira. But put something in there so that the head of product and the head of design can actually see what’s happening in those things but make sense of it. They don’t need to know. Move to button from this side of the page to the other side of the page. That’s too detailed. They need the roll up, right? They need that roadmap view, that prioritized problems view. That’s what they really need to see. So implement that for transparency is what I would say first. And then second, now we got to get everybody in the room to talk about. “Sre these the right priorities?” So what should be happening on a monthly basis is you want to run something like a roadmap review so you get all the teams in the room every month. And if you release slower, you can start to do this quarterly, but start monthly just so you can start talking to each other and have this alignment and get the teams to stand up there and say, what is it that we are going to be releasing soon? So what is almost done? Show that or what has been released. Show that and then what’s next on deck, what’s currently in the work and what’s next on deck, and talk about the priorities and talk about the outcomes, talk about the problems we’re going to solve there. Talk about the vision of those products that they’re actually scoping out. Make sure it’s not just like, yeah, we updated the CSV so that we’d have seven columns instead of six. That’s really detailed. Why? Why did they update that CSV? We’re making it easier for users to actually be able to track the status of their students in this program. So we put this other field on the CSV. That’s more of the whys there. So you got to bring that up high level and not just make it a task reporting on. Here’s all the work that we did and here’s the current tasks out there. Make them roll it up so that it actually contributes towards the outcomes. That’s going to help you then surface up and ask you questions in these meetings. Are these are right priorities? Are they actually focused on our overall goal as a company? Are there any dependencies between teams that we need to look at? Are there any issues because we have some overlap or are there any disagreements with these priorities? That’s where you really bring those up in those meetings. So that’s what I would really put in there. But your leaders need to get out of the weeds of reviewing tasks and it sounds like maybe they might be new to this job. And if so, you want them to be focused on the overall roadmaps, aligning their teams, not micromanaging every little thing that the teams are doing, but instead crafting the visions and steering them forward. So also the head of product and the head of design should be meeting with the head of engineering all the time as well and the other leaders of this organization and making sure that the business priorities are very clear that the strategic intents, as I call them, in the strategy is clear. The vision for the company is clear, and they should be doing work to make sure that that makes sense for the rest of the company. And that’s what you can help pull people together into as product operations manager. Get them the data they need to make decisions. Make sure that your reporting helps the product head and the head of design actually get the transparency they need into how the teams are moving towards outcomes. Those types of things will really help as well. So that’s where I think you should focus as a product operations manager and help roll up the information so that it’s valuable to the executives and valuable to the VP level as well. All right, next question. Dear Melissa, our tech department is small and in growth stage and we have recently implemented business OKRs with key results, but we’re not sure what to do next. We don’t have the team structure set up correctly, we don’t empower the teams. We don’t seem to have product or business strategy for digital products. How would you approach a situation with our product lead and stakeholders? So if there’s no guiding strategy, how did you come up with the OKRs? Right? So to me, they’re probably going to be a little messy and they’re not going to be focused on the outcomes that we actually are trying to achieve or the key results that we really need to achieve. So what you need to do, and this is usually what happens here, is that people put the OKRs all on the team level. They don’t roll them up. And actually you should have like three levels of OKRs that roll up to the business goals. So that might be a good place to start with your business leads and with your stakeholders. Look at all the OKRs and say to them, when we achieve these key results, what will happen for our business? What’s next? Right? Do all of these things actually come together to form a more empowered result at the top level? What are the business outcomes we’re trying to do? Okay, what are the things that we’re doing on the teams that are actually related to that business outcome? Your OKRs should flow. You should be able to look at your tech and product OKRs and go, okay, if this is to reach this initiative and we expect to see more user activity or adoption or increased retention, what does that mean for the business? If we have increased retention, that means it’s going to be more money. Okay. Is it directly related to this initiative at the top of the business? A lot of times we just don’t understand OKRs as a company and we implement them more from a performance management system perspective of, “Hey, let’s watch all our developers and our product managers and make sure they’re doing good things and that’s not what they’re used for.” So I actually had Christina Wodtke on the podcast a couple of weeks ago. She is an expert on implementing OKRs. She wrote a great book on it. If you’re curious about what to do with OKRs and how they should be used, it’s a great podcast episode to go listen to. But I think having this conversation of if we do all these things and hit our OKRs. What is it going to do for the business is a great place to start getting your product leads and stakeholders to think like, hey, does this all actually go together? Now, also, I say this a lot, but there might be a product strategy or business strategy, like, stuck in somebody’s head and not well communicated. So by asking a bunch of questions, you can start to pull that out and start to make that a little bit more rigid, a little more defined so that it leads things. Go ask questions, right? Go ask them, “Hey, this is interesting.” “If we do this, what do you think will happen?” “If we release these things?” “What do we expect to move?” “How can I tell the difference of success between releasing this thing and not releasing this thing?” “What is it going to do for our business?” “What are our priorities?” “What’s the most important thing we could do?” Just being curious and asking those questions usually reveals a lot, and it gets people thinking, like, “Hey, maybe people don’t know the answers to these things, or maybe we have to get together and actually think about this as well.” So I hope that really helps. But just be curious, ask questions, go to them. Don’t start being like, “Oh, we don’t have a strategy.” We don’t have a strategy. Because I guarantee you they’ll tell you they do. They may just not have communicated it. And people get very, like, especially leaders to get really scared about that. They’re like, “No, we have a strategy. You’re just not understanding it well.” And you’re like, okay, but if you approach it from, like, a humble curiosity, that always helps. So maybe try that as your first, next step. All right, that’s it for Dear Melissa this week. If you have questions for me, please go to dearmelissa.com and submit them. We’ll be back in two weeks with another Dear Melissa answering three of your questions, so definitely leave me a voicemail. Love hearing your voices on there. And I will see you next Wednesday with another one of our Product Thinking guests.