Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:00):
Hi, welcome to the
why and the what product
management podcast.
I'm Daniel Kahn.
In today we're speaking withErin Rothschild who started in
product management with Toshibaand Eloqua.
Aaron was one of the first teammembers at Influitive where he
led product.
He is once again an early teammember as head of product with
(00:21):
like Moji.
We explored errands path intoproduct management, how we
thinks about product as servingas the voice of the user and how
he builds relationships withother teams outside of product
through shared ownership ofmeasurable goals.
Hey Aaron, thanks for chattingtoday.
Speaker 2 (00:40):
Hey Dan.
Thanks for having me.
Speaker 1 (00:41):
Yeah, it's a exciting
to have you on.
I'm excited to dig into yourjourney with product.
Um, why did you tell us a littlebit about how you got into
product to begin with.
I know you've been doing Godproduct management with a number
of different organizations overthe years.
Speaker 2 (00:59):
Yeah, absolutely.
Um, I take a bit of a differentpath and I think a lot of other
product managers I've met anduh, I've come through the
customer side of things.
So for myself, uh, early on inmy career I started off in a
customer support sort ofscenario and then moved into
product management.
Uh, and I was lucky enough tofind that path cause uh, I'm not
(01:22):
sure how else I would have endedup there.
Speaker 1 (01:24):
Yeah.
I think it's, um, it's cool thatthat's your journey and that, so
my journey into this space alsocoming from the customer side,
but I'm obviously a pretty newto it and still finding my feet.
How do you find that's been asort of advantage disadvantage
coming from the customer side asopposed to engineering?
Speaker 2 (01:44):
Yeah, absolutely.
I mean I, I find it a hugeadvantage.
I mean I think that by mydefinition in a way, you know,
product management is reallybeing the voice of the customer.
And frankly, by just listeningto customers all the time on, on
the customer side of things, itmakes it really easy to, uh, put
(02:05):
the customer voice implicitlywithin your head and just really
think about how it customer x,think about what I'm just
talking about right now.
And I think that that'ssomething that product managers
often need to learn as a skill,but it comes naturally to people
who come from the customersuccess and customer support
side of things.
Speaker 1 (02:25):
Well, I certainly
appreciate that coming from that
space.
Hopefully that's a advantage.
I'll be able to lean on myselfas well.
Um, you, you started out with,I'm doing product management
with a to Sheba and Eloqua andthen you were one of the first
members of Influitive beforemoving over to your current role
(02:46):
with, uh, like Moji.
How did you see a productmanagement evolve between those
different organizations?
Uh, what's changed through theyears as you've been working
with different teams?
Speaker 2 (02:58):
Hmm.
So it's an interesting questionactually because then it just
got my mind going.
But, uh, I think ultimatelytoday what's really different is
the amount of tools available toproduct managers actually is
certainly a big change.
Uh, you know, I think thinkingback to the day, it was a lot
of, you know, Evernote or notetaking Apps, a lot of outlook.
(03:21):
Uh, but really today there'sjust so many options in terms of
how you do it.
Uh, but I think also, you know,obviously a big change from
waterfall style execution tomuch more agile.
Uh, but thinking back to it all,what I've always, you know,
instead of recognized for a longtime, I think is that there's a
time and place for things.
(03:43):
And in a product organization,you know, there's a time and
place for certain tools andthere's a time and place for a
certain process and a certainamount of not process.
So, uh, that's what I'verecognized over my career.
Looking back on things is just,hey, I may have brought that
tool in that worked for mereally well at this time and
(04:05):
place in an organization'shistory, but it's not the right
time for this right now.
And recognizing that I think isbeing, uh, you know, for me what
I've noticed as a, as a, Iguess, change over the years,
but something that you need tobe attuned to, uh, but there's
certainly a much largersmorgasbord of, uh, product
(04:26):
operations applications outthere today.
Speaker 1 (04:29):
Yeah, there's a ton
of stuff that's available to us
these days.
When you're working, I guessespecially with a new team and
um, you've worked with teams ofvastly different sizes, do you
have a tool kit that you startto evaluate even if some of
those tools aren't going to beright for the team at this
moment, for the current scienceof the team or for the
(04:52):
operations, um, process that isbeing followed, are there tools
that you, we are at leastlooking through a standard kind
of list of here are the thingsthat I like to use in evaluating
whether or not they'd be rightfor your current environment?
Speaker 2 (05:07):
Yeah, I think you
always have to start off with
the basics I think is where I,where I start off, it's really
easy.
I usually keep a spreadsheet ofthe different services and SAS
services that were subscribed toat a company because it's really
easy for it to get some of thata hand and I include free ones
and that as well.
(05:27):
Right.
Um, cause there's an integrationoverhead to them and whether
that's like a human integrationor whatever it may be.
Um, and bring it back to basicsI think is really like a Trello
type task board, whether it's,you know, Trello, Asana, that
sort of thing.
Uh, obviously Google sheets isthe lifeblood I think of any
(05:51):
product manager today.
Uh, just from a collaborationperspective and the toolkit
elements.
And, uh, but to me those arethe, the most basic elements of
it.
Uh, I don't get too caught upin, in exactly what the tools
are, but really what kind ofproblem you're trying to tackle.
And most often I just find whenI'm coming in, oftentimes it's
(06:13):
about prioritization and reallygetting a bunch of ideas down or
things that have been stagnantfor awhile.
And then saying like, these areactually the things that we need
to work on now because those arereally important.
And you know, it's most basicTrello just really lets you do
that.
And then I think tools followbehind that.
Uh, obviously this can takeplace on a whiteboard or
(06:35):
whatever.
But, uh, that prioritizationtool kit is very likely the
first tool that you need tofigure out.
Speaker 1 (06:44):
Yeah.
Tools, helping to facilitateprocess then and really
understanding what that processis.
Is uh, sounds like the, theright way to go about figuring
out what you actually need tohave in front of you.
Um, do you have a process thatyou prefer to follow?
What does a, the, the teamcurrently follow at like Emoji
as far as development andprioritization?
(07:06):
What is the sort of overallworkflow and process for you as
a product manager leader thereand the, um, the overall team?
Speaker 2 (07:15):
Sure.
So I mean, I think as a productmanager we all go through
different cycles where, youknow, you're an early product
development cycle versus youknow, launching a product.
But at all times you know, you,you get into different modes re
dive deep on to things.
And you know, just yesterday Icame back from a conference
where, you know, speaking with ahuge variety of people, right,
(07:40):
that are all potentialcustomers, prospects and users
of our product and personthrough a lot of that
information that I just pulled.
Um, you know, out of meetingwith all these various awesome
people, you know, it takes a lotout and I think that, but at the
core of it, it also distillsdown like what is a process and
(08:01):
product management.
And I think the way you get thatvoice of the customer out of
your notes and out of yourdiscussions and all those
various different items is andartifacts that come back from
whether it's meeting withcustomers on site or meeting
with them at a conference ismaking sure that you're pulling
(08:21):
the things that you can actionon looking for patterns.
Um, basically digesting thosecontents in a variety of ways.
I often go back over, um, notes,but also think about, you know,
how does this relate to otherconversations?
I've had other conferencesrecently and to me a lot of
product management is aboutpattern matching.
(08:44):
And how you develop patternmatching I think is a about
gathering a lot of disparatesources of data and in product
management, I think that thatreally ranges from, you know,
customer interviews to justcasual conversations to, you
know, diving deep into data setsto understand like a problem
that you're facing.
(09:05):
Uh, but then really pulling thatback into have a framework where
you can tie that to whether it'sa prospect, a customer, or an
internal customer, like anemployee.
And being able then to divvythat up and slice and dice it,
um, based on are they someonewho's helping to move our
(09:25):
software forward, like acustomer support person.
So by fixing this problem, youknow, is this something that's
going to not just help this onecustomer but help, um, my own
internal customer of, you know,the person who's sitting on, on
the phone helping people, howcan I help them?
And so that's one of the thingsthat comes into my processes.
(09:48):
Identifying, you know, whichperson's going to benefit from
this.
And maybe the support internalorganization.
It may be our customer, right?
Um, and pulling that out anddocumenting it.
There's systems out there, uh,tools that we can talk about
later that really help youprocess it.
But at its most fundamentallevel, you know, you need some
(10:08):
metadata that you can pop into aspreadsheet and go from there.
But there's tools that make iteasier than to tie in like
revenue from those customers.
And what's the prioritization ofour three largest customers and
what did they think are the mostimportant features?
And then tying that and saying,well, does any of that overlap
(10:30):
with what our sales team is alsolooking for?
By doing that?
You know, I think Anne and beingconscious of it as you're
gathering the data at theoutside of these conferences and
things like that, you can thenmake a more conscious effort to
making better prioritizedecisions ultimately.
Um, because using all thatmetadata to make the better
(10:50):
decisions is actually the hardpart of product management.
Speaker 1 (10:54):
Do you find that
you're typically aligned with
the other members of leadershipwhen you're actually going
through and picking out what theuh, the right stories are to
work on?
Um, how do you actually decidewhat is most valuable and, and
build that alignment with the,uh, the other members of the
team that aren't themselvesholding a, a product title role?
(11:16):
Sure.
I
Speaker 2 (11:16):
think, I think
there's two parts to that.
I think that there's an elementof first coming to agreement
that there is, you know, what isthe fundamental problem or are
we all looking through thisthrough the same lens?
You know, oftentimes and productmanagers too, we, we come to a a
(11:37):
pre solution, right?
And I think keeping our mindsopen to what the problem really
is.
Uh, and then acting as a way ofsaying, hey, all of us as a
leadership team, can we allagree that this is the
fundamental problem here?
I think that sometimes that's astep in itself, right, of, cause
(12:00):
it's everybody on the leadershipteam is getting inputs from
various different places.
Customer success leadersobviously getting it from the
front lines, you know, but evenlike the finance team, they have
things that are impacting theproduct.
And when you all look through itthrough the same lens, it makes
it much easier to identify thethings that probably the product
(12:25):
team should be working onbecause I think sometimes it
gets down to features andfunctions, but by looking to the
rest of the team and gettingaligned on that, um, and you
come up with product solutionsthat kind of often fit the
problem much better.
Uh, so I'm not sure if thatanswered the question that I
kind of veered off in a bitthere.
Speaker 1 (12:46):
Yeah, I think so.
It's, um, it sounds like it'sjust making sure that you've got
as a starting point, thatcollective understanding of the
problem space, what is it thatyou're, you're trying to solve
and then you can sort of focusin on getting the right data and
understanding the right storiesfrom the, the various customers
and users to align on what thebest priorities are for the, the
(13:10):
organization.
Um, one at task, a little bitabout, um, process from a
development perspective.
Um, do you follow, it soundslike you, you have over the
course of your career moved moretowards an agile process.
Are you following anythingformal, like a, a scrum or
Kanban process with your team atthe moment?
Speaker 2 (13:28):
Uh, as much mark
Kanban right now, uh, in the
past, you know, I just finddepending on the size of the
team or teams that are being,you know, working together kind
of a definitely influences that.
But right now it's reallycombine focused where, Hey,
what's, uh, what do we need thisweek?
Cause I met at a conferenceabout this person with this
(13:50):
person about this.
So we're gonna, we're gonna needto talk about that.
And uh, having that flexibilityis pretty much the stage that
we're at here at like Mudgee.
So, uh, that, that's the modethat I'm in right now.
But certainly, um, I think whenthere's Inter team dependencies
as and when it really becomeslike a different story
altogether, not becomes moredifficult.
Speaker 1 (14:12):
Yeah.
Okay.
That's, that's interesting.
And the, the size of the fulllike Moji team, do you feel like
that influences it?
I think he came from largerteams at the path in the past.
I'm most certainly you saw theearly stage days of Influitive,
but by the time you made yourmove over to like Moji was, uh,
a much larger organization.
(14:33):
Um, do you feel like team sizesis part of the influence on
that?
I think you were just sayingthat.
Speaker 2 (14:39):
Oh yeah.
I mean a team teams has reallyinteresting component of, you
know, the development process.
Uh, I think what sticks out tome is recognizing, you know,
when a smaller team is betterand when, you know, you may need
(14:59):
to throw more, throw moreresources at something.
Um, and I think it's not alwaysdefined by, you know, we need
more front end or more backenddevelopers on this, but what
type of problem it is and whattype of developers can really
help kind of crack that problem.
Uh, which I think isn't oftentaken to account so much.
(15:20):
It's more of like a resourcingtype of issue where people are
just, hey, we have an API teamand there's five people on it
and there's a, you know, frontend process team and there's
five people on that too becausethat's how many people we have.
But I think having dynamic teamsthat you can kind of bring
together based on certainproblems that the company's
(15:43):
facing can be really effectiveis what I've kind of found, uh,
to be the case, not just purelybased on number of team members
in it, but what are theirqualities and what do they excel
at?
Having that flexibilitycertainly seems to align with
that, that agile mindset to dealwith the problem of the moment
(16:03):
that brings the most valueforward.
Um, you've mentioned a number ofdifferent kinds of engineering
rules that are involved in theprocess.
What is the, the makeup of the,the team that you find yourself
working with'em as head ofproduct at like Mochi?
Who, um, who are you spendingthe time with during your day?
(16:24):
Yeah, sure.
So I mean, as a employee fivehere, like Moji, we're really
small.
Uh, you know, I've worked incompanies like Eloqua at
Influitive where there's acouple of hundred people.
Uh, but my day to day with mydevelopers right now are a
really, you know, very agile,very, uh, casual frankly.
(16:46):
Right?
It's more about, hey, when I wasspeaking with customer x, Y, z
about this, this is what's comeup.
These are some of the problemswe've faced.
Um, the team is generally morein sync about those things and
it's less of a distraction.
But at the same time, you know,being a small startup, limited
resources, we have a strong listof things that need to be done,
(17:11):
you know, in the next littlewhile.
And so, in a way, it really isgreat at forces prioritization.
Um, sometimes it's really hardand you end up spreading the
peanut butter too thin.
What I'd like to say sometimeswhere you'd take a, you know,
like when you take a bite of apeanut butter sandwich, at what
point is it no longer a peanutbutter sandwich?
(17:31):
Because you know, it's, it's agiant sandwich, but there's
nothing related taste.
So I, I like to focus with mydevelopers today on just what
are the issues that we'reencountering that we need to
conquer in the next month, let'ssay.
(17:51):
And it's not so much aboutroadmapping, but it's really
just about engaging with ourdevelopers, you know, with Steve
and Ben and trying to figure outa, hey, did anything changed
from last week when we weretalking?
And, uh, that agility just makesit really possible for us to
thrive, frankly,
Speaker 1 (18:11):
other than the, the
developers themselves and, um,
and yourself as a product who'sinvolved in the product planning
process as you're deciding whatthe next key features to build,
or if there's a, a bug that'sbecoming more and more of a pain
in the, uh, the side ofcustomers that needs to be dealt
(18:33):
with.
Um, who else has been involvedin that process with you?
Speaker 2 (18:38):
So it's used the,
it's me plus depending, uh, you
know, it's a mobile app bug orif it's a web bug, depending on
who's involved.
That's kind of how we split, ortwo developers that we've got
here.
But at the same time, you know,bugs and confusion points and
sticking points and frictionpoints, those are all things
(19:00):
that are really important to allof us.
And so actually my CEO, youknow, we'll have conversations
on a daily basis going over whatare some of the key parts that
are really like slowing downadoption or you know, impeding
how we explain our product topeople.
Those are really importantthings.
(19:20):
And so it's, it's not just meand it's not just our developer,
but really all of us at, at likeMoji involved in that.
Speaker 1 (19:28):
Um, when you're
working with those other
stakeholders, um, there's,there's certainly various scopes
of who's responsible for what,how do you build relationships
strongly with engineering andwith sales and with the other
members of leadership as aperson in product and help them
(19:48):
to understand where that valueis in having a product function.
Speaker 2 (19:55):
Yeah.
I think there's, there's acouple of quick questions in
there, I think.
Uh, how do you establish,
Speaker 3 (20:03):
yeah,
Speaker 2 (20:04):
great relationships
with people outside of pm is
something that's incrediblyimportant to product managers.
And I would argue that if youcan't do that, you can't really
be a great product manager.
Uh, I think a product personneeds to be externally aware of
the various different forces andbe very empathetic.
(20:25):
And I think that the empathy isoften, um,
Speaker 3 (20:29):
okay,
Speaker 2 (20:30):
put out there as a,
as a catchphrase for product
managers for their customers.
But I think it's so importantfor product managers to really
be empathetic towards theirother functions within the
organization.
I think really understandingwhat's really hard about
developing a product and thenlaunching it is difficult for,
(20:50):
for a typical product manager tonecessarily understand unless
they're in, they're in the, inthe weeds working with the
product marketing team and themarketing team to really launch
things and to go and support thesales team and make sure that
their products is beingsupported as well.
Uh, so I think it's, it'ssomething that carries across
(21:14):
the entire organization.
And if you can't establish greatrelationships with sales,
marketing, customer success inoperations, you're going to have
a hard time at some pointlaunching a product or ending
the life cycle of a product orreally gaining the adoption of a
(21:35):
product because all of thoseother units are basically, um,
you know, choke holds to yoursuccess.
Um, I don't think that I couldbe successful as a product
manager without interfacing verywell with those other teams.
Um, are there times where itcould have done better jobs
interfacing with sales,marketing support, all of them
(21:58):
for sure.
But at the same time, I knowthat in my career, some of the
great relationships I've hadwith both sales and marketing
have made real differences inour product and the success of
the company.
And I, I think for me, that'swhat's really exciting and the
best way of laying thatgroundwork, I think is trust and
credibility.
(22:19):
So I'll leave those two kind ofbig words as just, uh, you know,
say, Hey, if you can establishthat sort of trust and
credibility with your sales andmarketing team, you can build
great relationships upon that.
Otherwise it's really difficult.
Speaker 1 (22:34):
Yeah, totally agree
that, um, having strong
relationships with the otherfunctions and stakeholders and
teams is extremely important.
Are there sort of any tactical,um, approaches that you have to
ensuring that you'restrengthening those
relationships and making surethat you are keeping sales and,
(22:56):
and marketing in the loop asyou're moving forward with
product decision making?
Speaker 2 (23:03):
Sure.
I think obviously like touchbases on a very regular basis,
uh, are super important.
But I think having arelationship that involves a key
metric that's shared betweendepartments or organizations in
some way is something thatreally carries it together and
(23:27):
makes it something that is ahabit and makes both, both sides
accountable.
So when I know that I'vecommitted to, um, you know,
selling x number of dollars ofthis new skew product that we're
going to be rolling out.
Um, that's something that, youknow, just even me tying my
(23:49):
horse to gives a sales, youknow, manager and leader, the
sense that hey product is reallyhitching their horse to this and
is really involved in it.
And coming back to that andmaking sure that we're reporting
on, hey, how's this producttracking towards that key metric
that both of us agreed to bereally important, really carries
(24:11):
the conversation forward andmakes it easy to have those
types of relationships becauseit's built on a, a number.
Um, but be also something thatyou're both really interested
in.
It's not just like feature a wasadopted by at 37% of our
customers.
It's like feature a was adoptedby 37% of our customers.
But that matters because thehead of sales means that that
(24:35):
impacted 22 deals, whichresulted in us hitting our quota
for this year.
Right?
Yada, Yada.
But that's the sort of thingwhen you have that conversation.
Speaker 3 (24:47):
Okay.
Speaker 2 (24:47):
It's much more
interesting to someone outside
of products to, to know thatyou're, you're interested in
their success as well.
And that's, I think what's weirdabout product is that it's
basically about making sureeverybody else in the
organization is successful.
Right.
And your success is really tiedto them directly rather than the
other way around.
Speaker 3 (25:08):
Okay.
Speaker 1 (25:08):
Yeah, I like that
idea of having that shared
metric to make sure that thereis alignment between the teams.
And like you were saying, italso then forces that there's
some sort of regularconversation to make sure that
you are on pace for it.
Um, when you are working withthese other team members, how
(25:29):
often do you find that you areactually meeting with them?
Do you spend most of your timesitting with engineering or what
would you say the split is, um,in your conversation between
working with engineering versusworking with the, the other
stakeholders?
Speaker 2 (25:46):
It's hard to say
because this from the slicing
perspective, like I look at itas a life cycle element, but I
would say it generally ends upprobably being about a third,
you know, pm engineering timeand then sales marketing,
customer support, kind of beingthe other two thirds of it with
(26:09):
a bit sliced up with uh, youknow, design time.
Obviously the, it's everythingelse.
But I think about that, that'smy kind of mental split is
probably a third of my time Ispend with engineering and then
depending on what month it is orwhat part of the month it is,
um, you know, that that kind ofdictates how much time I'll be
(26:30):
spending with the other teams.
Speaker 1 (26:33):
Okay.
That's um, a good 30,000 footview of where the time
allocation goes and interestingto know.
Um, that's actually I think afairly high number to ensure
that you are making sure thatthose relationships are strong,
which certainly I think it goesback and aligns with everything
you were talking about before.
Speaker 2 (26:54):
Let's keep in mind,
sorry, just to clarify there,
when thing is like, you know,obviously it's been a ton of
time with customers too, right?
Like we're just talking aboutthe internals, but so, you know,
keeping all that as a, yeah,it's tough to keep that balance,
but it's, that's the thing is Idon't think it's a constant
balance.
I think I go into times where Ispend two, three weeks just
(27:15):
doing customer events, going andseeing a bunch of customers on
sites and, and then I don't seea customer for maybe two or
three weeks.
Right.
So it's a day in the life of aproduct manager is usually the
month in the life of a productmanager.
I find.
Speaker 1 (27:32):
Um, are there, um,
regular things that you're doing
on a daily basis to make surethat you are staying on top of
all these differentrequirements?
What does a uh, a typical daylook like in your world?
Speaker 2 (27:44):
Yeah, sure.
It's, uh, it's tough, veryfrankly.
That's, I, you know, I speakwith a product, people who try
to create products for productpeople to keep track of product
requirements.
And a, it's not a simple thingand there's a lot of things that
can slip through the cracks.
But, um, one thing I try to dois on a weekly basis, I try to
(28:08):
have one item.
I actually have a browser pluginthing.
Um, I think it's calledmomentum, but it basically says
focus on one thing per week.
That's strategic.
And so from there, um, that'skind of what I use just to focus
myself and bring myself back toit.
Uh, so that's my way of keepingon track in terms of particular
(28:34):
strategic things that need toget done on an ongoing basis.
And I find that then that justkind of informs me tactically
that week, you know, what did Iget?
Did I take care of thatstrategically important thing
and where there are three otherthings that were kind of of
importance as well.
So it really just brings my,kind of, makes me mindful of the
(28:54):
strategic things that I need tomake sure I'm on top of
Speaker 1 (28:57):
making sure you're
not spending all of your time
putting out the burning fires.
That's right.
So Erin wanted to also ask you,um, do you have any resources
that you would recommend forsomebody in product?
Speaker 2 (29:11):
Sure.
Um, I'm a big fan of mine.
The product, it's a, it's anorganization and also has a
community, uh, that you can tapinto.
It's got a slack, uh, you know,group that is great for tapping
into different folks.
Um, it's available at mind, theproduct.com I think, but they
have a great, uh, annualconference as well.
(29:33):
Really enjoyed going to that.
I was going to say, one of thething that really comes to my
mind is like, uh, some mentalmodels.
So there's this, uh, on yCombinator if you search for
mental models, actually I findit's, uh, there's some great
resources that come up forproduct people and just gives
you a great way of, you know,how do you look at the world
(29:55):
through the eyes of a productmanager and a, I find that
hacker news is always just agreat resource for that sort of
stuff.
Speaker 1 (30:04):
Okay.
So mine the product, definitelysomething to check out.
And, um, y Combinator isinformation on thinking about
the world in product through themind of a product manager as a,
a second one to explore.
Great.
Erin, thank you so much fortaking the time to talk through
(30:27):
your experience with product andbuilding relationships with, uh,
with your team members.
It's a had been a pleasurehaving you on.
Speaker 2 (30:35):
Yeah.
Thanks so much Dan.
Really appreciate your time.
Speaker 1 (30:37):
Thanks again to Aaron
for outlining how he thinks
about building relationshipswith other teams.
If you would like to hear moreinterviews from people working
in and with product, pleasesubscribe to the why and the
what.
Wherever you listen to podcasts.
We'll be back with anotherinterview soon.