Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Trisha Price (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 welcomeback to Hard Calls, the podcast where
we have some of the best productleaders from across the globe.
Come and talk about those moments thatmatter, the big decisions, the hard calls.
(00:25):
I am so excited for today'sguest Jessica Soroky.
I have had the privilege and pleasure ofworking with Jess for the last four years.
Jess has a great and interesting careerfrom agile coach to chief of staff
for one of the founders of Pendo,to now heading up product operations
(00:46):
across Pendo, where Jess isn't justresponsible for making sure that
Pendo efficiently ships software.
She is responsible to make sure that weachieve business outcomes and has been a
huge part of that transformation at Pendoover the last few years in this role.
So welcome to the show, Jess.
(01:06):
Hey, thank you so much for having me.
Well, we are so excitedto 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 therest 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 areally tough call that they've had
(01:28):
to make and what made it challenging.
Jessica Soroky (01:31):
Yeah.
So I'm gonna take a human aspectof this and talk about a challenge
that you actually gave me whenI started working for you.
And, and that challenge was to buildthe 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.
(01:52):
We had a team member who wasabsolutely trying their best.
They were incredibly positive.
They had like the, if I couldrecreate their personality and the
professionalism and the willingness totry, I would do it a million times over.
Unfortunately, even at their bestfor what we needed at the time, we.
(02:14):
Had to step back and be willing to lookat is this truly the best of the best?
Is this the elite team memberthat 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 weneeded to, to, to that a player.
(02:36):
so we had to make the really difficultcall to have to part ways with
that person to be able to createspace for somebody who was better
suited for our needs at the time.
And while it's on a product specificcall, I think it really did change
because I respect that human being,but the person they brought in.
Has made some game, changing moves forour team and for Pendo and all of that.
(02:57):
So at the end of the day, I knowit was the right call, but it was
definitely not easy in the moment.
Trisha Price (03:03):
I love that you
shared that one because people.
Are such an important part of oursuccess, and it is a hard call
making the right hires, lettingpeople move on when it's time.
And I remember that time well, andI respect your decision and the
way you handled it and so that'sa, that's a great one to share.
(03:26):
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 threeyears now since you started in this
role and started the transformation.
You helped the product team at Pendoand Pendo really transform from really
(03:48):
thinking about product and go to marketseparately and shipping features to
really driving business outcomes.
You'll never, I'm sure you'llremember and I'll remember forever.
There was a feature and I,I had heard it was shipped.
I could see in Jira it was shipped andI went into the product, which I use our
(04:08):
product every day and I couldn't find it.
And I went and asked a million peoplewhere it was and why I couldn't find it.
And I got 10 different answersand no one really knew.
But our scrum masters our team was sayingit was shipped, but it wasn't shipped
because it wasn't on in the product.
And that became, began and sort ofa catalyst for all the work that
(04:32):
you did in the transformation.
So tell us about it.
Jessica Soroky (04:35):
Yeah.
that, I do remember that feature.
I remember that, that slack interactionand the horrible feeling of also
not being able to find you theanswer as, as an operational person.
I, it went into all of our systems andall 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 thiscatalyst to really shifting our
(04:57):
focus from done, being defined asengineering is done to No, no, no.
There's this much bigger ecosystem as awhole company and what does it mean to
launch as a whole company and make surethat all the different facets are ready,
enabled, supported, and can, everybodycan work together to make that successful.
So I think.
(05:19):
It was necessary that we went throughthat because it led to to where we are
today, which is a lot more cohesiveas a larger organization and how we
launch products, and it completelychanged our entire lifecycle.
We went from, I think, beinglike an SDLC-focused shop to.
We don't really talk aboutour SDLC, and now it's the
(05:39):
product development lifecycle.
It's the PDLC through and throughevery department, every part of Pendo.
We all know where we live and how weact in that PDLC to make sure that the
investments we're making and what webuild are as successful as possible.
And, and when they hitwhen they hit the market.
When it hits customers.
Trisha Price (05:57):
I love that, and you've
done an incredible job of that.
Tell us a little bit about how you did it.
I'm sure it was a change topeople, to process, to technology.
It's probably a change and atransformation that's never really
complete, but talk to us abouthow you led us through that.
Jessica Soroky (06:13):
Yeah, so we first
looked at the people, the roles that
we had at the time, and when we weremore focused on eng-done Nat, I, I
wanna say naturally it felt natural.
At the time our role wasfocused in the agile space.
We had a team of Scrummasters that were supporting.
I hate saying traditional scrum waybecause that feels so weird, but a
traditional Scrum way and that they werereally dedicated to the engineering teams.
(06:35):
They were in the weeds with themand managing the day to day.
And so the first and biggesttransformation we had to do was to
get those operational process peopleto look at this bigger lifecycle.
They needed to understandwhy the entire, uh.
From beginning of an idea all the waythrough customer hands and then closing
that loop for us, given the productthat we build, we needed to be able to
(06:57):
make sure that we were truly utilizingadoption metrics, usage engagement.
All of that needed to come back to thebeginning of the cycle to make sure
that we were constantly iterating andimproving based on those analytics.
and so.
To do that.
Then the first thing that we didbeyond changing their role and, and
kind of doing some base level atreeducation of what they're responsible
(07:18):
for is we did an education tour.
If you remember this, I think I came toyou and was like, Hey, I wanna invite
leaders from the different departmentsacross the business to kind of do an
empathy tour with my team and teachthem from a customer success standpoint.
Why does this all, like whatmatters to customer success?
What are their pain points?
What do they care about?
We did that for every major organization.
(07:38):
We had sellers come insupport folks come in.
We had, I think, legalsecurity, all of the things.
And we did a pretty deep dive forthe now program managers and all
these different functions that.
Kind of wildly and theirengineering focus, they never really
interacted with or understood.
They knew the conceptual right ideaof what a customer success person
(08:00):
does or what security does, butthey didn't understand it to this
level, and they needed that depth ofknowledge to be able to then put pieces
together more effectively as they werecoordinating this much larger process.
Trisha Price (08:12):
That is great.
I love your focus on peopleand giving them the exposure
to the rest of the company.
And I love, like, as an operationsperson who does care about process,
that your first answer wasn't aboutprocess, it was about the people.
But I think, you know, and, andnot over rotating on process.
(08:32):
And I think that's the truetestament to why you've been
successful with this transformation.
Jessica Soroky (08:39):
Yeah, I mean we, we of
course had process pieces to it, right?
So as we were building out the peopleand the education and the breadth of
knowledge, we did look at the processwe created, what we called I think we
still call it double diamond, which isour mapping of this larger lifecycle.
And we needed to be able,essentially to do our own version
of a customer journey and like.
(08:59):
If you're at the very beginning stage andyou're ideating what behaviors and actions
are happening, who's responsible for what?
How do we visualize and communicatework 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.
(09:22):
Whatever the work stage is now, it'scrazy because that's like the part we
focus the least on because that's thething that we, we already knew very well.
And then all of the launch actionsand the go to market and all of that.
So we, we made sure it was reallyclear who did what, when and
where in each of those steps.
And then we did a very big educationtour of our own this time going
around and making sure everybody knew.
(09:43):
What we did, how we did it, whatproduct ops did in that new function.
because we did change kind oftheir role as a part of this
big transformation as well.
So we wanted to clarify how theyadd value and where to use them.
and then frankly, we justhad to start executing.
We had to start proving it throughday-to-day behaviors and actions
and taking people's feedback.
Pendo has never been a companythat wants Heavy, heavy process,
(10:08):
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 testit and not get offended or hurt.
If somebody comes back to us andgoes, 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 thefeedback and iterating.
Trisha Price (10:30):
I'll say that is
definitely one of your biggest
strengths that has shown up.
and, and probably a big partof why this transformation was
successful is your ability to takethat feedback from everybody and
just let it power improvement.
not, take offense to it.
So, Jessica, we're talking so much aboutmoving to business outcomes versus just
(10:51):
focusing on optimization of process.
Can you share.
What's a business outcome that youand your team have been accountable
to drive across the company?
Jessica Soroky (11:02):
Yeah, so since we define
product ops as half program management and
then half product operations managers, theprogram managers are held to the business
outcomes of the success of our launches.
So they are expected to drivemore thoughtful, intentional,
strategic launches of our products.
Measures of success business outcomes.
There is, do every one of our launcheshave clearly defined measure of success?
(11:24):
Do we have Pendo dashboardsthat can show that we are
progressing against those goals?
are we communicating effectively givenour leadership's how do I wanna say this?
Given, given
given our leadership's desire to.
Be able to grab informationwhenever they want, right?
(11:44):
So even all the way up to Todd andour CEO, he loves to be able to
asynchronously go find information.
I remember you and Italking about this a ton.
How do we make it simple so that if hewakes up at 3:00 AM and wants to go find
an answer, he can do that on his own.
So they were absolutelymeasured by that outcome of.
How often does he have to go?
Or do you have to go ask somebodyas a human for an answer versus
you can find the informationon the product operations side?
(12:08):
We had to really figure out, becauseour PMs should be really good at
their own segment of the productand finding and using data, right?
So a lot of product operations teamshave to be that like data force where
they're pushing data out, they'rehelping educate how to use data,
how to make data-driven decisions.
We didn't have nearly the same.
Responsibility in that spacebecause of the PMs that we
(12:30):
employ and, and their day-to-day.
But we did have to start to drive betterbusiness outcomes about how we use
the aggregate data across our product.
So how do we make sure that, thatyou as our CPO had the right level
of information looking holisticallyversus these individual slices
where the individual PM sat.
And so we were really look constantlyfocusing on how do we incorporate
(12:51):
it into our operating cadence?
How do we make data anatural part of our behavior?
Versus this forced functionwhere we had to stop and go,
okay, now it's that time again.
Let's look at the data and makesure we're paying attention to it.
so that's definitely one that we'vedriven to on the product operations side.
Trisha Price (13:07):
So you talked about
Pendo and our obsession with data.
As a part of our decision making andprocess 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 thetime, and I'm sure you do too.
Is, what is our product cadenceor product review like at
(13:29):
Pendo and how do we use data?
and metrics in that process.
So talk to us about that.
Jessica Soroky (13:37):
Yeah, so each of our
individual programs has a little bit of
their own flare as to how they are lookingand using their individual product data.
But across the product we have westart with our roadmap reviews.
so these are a shared meetingbetween product leadership
and engineering leadership.
It is a smaller audience in thatthe presenters are really focused
(13:59):
on like one segment of our product.
and they're normally our most seniorproduct leaders in that segment.
So it's not like a broadermeeting they come in.
We have really worked hard toeliminate presentation building.
we try really hard tojust say, Hey, come in.
Pull up your Miro board if you'replaying with, or your Figma board if
you're playing with early designs.
(14:20):
But pull up Pendo, show us Pendo itself.
Bring up your dashboard.
Show us what's going on in in the areaof the product that you have built.
Use that data to build the storyas to what you plan to build next.
And then leading throughthose types of conversations.
We use Pendo roadmaps tovisualize what they have built
and they're about to build.
So that's a monthly cadence.
We also have a quarterly cadence that wecall the product Impact ONI, which is.
(14:44):
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, Ithink, to making sure it's highly
valuable for everybody, which is kindof a cool pressure in my opinion.
But in that meeting wesplit the responsibility.
So the first half of the meetingis customer facing teams.
That are coming to us sharing qualitative,typically sometimes quantitative
(15:07):
data from their point of view.
What are they seeing in the field?
What's the market likeanalysis going on right now?
What's a big competitor weshould 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 productsresponsibility is to bring.
Now this is where we invite the vastmajority of our PMs and they get the
(15:29):
chance to show off in a broader sense.
Here's what I've built recently.
Here's how it's being inutilized by our customers.
There's oftentimes calls to actionthere 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 shouldwe utilize different types of, of tools?
(15:55):
And then they also show off.
the Next six weeks.
Again, we really try to keep itfocused, narrowed in on what did we just
build and what are we about to build?
and then they get feedback fromthose cross-functional partners again
on are we hitting the right marks?
Are we addressing the issues thatyou 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.
(16:16):
Obviously we are still a scrum shop, soon an ongoing basis our teams are meeting
every two weeks, reviewing what theybuild, planning their what's next and
looking adoption metrics at that point.
But we as an organizationare, have those two cadences.
Trisha Price (16:29):
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 wherepeople can tear apart each other's
ideas without taking offense?
Is this a meeting where we're tryingto band together and we have meetings
(16:51):
before the meetings and we'rereally 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 to the right answer?
Jessica Soroky (17:01):
So
single word was the vibe.
Passionate.
They're very passionate meetings.
No, to my knowledge, there's nomeeting before the meeting to try.
Thank goodness.
Yeah, thank goodness.
and I will say I, I don't have likea hard statistic, but I know that
we have significantly decreasedthe amount of preparation that
used to go into similar meetings.
The amount of hours to build slidesto show what we have in our own tool
(17:25):
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 opinionsin those meetings, but I think we
have fostered a culture where youcan challenge and be challenged.
And it's not a personal thing,it is really just about.
(17:46):
What is the rightstrategy for the business?
What's the right strategy for the product?
And then if you're being challengedon your idea, like where's the data?
Show us what makes you believe thatyour idea is the right idea for
our customers or for our product?
I think it's a pretty, 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 frequentlythey happen given just like where
(18:09):
the, frankly, the world is rightnow 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 agood idea a month ago, is it still
Should we keep investing in it?
That kind of thing.
Trisha Price (18:26):
So you mentioned AI,
and obviously AI is changing, not
just the features and how peoplein 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
(18:52):
the efficiency and how you work?
Jessica Soroky (18:56):
okay, so great question.
one of the things that I would saythat we've utilized probably the most
recently is Bolt, which we did a reallycool hackathon recently where normally
our hackathons historically have beenrun by our engineering teams to, and
they have some sort of a theme and theyget free run to go build and, hack.
This particular hackathon was reallyhyper-focused on how do we use AI to
(19:19):
prototype early ideas faster and to, tofigure out the viability of those ideas.
So our design team ranit, which was really cool.
and they kicked off.
They gave a very short, 30 minute intro.
A lot of our folks that were playing inthis hack had never experienced this tool
before, this 30 minute intro, and thenthey were given a couple hours to, with
a, with a problem statement that they weretrying to solve for, to go play and solve.
(19:42):
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 wereable 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 are, are from a productoperations point of view specifically,
(20:03):
we do lean in heavily to the insightsthat Pendo provides through Listen, and
how we try to look at that across theproduct 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 thelarger cross-functional meetings, making
sure we're pulling those insights and,and making them visible to everybody
has been a big improvement as well.
(20:25):
We don't have to manually go throughall 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 (20:34):
That's awesome.
That's great.
Well, switching gear gears backto measurements and outcomes.
I know OKRs are a big part ofhow Pendo runs the company.
Talk to me about your role with OKRs andthen specifically product operations.
How do you take company OKRs andhelp cascade them specifically
(20:57):
to what you measure in productand and the success there?
Jessica Soroky (21:01):
Yeah.
So we have the program managersas a part of product operations.
They are the ones that manageall of our companywide OKRs.
So we assign one programmanager to each OKR, and they
essentially program manage the OKR.
They make sure that there's clear setsor clear measurements for success.
They ensure there's milestones,they make sure progress is
(21:21):
happening, they raise risks, handleinterdependencies, those types of things.
My role is I get to do the samething, so I, I jump into to OKRs
myself and help program manage them.
similarly in R&D across productand engineering, if there's a big
cross-functional, hairy, complicatedthing, normally I get the joy of
(21:41):
jumping into them and helping herdthe cats and, and organize that.
there was an OKR somewhat recentlythat stands out the most to me.
That kind of reallyiterate, like to me, shows.
an outcome that we were trying to drivetowards, which was we were trying to
improve as a company, our cross sell.
So we had recently released a coupledifferent new SKUs, new products and we
(22:03):
weren't getting the attachment that wewere looking for with those new SKUs.
It wasn't that it was horrible, butit wasn't the ideal state, right?
So we organized a company-wide OKRthat included folks from all the
major departments, revenue marketingproduct engineering, every facet to
say, how do we really intentionally.
increase cross sell, increase theadoption of these different products.
(22:28):
And so that was really cool because weobviously had the direct connection to
our product organization, and we wereable to bring that OKR into product
and say like, from our, from our pointof view, what can we be doing better?
Right?
Are there guide strategies that we couldbe using that to drive adoption here?
Are there intersections?
I think that was actually one of the.
OKRs that really startedto birth this concept of
(22:49):
intersections across our product.
And so making sure that from anproduct ops point of view, we were then
taking that lesson of, okay, there'sthis concept of an intersection.
How do we start to drive that as anoutcome as we build going forward,
even after the OKR ends, we wannamake sure that this concept becomes
a part of our natural behaviorsand that we're talking constantly.
(23:10):
I remember we do something thatyou 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 togetherand it's this cool showcase of them
getting the chance to show off whatthey've built, what they're doing.
It really drives cross knowledgeknowledge sharing around what
(23:31):
other folks are building.
But when we started to incorporate thisidea of intersections from that OKR, it's
like that showcase just really took offbecause then they were challenged to think
about what they were building, but froma larger point of view and this bigger
ecosystem that we were building, and itwas just, it became very, very impactful.
I, I still hear constantlyabout when's the next one?
When, when do we get to dothe next product showcase?
(23:53):
so it's definitely latched on for sure.
Trisha Price (23:55):
I love this concept of
intersections that you raised, which
is so many product companies claimto be a platform because they simply
build multiple modules or products.
On the same technology stack or evenhave a similar look and feel or a part
of the same application, but this conceptof intersections that you bring up,
(24:19):
which is really, really thoughtfullyunderstanding the user experience and
those magical intersections betweentwo different projects, products
between two different modules.
Is so special.
And to your point, it can drive realbusiness outcomes of cross sell, right?
If you're thinking about one of yourproducts and a job to be done or an
(24:39):
action or a workflow that, that someone'scompleting, and then right naturally from
that, you can figure out a launch pointto one of your other products or modules.
It's such the special way to differentiatefrom the competition, but also a diff
a special way to drive cross sell.
So that, I love that youbrought that example up.
(24:59):
So OKRs, you help runthem for the company?
Yep.
OKRs can be amazing when done well.
They can be a major eye roll and just.
A headache and a checkboxexercise when done poorly.
Tell me, what do great OKRs looklike and how do you help make sure
they're actually useful for Pendo?
Jessica Soroky (25:21):
Whoa,
that's a big question.
we, we have tried lots ofdifferent 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 Goldilocksthing where we have figured out that
it's not always one or the other.
that's definitely something that I wouldsay is a successful OKR is looking at
(25:45):
the outcome you are trying to drive withthat KR to decide the timeframe to give
it versus being super locked into knoweverything must fit into this time box.
so I think that's number one is makingsure that you allow at the time it needs.
To actually achieve the outcome.
then I think you needclearly measurable outcomes.
it is not an OKR unless you canmeasure the thing that you say
(26:08):
you are trying to accomplish.
So what does that look like?
Right?
So in, if you're trying toincrease cross sell, that's a
pretty simplistic one, right?
So we know what our baseline metricfor 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 by15%, 20%, whatever that that is.
Making sure you're driving to that andthen having milestones that are truly
(26:31):
value checkpoints, not just, I accomplishthese three tasks, meaning sometimes
I can see poor OKRs being the laundrylist of all these activities we have to
do and in a sequential order, and thenthem going, okay, milestone here, but
like, what did you actually achieve?
At that milestone when you do itthat way versus, I like to just start
(26:51):
with, what's your overall outcomeyou're trying to drive towards?
And then if you almost like reverseengineer it, if we're gonna get there
in three months or six months, whateveryour timeframe is, where do we need to
be a month before the end of that to beknow that we're gonna nail that thing.
Oh, we need to be here.
Okay, cool.
And you continue to do thatback until you get to the very
beginning and then you fill inyour tasks versus I oftentimes see.
(27:15):
folks that are slightly newerto 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 thatnearly as successful.
Yeah,
Trisha Price (27:27):
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 tasksversus what am I trying to achieve.
And I think that's so relatableto this whole conversation for
product particularly because.
It can be the same way, right, forspecific products that we ship, as it
(27:50):
can be very easy to get excited thatwe shipped five different features,
even if none of those five featuresactually improve retention or adoption
or revenue or whatever our goal is.
So I think that's good advice forall of us to keep in mind whether
it's OKRs or launching a new product.
(28:11):
Shockingly, not every singleproject program product that we
try to accomplish is successful.
So one of the things I know you'reexceptional at is postmortems and
helping us figure out the why.
So tell us a little bit about yourprocess for running postmortems on
(28:33):
product decisions that didn't pan out.
So
Jessica Soroky (28:37):
this goes
to my Agile background.
it's a pretty core conceptto any Agile's out there.
You retro you retro constantly.
I think I really benefited from areally good mentor when I first started
out and like some of the facilitationtechniques to draw some safety into the
room so that people can be honest, basic.
(28:57):
guidance would be starting with somerules of engagement, especially if
something really didn't go well.
Making sure that everyone in thatroom knows this is not a blame game.
We're not looking to.
Point fingers at each other or tearother groups down to, to justify
the situation that we are in.
I prefer if at all possible inperson postmortems just because
(29:19):
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 notesand a whiteboard and we can
postmortem literally anything.
because it's, it's nice to be ableto, to just write down kind of what
you're feeling, what you're thinking.
It sounds wildly simple, but I stillconstantly have to remind people that
when you are, whether it's a virtualwhiteboard and aren't an in person one,
(29:42):
identifying things that went wrong.
Don't call out names or teamslike we, we, we don't need to know
that Becky screwed this thing up.
We need to know that x, y, and Zprocess didn't work efficiently or
that a step got missed or, or whatever.
The thing is, don't, we canidentify the thing, not the person.
And sometimes I've even hadto, as, as the facilitator,
(30:04):
reading through them, just omit.
Pieces that somebody has written on, ontheir piece of feedback to make sure that
it doesn't become this personal thing.
so those are some basic, I wouldsay, facilitation techniques.
The other thing that I would, Ireally encourage, or that I do
myself is I'm not afraid to asksome dumb questions in the session.
If I don't know everything that'sgoing on, I think it can actually
(30:27):
be really beneficial because I cansay, Hey, as an outsider, explain
this more to me in layman's terms.
And it almost like de-villanizes thesituation because it just, it, it gave
me the most basic rundown of what wassupposed to happen and what did happen.
And when they are able to do that, itcan take some of the heat off of it.
And the key, the final key is if you don'tget to action about what you're going
(30:50):
to do different next time or what you'regoing to change as a lesson from this.
It's a waste of everyone's energyand time, so making sure that you are
clearly and constantly getting to action.
I prefer to do it as we talkabout each individual thing versus
I've seen some folks that liketo talk through all of the stuff.
And then get to action.
I think folks are exhaustedwhen you take that, that path.
(31:11):
So I like to just action it aswe 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 changeor do differently first?
and then I assign an owner.
And when are you gonna be accountableto finishing that thing, which also
sometimes gets missed when you'redoing these post-mortems is ownership
(31:34):
and deadlines to see it improve.
And then I'm a great nag.
I love to nag people after.
Yeah.
Trisha Price (31:40):
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 aboutyour role of program managing as well
as product operations holisticallyto help product teams effectively
and efficiently drive businessoutcomes through shipping software.
(32:03):
Part of your job is to constantly lookat how the product team and engineering
are doing and make suggestions toimprove, to help us figure out where
our bottlenecks are, to help usfigure 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?
(32:27):
and then how do you foldthat back in to make change?
So I think
Jessica Soroky (32:32):
something
Trisha Price (32:32):
I've learned
Jessica Soroky (32:33):
somewhat more recently
is just being really, really close with
the leaders in product and engineering tounderstand 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 Iknew 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,
(32:56):
okay, let me check in again and figureout what did Trisha care about versus
what does this new CPO care about?
How is that different,how our behaviors change?
very recently we've beentalking internally about this.
Building AI is a very differentway of building software than
than previously experienced.
So similar conversations is like,okay, CTO CPO what do you want to see?
(33:22):
What is the outcome thatyou are trying to drive for?
And then how does the processand what we measure create that?
So for instance one of the thingsthat we're trying to figure out
how to do is iterate even faster.
How do we increase the or howdo we decrease, I'm sorry.
The time from idea tojust hands on keyboard.
We wanna just experiment rapidlyso that we can test it quickly and
(33:43):
learn from our lessons quickly.
And so we had to step back and go,okay, well what are we measuring
today and what behaviors aredriving the anti-patterns to that?
Like why aren't we getting that tobe able to then go if that's what
I believe what you measure is thebehaviors you're gonna get 100%.
So when we stopped and looked atit from that point of view, we were
able to quickly realize, well duh.
We're getting the resultsthat we're getting because of
(34:04):
the things we're measuring.
So let's change those measurementsand let's find measurements that
make sense for this new behavior.
So that particular example, oneof the ones we're playing with
is how do we decrease cycletime 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 thestandard and now it's just, okay, let's
(34:27):
experiment and figure out what ways can wedecrease that cycle time really quickly.
Trisha Price (34:31):
That's, that's amazing.
And so you talked about yourengagement with the product leaders
and understanding what their goalsare and what's important to them.
When you figure out these changes thatyou do need to make, how do you manage
that change with the rest of the team?
Jessica Soroky (34:49):
Depends
on the scale of a change.
Definitely impacts it.
because of my experience at Pendo.
Being in both engineering andproducts and having really strong
relationships with both leadership teams.
Normally my first reaction is to try toassess how much do I need both sides.
Like, so some changes I mightjust need product buy-in.
(35:10):
whereas other changes, I absolutelyneed R&D to be bought into it, and so
that changes my behaviors going forward.
If I need engineering to also bebought in, then playing through
our own internal dynamics tofigure 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.
(35:30):
I think you, you really helped meconstantly 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 manageror product operations manager, an
engineering leader or an IC engineer,if we're asking you to do something
differently, What's the positive impactyou should, you should expect from that
(35:52):
change and trying to lean into that.
and then I know this is no, no leader'sfavorite thing, but like repetition
over and over and over again.
Communicate it over againand again and again.
Um.
I, that's a, that's a constantchallenge, but and you're
Trisha Price (36:09):
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 newconcept in product, but it's not.
(36:29):
been around as long as product either, andespecially for companies that are still,
you know, undergoing the transformationto some sort of product operating model.
You know, may not be as familiar withproduct operations or people may think
that's something I can do down theline or if I'm trying to save money,
it's not something I need right now.
(36:51):
Tell us why product operations is socritical and why people can't afford
not to have product operations.
Jessica Soroky (36:59):
Yeah, so I, I see it
actually really similar to this craze
around AI in the sense that with everyonewanting to to be as fiscally responsible
as possible, given the constant upsand downs of the economy right now.
Product operations when, when done wellis an incredible way to get more out of
your existing product organization withouthaving to add additional heads to it.
(37:23):
it is an incredible way to make surethat if you are investing in ai, that
you're getting the most out of thosetools and the rollout across your product
org, and ensuring your PMs know how touse 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 heartbeatto a product organization that, like a
(37:47):
rev ops is to a revenue organization.
It's continuing to just capitalize on, onthe value that it brings and make, and.
Creating consistency acrossthese product organizations.
But if anything, I think it's morecritical now than ever because folks don't
have the dollars to go build out 10 morePMs or even expand by one or two more PMs.
(38:12):
So if you can figureout how to get a small.
Very operationally mindedset of human beings to find
you efficiencies constantly.
Why would you not want that right now?
When, when all belts are tight?
Trisha Price (38:24):
Yeah, I think
that's a great point, Jess.
And, and I was having a conversationwith Marty Cagan who we all look
up to especially when it comesto product operating models.
And one of the things that Marty saidthat I really appreciated was that.
Every single company creatingsoftware needs, project
(38:45):
managers and program managers.
But that's not what a product manager is.
And if a product manager is spendingall their time doing program management
and project management, then noone is being a product manager.
And I think that's true across,right, whether it's the design team,
whether it's product marketing.
And so I think your team has justdone an incredible job of keeping.
(39:11):
Us focused on the business outcomes we'retrying to achieve, helping us understand
where the roadblocks are, where we'reslowing down, where we're stuck, providing
transparency into that, and then reallyhelping all the other teams stay true to
also what they're supposed to be doing.
And just because you're a goodproduct manager does not mean you're
great operationally and vice versa.
(39:32):
So but we have had people.
From a career path, go from productoperations to product management as well?
Jessica Soroky (39:41):
A hundred percent.
I actually think it's one of thebiggest symbols of success in my mind
is especially because those two usecases, they were agile backgrounds.
and had we stayed on thepath that we were on.
I could almost bet my paycheckthat they would've never moved from
Scrum master to product manager.
But this move into program managementbeing such a vital part of product
(40:02):
operations and living in product,gave them this really cool career
opportunity to, to see just muchmore about how product is built and
then move into that space themselves.
Trisha Price (40:13):
That is great
and hopefully that's a great
advice for all of our listeners.
For people who ask you and I all thetime, how do you get a path into product?
it is, you know, it is obviouslymore than being organized in a great
program manager, but by sitting inproduct and understanding the outcomes
and understanding what product isand does, gives them more exposure
(40:34):
and sometimes even they can tryit out and yeah, somebody might be
on leave or someone might be away.
Or we may have a new open spot and, andeven give someone from product operations
or program management a chance at that.
So that's great.
Well, Jess, thank you so much forjoining us today on hard calls.
I really appreciate you sharing yourexperience, your wisdom around all
(40:58):
things, product, operations, allthings data, some things Pendo, and
specifically on the transformationat Pendo to, business outcomes.
So thank you.
No problem.
Thanks for having me.
Thank you for listening to HardCalls, the product podcast, where
we share best practices and allthe things you need to succeed.
(41:18):
If you enjoyed the show today, sharewith your friends and come back for more.