 Hi everybody, my name is Perpette DeSuckriff and I'm really excited to be here today to share some of my thinking and learnings on how to manage conflicting or disagreeing stakeholders as a product manager. What can you do if people don't agree? I just wanted to start by introducing myself, my role, and then I'll give you a bit of an overview of my journey into product before getting into the content of the webinar. So as I said, hi, my name is Papatia, I'm a senior product manager at a company called Deliveroo. We are a three-sided marketplace connecting our restaurant and grocery partners together with our customers using a self-employed rider fleet. I'm a senior PM there for just over a year. So a little bit about my background, I'd say my journey into product was pretty atypical. It's kind of a meandering path. So I graduated from university in 2014. I did an undergraduate in classics post-grad in Russian and international relations. So very much a linguist by background and at that time, I don't think I'd heard of the technology industry. I certainly wasn't aware of product as a career path. I wasn't really sure what I wanted to do. I talked with the idea of becoming a diplomat or going into the public sector. I ended up applying for a bunch of grad development programs in various different companies here in the UK. Because I wasn't super sure exactly where I wanted to go, I ended up getting a position at Rolls-Royce, the aerospace company. And I was really fortunate to land on my feet because I did my first two years of my career in their graduate development program where they basically exposed you to lots of different parts of the business. So I had the opportunity to do a bit of business development, bit of account management. And after that sort of first two-year period, I had what I would call my first light bulb moment. And I had the chance to work as a chief of staff to our chief digital officer for a burgeoning new division within Rolls-Royce, which was our data science data innovation department called R-Squared Data Labs. And in working together with him, I realized that actually I'm super interested in tech, really interested in how data science and software can add value to a business. So that was my sort of first light bulb moment. After that, I moved into another team within the same area where I was fortunate to work in venturing and incubation, where we were basically bringing in third-party software companies, third-party machine learning data science applications, and applying them to Rolls-Royce's industrial data sets to really value to the business. So really, it's about combining skill sets from inside the company with outside the company to add value to help Rolls-Royce get insights from our data. And at that point, partnering with various startups and scale-ups, I came to know of this discipline called product management. I started looking into it. I started reading books by people like Marty Cagin about lean product development. And I thought, hey, this sounds really interesting. This sounds like a role that's at the intersection of technology and business. I actually would like to learn more. And that might be an area that I want to get into. So that was my second kind of light bulb moment in my career. After that, I had the opportunity to work as a product manager at VP, working with a colleague of mine. We developed a virtual card, a virtual payment proposition, which we took to small and micro businesses in Central Europe. So that was my first product role. And then I was approached by DeLibru. Obviously, super excited to come and work for a company that certainly a lot of us in Europe have heard of. And it's a product that many people use regularly. DeLibru is a really, really great kind of product company. So I was super excited to jump on board just over a year ago now. And now I'm senior product manager in our delivery team. So within delivery, I work on the rider app and rider proposition. So we have a fleet of self-employed riders. And the problem space I've just moved on to owning is our rider supply and onboarding space. So how do we solve the problem of how big our fleet should be? How do we grow our fleet size in a cost-effective manner? How do we motivate riders to come online and work with us when and where we most need them? And so on. So yeah, that's me. As I say, like, not a typical path, but I'm really grateful that I discovered product a few years ago and that I have the chance now to work with one of the best product companies here in Europe. Cool. So what is the webinar about today? So I really wanted to talk to you guys about a scenario that I have come across frequently, but I found often quite challenging, certainly in the early days in my product career, to navigate. So there's an analogy here that I have stolen from my boss. Will, if you're listening, thank you so much for this great analogy because it's really stuck with me. Thank you so much for this great analogy because it's really stuck with me. So I think as a PM, essentially you're sitting at the intersection of lots of different domains, disciplines, and stakeholders. And your job is to really knit together those different skill sets and marry those up with an end state that you're trying to get to and a vision and make sure that those skills are well deployed in execution of that vision. That's kind of how I see a PM. You're right in the crossroads of all of these different sort of talented people coming from different parts of your business. And so what's that's obviously really fun and really interesting and it allows you to be a multi-developed into kind of a multifaceted leader. On the other hand, it can also be stressful. And the analogy I'd like to use here is the one of being a ship in the storm. So it can really sometimes feel like you're being buffeted by these waves of somebody from marketing wanting one thing, someone from engineering wanting another thing. And it can be easy. It can be very easy to feel kind of overwhelmed by that and feel like you're losing a sense of direction and you don't know which way to go. And so this is the kind of situation that I wanted to talk to you guys about today. It's something that, as I said, I found quite challenging in the early days of my career when I first started out. And I just wanted to share some tools and some methods that I think can help you organize your thoughts and kind of progress in situations where you're being pulled in different directions. So the scenario that I'm going to lean on as I talk through today is one that I've come across a few times before. And it's where you're sort of caught in the middle between a technical discipline and a business operations discipline. So the scenario I'm going to chat about today is essentially you're testing a feature. You've released it to a certain number of your consumers. In my case, that would be delivery riders and you're testing it out. And you've got to a point where you have planned to run the test for four weeks, but your team in data science and perhaps machine learning are telling you, hey, we need to roll it. We need to run it for another month because we're not quite getting enough data to test the hypothesis that we need in a robust way. So that's on the one side. These folks want to run the test for a bit longer so they can get the data and make some really robust conclusions about whether this feature is going to deliver the outcomes that it was expected to deliver. On the other side, then, you've got your marketing team and your operations team who have their own deadlines to meet. They perhaps banked some value that that feature is expected to deliver. So they put it into their financial plan for the upcoming quarter. On the marketing side, they might have some campaigns planned around that feature being released at a certain time. But you know, speaking to your colleagues in DS and ML, that if you run this test for another month or so, you're not going to hit those deadlines. So you're really caught in the middle. And that's the scenario I wanted to refer back to as I talked through the three kind of different tools that I wanted to share with you guys today on how to manage disagreeing stakeholders and how to reach alignment. So the first thing is, I think, one that should be really familiar to you guys, but I just wanted to reiterate, as it's easy to lose sight on that, before going into any kind of, I guess, product initiative or picking on a new area or driving a new feature, it's really important to get the foundations right. Again, sounds really obvious, but it's something that is sometimes easy to lose sight of, particularly if the team is new. And the initiative is one that you've sort of been perhaps thrown into and aren't super familiar with. So the first thing is obviously to align on the vision, the goals and the metrics. I'm not going to go into lots of detail today on how to write a good product vision. Actually, product school has loads of great resources on how to write a strong product vision and how to chart out a roadmap. But I think this is just really a sense check to say, hey, if stakeholders are disagreeing or they're misaligned on a particular point, are the foundations in place? So of course, you should ask yourself the question, do people understand where we're trying to get to? Do we know how we're going to measure progress to that end state? And your sources to establish those two things are talking to the immediate team, talking to your peers in tech, talking to your business stakeholders, to your leadership, and of course, talking to the end users, the customers of your product. So super important that that end state, the direction is well defined and that the team have an understanding of the goals, which is what are the touch points along the way to getting to that end state and then the metrics, which is how are we going to measure that we are achieving that progress towards the end state? Again, I always try to write things down. So people might have in their heads, hey, I think the end vision is this. But actually, if you try to work with the team to articulate it in words, you'll often, through that process, expose any gaps or any fundamental kind of points and misalignment. So make sure you write things down. When you're talking about goals that help you get to that vision, make sure that those goals are prioritized. So you might have a P zero goal, which is, hey, we absolutely have to hit this in a given timeframe, maybe in the upcoming quarter or upcoming year to help us progress to that vision. And then of course, your metrics are, how are you measuring success? Finally, once you've written those down or perhaps tweaked what was already written down, be sure to share those assets widely, invite comment and publish them. So getting the foundations right, I think is a really, really fundamental part to setting the scene so that in future or presently, when disagreements arise, you can refer back to the agreed end state that the team is trying to get to. Okay. So say you've set the foundations right. You've got your visions and your goals and plagues, but we still have this situation where, hey, data science and machine learning want to run this thing for longer, marketing and operations want to get the feature out. So what do you do? You might feel really like you're pulling, being pulled in different directions and you're not quite sure who has the right view. Well, I think the first thing here is really try to develop empathy for diverse viewpoints. So I learned this phrase from back in the day when I was at Rolls-Royce, we used to have this phrase called staying curious. And I think it's a really good mindset for a product manager to be in at any time, but particularly at times where people are misaligned or disagreeing. So really try and take a neutral stance and treat it as a fact-finding mission. So, hey, these two teams don't agree on the path forward. Why is that? And being in a receiving mode to better understand where they're coming from. So I think there are two sets of questions you should ask when you're trying to understand people's positions. The first is, what are these people's personal goals? What are they here in the business to achieve? What's their personal metrics? And then the second one is focusing more on the individual. What's their personal definition of success? So maybe that they're in a team that's here to achieve XYZ, but within that, their individual definition of success is a slightly different thing. So understanding those two things can really help you boil down the disagreement or the misalignment to its fundamentals. The way that you gather that information is obviously having individual conversations with those disagreeing stakeholders and ideally also try to get them in a room together in obviously a non-confrontational sort of setting. But you might try to bring together the data scientists to saying, hey, I really want to run this test for longer. I'm not confident in the results. Get them in the same room with the operations stakeholder and let them converse. And often I find that even through that very act of bringing people together into one place, a lot of disagreements naturally kind of get ironed out. And if they don't get ironed out through the conversation, you're able to really boil down the misalignment to its core, what is actually driving the disagreement here. And then it can help also to bring together in your head. It can help also to bring together in your head the different team's goals and metrics. So if the operations team is here to achieve a certain financial outcome, the data science team might have a different thing that they're aiming towards and putting those two things side by side can also help you boil down to what's really driving this. And so in the example I used, on the surface level it may seem that, okay, this person wants to extend the test by two weeks or a month. The other person wants to go live immediately. But actually, if you boil that problem down to its core, it's about the level of risk that the different areas of the business are willing to take. So the data scientists might feel that their job is to analyze the data and provide with a high, likely level of certainty, the outcome that launching the feature is going to drive, they will see that as their responsibility. And ultimately I find that people are just here to do a good job. So the data scientist says, hey, ultimately my job here is to make sure that when we roll this feature out, we said we were going to deliver. And so they're optimizing for that. Whereas the person in operations is maybe optimizing for different things such as hitting their team's deadlines or delivering on a certain P&L commitment that the feature is expected to release. So the core of that disagreement is really about appetite for risk and the extent to which each team is willing to entertain the feature, perhaps not delivering exactly what we expected it to deliver. And that's kind of at the heart of it. Okay. And then the final piece is say you've gone through that process, you've set the foundations, you've brought the stakeholders together, you've understood the kind of the drivers, the core drivers behind the misalignment. The final thing that you need to do then if people still can't agree and you can't get alignment at the working level is to leverage your leadership team. So we have this idea called very hotly contested principles. And those are the things that I described in the previous slide to their what's really at the heart of this misalignment, what's the driving force behind it. Once you're able to understand that, that's the time where you want to leverage your senior leadership and seek their guidance and input. So as part of any product initiative, particularly if it's a big or a complex one, you want to set up regular checkpoints with your senior stakeholders. And so getting those in the diary ahead of time as progress points, opportunities to unblock blockers, opportunities to, in this example, escalate areas of misalignment. If you have those regular check-ins in place, that then allows you in a situation where you can't get agreement to escalate in the right way. So when it comes to escalating to your senior stakeholders, I would, as I said, seek alignment on overarching principles rather than implementation details. So if we go back to the example we were using, this isn't really about running a test for two weeks versus an extra four weeks. It's really about the fact that in data science, the team really want to have robust outcomes for any experiments or tests that we run, whereas in operations, people are measured on their ability to deliver business metrics. That's really at the heart of the clash. And so really what you're trying to escalate there is, are we willing to live with a level of risk that this feature may not deliver quite what we thought it would? And by seeking guidance, you can get a sense of whether that level of risk is acceptable to your leadership team and therefore whether it would be acceptable to you. So again, really boiling it down to the fundamentals and escalating it in a context where you have other senior guidance can really help you get find a way forward. I'd like to think of the leadership team in this situation as a bit of an advisory board. They're a sounding board there and they're really there to help you progress and unlock because that's their role as leaders. So don't be scared to use their expertise and judgment in that way. I've sometimes in the past been scared to escalate things because I'm worried that it will create a confrontation or that it'll make the team look bad because we're not aligned. But I think if you really go through that process of understanding where the people are coming from, boiling it down, not to the minutiae, but to the principles, to the core areas of misalignment, such as in our example, you know, the appetite for risk across different divisions. If you're able to boil it down to that and then raise it up in ideally quite a neutral and data led way, you would actually get a lot of value out of those senior conversations. So your sources are the core areas of misalignment. And I would also suggest that it helps if you as the PM at this point, I know I said earlier, kind of be neutral, be in listening mode, but at the point of escalation, it can be helpful for you to take a view. Because if you come up with a clearly worded recommendation, hey, I think we should go this way versus the other way, versus the other way. And here's my evidence for it. That gives your leadership team something to engage with. If you give them just a list of pros and cons on each side, it could come across like, you haven't done the work, or you're expecting the leadership team to do the work for you. So I think this is the point when you've been through that whole process of setting the vision and the goals, understanding where each stakeholder's coming from, understanding what their individual drivers and metrics are, boiling it down. This is the point at which you can kind of take a view and articulate that upwards. So you use these regular check-ins to surface up things like this. And ideally in your check-ins, you're only surfacing up, as I say, a handful of areas of disagreement. And you've used the previous two steps in this kind of toolkit to iron out any kind of lower level misalignment. Cool. So to summarize what to do when your stakeholders are disagreeing firstly, start with the foundations, make sure the product vision and the metrics are understood and agreed and the evidence aligned behind them. Number two is to empathize and stay curious, really deeply understand where the disagreeing folks are coming from, what are there, both their business and work drivers, but also their individual drivers. And then finally, don't be scared to leverage your senior leaders and draw on their experience and their overall view of the business in order to surface and escalate in the right way. Cool. So thank you so much for your time. Please feel free to reach out to me on LinkedIn. You can use this QR code to add me, DM me if you have any product questions. Yeah, stay in touch. I'd be happy to help.