Trisha Price: [00:00:00] If you build software or lead people who do, then you're in the right place. This is Hard Calls, real decisions, real leaders, real outcomes. Hi, I'm Trisha Price, and welcome back to Hard Calls, the podcast where we have some of the best product leaders from across the globe. Come and talk about those moments that matter, the big decisions, the hard calls.

I am so excited for today's guest Jessica Soroky. I have had the privilege and pleasure of working with Jess for the last four years. Jess has a great and interesting career from agile coach to chief of staff for one of the founders of Pendo, to now heading up product operations across Pendo, where Jess isn't just responsible for making sure that Pendo efficiently ships software.

She is responsible to make sure that we achieve business outcomes and has been a huge part [00:01:00] of that transformation at Pendo over the last few years in this role. So welcome to the show, Jess. Hey, thank you so much for having me. Well, we are so excited to have you here today. It's gonna be a super fun conversation.

Jess and I know each other very well. So I hope this is as fun for the rest of you as it is for Jess and I. Jess, this is the Hard Calls podcast, so we like to start every episode with the product leader sharing a really tough call that they've had to make and what made it challenging.

Jessica Soroky: Yeah. So I'm gonna take a human aspect of this and talk about a challenge that you actually gave me when I started working for you.

And, and that challenge was to build the best possible team out there and, and you really held a high bar that. Frankly was incredibly motivating, but it created the opportunity for a really difficult call. We had a team member who was absolutely trying their best. They were incredibly positive.

They had like the, [00:02:00] if I could recreate their personality and the professionalism and the willingness to try, I would do it a million times over. Unfortunately, even at their best for what we needed at the time, we. Had to step back and be willing to look at is this truly the best of the best?

Is this the elite team member that we need right now to do everything we're trying to achieve? And the hard call, there was no, no, like great human being, amazing person. Worked really hard, tried really hard. But they just weren't what we needed to, to, to that a player. so we had to make the really difficult call to have to part ways with that person to be able to create space for somebody who was better suited for our needs at the time.

And while it's on a product specific call, I think it really did change because I respect that human being, but the person they brought in. Has made some game, changing moves for our team and for Pendo and all of that. So at the end of the day, I know it was the right call, but it was [00:03:00] definitely not easy in the moment.

Trisha Price: I love that you shared that one because people. Are such an important part of our success, and it is a hard call making the right hires, letting people move on when it's time. And I remember that time well, and I respect your decision and the way you handled it and so that's a, that's a great one to share.

And, and so Jess, I'd love to, to start off by talking about the transformation that you led at Pendo. I'm gonna guess it's been about three years now since you started in this role and started the transformation. You helped the product team at Pendo and Pendo really transform from really thinking about product and go to market separately and shipping features to really driving business outcomes.

You'll never, I'm sure you'll remember and I'll remember forever. [00:04:00] There was a feature and I, I had heard it was shipped. I could see in Jira it was shipped and I went into the product, which I use our product every day and I couldn't find it. And I went and asked a million people where it was and why I couldn't find it.

And I got 10 different answers and no one really knew. But our scrum masters our team was saying it was shipped, but it wasn't shipped because it wasn't on in the product. And that became, began and sort of a catalyst for all the work that you did in the transformation. So tell us about it.

Jessica Soroky: Yeah. that, I do remember that feature.

I remember that, that slack interaction and the horrible feeling of also not being able to find you the answer as, as an operational person. I, it went into all of our systems and all of our existing processes, and the fact that I couldn't find it either was. I'll never forget that moment. but I do think that it was this catalyst to really shifting our focus from done, being defined [00:05:00] as engineering is done to No, no, no.

There's this much bigger ecosystem as a whole company and what does it mean to launch as a whole company and make sure that all the different facets are ready, enabled, supported, and can, everybody can work together to make that successful. So I think. It was necessary that we went through that because it led to to where we are today, which is a lot more cohesive as a larger organization and how we launch products, and it completely changed our entire lifecycle.

We went from, I think, being like an SDLC-focused shop to. We don't really talk about our SDLC, and now it's the product development lifecycle. It's the PDLC through and through every department, every part of Pendo. We all know where we live and how we act in that PDLC to make sure that the investments we're making and what we build are as successful as possible.

And, and when they hit when they hit the market. When it hits customers.

Trisha Price: I love that, and you've done an incredible job of that. Tell [00:06:00] us a little bit about how you did it. I'm sure it was a change to people, to process, to technology. It's probably a change and a transformation that's never really complete, but talk to us about how you led us through that.

Jessica Soroky: Yeah, so we first looked at the people, the roles that we had at the time, and when we were more focused on eng-done Nat, I, I wanna say naturally it felt natural. At the time our role was focused in the agile space. We had a team of Scrum masters that were supporting. I hate saying traditional scrum way because that feels so weird, but a traditional Scrum way and that they were really dedicated to the engineering teams.

They were in the weeds with them and managing the day to day. And so the first and biggest transformation we had to do was to get those operational process people to look at this bigger lifecycle. They needed to understand why the entire, uh. From beginning of an idea all the way through customer hands and then closing that loop for us, given the product that we build, we needed to be able to make sure that we were truly utilizing adoption [00:07:00] metrics, usage engagement.

All of that needed to come back to the beginning of the cycle to make sure that we were constantly iterating and improving based on those analytics. and so. To do that. Then the first thing that we did beyond changing their role and, and kind of doing some base level at reeducation of what they're responsible for is we did an education tour.

If you remember this, I think I came to you and was like, Hey, I wanna invite leaders from the different departments across the business to kind of do an empathy tour with my team and teach them from a customer success standpoint. Why does this all, like what matters to customer success? What are their pain points?

What do they care about? We did that for every major organization. We had sellers come in support folks come in. We had, I think, legal security, all of the things. And we did a pretty deep dive for the now program managers and all these different functions that. Kind of wildly and their engineering focus, they never really interacted with or understood.

They knew the conceptual right idea of what a customer success [00:08:00] person does or what security does, but they didn't understand it to this level, and they needed that depth of knowledge to be able to then put pieces together more effectively as they were coordinating this much larger process.

Trisha Price: That is great.

I love your focus on people and giving them the exposure to the rest of the company. And I love, like, as an operations person who does care about process, that your first answer wasn't about process, it was about the people. But I think, you know, and, and not over rotating on process. And I think that's the true testament to why you've been successful with this transformation.

Jessica Soroky: Yeah, I mean we, we of course had process pieces to it, right? So as we were building out the people and the education and the breadth of knowledge, we did look at the process we created, what we called I think we still call it double diamond, which is our mapping of this larger lifecycle. And we needed to be able, essentially to do our own version of a customer journey and like.

If [00:09:00] you're at the very beginning stage and you're ideating what behaviors and actions are happening, who's responsible for what? How do we visualize and communicate work in that stage to our CPO, to our CEO, to our CTO, to all of those folks? And so we did that step by step. We created I believe it was ideate, define, no ideate, validate, define.

Whatever the work stage is now, it's crazy because that's like the part we focus the least on because that's the thing that we, we already knew very well. And then all of the launch actions and the go to market and all of that. So we, we made sure it was really clear who did what, when and where in each of those steps.

And then we did a very big education tour of our own this time going around and making sure everybody knew. What we did, how we did it, what product ops did in that new function. because we did change kind of their role as a part of this big transformation as well. So we wanted to clarify how they add value and where to use them.

and then frankly, we just had to start executing. We had to start proving it through day-to-day [00:10:00] behaviors and actions and taking people's feedback. Pendo has never been a company that wants Heavy, heavy process, and I've known that from day one, which was helpful in this because it, we started with a steel thread.

What's the bare minimum? How can we define it the best we know? And then let's just iterate and test it and not get offended or hurt. If somebody comes back to us and goes, Hey, this piece isn't working, or It's too heavy, or it's too light. Let's just make sure that we're listening. Constantly taking the feedback and iterating.

Trisha Price: I'll say that is definitely one of your biggest strengths that has shown up. and, and probably a big part of why this transformation was successful is your ability to take that feedback from everybody and just let it power improvement. not, take offense to it. So, Jessica, we're talking so much about moving to business outcomes versus just focusing on optimization of process.

Can you share. What's a business outcome that you and your team have been [00:11:00] accountable to drive across the company?

Jessica Soroky: Yeah, so since we define product ops as half program management and then half product operations managers, the program managers are held to the business outcomes of the success of our launches.

So they are expected to drive more thoughtful, intentional, strategic launches of our products. Measures of success business outcomes. There is, do every one of our launches have clearly defined measure of success? Do we have Pendo dashboards that can show that we are progressing against those goals? are we communicating effectively given our leadership's how do I wanna say this?

Given, given given our leadership's desire to. Be able to grab information whenever they want, right? So even all the way up to Todd and our CEO, he loves to be able to asynchronously go find information. I remember you and I talking about this a ton. How do we make it simple so that if he wakes up at 3:00 AM and wants to go find an answer, he can do that on his own.

So they were absolutely measured by that outcome of. How [00:12:00] often does he have to go? Or do you have to go ask somebody as a human for an answer versus you can find the information on the product operations side? We had to really figure out, because our PMs should be really good at their own segment of the product and finding and using data, right?

So a lot of product operations teams have to be that like data force where they're pushing data out, they're helping educate how to use data, how to make data-driven decisions. We didn't have nearly the same. Responsibility in that space because of the PMs that we employ and, and their day-to-day. But we did have to start to drive better business outcomes about how we use the aggregate data across our product.

So how do we make sure that, that you as our CPO had the right level of information looking holistically versus these individual slices where the individual PM sat. And so we were really look constantly focusing on how do we incorporate it into our operating cadence? How do we make data a natural part of our behavior?

Versus this forced function where we had to stop and go, okay, now it's that time again. Let's look [00:13:00] at the data and make sure we're paying attention to it. so that's definitely one that we've driven to on the product operations side.

Trisha Price: So you talked about Pendo and our obsession with data. As a part of our decision making and process and how that is a self-served motion for our product managers.

And that I definitely agree with. It is true. So I get asked this all the time, and I'm sure you do too. Is, what is our product cadence or product review like at Pendo and how do we use data? and metrics in that process. So talk to us about that.

Jessica Soroky: Yeah, so each of our individual programs has a little bit of their own flare as to how they are looking and using their individual product data.

But across the product we have we start with our roadmap reviews. so these are a shared meeting between product leadership and engineering leadership. It is a smaller audience in that the presenters are really focused [00:14:00] on like one segment of our product. and they're normally our most senior product leaders in that segment.

So it's not like a broader meeting they come in. We have really worked hard to eliminate presentation building. we try really hard to just say, Hey, come in. Pull up your Miro board if you're playing with, or your Figma board if you're playing with early designs. But pull up Pendo, show us Pendo itself.

Bring up your dashboard. Show us what's going on in in the area of the product that you have built. Use that data to build the story as to what you plan to build next. And then leading through those types of conversations. We use Pendo roadmaps to visualize what they have built and they're about to build.

So that's a monthly cadence. We also have a quarterly cadence that we call the product Impact ONI, which is. This really cool cross-functional event. It's big. I'll be the first one to admit it. It is not cheap. but that just pushes an onus, I think, to making sure it's highly valuable for everybody, which is kind of a cool pressure in my opinion.

But in that meeting we split the [00:15:00] responsibility. So the first half of the meeting is customer facing teams. That are coming to us sharing qualitative, typically sometimes quantitative data from their point of view. What are they seeing in the field? What's the market like analysis going on right now?

What's a big competitor we should be paying attention to? What's PMM's strategy and priorities? what's sentiment with renewals? What's challenging? Those types of things. They bring that products responsibility is to bring. Now this is where we invite the vast majority of our PMs and they get the chance to show off in a broader sense.

Here's what I've built recently. Here's how it's being in utilized by our customers. There's oftentimes calls to action there to be able to build that cross-functional relationship to say, Hey, if adoption's here and we want it to be here, cross-functional partners, I need your help in designing.

What does this look like? What's the right strategy? Should we deploy more guides or should we utilize different types of, of tools? And then they also show off. the Next six weeks. Again, we really try to keep it focused, [00:16:00] narrowed in on what did we just build and what are we about to build? and then they get feedback from those cross-functional partners again on are we hitting the right marks?

Are we addressing the issues that you guys just presented and what we're planning on building next? It's pretty simple in my opinion. It's just really those two cadences. Obviously we are still a scrum shop, so on an ongoing basis our teams are meeting every two weeks, reviewing what they build, planning their what's next and looking adoption metrics at that point.

But we as an organization are, have those two cadences.

Trisha Price: That's great. So Jess you talked about, especially that first smaller meeting, tell me like, what's the. What's the culture? What's the vibe in that meeting, right? Like is this a meeting where people can tear apart each other's ideas without taking offense?

Is this a meeting where we're trying to band together and we have meetings before the meetings and we're really championing ideas so that the CPO and the CTO sign off on it? Like just tell us what's the vibe there? Like how do they get [00:17:00] to the right answer?

Jessica Soroky: So single word was the vibe. Passionate.

They're very passionate meetings. No, to my knowledge, there's no meeting before the meeting to try. Thank goodness. Yeah, thank goodness. and I will say I, I don't have like a hard statistic, but I know that we have significantly decreased the amount of preparation that used to go into similar meetings.

The amount of hours to build slides to show what we have in our own tool was, was kind of crazy in the past. I do think it, there is a lot of. I mean, it's product people. Everyone loves what they're building. Everyone has their baby. Everyone has their idea. So there's definitely strong opinions in those meetings, but I think we have fostered a culture where you can challenge and be challenged.

And it's not a personal thing, it is really just about. What is the right strategy for the business? What's the right strategy for the product? And then if you're being challenged on your idea, like where's the data? Show us what makes you believe that your idea is the right idea for our customers or for our product?

I think it's a pretty, [00:18:00] pretty fun, they're definitely, they're intense. They're intense meetings for sure, but I think that they're mostly fun. and it's cool because of how frequently they happen given just like where the, frankly, the world is right now with how fast everything is evolving and, and how big the AI.

Conversation is becoming. It gives us a chance to iterate much, much faster on is this the right strategy? Still, even if we knew it was a good idea a month ago, is it still Should we keep investing in it? That kind of thing.

Trisha Price: So you mentioned AI, and obviously AI is changing, not just the features and how people in product and engineering deliver software through agents, et cetera, but it's also changing how we work in product and design and engineering.

How have you, your team, Pendo, utilized AI and how is that changing the efficiency and how you work?

Jessica Soroky: okay, so great question. one of the things that I would say that we've [00:19:00] utilized probably the most recently is Bolt, which we did a really cool hackathon recently where normally our hackathons historically have been run by our engineering teams to, and they have some sort of a theme and they get free run to go build and, hack.

This particular hackathon was really hyper-focused on how do we use AI to prototype early ideas faster and to, to figure out the viability of those ideas. So our design team ran it, which was really cool. and they kicked off. They gave a very short, 30 minute intro. A lot of our folks that were playing in this hack had never experienced this tool before, this 30 minute intro, and then they were given a couple hours to, with a, with a problem statement that they were trying to solve for, to go play and solve.

And the results that we got back were. Kind of mind blowing and how, how cool of of idea and how far the idea got that fast. Like the way that they were able to visualize it, it was. A really cool experience. So Bolt has stuck since that hackathon. our, our teams all love to play with that. We also [00:20:00] are, are from a product operations point of view specifically, we do lean in heavily to the insights that Pendo provides through Listen, and how we try to look at that across the product to make sure that we're weaving.

that Back into those cadence, those operating cadence meetings that I was talking about. So in the roadmap reviews and the larger cross-functional meetings, making sure we're pulling those insights and, and making them visible to everybody has been a big improvement as well. We don't have to manually go through all of our NPS results one by one by one anymore, and create our own summary.

Now it's. It's simple. It's fast.

Trisha Price: That's awesome. That's great. Well, switching gear gears back to measurements and outcomes. I know OKRs are a big part of how Pendo runs the company. Talk to me about your role with OKRs and then specifically product operations. How do you take company OKRs and help cascade them specifically to what you measure in product and and the [00:21:00] success there?

Jessica Soroky: Yeah. So we have the program managers as a part of product operations. They are the ones that manage all of our companywide OKRs. So we assign one program manager to each OKR, and they essentially program manage the OKR. They make sure that there's clear sets or clear measurements for success. They ensure there's milestones, they make sure progress is happening, they raise risks, handle interdependencies, those types of things.

My role is I get to do the same thing, so I, I jump into to OKRs myself and help program manage them. similarly in R&D across product and engineering, if there's a big cross-functional, hairy, complicated thing, normally I get the joy of jumping into them and helping herd the cats and, and organize that.

there was an OKR somewhat recently that stands out the most to me. That kind of really iterate, like to me, shows. an outcome that we were trying to drive towards, which was we were trying to improve as a company, our cross sell. So we had recently released [00:22:00] a couple different new SKUs, new products and we weren't getting the attachment that we were looking for with those new SKUs.

It wasn't that it was horrible, but it wasn't the ideal state, right? So we organized a company-wide OKR that included folks from all the major departments, revenue marketing product engineering, every facet to say, how do we really intentionally. increase cross sell, increase the adoption of these different products.

And so that was really cool because we obviously had the direct connection to our product organization, and we were able to bring that OKR into product and say like, from our, from our point of view, what can we be doing better? Right? Are there guide strategies that we could be using that to drive adoption here?

Are there intersections? I think that was actually one of the. OKRs that really started to birth this concept of intersections across our product. And so making sure that from an product ops point of view, we were then taking that lesson of, okay, there's this concept of an intersection. How do [00:23:00] we start to drive that as an outcome as we build going forward, even after the OKR ends, we wanna make sure that this concept becomes a part of our natural behaviors and that we're talking constantly.

I remember we do something that you started with us, which is these product days and once a quarter. Once a No, twice a year. Twice a year. Not once a quarter, twice a year. We bring all the product together and it's this cool showcase of them getting the chance to show off what they've built, what they're doing.

It really drives cross knowledge knowledge sharing around what other folks are building. But when we started to incorporate this idea of intersections from that OKR, it's like that showcase just really took off because then they were challenged to think about what they were building, but from a larger point of view and this bigger ecosystem that we were building, and it was just, it became very, very impactful.

I, I still hear constantly about when's the next one? When, when do we get to do the next product showcase? so it's definitely latched on for sure.

Trisha Price: I love this concept of intersections that you raised, which is so [00:24:00] many product companies claim to be a platform because they simply build multiple modules or products.

On the same technology stack or even have a similar look and feel or a part of the same application, but this concept of intersections that you bring up, which is really, really thoughtfully understanding the user experience and those magical intersections between two different projects, products between two different modules.

Is so special. And to your point, it can drive real business outcomes of cross sell, right? If you're thinking about one of your products and a job to be done or an action or a workflow that, that someone's completing, and then right naturally from that, you can figure out a launch point to one of your other products or modules.

It's such the special way to differentiate from the competition, but also a diff a special way to drive cross sell. So that, I love that you brought that example up. [00:25:00] So OKRs, you help run them for the company? Yep. OKRs can be amazing when done well. They can be a major eye roll and just. A headache and a checkbox exercise when done poorly.

Tell me, what do great OKRs look like and how do you help make sure they're actually useful for Pendo?

Jessica Soroky: Whoa, that's a big question. we, we have tried lots of different flavors of them if we're being transparent, right? We've tried annual OKRs. that span the entire fiscal year. We are currently in quarterly OKRs.

I think the, it's kinda like a Goldilocks thing where we have figured out that it's not always one or the other. that's definitely something that I would say is a successful OKR is looking at the outcome you are trying to drive with that KR to decide the timeframe to give it versus being super locked into know everything must fit into this time box.

so I think that's number one is making sure that you allow at the time it needs. To actually achieve the [00:26:00] outcome. then I think you need clearly measurable outcomes. it is not an OKR unless you can measure the thing that you say you are trying to accomplish. So what does that look like? Right?

So in, if you're trying to increase cross sell, that's a pretty simplistic one, right? So we know what our baseline metric for what the adoption of those new products was when we started. Then you set a goal. Where are we trying to get to? We're trying to increase by 15%, 20%, whatever that that is. Making sure you're driving to that and then having milestones that are truly value checkpoints, not just, I accomplish these three tasks, meaning sometimes I can see poor OKRs being the laundry list of all these activities we have to do and in a sequential order, and then them going, okay, milestone here, but like, what did you actually achieve?

At that milestone when you do it that way versus, I like to just start with, what's your overall outcome you're trying to drive towards? And then if you almost like reverse engineer it, if we're gonna get there in three months or six months, [00:27:00] whatever your timeframe is, where do we need to be a month before the end of that to be know that we're gonna nail that thing.

Oh, we need to be here. Okay, cool. And you continue to do that back until you get to the very beginning and then you fill in your tasks versus I oftentimes see. folks that are slightly newer to that structure go massive objective laundry list of tasks, and then they just, oh, crap. We need some milestones, and they tag some dates.

And I, I don't see that nearly as successful. Yeah,

Trisha Price: no, that's great advice and easy to get caught up in. I already know what I need to do. Let me start focusing on the tasks versus what am I trying to achieve. And I think that's so relatable to this whole conversation for product particularly because. It can be the same way, right, for specific products that we ship, as it can be very easy to get excited that we shipped five different features, even if none of those five features actually improve retention or adoption or revenue or [00:28:00] whatever our goal is.

So I think that's good advice for all of us to keep in mind whether it's OKRs or launching a new product. Shockingly, not every single project program product that we try to accomplish is successful. So one of the things I know you're exceptional at is postmortems and helping us figure out the why.

So tell us a little bit about your process for running postmortems on product decisions that didn't pan out. So

Jessica Soroky: this goes to my Agile background. it's a pretty core concept to any Agile's out there. You retro you retro constantly. I think I really benefited from a really good mentor when I first started out and like some of the facilitation techniques to draw some safety into the room so that people can be honest, basic.

guidance would be starting with [00:29:00] some rules of engagement, especially if something really didn't go well. Making sure that everyone in that room knows this is not a blame game. We're not looking to. Point fingers at each other or tear other groups down to, to justify the situation that we are in. I prefer if at all possible in person postmortems just because you do get the I think increased.

Anonymity of a, I love a sticky note. I'm, I'm an old school. Give me a stack of sticky notes and a whiteboard and we can postmortem literally anything. because it's, it's nice to be able to, to just write down kind of what you're feeling, what you're thinking. It sounds wildly simple, but I still constantly have to remind people that when you are, whether it's a virtual whiteboard and aren't an in person one, identifying things that went wrong.

Don't call out names or teams like we, we, we don't need to know that Becky screwed this thing up. We need to know that x, y, and Z process didn't work efficiently or that a step got missed or, or whatever. The thing is, don't, we can identify the [00:30:00] thing, not the person. And sometimes I've even had to, as, as the facilitator, reading through them, just omit.

Pieces that somebody has written on, on their piece of feedback to make sure that it doesn't become this personal thing. so those are some basic, I would say, facilitation techniques. The other thing that I would, I really encourage, or that I do myself is I'm not afraid to ask some dumb questions in the session.

If I don't know everything that's going on, I think it can actually be really beneficial because I can say, Hey, as an outsider, explain this more to me in layman's terms. And it almost like de-villanizes the situation because it just, it, it gave me the most basic rundown of what was supposed to happen and what did happen.

And when they are able to do that, it can take some of the heat off of it. And the key, the final key is if you don't get to action about what you're going to do different next time or what you're going to change as a lesson from this. It's a waste of everyone's energy and time, so making sure that you are clearly and constantly getting [00:31:00] to action.

I prefer to do it as we talk about each individual thing versus I've seen some folks that like to talk through all of the stuff. And then get to action. I think folks are exhausted when you take that, that path. So I like to just action it as we talk about it and then make them find or finish the session, I'm sorry, with prioritization.

Out of everything we just actioned, what's the most bang for our buck? What should we change or do differently first? and then I assign an owner. And when are you gonna be accountable to finishing that thing, which also sometimes gets missed when you're doing these post-mortems is ownership and deadlines to see it improve.

And then I'm a great nag. I love to nag people after. Yeah.

Trisha Price: Got to Got to that's part of the job, right? Yep. It's part of the fun. Yep. So, you know, we, we've talked about your role of program managing as well as product operations holistically to help product teams effectively and [00:32:00] efficiently drive business outcomes through shipping software.

Part of your job is to constantly look at how the product team and engineering are doing and make suggestions to improve, to help us figure out where our bottlenecks are, to help us figure out what's not working well and where we're not achieving outcomes. How do you help? Like, what are you looking at?

What is this continuous improvement, continuous learning look like? and then how do you fold that back in to make change? So I think

Jessica Soroky: something

Trisha Price: I've learned

Jessica Soroky: somewhat more recently is just being really, really close with the leaders in product and engineering to understand what they care about because As their desires and needs change. So should what, what and how we behave. And I will say, I don't think I knew that earlier on in my career. I didn't realize it. so we went through a CPO change and, and it was a big reminder of like, okay, let me check in again and figure out what did [00:33:00] Trisha care about versus what does this new CPO care about?

How is that different, how our behaviors change? very recently we've been talking internally about this. Building AI is a very different way of building software than than previously experienced. So similar conversations is like, okay, CTO CPO what do you want to see? What is the outcome that you are trying to drive for?

And then how does the process and what we measure create that? So for instance one of the things that we're trying to figure out how to do is iterate even faster. How do we increase the or how do we decrease, I'm sorry. The time from idea to just hands on keyboard. We wanna just experiment rapidly so that we can test it quickly and learn from our lessons quickly.

And so we had to step back and go, okay, well what are we measuring today and what behaviors are driving the anti-patterns to that? Like why aren't we getting that to be able to then go if that's what I believe what you measure is the behaviors you're gonna get 100%. So when we stopped and looked at it from that point [00:34:00] of view, we were able to quickly realize, well duh.

We're getting the results that we're getting because of the things we're measuring. So let's change those measurements and let's find measurements that make sense for this new behavior. So that particular example, one of the ones we're playing with is how do we decrease cycle time from idea to to dev start.

we have baselines. We measure them already in, in, in our tool, current tool suite. So it's not hard for us to, to set the standard and now it's just, okay, let's experiment and figure out what ways can we decrease that cycle time really quickly.

Trisha Price: That's, that's amazing. And so you talked about your engagement with the product leaders and understanding what their goals are and what's important to them.

When you figure out these changes that you do need to make, how do you manage that change with the rest of the team?

Jessica Soroky: Depends on the scale of a change. Definitely impacts it. because of my experience at Pendo. Being in both engineering and products and having really strong relationships with both [00:35:00] leadership teams.

Normally my first reaction is to try to assess how much do I need both sides. Like, so some changes I might just need product buy-in. whereas other changes, I absolutely need R&D to be bought into it, and so that changes my behaviors going forward. If I need engineering to also be bought in, then playing through our own internal dynamics to figure out what's the right way of.

Bringing the situation to them, but at the bare, at the basics level of it, it's always the why. I think you, you really helped me constantly think about and, and position any change management, starting with why are we doing this and why do you IC care about that? Why? So like whether you're a product manager or product operations manager, an engineering leader or an IC engineer, if we're asking you to do something differently, What's the positive impact you should, you should expect from that change and trying to lean into that. and then I know this is no, no leader's favorite thing, but like repetition over [00:36:00] and over and over again. Communicate it over again and again and again. Um. I, that's a, that's a constant challenge, but and you're

Trisha Price: right, it's not our favorite, but it is important and you're good at reminding us of that, and you're a great partner that way.

and, we appreciate that. you know, in, in closing today, Jess, one of the things, product operations, it's not a new concept in product, but it's not. been around as long as product either, and especially for companies that are still, you know, undergoing the transformation to some sort of product operating model.

You know, may not be as familiar with product operations or people may think that's something I can do down the line or if I'm trying to save money, it's not something I need right now. Tell us why product operations is so critical and why people can't afford not to have product operations.

Jessica Soroky: Yeah, so [00:37:00] I, I see it actually really similar to this craze around AI in the sense that with everyone wanting to to be as fiscally responsible as possible, given the constant ups and downs of the economy right now.

Product operations when, when done well is an incredible way to get more out of your existing product organization without having to add additional heads to it. it is an incredible way to make sure that if you are investing in ai, that you're getting the most out of those tools and the rollout across your product org, and ensuring your PMs know how to use them, where to use them, how they can simplify their life with them.

I think that it is, it's not there yet, but I do believe that product ops is gonna become the same type of heartbeat to a product organization that, like a rev ops is to a revenue organization. It's continuing to just capitalize on, on the value that it brings and make, and. Creating consistency across these product organizations.[00:38:00]

But if anything, I think it's more critical now than ever because folks don't have the dollars to go build out 10 more PMs or even expand by one or two more PMs. So if you can figure out how to get a small. Very operationally minded set of human beings to find you efficiencies constantly.

Why would you not want that right now? When, when all belts are tight?

Trisha Price: Yeah, I think that's a great point, Jess. And, and I was having a conversation with Marty Cagan who we all look up to especially when it comes to product operating models. And one of the things that Marty said that I really appreciated was that.

Every single company creating software needs, project managers and program managers. But that's not what a product manager is. And if a product manager is spending all their time doing program management and project management, then no one is being a product manager. And I think that's true [00:39:00] across, right, whether it's the design team, whether it's product marketing.

And so I think your team has just done an incredible job of keeping. Us focused on the business outcomes we're trying to achieve, helping us understand where the roadblocks are, where we're slowing down, where we're stuck, providing transparency into that, and then really helping all the other teams stay true to also what they're supposed to be doing.

And just because you're a good product manager does not mean you're great operationally and vice versa. So but we have had people. From a career path, go from product operations to product management as well?

Jessica Soroky: A hundred percent. I actually think it's one of the biggest symbols of success in my mind is especially because those two use cases, they were agile backgrounds.

and had we stayed on the path that we were on. I could almost bet my paycheck that they would've never moved from Scrum master to product manager. But this move into [00:40:00] program management being such a vital part of product operations and living in product, gave them this really cool career opportunity to, to see just much more about how product is built and then move into that space themselves.

Trisha Price: That is great and hopefully that's a great advice for all of our listeners. For people who ask you and I all the time, how do you get a path into product? it is, you know, it is obviously more than being organized in a great program manager, but by sitting in product and understanding the outcomes and understanding what product is and does, gives them more exposure and sometimes even they can try it out and yeah, somebody might be on leave or someone might be away.

Or we may have a new open spot and, and even give someone from product operations or program management a chance at that. So that's great. Well, Jess, thank you so much for joining us today on hard calls. I really appreciate you sharing your experience, your wisdom around all things, product, operations, all [00:41:00] things data, some things Pendo, and specifically on the transformation at Pendo to, business outcomes.

So thank you. No problem. Thanks for having me. Thank you for listening to Hard Calls, the product podcast, where we share best practices and all the things you need to succeed. If you enjoyed the show today, share with your friends and come back for more.