Episode 62: Answering Questions About Dual Track Agile, Processing Negative Feedback, and Starting as a New CPO
In this Dear Melissa segment, Melissa answers subscribers’ questions about what it looks like when teams are successfully running delivery and discovery in parallel, and the two reasons teams typically struggle with delivery, throwing yourself back in the ring after a disheartening work experience has left you feeling discouraged and frustrated (and asking yourself some hard questions), and where to focus your efforts when starting a new CPO role.
Have a product question for Melissa? Submit one here and Melissa may answer it in a future episode.
Subscribe via your favorite platform:
Q: How do we do discovery and delivery together for dual track agile? [1:59]
A: I think the first thing to look at is if your discovery and delivery are aligned for the most part of what you're doing. Unless you're kicking off an entirely new feature or issue to solve, then you should be making sure your discovery feeds into delivery and doesn’t disrupt it. You shouldn't be working on multiple initiatives at once unless you're in the transition phase… When teams are confused about delivery, it typically happens for two reasons: first, they don’t know how to do it, and second, the constraints might be too wide and your team's not yet mature enough to actually engage in discovery. [2:43]
Q: What do you do when a job experience as a product manager has left you so burned out that it makes you afraid to take on that responsibility? [9:29]
A: Based on what I learned from my experiences here's what I would do for you… What was the direct feedback on why they gave you 1 out of 5?... How were your interactions with people while doing these things? I found that when I have been showing that I'm really good at my job… and I’m still not getting along with my managers… it was actually my interpersonal relationships. I learned over the years that just hitting your numbers isn't enough. You also have to build relationships with people and make sure that you're doing the other parts of your jobs too, and as a product manager, that’s a huge part of it. [10:14]
Q: As a new CPO, where should I start and how should I sequence with regards to building out the team hires, culture, systems, and processes? [17:34]
A: Make sure your first hires are the people who are going to be freeing up your time, which means leadership. You’re going to have to hire a bunch of junior people, but you need to hire the leadership first so that they can go hire the junior people. What I look at is: how do I scale myself? How do I make sure I'm maximizing my time to do the things that I was hired to do, which is build out the team and also do the strategy?... The most important thing that you could possibly do is get really good leadership. [18:08]
Resources
Melissa Perri on LinkedIn | Twitter
Transcript:
Melissa:
Hello, and welcome to another episode of Dear Melissa. Today on the podcast, we've got three great questions for you about leading teams through dual track agile coming back after a toxic work environment and what to do first, when you're starting as a new CPO. But before we get to that, I just wanna remind you that you also can submit questions to dear Melissa. So go to dear melissa.com. Let me know all of your burning product questions, and we'll answer them on one of these episodes coming up. So with that, let's dive in.
First question, dear Melissa, our product teams have been working with dual track for quite a while. We are doing delivery with scrum and while it's not perfect, the routine is there and it's flowing, but we haven't found a good routine to run discovery in parallel to delivery. The team tends to favor delivery. It's more concrete and urgent. Whereas discovery is more uncomfortable and abstract. At least at the beginning, any concrete tips on how to run team meetings or celebrations, mixing discovery and delivery, how should we run dailies planning, demo and retro for dual track agile. When do we talk about both discovery and delivery? And when do we focus on one? This is a fantastic question. And we're gonna get back to it right after this message.
All right, we're back. And we're talking about dual track agile. So how do we do discovery and delivery together? Um, I think the first thing to really look at is, is your discovery and delivery aligned from the most part of what you're doing, unless you're kicking off an entirely new feature or issue to solve, then you should really be making sure your discovery feeds into delivery and not disrupt it. You shouldn't be working on like multiple initiatives at once, unless you're in the transition phase of, Hey, we're pretty much done with this. Now it's time to move on to the next one. And at that place, you know, it might be a little bit tricky. Um, you're gonna have to keep people updated on what the new discovery stuff is, um, but not disrupt their delivery progress on the old issues as well. So that's where you're gonna really diverge in these cases and have different meetings to talk about what are we learning about, uh, for our next feature?
How are we talking to customers? What feedback do we get? And the idea is that you don't wanna like pull the whole team into those discovery sessions every single day. The developers aren't used really focused on that part of it yet, but you wanna come to them when there's some meaningful information that they need to know that's gonna set them up for success. Once they start to actually get into delivery mode. Um, on the other side, though, let's say you're not really ready to switch features yet. Like you're just doing discovery along the way, which is what most, for the most part you should be doing, right? Like you should be, uh, launching something, going out, doing discovery to make sure it worked and then coming back and iterating on it. If you're doing that, these conversations tend to flow pretty naturally because you're like, oh, what did we learn last week that we have to incorporate into this week's sprint?
You know? So I'd say in those cases, you should be thinking about how that feedback gets communicated in dailies, planning, demo and retro. Um, all of those things should go very nicely together because you should be feeding feedback into it. So that's really making me think about two question is to really ask you, um, about this one. You know, when teams are confused about delivery, typically there's, there's two, two reasons. So the first one, like they don't know how to do it. Uh, and you really solve that with training, but two is the constraints might be too wide and your team's not mature enough yet to actually really engage in discovery. Um, so I wanna focus on that second one that I was just talking about. Like, do you feel like your strategy has been deployed correctly into a space where the teams can actually look at what's should be discovery work in front of them and go, okay, so let's make a plan of action and we know how to get started.
If you want teams to focus more on discovery, you gotta make it accessible for them to jump into the discovery. So if your teams are not super mature yet, and they haven't been doing this for quite a while, what I'd say is tighten the constraints around them enough to help them start generating more ideas and spark direction. If you have teams that are like waffling on which way to go, uh, for too long, like, let's say a couple weeks where they're like, I don't know, I try that. It didn't work. I try that it didn't work, but like they're not getting meaningful impact to help them make a decision. Um, if it's not the training problem, it's that the bounds of your strategy that you deployed to them or the goals that you gave them is just way too wide for their skill level. And then as the product leader, you now need to come in and tighten those constraints so that they can, you know, have some action.
They can know what to do first and they can start to get some questions answered. Once teams get questions answers in discovery and it points them on the right path. They usually love it. But if you let them flail for too long, they're gonna get like, I don't wanna do this. I wanna do delivery because it's measurable. We can look at the outputs. We can see what we actually did. We made progress. So I really want you to take a step back and look at what directives the teams have for discovery work. Are you like go out and discover, do all the things, you know, like bring me back ideas that might be too much for them. That might be too much for junior product managers or people who are new to discovery like I would instead maybe bound it around. Here's um, a problem that we're hearing go validate it, right?
Go see if this is the right problem. See if it's the wrong problem, give them something to go off of so that it, that they have a chance to go out and discover towards a goal. Um, so I'm not saying like give them a solution to build what I'm saying is just like bound the problem space a little bit more. And that's a nuance that you have to get really used to when you're a product leader, you have to figure out when do I bound and when do I just let people run? So if you are finding that, it's like your, it, your culture is like, ah, we just don't wanna do discovery work. Like think, do they know how to do discovery work? And two, am I giving them enough encouragement to go out and do discovery work by bounding their constraints, you know, by bounding their strategy enough to get them started two.
Um, how are you measuring progress here with, this is my second question after that one. How are you measuring the progress on the discovery work? When we measure outputs, what we do is we say, Hey, look at all the features we just released. We did a retro on it. We do demos on it. What are you doing for discovery work? That's showing that we care about it. Um, this is where I love to use product kata. That's why I got started with it. Um, because you get to track all of your experiments, uh, reflect on it, show the learnings and you do this in a really nice grid, uh, that shows everybody what we've been doing, what the progress is. It's a great way to communicate it. Usually when I teach teams that are new to discovery and I show them the product kata, they love it because they're like, oh, finally, this is like my JIRA for experiments, right?
Like this is my way to actually track and show people what we're doing. And then the executives like it, because it shows that there's a lot of learning going on. We're working towards goals and there's lots of results here. So I would really think about it like that. Are we, are we measuring our progress in rewarding the progress for discovery in the same ways that we rewarding the progress for delivery? And that's a culture thing as well. So I don't think it's just about like how you run your daily as you're planning your demo in retro. I think it's actually a bigger question about, is your strategy at the right constraint? Are your teams well equipped to go due to discovery and three, how are you celebrating your successes or showing them that they're making progress, right? How do you talk about the progress of learning in all of those, you know, rituals that we just talked about?
So I don't think it's about focusing on one versus the other. It's gonna diverge when you're kicking off something new. But if you are in the middle of creating a new feature or product, these things are gonna be pretty well tied together and they should just feed into each other naturally. And if they're not, then you have to ask yourself like, are we, are we setting up two major initiatives for the team and splitting it? You want people to concentrate and focus and get something done and work towards a goal, then move on to the next goal, then change focus for something else. So hopefully those tips help you. Uh, it is hard to start doing this at first too. And I would also encourage you to look at your cadences for dual track and just see if something's not working for you. Right. You don't have to follow everything by the book. You don't have to just copy and paste. Whatever was out there. If it's not working, change it, find something that works for you. Don't feel like you have to be locked into the bounds of every framework that's out there.
All right. Second question, dear Melissa, what do you do when a job experience as a product manager has left you so burned out that it makes you afraid to take on that responsibility. Again, in my last job, I was under a lot of pressure from the VPs to make our product profitable quickly. I proposed a model having a different product and worked so hard to launch it. After two years of work, the VPs evaluated me at one out of five. That was it. I quit the same day, my team and I improved every KPI. And that product is still active. I loved being a product manager, but that company didn't believe in me, long story short, I'm still resentful of that evaluation. And I became insecure. What do I do now? Well, I'm really sorry to hear that. Um, I've had experiences like that too, where I feel like I did a lot of productive things and I still wasn't rewarded for it, respected for it.
Um, so based on what I learned from my experiences, here's what I would do for you. And I'll tell you how I did them too. But two things to think about one, what was the direct feedback on why they give you one out of five? Um, even if you hit your KPIs, like, were they measuring you towards those KPIs and if not, what were they measuring you on? Um, but also how was your human interactions with people, you know, while you doing these things? Uh, I've found that in my experience, when I have been, uh, you know, showing that I'm really good at my job and I can hit all these KPIs and I could do all these things and people I'm still not getting along with my managers or they're, don't like me or they me a one outta five. Um, I've reflected on that in the past and found that it was my interpersonal relationships.
Uh, I was a hothead when I was younger and when I would come into companies, I was like, I know I'm doing this right. And you're doing it all wrong. And people do not wanna hear that. So, uh, I learned over the years that, you know, just hitting your numbers isn't enough, right? You also have to build relationships with people and make sure, sure that you are doing the other parts of your jobs too. And as a product manager, that's a huge part of it. Right? So you may have came in here and I don't know, I'm just saying like, this happened to me. So maybe it happened to you, but it's something good to reflect on you. You may have came in there and said like, I'm gonna do this, watch me do this, but burnt a lot of bridges along the way. And, and, you know, made some enemies.
And that might be why you got a one out of five or you didn't know how to manage up. That's a hard thing to learn too. It took me a really long time to learn that, how are you communicating the progress of these things to your VPs along the way? How are you keeping them informed? How are you making sure that, um, you know, they had some input into it and you weren't just dismissing everything that came out of their mouths, but you were really taking in their feedback, understanding the business and moving in the right direction for that. I would really look at some of those things and, you know, have a hard conversation with yourself and say, could some of this have been me if it wasn't right, this is number two. The second thing I would think about, um, if it wasn't, the other thing you need to remember is sometimes managers suck like really, really suck.
Uh, a lot of people are in positions of power that should not be in positions of power. And how do they get there? They get there from being great individual contributors, sometimes having a really big ego and they get, you know, promoted doing their job well into this new job, managing people. And they've never done it before and they just suck at their jobs. Um, so I don't know what the culture was like at your company, but maybe you had a bunch of really sucky leaders, uh, who took advantage of you didn't understand what you were doing and, you know, didn't really understand the value that you were providing there. That could be it. Um, I'd encourage you to look at number one first and reflect internally before looking at the leadership. But sometimes it is the leadership. And, uh, I hate to say that, but like, yeah, sometimes there are really sucky leaders out there and they ruin our experience and they take us for granted.
And I've also seen, you know, bias in organizations too, where you do a lot of really good work and people just don't recognize it because they have biased notions about what you should be doing. Um, I was passed up for a job really early on in my career. Not really early on in my I'd say like later stages where I hit all these qualifications on a rubric they wanted to hire me for, but they didn't wanna hire me for that position. They were like, no, you're more junior than that. I said, you gave me the rubric. I fit these rubrics. Right? Like I, I hit all these levels. Yes. But we just don't feel like you're senior enough for this position. I'm like, well, what does that mean? I hit all the requirements. Right? You may have had a situation like that too, where there's just a lot of bias and, and, you know, you were taken for granted for what you could actually do.
Um, how did I get over that? I channeled all of my frustration at that into proving people wrong. That's probably where I'm at today. And, uh, you could do that. That's how you can get over feeling insecure. But I will say the way that I feel like I became more successful and didn't keep running into these situations, cuz I did run into many different situations along the way to where to I got, where I got to now is just like really being self, um, you know, retrospective where you really look internally and all right, some of these situations could be my fault. Some of them could be external factors, which are the pieces that were my fault that I might try to tweak next time and see if it changes that situation for the better. Um, and where can I draw the line and say objectively that wasn't, it might be helpful to like talk that through with a coach.
Talk about those experiences. I found when I started to really think about the conversations I was having, uh, that kept pointing out places where I could have had those conversations better. And you know, in the first story I was telling you about a place where I came in and I was like, no, you're doing it all wrong. I wouldn't have told you like even six months later that it was my fault with that company. But a year later, two years later, when I start reflecting on, uh, you know, my experiences there and my experiences elsewhere and why certain things were working, why certain things don't work there. I realized a majority of it was me. Part of it was definitely the people I worked for, but part of it was me. And I think that's really important for any career is to look back and say, what can I do better?
I'm not gonna have a perfect situation all the time. I'm not gonna work with perfect people all the time, but what can I do better to actually help with that? Um, I think if you came in there launch this product, it's still running, you hit all those KPIs. Uh, don't take this super personally like reflect and figure out, you know, what might I have done differently communicating with the VPs or working with the VPs, uh, to make that experience better. Was there, you know, did I not just know how to communicate to them? Did I not? Um, keep them apprised of the situation was a kind of a jerk, ask yourself these questions. They're hard questions to ask and they will be humbling. And I have reflected on my experience before and been like, yeah, I was a jerk. Uh, but you have to be honest about that because that's how you grow, right?
That's how you get better in your career. But then too, don't let this, you know, don't let this kick you outta product management. It happens to all of us. It happened to me. It like happens to the best of us and all you can do is learn from it and keep going. And I think if you were able to get the results that you're describing to me in this, you're gonna be a great product manager. You may need to just work on some other skills. Uh, and you may need to find a culture that actually appreciates it and gets product management. Your company did not understand product management. Like you didn't have a shot in hell there. So find a place that really gets it and then thrive because they're gonna be super happy to have you. They're gonna want somebody who's hit all those KPIs and all those goals.
And you can say, I was just not being, you know, appreciated my last role. And I really wanted to come somewhere that got it. And that's a totally fine story to tell. So don't feel like you're out of the race. Um, but do think about all of your experiences and the people you interact with and then take some of that to grow and learn. That is probably the thing that has helped me. Most of my career is being able to analyze the situation, reflect on it and be really honest about what I could have done better. And if you keep doing that, you're gonna get better at everything that you do and things are gonna get easier too, at the end of the day, like, I'll just say, you're just gonna work with people and it's gonna be easy and it's gonna be nice and it's not gonna be frustrating anymore when you think through all of those things.
So it's a really important skill to have is, you know, being able to be introspective and really think about what I'm doing as well, but also recognize when you know the situation's outta your hand and it wasn't your fault. So get back in there, keep going. Don't let this hold you back. We still need some great product managers. So don't feel down about this. All right, here's our last question, dear Melissa, I'm starting a CPO role soon for an ambitious new startup with the large initial budget, over 50 million of funding. We are roughly five pillars propping up the vision. And one pillar is substantially larger at this stage than the others. In year one, I will need to build out product leadership management and design functions. Assuming I have confidence in the vision pillars and key problems to solve. Where should I start? And how should I sequence with regards to building out the team hires culture systems and processes.
Thanks in advance. You're welcome in advance. All right. Most important advice I can give you as a new CPO stepping into this role is make sure your first hires are for the people who are gonna be freeing up your time, which means leadership. You know, you're gonna have to hire a bunch of junior people, but you need to hire the leadership first so that they can go hire the bunch of junior people. So what I'd look at is like, how do I scale myself? How do I make sure that I'm maximizing my time to do the things that I I was hired to do, which is build out the team, but then also do the strategy. Uh, one of the biggest reasons I see CPOs get fired when they're new is because they spend all their time doing everything else, except the strategy you are hired to help with the strategy.
So make sure you're concentrating on their vision, make sure you're concentrating on that strategy and make sure that you're really being a member of the executive team. And you're spending a lot of time building those relationships like that is where your focus should be. Now let's talk about your team, hires your culture, your systems, and processes. If you get design leadership and product leadership in place, now they can go hire the teams, hire great people for, for that, that you can work with and let them go take that work on because as you know, I'm sure hiring takes up a ton of time. You shouldn't be spending your time hiring a ton of junior people. That's not worth it. Uh, get in a VP of product, get in a VP of design, uh, you know, get a product ops person and then let them go build teams.
That's how you, you really be thinking about this. Like how can I get the people who are gonna build my teams. Two. If you bring in leadership too, they can also help with the processes. So if you hire a product ops person early, they can help you standardize some of these processes. They can help you set up your metrics so that you can measure your strategy, which is really important. And they're gonna help you set up the systems as well and make sure your tools are working same with design leadership, same with product leadership. So the most important thing that you could possibly do is get in really, really good leadership. Start there. I would spend a lot of your time right now, making sure that you get those people in there and then delegate to them a bunch of the work to go out and hire the next people.
And also start to set up processes and systems, right? If you get those people in there, they can take the brunt of the everyday like brunt work going on with this. And then you can come back in and check and give your inputs, but you don't wanna be the person who's making a PowerPoint on how we do product management at your company, right? Like that's not your role as a chief product officer. I'd also say it. If you are building up a team this large, uh, you may also wanna think of getting a chief of staff, chief of staff, um, usually come from, come from bunch of backgrounds, but I've seen a lot of really good like consulting chief of staffs. Uh, you know, they come from bane and McKinsey and all those places. And what you can give them is, you know, help me make my board slides help me, uh, make sure communication's going seamlessly across all my leaders.
Uh, help me pull the financials that I need to be able to communicate my next strategy. They can help you with strategic thinking. They can go do research for you. They can go make sure everybody's moving in the same direction. And you might want somebody like that as well in your, in your team, depending on how many people you're gonna oversee in this product management organization. Um, I've worked with a lot of CPOs. Who've had chief of staffs and they love them and they're like, wow, I would never, you know, exist without this. This helps me so much, especially when it gets into board, uh, slide, territory, which, you know, pops up at least four times a year and you gotta go spend the next several weeks, putting board slides together. You don't wanna take out four months of your year to put board slides together.
You want somebody else who can help with that? So just remember like the biggest thing that you could possibly do as a chief product officer, as an executive is get leverage. So anything that provides you extreme leverage is what you should do first. That's how I would think about it. All right. That's our questions for today in the product thinking podcast. If you have a question for me, please go to dear melissa.com. And if you've been enjoying the product, thinking podcast, I'd really appreciate it. If you could leave as a review and a rating, anywhere that you're listening to this, it helps people find us. We also love to hear your feedback. We wanna hear what you wanna hear more about on the show. So definitely ask more questions because this helps inform what kind of guests I get on the show and leave some review and let me know what the feedback is. I'll see you next time.