Hi, folks. We can get started. Thank you all for being here.My name is Swati Chandrasekaran, and I'm gonna be talking about how to navigate shifting priorities without using momentum. These are all based on some of my experiences with working with an amazing engineering data science and product team here at Paramount Global. So before we get into it, a quick introduction slide. As I said, my name is Swati Chandrasekaran. I am a director of product on the advanced advertising team of Paramount. My background is in engineering, data science, and then the shift to product, and I'm proud to call both Chennai, India, and now New York City as my home.

Obviously, that's my alma maters, and I try to embody a chain of all trades, outlook in life. So everything that's interesting, I'm there to learn. And there are some of my interests on here, but anything that's not on here are things that I look at as opportunities in the future. And I'd love to connect with all of you, so that's my LinkedIn. Feel free to shoot me a note. That said, I'm gonna get right into it, starting with the priorities changing again. In 2024, here at Paramount, we had a monumental shift in priorities around q four. We were in conversation with one of our data providers, and there were chances that the agreements will be negotiated and signed and agreed on in time. We just didn't know whether or not it could be.

And by the time we would have found out for certainty, it would have been too late to make changes to keep all our products alive. The data was powering dozens of products across our company, and we had to get started working on it as soon as there was any doubt that things could go sideways. So we did. We had to commit to this one single priority across all of our engineering and data science teams with a singular goal, to keep our functional, regardless of whether we have this data source or not. It was a challenge and we had to make in redundancies everywhere. What happens if we could keep all the data and the agreements did get signed in time? Well, we didn't want to upload our entire system just to just for no reason.

But on the flip side, what happens if things had to get purged and we couldn't keep any of the historical data? We also had to be prepared for all the contingencies and all the different scenarios that would come up from this shift, and all this had to be done in record crunch time. We had money on the line for every single day that we had any downtime across our products. By the end, we were prepared and not without effort. Across all our teams, we spent a ton of time pulling this off. It was not easy. There were long days, long hours, but by the end, when the data data had to be paused, we were completely ready. We had no downtime at all in any of our completely ready. We had no downtime at all in any of our products.

And the most interesting thing for me is that our teams felt more motivated at the end than they had been at the beginning. To date, we talk about this period of changing priorities and focus as a period of incredible collaboration, something that we want to emulate even without the pressure. The thing to note is that priorities will always change, and I'll try convincing you why that's the case. And your change may not come from a data governance standpoint. It could be a dying library or a package. It could be a knowledge transfer session that an engineer is rolling off a project. It could be something else entirely. As a product person, your job is to find out if the thing you're working on really is a priority. Because once you've identified it, you just have to motivate the teams towards a new goal.

The rest of the presentation is a walk through of how some of the hows that have worked for me. Again, one of my favorite quotes is the best read plants of men and mice, but in this case, mice and PMs often go awry. And I'll try convincing you why. So firstly, we've all seen this image before of the reality of product management. We all have different ways that we define each of these steps. For some of us, aligning could be quarterly roadmap presentations. For others, it could be the weekly development calls and user sessions that we have. But the crux of it is that we start with aligning, working with everybody on the priorities, go into the design phase, which is UX, scoping, engineering scoping, engineering design, and then comes the build and deploy phase.

It relates to getting feedback. And what I really want us to focus on here is the reprioritization part of it. The note here is that shifting priorities shouldn't be and is not a failure. It's product strategy in action. If you have a static road map or a static Gantt chart that hasn't changed, that isn't strategy anymore. It's probably just art. So knowing this and accepting this, how do we prepare for the changing priorities? And how can we, more importantly for me, how do we keep our teams energized when working through these changes? So through the rest of the presentation, our priorities are going to be changing a lot. This slide is going to keep coming up.

And the rest of it are action points that helped my team, and I'm hoping that helps your teams as well. Firstly, and the fun part of this is that you don't have to do it alone. Again, as a product person, your job is to ensure that the thing you're working on is the highest priority. And even to do that, you work with a myriad of different teams. You work with your business stakeholders, you get the right people in a room so that you can align on the what you're building and why it's important now. And once you have those two pieces together, you can pretty easily get to part three, which is aligned teams.

Facilitate your teams to make the best decisions in their day to day. If you are involved in every single decision that your engineering and data science team needs to do to make a feature work, to me, that's a figure. You have to make sure that your teams are self sufficient. And once you've set up the why and the what, that they're able to make all the decisions about the how and some of the even the whats as we go down the line. This isn't necessarily calling for long PRPs or kickoff calls. That's really up to your individual teams. Even within my team of about 30 engineers and data scientists, we use separate ways of navigating this and aligning for different projects.

For certain teams, it's direct user calls and user demos and user feedback sessions for very nuanced user flows on our products. Other times when it's a brand new project or a brand new data source, it starts with a PRD, and those are well written and over communicated. Yet other times, like for our q four example, it's just direct collaboration and calls with engineers and data scientists that run ten hours a day. The point is you don't have to do this alone. The aligning is a team sport, and the way you align depends on your team's culture and the way your team prefers it. So this is gonna come keep coming up again and again. Process for processes sake is useless. It should be seen as a tool.

And if it doesn't work, throw it away and start with something else. So three things that really worked for us with alignment. One, seeing prioritization as a means for it. Doing it as visibly as possible, sharing as much of the context as possible. Doing it transparently, I think, has helped our team a ton over the time in understanding why certain things are prioritized ahead of other things. And when I say do it visibly, it's to both your stakeholders and business users as well as on the other side to your engineering and data science teams. A A singular backlog. I cannot stress how important this has been in our products. Having our lead engineers and our lead data scientists understand and share context across all of the different product priorities and having a single backlog that everybody can look at already does half the job of explaining and aligning teams.

The shared context is invaluable when it comes to especially shifting priorities, but even in the day to day, even when you have static priorities, having a singular backlog and not depending on separate views of it works tremendously well. The third thing, which is really hard to do, especially for product people is accept that you won't know. You can't tell the future exactly, and you have to stay humble with the changes that are coming up. Be ready to say, I don't entirely know if this is the next thing we're going to do after the current effort. I hope it is, and that is the plan for now. But if something else happens, if if another contract dies in three months, we have to be ready to pivot.

And that is something you have to establish with your entire team, which doesn't happen in a waterfall development. It happens really well in agile software development. And I think the crux of that for product people is staying humble. Alright. So priorities changing again. What are other things that you can do to help navigate this? Kill your darlings. This is really hard to do, and we've all heard this phrase of saying no and learning to say no. I would extend that by saying learn to say no and learn to explain why. This could be to users, stakeholders, developers, data scientists, to other product people. It's not important to just say the no, but to have the backing of why. And if something has to be punted, knowing why and knowing when you will pick that back up or when you plan to pick that back up.

For example, for us in q four, a very beloved but slightly lower impact feature had to be content. We were making tech improvements to our core repositories, which had to be completely paused. We also knew that we had to accrue that debt in order to build and deploy the changes that we were making for the crunch time in q four. Those things will happen. And I think the expectation there for product people is to explain why. For us, it was sitting with engineers and talking about, hey. We really can't work on this lower impact feature right now because it will block all the other changes we need to make for the crunch time. It could be something else entirely for you. But the point is try removing things from your backlog that don't have to be there. It's a ticket. It'll come back.

One thing that we've done in the past, which has really helped us, is purge in tickets. It's extremely hard to do when you have an idea six months ago that sounded great, that you'd still think at some point might be interesting, might be something that your team works on. But if you aren't keeping your backlog crisp and if you aren't deleting those old tickets and old ideas, again, you're stuck with a static road map and a static backlog that doesn't represent what you're going to be building. So get into the practice of going in and killing your darlings regardless of who the idea comes from. Other things that worked for us, being the context machine. This is more so for a product person, but it really strikes gold when you have an engineer who can be the context machine as well. Repeat the context until it feels like an overkill.

Repeat it over and over again in different rooms to different sets of people or to the same rooms to the same set of people and own the why. And be open to questioning when you do this because most of the time you might have a new engineer or a new data scientist asking a question that you just don't know the why to. If your answer is, well, that's how we've always done it, great. Say that and then go around and try finding out why have we always done it this way. This happens quite a lot in our suite of products because we have done things a certain way because of how historically the industry has prepared us. That doesn't mean that it's not open to questioning. Having your users and engineers and data scientists ask you a question of why you're building things is probably the best test case scenario that you can have at the start of a feature design and feature building.

And so and the way to invite those questions is by owning the why and is by repeating the why in every single room. Other things you can do, and I think the next one is very, very important, is knowing that momentum is not the same as motion. Momentum is moving in the right direction. Don't confuse being busy with being effective because you could have your entire team blowing out fires, and you might not be getting to the point of it and you might not be doing it the right way. Next thing on here is building Slack into the system. Again, don't confuse being busy with being effective and plan it. This number varies per team from team to team, but plan at 80% capacity at the most. Ideally, even lower. You're going to have unknowns that come up.

You're going to have test cases that you haven't thought about. You're going to have sick days that you haven't thought about during your crunch time, and you have to be prepared for it. The other part of this, which I think is extremely important, is seeing knowledge sharing as an ongoing practice. Just because you're in a crunch time and you don't wanna lose momentum in what you're building now doesn't mean it has to come at the cost of poor knowledge or bad code practices. Things that have effect been super effective for us are ensuring paired programming in terms of high prioritization, ensuring that at least two people look at a particular piece of code all the time, having collaboration calls, which allow for users and sorry, which allow for engineers and data scientists to ask questions to each other as they're working on their projects and live code reviews.

I cannot stress how important live code reviews have been in our company and our products. And, it's helped tremendously not only with writing good code and good good practices, but also onboarding new engineers and making sure the knowledge sharing becomes a part of what we do every single day and not a separate meeting we need to set up once in a while. Alright. And I think next slide is probably my favorite, about priorities changing again. It's pretty simple. Just don't forget the team. Celebrate your wins even if they're small, especially in dark times when you have a 100 things changing all the time. Make sure that you call out the engineer who wrote out the perfect Slack message that made everything super clear to everybody else. Make sure that you celebrate the edge case that we caught before anybody else saw it or the test case that failed or the perfect test that was written that was actually able to catch failures before it went anywhere.

From a product perspective, replace what's done in your daily stand ups with what's unclear. And I think we do this in a in a variety of different ways. Sometimes we ask about what's blocked and how how we can help you. I think focusing instead on what's unclear for engineers and data scientists helps route us to what needs to be done and helps organize the product manager's job. When you fail, fail loudly. It's going to happen. You're going to have unexpected results. You're going to have data that you didn't expect. You're going to have tools that were built at a point in time that didn't take into consideration all of the edge cases. Treat every single user, data scientist, engineer, business stakeholder as somebody who is a partner to you with the product.

On our side, I have never hesitated in sharing and oversharing details about our products. And that might be hard for you if you're on a b to c product or if you work indirectly with external stakeholders. So the feeling loudly, I think, depends on your company and how your relationship is with all of your stakeholders. But the thing that's helped for us is taking the time to explain to even our nontechnical stakeholders why certain things are difficult. It could be just adding a row to an Excel. And you might notice all this dataset doesn't exist anywhere in our system. Explain that and explain why it's an issue and take the time at every juncture to make sure that you're explaining to everybody else in the room.

This is something I mentioned before. Process is a tool. Keep asking yourself if the process is helping you move any faster. It's not dogma. It's not religion. Just make sure that process is working for you and not the other way around. And finally, ask what can I do better and what can I do to help over and over again in different rooms to different people because the feedback you get, especially when priorities are shifting, is invaluable? On our team, I'm again, I start off by saying this. We after our monumental shift in priorities and working during crunch times, one, we still look at this time as a time of great collaboration that we want to continue doing even without the pressure. And two, we got invaluable feedback from every single engineer. We got feedback on Jira processes that didn't work.

We got feedback on Slack messages and will Slack a ticket that we need to change and refine. We didn't lose a single person even after weeks of overworking all of our teams. And I think it's testament to how not just the product team, but the larger business organization treated the team during this period and celebrated the wins as we went through it. Just a couple of minutes left, so just quickly wrapping up. Anchor to the why and be the context machine. Drop what's obsolete and be prioritizing ruthlessly. Drive with collaboration. Don't forget your team. And finally, leave room for change. I just had one extra slide slide. I think we mentioned a bunch of this already. When in doubt, communicate. Process being a tool, not a dog mouth. And focus on your on keeping your lights on, which are three different things.

Cold maintenance, keeping business running, working on those quick wins that can delight your users, and making long term strategic bets on new tools and the systems that you can build. That's it. So it's around time. Thank you all for listening. I'd be happy to take any questions from chat or connect with you all offline. I just read from the Slack, from the chat here about failing forward, which I think is a fantastic idea and something I might try incorporating here of things that didn't work in the last week and how we what we learned from it and how we can improve it in the future. That's from Jennifer Baxter, which sounds amazing. Going back a slide because there's a question about what are the three things to keep your lights on. Core maintenance, keeping business continuity, quick wins for users that can delight them, and making those long term strategic bets on and making sure that you're paying attention to all three of these. What's helped you stay open to questions even in high pressure situations? I think a part of this is team culture. It's not just been me.

It's been top down from everybody that you need to build a culture of saying we don't know and staying humble to things that you invariably won't know, and continuing to iterate on it and emphasize on asking questions in every single room, whether it's a newest developer who joined a week ago or a senior engineer who's been here for the longest time.

Do you have a tip on which level to involve for the alignment? So to answer Helen's question, I think we don't have a systematic approach to this. I I'm not I don't think I can tell you involve always the VPs and not the c level for certain things and in others. I think it's a very case by case scenario. Sometimes we involve every single level of brain scientist in the room, which has been helpful and sometimes chaotic. And it's about keeping your finger on the pulse and knowing when it gets chaotic that you need to change the process around. To Sarah's question, I think that's exactly why you need to punk and be able to say you can't do something you're working on, even if it's something that's currently in progress. One, having slack in the system helps, but most importantly, killing projects regardless of what status they're in. Some cost fallacy is real in agile software development as well.

So just because you've spent three months on it doesn't mean you have to complete it before you start the next project or the next priority. Prioritization should be seen as a ruthlessly efficient task. Alright. It's just on time, so I am going to stop here. And again, I'd be happy to connect with everybody on LinkedIn. That's my LinkedIn on the slide. Thank you all for joining.