I knew I was taking folks who had been careers remasters, and if I left them in their comfort zone, I knew I was going to have a much harder battle to get them to change their daily behavior.
So that was kind of the original intent behind it.
But what we found is that the positioning in product allows for them to have a lot more influence.
When they're having these cross functional conversations, it gives them different positioning, which I think has been really helpful.
We're redefining our operating cadences as a product organization, which has been mildly terrifying, but also very exciting as it gives us a chance to re -evaluate what's working and what's not working.
So, our new cadence is that we do every six weeks what we're calling a product impact meeting, which is really cool and it's cross -functional.
It gives us this more holistic view of what is truly going on with our customers, with their usage of our tool, how do we keep the folks making decisions about the strategy of our product as in tune with our customers and their true feelings.
Even with such a strong analytics tool, it's easy to get lost in the noise.
And then we also do monthly roadmap reviews.
We're trying to get into a cadence of a rolling planning versus like a point in time planning.
And so our product areas come in and walk through what they just built, how it's adopting, how it's being engaged with, and then what are they building next.
Creating great products isn't just about product managers and their day -to -day interactions with developers.
It's about how an organization supports products as a whole.
The systems, the processes, and cultures in place that help companies deliver value to their customers.
With the help of some boundary -pushing guests and inspiration from your most pressing product questions, we'll dive into this system from every angle and help you think like a great product leader.
This is the Product Thinking Podcast. Here's your host, Melissa Perry!
Hello and welcome to another episode of the Product Thinking Podcast. We have a very special guest joining us today, Jessica Sorokay, the Senior Director of Product Operations at Pendo.
Jessica is a passionate advocate for continuous improvement, collaboration and effective leadership, and she has played a pivotal role in transitioning Pendo's product operations framework.
Today, we're diving into how Pendo has developed their product operations organization and impact it's had on their product management practices.
But before we talk to Jessica, it's time for Dear Melissa.
This is a segment of the show where you can ask me any of your burning product management questions and I answer them here every week.
Go to dearmelissa .com and let me know what's on your mind.
Today's episode is brought to you by LiveBlocks, the platform that turns your product into a place that users want to be.
With ready -made collaborative features, you can supercharge your product with experiences that only top tier companies have been able to perfect.
Until now! Think AI copilots like Notion, multiplayer like Figma, comments and notifications like Linear, and even collaborative editing like Google Docs, and all that with minimal configuration or maintenance required.
Companies from all kinds of industries and stages count on Liveblocks to drive engagement and growth in their products.
Join them today and give your users an experience that turns them into daily active users.
Sign up for a free account today at Liveblocks .io.
Let's see this week's question.
Dear Melissa, how should we think about the product strategy canvas with its vision and challenges in a large company with multiple business units?
Where are our products only indirectly relate to a company's larger vision?
For example, in my case, product manager is helping to build internal tools and dashboards to be used by internal auditors.
Should we be using the product strategy canvas or is that not the right tool to think strategically about our long -term product goals?
Great question, and this is very timely too since I just released a new course on Product Strategy over at Product Institute.
If you have more questions about this, definitely check out that course.
But to get to your question, yes, you can use a Product Strategy Canvas for this.
So there's kind of two questions here.
With a large company with multiple business units, you wanna think if they are standalone companies and if they can operate independently.
So if that's true, then I treat each canvas like a separate company.
You'll have a vision for each business unit, strategic intends for it, and then a software portfolio that makes up the business unit, and you have product strategies for each of those individual products and the whole portfolio.
Now, internal tools are included in this as well.
Internal tools help your company operate.
So for instance, if you're out of bank, let's say, and you're working in the credit card division, your strategic intents for the credit card are probably going to be centered around growing your business, getting more clients, all that stuff.
You do this through a few ways.
You launch new credit products, but you also ensure the trust of your customers.
That promotes retention and growth.
They're gonna come back and keep working with you.
Think about it, would you ever bank with somebody that you don't trust?
Probably not. So that's where auditing comes in, right?
Auditing gets pulled back into customer trust. You're gonna want to be looking at compliance there, regulations, helping your auditors to actually succeed.
So the idea here is that those types of internal tools, even if they are for people inside your business is contributing to customer value along the way.
So when you're thinking about internal tools, you have to figure out what levers you pull to deliver value to the business and customers.
So you need to make it easier to do those internal auditing that can save you company money.
It can ensure better compliance for the company and that helps translate into improving trust. So that's how I would think about it.
So your challenge here would probably be related to providing those types of value back to the customers which you don't do alone.
You probably do with other types of auditing tools and you're part of the bigger picture about trust in the company.
So I would really dig into how that all relates and that's how you use a product strategy canvas to ladder all the way back up to business goals.
I hope that helps. And again, if you have questions, go to dearmelissa .com.
Let me know what they are.
Now, let's go talk to Jessica.
Welcome to the show, Jessica.
It's good to have you.
Thanks for having me.
I'm excited. So can you tell us a little bit about what got you into product operations?
Yeah. It was deeply unintentional.
We had somebody else running our product operations team at the time, And I was actually a chief of staff for our CTO and co -founder, and I had come to Pendoh at leading our out of practice.
So that was kind of where my forte was.
And our CTO asked me, we had gotten a lot of scary questions.
Like do we really need all these scrum masters?
what value do they provide?
can't the engineering manager do those types of things?
And so he was like, Hey, why don't we do an objective assessment of our product development life cycle and all the roles that play into it and let's see where we're doing well and where we're not.
And so very Chief of Staffy thing.
And I was like, cool, I can be objective and I can go make that assessment.
And long story short, I made a decently bold proposal in that assessment.
So we we could dive into kind of what we found if you want, but I suggested shifting all of our Scrum Masters to program managers.
And in that really changing the relationship that they have with our product operations team at the time.
The powers that be liked it.
And then they're like, Hey, you, this was your idea.
You should go do this.
And I was like, oh, oh, but I like my Jesus staff job.
So I was a little bit hesitant.
I also entirely grew up in the engineering world.
I'd never actually worked in product and a part of taking on this new team would be moving to product.
And that was frankly intimidating working for a product company.
So anyway, so long story short, it was through that assessment that we eventually got to me moving the scrum masters and program managers and then us putting program management underneath product operations and taking on that whole thing unintentional.
So what came out of the assessment?
So we found that we were really good at the engineering part of the part development lifecycle.
We were once engineering got the work and then executing against it, us iterating and testing, playing with all that was pretty good.
We weren't perfect, but pretty good.
We had completely ignored ideation through to engineering.
I shouldn't say completely almost completely.
And once engineering was done, the go to market motion, how do you actually launch a product to Festival Hands was also an area that we hadn't completely ignored, but we weren't doing great transparency wise.
We weren't communicating super effectively or cross -functional partners across Pendo who had to enable customers and sell it and support it once it was live, they were finding that they were just surprised way often and no one likes to find out about a product release within your own company when the festival calls, that's not, that's not great.
so we realized that we've had these two ends of this process that weren't as evolved as we wanted them to be.
And so we also found that assessment that we had too many players and similar types of roles, product apps being one of them at the time, they were trying to establish themselves and figure out what their role and their value to the company was.
And so they were, I'm going to say inserting, but that sounds way more aggressive than I mean.
Um, but they were inserting themselves throughout that lifecycle, wherever they felt like they could be offering value.
And that mixed with our Scrum Master's was creating a lot of communication handoffs that we just weren't executing effectively.
it was causing us to drop stuff and to miss things.
And the constant finger pointing of way that was your job, that's your job.
So we really wanted to simplify and make sure that we were now owning the entire PDLC and not just the SDLC and with the scrum masters.
I think that's always a controversial topic right now.
And I know Capitol one released a statement saying they got rid of all of their scrum masters too.
I think sometime last year it was in the news.
What were the scrum masters doing and what changed about their role, moving them into program managers.
Yeah, that was probably the boldest thing that we did.
They were doing a pretty, I hate to say traditional Scrum Master thing.
Cause I didn't even know there was a traditional Scrum Master, but they were running Scrum ceremonies.
They were leading two to three engineering teams, typically in the same product space.
They were helping coordinate all of the execution planning, essentially just doing Scrum Master restiff, right.
But what they changed to was they were as program manager was now responsible for the idea, the minute it was created in somebody's head all the way through customer hands.
And given that we're Pendo at the adoption pieces while obviously paying attention to what our customers were doing.
Which really changed frankly their stakeholders.
So they used to be as scrum masters, mostly engaged with engineering teams and engineering leaders.
Yes, designers and definitely some of the product managers as well, just naturally.
But now we said, hey, while that's important we need you to also start to play with and engage way heavier with product marketers, with customer success, with technical support, with revenue enablement.
Like we need you to really go cross -functional, which at first they were, I will tell you my team was not super happy when I was like, hey, I'm changing your entire job and your title and all of these things, but we really tried to hyper focus on the career benefit it would give them to be able to expand and be able to speak so much more broadly to how an entire business runs instead of just how engineering functions within the broader organization.
When you're talking about program management too, sometimes I think people get confused with that role between that and product management, right?
Shouldn't the product people be overseeing the idea all the way through at the end?
What's the difference between how you have program managers and what they do with product managers?
I would say that it's probably because they came from scrum masters, but they're really like this souped up scrum master in the sense that they're cat hurting, like they're not the ideators.
They're not the ones that are like combing through appendo data and saying, Hey, now we think you should build this or, Hey, we're not getting adoption here.
And so we should focus investment in this space.
They're really still figuring out who are all the right players to make sure that this idea that this product manager has gets executed effectively and gets launched with success so that we can have as accurate as possible data on how our customers feel about it.
So we can make smarter decisions following up.
And what shifts have you seen since implementing program managers, way better communication across the company.
we've we call it whole product launch. And what you really mean by that is it's whole company, product launch, meaning we drastically decreased the number of surprises.
So I mentioned earlier, okay, you never want to have a customer call you and tell you what feature your company just released.
So we've almost entirely, I cannot say with certainty that we've completely erased it, but I think we've gotten as close to erasing it as we possibly can.
And I think we've had better product launches with it.
Like I, given that we have now one legal and security get way more involved much earlier in our PDLC now, which minimizes waste and rework and long -term issues.
There are support both customer success and technical success are typically more enabled, and I think we're being able to serve our customers more effectively and ironically weirdly, I think we're actually more agile as a company because we are seeing such consistency through that whole process.
We can adjust and adapt a lot easier than we were in the past. What do you think of product operations at Pendo?
What's the vision for what you want it to become and what the scope is?
I think about this a lot, and it's, it's an interesting question because we have a somewhat unique use case for product ops.
And I don't wanna be that person who's all, Oh, we're a snowflake, we're not a snowflake.
Everyone's a snowflake.
But it's unique to us in that given Pendo's brand and given its stance in the product industry, and really wanting and intending to be a product industry thought leader, our product operations team not only has to function as a product operations team, but they have to figure out how do they help other product leaders do product operations more effectively.
We talk, and we also, even our main pillars of product ops.
So I personally think that product ops is supposed to be all things data, process optimization and scaling of process, and then tooling, administrative optimization of tooling, rolling tooling, all that kind of fun stuff.
Because of our use case, since we are Pendo, our data pillar is really different.
Because our PMs have to know and have to use Pendo intimately themselves.
If they were not in it, in the weeds and up to their elbows, we would have a much bigger problem.
So where we see a lot of our customers' product operations is utilizing Pendo to give a lot of data out to PMs to synthesize themes, to give them customer feedback and like really centralized voice of customer.
Our product ops team doesn't really need to do that as heavily because our, we expect our PMs to do it.
So we shift some of that energy into this thought leadership.
So where do I see them going?
I see them really trying to continue to be louder and louder thought leaders.
Everything we hear is that product ops individuals are dying for best practices.
For how do I do this?
For templatization of things that already exist. Don't make me reinvent the wheel.
And I would really love it if pando is on the forefront of that.
And it is really a resource center that other organizations look at as, Hey, this was really helpful with the tooling that comes out to, you said that pendo enables a lot of the stuff that we would see other product operations teams do like the customer researcher, pulling that out of it.
can you talk a little bit maybe about what you've been observing with the change in product operations and how new tools are coming out and what people are doing to harness them and what that does to actually impact product operations as a team?
Yeah. I think we should like mark the time for when AI got brought up.
But I definitely think that what we are seeing with a lot of our customers, when it comes to the ProjOps conversation, is now it was about how do I utilize Pendo to optimize customer feedback qualitative and quantitatively?
How do I arm my PM to make a data informed decision effectively?
And now it's okay. How do I do that?
How do I also either marry that or bring in AI functionality to really streamline and get rid of some of the heavy tasks a PM can get bogged down with?
And so that's a big trend that we're seeing a lot of.
And of course, naturally they're saying what's Pendo doing with AI and how can we combine these efforts versus having to manage multiple tools for our product organization.
So that's probably more recent, like even in the last three to six months, that's become a pretty, pretty big topic.
What are like the heavy tasks that people are asking for help with?
Ton of data digging.
There is a very big desire for lots of both qualitative and quantitative data as to what your customers are doing, what they're saying, what they're feeling, but once the data gets surfaced, it's almost like this overwhelming feeling of, okay, but now what do I do with it and how do I dig through that?
One of I think, Pena's, about newer AI features is really centered around how do you get insights to know what your data is telling you and how do you simplify essentially like just the overwhelming feeling of all of the information you could have. And obviously from a product's point of view I think that's such an amazing way to add quick value is to be able to optimize for them and do some of that task management is the helping them figure out how do I use my data?
Where do I use my data?
We just did a pretty cool internal project where we created a portfolio level dashboard in Pendo for our SVP as a product.
And what was cool about it is that we were able to work with them to figure out, Hey, what's your top five, six Northstar metrics across your hope portfolio that you want to pay attention to if these numbers don't move, something needs to change and that it was a decently simplistic dashboard, we had to play a little back and forth on. Nobody wants a dashboard of nothing but charts and numbers.
So we had to have some free text in there to help make sure that everyone knew context, but that was such a simple value add from a product's team member at that really impacted not only the SVP individually, but our whole product leadership team now looks at those on a weekly basis and really helps drive our decision -making, our conversations, our investments in the end of the day is really big.
For product operations, especially with how you're describing that you're set up, it sounds like you have a lot of stakeholders, right?
You've got the leadership team with the portfolio level you were just talking about, the program managers see across everything, they interface with the go -to -market side as well.
How do you think about prioritizing what needs to happen across so many different stakeholders?
Oh, that's a good question.
We're pro we're decently lucky in that we have, so product ops at pendo is I call it strip.
It's two houses it's the program management side, and this, the product operations manager side.
So that helps us naturally prioritize a little bit differently because I essentially have two small armies to go tackle different problems. But I think it's really just having to sit back with my leaders of both those Was halves of the house and asking ourselves constantly what moves the biggest needle for kendo when we did the big transformation from scrum master to program management, one of my behind the scenes wise, operational roles are often one of the first ones to get.
Take a hit. You mentioned Capitol.
One was a huge headline in the auto industry.
It is for whatever reason, always going to be the space that executives questioned their value once they have to tighten their belt.
And so what my objective to that transition to program management was I wanted to make them unfireable.
I wanted them to be clearly adding value and never again get the question of, what do you do, and why can't I have somebody else do this kind of thing?
And so I think that we still really come back to that at the end of the day when we are looking at our priorities of we have all these requests, all these things we could do, and it's easily distracting, but what of these tasks make us the most valuable to the company, what impacts positively Pendo at the end of the day?
And from what I've experienced in the last two -ish years, The more we put Pendo and its needs first, the more successful and valuable we are.
So we try to use that as like our guiding star for like a better phrase.
With the two sides of the house too.
Like how are your program managers measured for success and how does it compare to your product operations managers?
Pretty different measures of success since program management is still working really closely with our product areas, even though their stakeholder base has pretty significantly changed.
They're still measured on the success of their launches, the coordination, the effectiveness, the timeliness.
We don't manage budgets to individual product areas, so they don't have to dabble in that, but their measures of success haven't wildly changed since when they were Scrum Masters, it's just expanded their scope of responsibility to include the whole launch. Product operations is more so measured on a quarterly basis of achieving OKRs.
So we get really clear on what part of the company we're trying to impact this quarter, how we'll know for successful, and then did we achieve that OKR or not?
So like right now we've got three major OKRs, one of them is automating betas, our beta process, and trying to improve the consistency of how betas are managed for product managers, how much they use Pendo to do so.
How we can self service it for customers, all that fun stuff.
And so they've got measures within that OKR of how do we know we've achieved this?
And essentially we check in constantly throughout the corridor on, are they progressing or not.
You talked about to the program managers overseeing the whole life cycle, the products that they're helping.
We also talked a little bit about like standardization or templates.
When you look at that life cycle, what were some things that you implemented either process wise or template wise that you felt like helped solve your problem of making sure that things were launched correctly?
And that was all streamlined.
We had two big ones that I think were the most impactful.
Our first was a go to market checklist, which is not a new invention.
We are not unique in that, but, and we are actually currently trying to update it again because, I think everyone's goal in life is to have the smallest checklist possible, nobody wants some hundred and forty five item list. but we created that checklist, which is broken down by each, cross functional department and tells them, Hey, here's the objectives.
To do that, we had to establish launch levels.
So not everything is the same, right?
You might have a low level launch that is just an enhancement or an update to an existing feature versus a brand new product launch is a wildly different go to market motion.
So we had to be specific based on what level launch you're doing, but it is now made it so that all of our partners know based on what launches, how they engage, what they're supposed to do, what the timeline is, all that kind of fun stuff, so that was really helpful.
And the second one was a launch brief.
So this is basically all of the major parts of the early planning stage when we finally decide, hey this idea is going to make it to an engineering team.
We validated it with customers, We've got the data to back it up and we have what we think are the measures of success for it.
We do a launch brief and a launch brief meeting.
And that's where you have the first initial interactions with the engineering team and then all of those key cross -functional partners to agree on what's a reasonable time to market, what's the right launch level for it, because it's not always explicitly clear.
And then based on some of the details of the project we're taking on, when and how do we need to involve certain partners.
like for anything, AI security is our best friend throughout the entire thing.
so making sure they're well aware versus and also with AI, I'm sure people have had this experience, but.
We have to typically update our DPA or data processing agreement.
So when and how do we do that throughout it?
But this launch brief kind of captures all of those little nuances and is this like launching point for our program manager to make sure that they've got everybody on the same page from as early to day one as possible.
and then they use that as their source of truth throughout.
With the program management too, I think some people could listen to this and say, Hey, like that concept has been around a long time or we've had project managers like that.
What's different about the way that you do it or what's similar that you've seen with other companies do it and why does it fit well under product ops for you?
Yeah, that's a great point.
We're definitely not special in the sense that we invented this concept.
I think something that we do that is probably a little bit different Is that they're housed under the product organization.
And we did that really intentionally.
Part of it was psychological in the sense that I knew I was taking folks who had been career spread masters.
And if I left them in their same comfort zone, frankly, living in engineering, I knew I was going to have a much harder battle to get them to change their daily behavior.
So that was kind of the original intent behind it.
But what we found is that the positioning end product allows for them to have a lot more influence when they're having these cross functional conversations when they're trying to drive let's say a technical success manager to really do some enablement or a customer support human being to revamp some internal training or whatever their tasks are, right?
It gives them different positioning, which I think has been really helpful.
It's worked incredibly well for us to be under product operations, because I think what it did was it also really simplistically clarified the roles and responsibilities and what was a really complex relationship when it was early days, product in our scrum masters, like I said, they were stepping all over each other unintentionally because everyone was just trying to figure out who does what, when and where and so this has allowed us to be pretty black and white and okay, this is what you own.
And this is what you own in the benefit to the product ops managers is it's let us really have them lean into what the industry looks at from products.
And I noticed a trend.
We have a lot of customers who start off the same way we do a grab bag of random tasks are just trying to add value.
PMs don't want to do it.
So somebody has to do it.
We started the same way and what helped us get to clarity was this combination of product ops and program management.
With this area too, I think what some people fear in the product management world is that product ops starts doing exactly what you said, like taking on all the stuff, the product managers don't want to do.
Right. And they almost become people that they think of as interns.
They could just shovel the junk work onto them.
Like, how do you make sure that doesn't happen with your team?
I think it's being obnoxious and expressing what your product ops vision is to all of your stakeholders.
We had to do a pretty significant enablement tour of, hey, we've rebranded we've clarified here's what our purpose is.
Here's how we help you.
Here's how you can engage with us.
And we've honestly done that almost two full times now cause we just need the repetition of our stakeholders learning.
So, uh, I think it's being really annoying and just being really clear with what your goal is, but it's also being explicit and saying no. And why you're saying no, you've had to learn that a lot because it's really easy.
I think operational minded human beings are very quick to want to solve problems. And so having to teach them that skill of.
You're not actually adding value by saying yes to what, everything that everyone brings you all the time.
Yeah. We need to be strategic in how we do it and we need to draw patterns and data.
I think working at Pendo helps in that we are so in love with data.
So being able to ask them, okay, great.
One person came to you 1PM and asked you for help here.
Do we have data to support that this is a wider spread problem?
How can we solve this more holistically versus just solving it for one individual has been also really helpful for us.
Sounds a lot like putting your product manager hat on over there to solve problems for product managers.
Yeah, that's probably true.
With the team as well.
What's like your, do you have cadences that you follow or you oversee?
What's the daily life look like for a product operations manager?
Yeah. We just went through a shift in our CPO, so one of our co -founders sucked into our CPO roles for redefining our operating cadences as a product organization, which has been mildly terrifying if I'm honest with you.
But also very exciting as it gives us a chance to reevaluate what's working and what's not working.
So our current, our new cadence is that we do every six weeks, what we're calling a product impact meeting, which is really cool.
And it's cross -functional, um, from the standpoint of all those partners I was just talking about.
They also come and talk and present to product and product come comes and talks and presents to them.
And it gives us this more holistic view of what is truly going on with our customers, with their usage of our tool.
How do we keep the folks making decisions about the strategy of our product as in tune with our customers and their true feelings, even with such a strong analytics tool, it's easy to get lost in the noise.
So having this every six week cadence, I think lets us really hyper -focus and center and come up with a common theme or themes that hits on all of these different areas and we can march together towards a solution.
So that's a big, big difference for us.
That's been, been really good.
And then we also do monthly roadmap reviews.
We're trying to get into a cadence of a rolling.
Planning versus like a point in time planning.
And so we're moving into those were all of our products, our product areas come in and walk through what they just built, how it's adopting, how it's being engaged with, what are the key metrics and then based on that information, what are they building next?
I think this kind of like heartbeat of the company and cadence is a really hot topic for people out there right now.
So it sounds like you've got the product impact review of the roadmap review.
What else do you suggest companies look at to make sure that they're monitoring their strategy and figuring out if what they're shipping is working?
Yeah, I think it's different, right?
Based on every company structure, we're obviously a company that I don't know that we put any organization higher in the pedestal than our product organization, just given what we build and what we do.
And so I think our product leadership team is also in a really good cadence.
We meet every single week for two hours, which sounds It is really heavy, but it is a meaty full meeting every single time, which to me means that we're doing something right.
And we start that meeting every week with going through multiple dashboards in Pendo about what is working in our product and what's not working and what have we learned and what are the customers saying?
And it drives the rest of the agenda of that meeting, which has been a really big and I think improvement, it's really forced us to just look at things a little bit differently.
again, like I think it's really easy to get out of those metrics and, and think about them as again, just noise versus like, how do I really utilize this to make better decisions, our CPO Rahul, he takes the conversations we have and those weekly meetings up to his sea level meetings on a biweekly basis as well.
He's very informed about our product, which seems to be really helpful.
So I think if you have the ability to do that, it's a small group, you're stocking five, six people max.
So if you have the ability to drive that, I think that is great.
We also push and encourage that our product area leadership team.
So you're talking product manager, PGM, designer, so on and so forth that they're also constantly looking at Pendo and the data that it's being used.
And then of course, we do the thing at the end of each quarter, where we summarize it all and send it to our board and get their input and what they think and their feedback.
With these types of cadences, a lot of data and a lot of information comes into it to be discussed.
Does the product operations team do anything about gathering that information or providing the templates for it.
What does that look like?
Yeah, they're the ones that actually designed the SVP level dashboards that I was talking about that we would use every single week.
One of my team members, shout out to Allie.
She's incredible. She worked very closely with each of our SVPs to decide what works for them and what metrics they needed, how they needed to visualize all of that.
So product ops is a big part of that.
And then they also help us standardize data consumption and dashboards and for all of our PMs are leading the different product areas.
Since Pendo is an analytics company and data is incredibly important to you.
What types of things do you do to make sure that everybody is being data -centered?
We're very thoughtful about never wanting to get on and talk to a customer and have to - We never want to bluff our way through our own usage.
So I think when we talk about our operating cadence, when we talk about how we function, how we make decisions, it's just a somewhat natural motion for us to bring Pendo up first and foremost, right.
And to figure out or to raise a hand, if we're not using Pendo on a certain conversation, if we're having big investment conversations and Pendo's not on the screen asking, Hey, why aren't we looking at this and digging into that.
I think it's just a really big part of how we function.
I don't think it hurts that we have three co -founders who've been around the entire time and are actively engaged in how we build and engineer our products.
They're also incredible about making sure that we are using our own and constantly bringing that into the conversation.
But I don't know that there's like specific things that we do other than like I said, just ensuring that how we operate and brings that data out all the time.
We talked a little bit about it, but AI with the change of it, how have you been using AI and how have you seen product managers use AI to either get smarter or help them with the stuff that they need to get done?
We've done what I'm sure a lot of companies have done, which is play with some of the requirements, doc writing tools and trying to simplify some of that, like heavy lifting.
I'll be the first one to admit that I don't know that we have cracked the code on it.
It seems like a lot of the tools out there are great starts, but we haven't found the thing yet that has the mixture of the right AI features.
And the right, I guess in the right compilation that really crack something for us.
So we're still experimenting a lot.
We found some really cool use cases in our design space and like really fast prototyping through some of the AI tools that has been really helpful, but we're mostly still in this experimental phase.
We actually have a company -wide initiative, which I'm sure many companies do right now, of trying to assess all the possible tools out there and how they could serve hopefully more than one organization within Pendo so it can take greater advantage of it, but we're still in the weeds of that ourselves.
How do you think AI is changing the face of product operations?
What do you think it's gonna look like in the near term versus long -term future?
I think it's a really difficult time because it's such an emerging industry still.
And like I said, like so many people that we encounter are looking for best practice are struggling to find a ton of resourcing out there or guidance on how do you do product ops?
So many of the answers are still well, it depends, it depends on your org and your maturity and all of these things.
And what I've heard directly asked of us many times is don't you just have a template?
Can't you just, can you just give me this thing that solves my problem for me?
And I think weaving AI into that is honestly just over -complicating and already messy space for companies who are trying to still figure it out.
So I'm sure it's going to have a big impact, especially with data being so prevalent in the product operations job, and the more tools in the more AI comes in and tries to optimize our usage of data, I think the more it's going to shift. I think if anything, it will help ProdOps be able to lean away from some of that.
I hate to say administrative tasks and like just data digging and allow them to be more strategic because they're not having to go through all of that.
That's my long -term hope.
My biggest fear with ProdOps is that it will be seen, frankly, a lot like how scroll masters were for a long time, which is it can be easily oversimplified into this administrative type of role, and I think there's just so much more value that they can bring.
So my hope is AI helps speed that timeline up to strategic involvement.
Yeah, that is a fear I think that some people have, and I do see at some companies as well, to be fair, like some of the criticism I hear about product ops, the product ops people are kind of admin, right?
They're not being strategic.
If you were to give advice to somebody who's starting out a product operations function and you wanna help guide them on how to make it more strategic and evaluate if they're getting stuck in admin role, what would you tell them to look at?
I know this is probably not the best answer in the world, but I love a good old fashioned listening tour, talking to lots of different roles and functions in your organization to find out where the pain points are proactively.
And then coming to the table with a proposal on where you think the biggest impact could be and how you intend to solve it.
I think sometimes folks get too worked up in what if I'm wrong or what if my answer isn't perfect?
And I have experienced at least personally Whether your answer's right or wrong, executives prefer the, the umph, the gumption, the willingness to try and help add value to your company versus sitting back waiting for somebody to say, Hey, I have a job for you.
So we do this. I'm actually currently on a listing tour with our revenue organization, trying to figure out how can products drive a tighter relationship between revenue and product.
And through that, and I've already found a few different ideas of, Hey, we can move the needle this way.
We could engage with this team this way.
And so I think that's my best advice is talk to the folks around in and around product, depending on what your maturity is.
We're moving into revenue right now because of how much we have spent building the relationship with engineering.
So that's just not where our biggest pain point is, not to say that we have a huge pain point with revenue, we love them, but that seems to be the best next opportunity for us.
So not being afraid to just sit back and talk to people and ask questions.
For companies that maybe are not as mature of their product practice, let's say, Where would you advise them to start?
So we have a myriad of customers that are all kinds of spans of the maturity model.
I think don't, if you're less mature, I would not hyper -focus on the titling.
I would really just try to identify for what is out there on product ops, like for my best practices and or here's the big key pillars that make up product ops, figuring out what parts of your existing role and your existing title, you can start to do some of those tasks and you can start to show your company, hey, this is really helpful, this is adding value to my PMs, it's making my PMs jobs easier, better, more effective, it's helping our end customer at the end of the day.
I think people get too hung up on, I have to have the title, I have to have the team.
And I just don't know that's really as necessary, especially when a product organization isn't as mature.
They're probably still figuring out what product management truly is and feels like at that point.
Yeah, that's what I see definitely in a lot of those organizations.
Jessica, when you're thinking about the evolution of product operations for the next five years, what it's gonna look like in the industry in the future, what are you excited about?
I feel like Pinda would be upset if I didn't say more data, all the data.
I think that there this whole move, digital transformation, product -led transformations, this idea that any company can be customer centric and use their product to really drive benefit for their customers is where I hope it continues to go.
And I hope that, like I mentioned earlier, product ops can be seen as a strategic part of that equation and not get lost in some of the administrative stuff.
Where I've seen organizations be successful in being strategic, it is game -changing for those, not even just those product works, for that entire company.
So I hope we continue to lean into that.
And I hope that product ops folks out there continue to fight the good fight because I know it is frustrating sometimes to try to constantly convince folks that what you're doing is good and valuable for them.
But when you can break through it's still worth it.
My last question for you, Jessica, is if you could go back and give your younger self some advice, what would you tell her?
I think embrace the imposter syndrome to be honest with you.
I am naturally a pretty, uh, pretty bold, unafraid human being, but moving into product ops is probably one of the biggest moments in my career where I was like, I don't know if I know what I'm doing and if I'm the right person.
And it very much got in into my own head.
And I think I wasted a few cycles just over analyzing that whole thing.
So just embrace the new.
And I think what got me through it was continuing to go back to this idea of if if I just show up and I do something that helps Pendo every day, I will be rewarded.
They will be happy, I will be happy.
So yeah, I would just probably tell my younger self something about getting through that imposter syndrome faster.
I think that's good advice for people out there.
Especially those dealing with imposter syndrome.
Well, thank you so much for being on the podcast. If people want to learn more about you and Pendo, where can they go?
You can always go to pendo .io or you can find me on LinkedIn.
I think it's jessica .soroki.
So yeah, probably the easiest places.
Great, and we will put all of those links in our show notes at the product thinking podcast .com.
Thanks again, Jessica, for being with us.
And thank you to our listeners out there for listening to another episode of the product thinking podcast. Make sure that you like and subscribe so you never miss another amazing guest. And in the meantime, if you have any questions for me, go to Dear Melissa .com and let me know what they are.
I answer them every single week.
We'll see you next time.
