LaunchPod - Naomi Lariviere
===

[00:00:00] 

Jeff: Hey, Naomi, how you doing? Thanks for, uh, thanks for joining us today

Naomi: I am doing well. Thank you for having me. I appreciate the time and, , the opportunity to talk everything about product

Jeff: you're at ADP, , CPO product over at ADP, and product is changing , not like building product, but the discipline of product and what teams do, I think we can all agree is changing immensely, with AI and how it grows and changes, it seems like every day.

, But you guys are doing cool stuff , and I think a good chance to kind of look through , and where is the profession going, but also, like, what are the things you're doing that have been really positive and accretive for your team to be more powerful with these tools instead of kinda just giving it all away to the developers coding faster?

, But maybe before we do that, let's just take a second , and can you give us the TLDR on, like, how did you get here? What's the background? 'Cause I think you ha- you have a unique background of a lot of people who've come on the show.

Naomi: Yeah. Um, so I, I would say my background is kind of different than most people in my role, I think. , So I have [00:01:00] a, , background, you know, started in the financial services industry. Started as actually a b- business systems analyst. , And over, 20-plus years now, , I've taken, traditional product course of career ladder maturation.

But, you know, at one point in my career, I decided, you know what? Maybe product really isn't for me, and I tried doing other things. So I ran an IT PMO. I ran professional services for an organization. I even did, pricing and sales ops for an organization. And really, what I was thinking about when I was making those changes was understanding the full scope of how you build a product and all of the important elements of how do you onboard a client?

How do you sell to a client? How do you actually price the value of what your product is offering? , And for the last seven years, I've been at ADP and I oversee our, , mid-market portfolio of products and, it's about $4 billion worth of, , annual [00:02:00] revenue that we generate

Jeff: So just, you know, just a little bit of cash. Um,

Naomi: Just a little.

Jeff: I think, you know, the side quest there is, important to what's going on now but like AI, everyone kind of questions is it the end of product and, and I, I for one really don't think it is, , we can go into it 'cause I think you have a great take on why not.

But I think it's probably the end of bad product management.

Naomi: Yeah

Jeff: but so much of the things you talk about there, you know, as a side quest are what makes a great product manager because , we're not here to make software, right? That's not really the goal.

We're here to solve customer problems, and all the things you describe is how you actually do that. So, mean, with that, let's just, let's just dive on in. , Let me put you on the spot. , Is product going away with AI? Is that the end of it? Are we, you know, DOA here?

Naomi: No, I don't think we're DOA. I, I, I don't. Um, I actually think, y- you know, AI will help us take a lot of the friction out of what a product manager does, and , I kinda like how you framed it there of, , bad product management or bad behavior. I [00:03:00] think, you know, I've been in this business quite a long time, and I started - in the days where you had to, like, basically spell it out for a developer.

You know, Here's the field. The field will be called this. This is how many characters," and you were just giving them every single piece , of nugget. And I think, you know, when organizations , transformed into the agile organizations and product owners and, and all of that, it's like, okay, well, I want you to wear all the hats of a product manager and now basically run a dev team and, , create a backlog, refine that backlog, and then prioritize the backlog, and then, you know, answer all the questions, QA, all this stuff.

And, like, you're wearing all, all the hats to keep, I always call it the care, love, and feeding of a development team. And you're not doing the thing that product is s- like intrinsically positioned to do, which is actually understand what problems a s- prospect or client has and how you can bring software to actually solve the problem that they have and drive the outcome that they want to [00:04:00] achieve.

And I think over, , the last 20 years, we've lost our way to a certain degree, and I think that's why a lot of people question the value of what product, , organizations, brings to an organization. But if you do product well, you will notice if you remove it from the equation. If you don't do product well, then you don't notice.

But, I don't think we're going away, and I think this is a rare opportunity for us to actually get back to the work that does matter in building products , and building products at scale.

Jeff: I don't think the speed argument is contraindicative of product because , not to get like physics nerdy, but velocity is what we talk about, and velocity is a vector. It has direction and it has speed, and you can go really fast in the wrong direction.

, And at some level I feel like that's what product at, you know, at a very, very probably dumbed down way, product gives you the direction for the speed. What does that look like internally? I guess like How has this changed at, over at, uh, at ADP?

Naomi: so I think AI makes building cheaper, but it doesn't make [00:05:00] choosing things any easier. , I have an opinion that, maybe we won't need so many developers, or maybe we move the developers around to do more things. But, you know, what product brings to the table is understanding the problem to be solved and then figuring out what's the best opportunity of how to solve that, and then, pointing your development team , at that, uh, particular thing.

in our organization, , we actually had this kind of fun conversation about, well, maybe you don't need product, maybe product is eliminated. And - I said, "Okay, you figure out how to, to deliver something." And, you know, the dev team took a, a, a shot at it, and ultimately, we ended up, oh, wait, w- we need the product person to tell us, like, well, what are the rules?

What is the compliance regulation? You know, all of that kind of stuff. And it's like, see, you can't do it without us. and I think, you know, whether it's ADP or any organization, , there is value in, in what product brings. But I think what we've been trying to figure out is, we don't [00:06:00] wanna be the stewards of, , helping the development team move the widgets along in, in the development, , life cycle.

What we wanna be spending our time doing is figuring out, what are the, the problems that we should be solving, how should we solve them, and then, like, understanding does it drive an outcome both for our users as well as our business. So we've spent a lot of time, contemplating how AI can make our jobs and make us more efficient and more effective in what we're doing.

So, while it makes a lot of building things cheaper, it doesn't make choosing what you build easier, and it doesn't, , mean that we would continue to, , spend the time always just with the development team. , It - kind of changes where the direction of where we point our focus.

Jeff: I wanna, I wanna pick this apart 'cause I, I, I've heard you kind of talk about this before, and the phrase I saw you use at one point was, we got Scrumful, not Agile." , , what'd you mean by that?

Naomi: You know what? When I was first coming up in this profession, , I spent a lot [00:07:00] of time, you know, talking with clients and prospects and doing market research, understanding competitive landscape and, and all of that. But over time, as, Agile got introduced into the development process, the expectation of a product manager really shifted to, well, you need to come up with all the requirements , and the definition of what we need to do, but then you also need to tell the developers exactly what they should be doing every single sprint and, like, how they should be prioritizing the work.

And I think basically we became a bit of a babysitter, , for the development team because, , what ended up happening is, like to a certain extent product changed, but how development needed to receive the information didn't change. They still wanted all of that hand-holding that if, you know, at the very beginning of my career where I was a, a BSA, they still wanted that level of detail.

And so that requires a lot of time and effort And so , the expectation was for product [00:08:00] managers to be delivering that kind of, , level of detail to the development teams. so if you're doing that, then what are you not doing? You're not going and talking to your clients. You're not talking to prospects.

You're not, understanding the market. You're not understanding the macroeconomic situation, and so , you've traded one thing off - for another. Now, could that possibly mean you actually should have two roles, more of a, a technical product owner and, a product manager?

Yes, probably that, that is what the answer should be. But, I think, it, it kind of like took what the value that product brought, and it changed the value of it to where it becomes commodity to a certain extent within the development life cycle. And, I think the criticism of a lot of product organizations is, , you've fallen into this trap of, you know, the care, love, and feeding of a development team, but you're really not doing the things that what, you know, most businesses understand the value of what products should be bringing to the table.

So then it becomes this questionable thing. [00:09:00] And now it's not surprising to me in this age of AI, you know, people can go, "Well, it can write the PRD. It can write the user stories. It can do all of these things for you." And miss the fact that, , what product actually is doing is synthesizing multiple inputs and then, , going, "Here's the best opportunities that we have to solve a problem, and here's the ones that are gonna make you money."

And a lot of people, , forget that product is-- I, I always say it's a u- a unicorn role. Like, we are doing nine different jobs in what we do. It is not just around the software development life cycle. , , you know, you have to understand finance, you have to understand pricing, you have to understand sales, you have to understand marketing, , competitive intelligence.

All of these things that we are doing that I, I think, over the last maybe 10, 15 years have been kind of diminished all for the value of helping a development team execute on a deliverable.

Jeff: we started to mistake the [00:10:00] ceremony for the job. Um, ., Why did we go from waterfall to agile and, and put process behind agile and all that?

Was because they were kind of slow, bad ways of doing things that needed, that were required because of h- you know, when you had a physical data center you owned and, and there wasn't a great way to do versioning and all that kind of stuff. yeah, you released once in a while because you had to, to...

It was a huge effort to do all the things under, under it. As that got easier, we moved to much, much faster, and you could deploy a lot more and do a lot more, and all these things had value. But like the tenants behind Scrum and, and the roles and the meetings and the, the ceremony, it was a means of getting something done.

You didn't do that well because the goal was do well. It was because if you were disciplined and did it well, it usually led to a better outcome, , and we kind of forgot about the outcome part, it seems like.

Naomi: Yeah, I think we forgot about the outcome, but I also, y- you know, I don't know that Agile actually made us deliver things, and fail fast or quickly., don't think it did that. I think we just took, chunks of the work that we would've already had been doing and, and broke them down a little bit.

, [00:11:00] Especially in, in larger organizations, you don't push code as frequently as a startup does. Like a startup may be pushing code every day. I mean, I know f- you know, some of, larger, uh, social media organizations, for example, they're pushing code all the time, multiple times during the day.

Large enterprises, we don't do that. , We're much more, thoughtful about how we introduce

Jeff: especially where ADP sits, I'm, I'm kind of thankful, uh, that like, you know, you don't w-w-- Some joke I heard someone make the other day, You don't want too much innovation from your accountant or your barber, , because there's certain areas that, the downside has such a high cost. and then things like, sure, if Twitter has a problem for a second, it's 

Naomi: that's not a big deal. If we don't, if, if, if we don't pay you,

Jeff: If I don't get paid, I'm really mad and I'm in

Naomi: that-- you're, you're very mad. And, you know, like ADP, , we've got over, , 1.1 million clients, and we pay one in six Americans. And when you think about somebody's pay, they could be counting on that check to make their rent [00:12:00] or, you know, pay for a vacation, or they're getting married and they need to put a deposit on an event space.

You know, if we do something that means they miss that, that is-- that's not okay. That is a moment in their life that we are impacting, and we don't wanna do it. So kind of ADP or one of the banks , you know, we innovate actually all the time. , , But we do it very thoughtfully, and , in a very controlled fashion

Jeff: I Do wanna put in one thing, which is , I don't think the kind of process end of it was a bad thing, what I mean by that is, is yes, , we got distracted as a practice that the ceremony was the job, and I think that general flavor of product will get compressed and have trouble right now. ,

but I, I remember my wife for a long time worked at, , Bain, the consulting company, and I thought this was really, really interesting of how they looked at how they prioritized and, and thought about their teams. They had, like, the general partners and the managing partners and kind of the, you know, the bigwigs, the rainmakers.

Those were clearly vital, vital people to the org. [00:13:00] But as you looked at how they actually thought about who was prioritized , who they really needed and , who brought the most value, the next one down was actually the, - executive admins to those, , managing partners, because it gave them so much leverage to do a lot more and move faster and be better rainmakers.

And I think there's something to a good process and tight operations and keeping all that stuff from getting in the way of what you described, right? We're here to drive value and solve problems. That level of process is great and super, super important. But no one cares about the third meeting on Tuesday that we have to have because that's just what we do all the time, right?

But it's more what you just talked about. When you're thinking about how you innovate, you have to keep in mind, if this goes down, someone can't pay their mortgage. , I think that level is, is...

It's not no value, it just how we're delivering that is changing.

Naomi: , I like process, but I don't like process for process's sake., And I think, in a lot of [00:14:00] organizations, , you've got product managers who are maybe handling, , anywhere from one to three teams,

and when you're kind of bouncing back and forth, you know, now we're talking three daily stand-ups, we're talking, , three planning sessions, it's just a lot of busywork, and maybe that's a little bit performative versus, , meetings where we're driving to make decisions about what's the next right thing that we do or next best action that we take.

And I, I think I get more value out of that than, you know, process for process's sake. So that's maybe where I'd, I'd clarify my statement.

Jeff: I've heard someone else say that basically every meeting should have a reason for existing.

There should be a decision you're making or, or something you're fundamentally unlocking by taking that time to do it. And what's interesting is you hit a point where, like, the chaos of a startup actually, and the speed starts to get in the way, and you need a little bit of process. And you see great companies are able to kind of bring that in, refine it, and keep going at their speed, but just be a little bit more organized.

And then some [00:15:00] places, or especially if you get, like, acquired by, you know, some company that does it much, much bigger and tries to apply huge enterprise rules to a tiny startup, everything just slows down. , And somewhere in the middle there , is where you see that value of, like you said, it's not three standups a day and all that.

A decision needs to be made. , The engineers need to build the right thing. How do you make sure they're building the right thing? And then let's, let's get out of the way and go. -

Naomi: Exactly. , I think the best job of a team is to clear the things that are blocking them as quickly as possible so they can keep moving forward and, development teams are highly accountable for owning how they actually build whatever it is that they're trying to build

Jeff: Yeah. Your, your, the product team's understanding of the problem doesn't excuse the engineers from also having a firm grasp on why we're doing something, what are we building, what does great look like, what's the problem we're solving, and, and all of that. So the, I don't know, trillion-dollar question, I guess, at this point becomes, the other thing we talk about is the future product.[00:16:00] 

You know, people talk about becoming product builders versus product managers., how are you looking at that evolution?

Naomi: I think that perception is, is maybe a, a little silly at, at this point in, in the game. A lot of people who are in product are not computer science background individuals. Yes, do I know how to code a little bit? Yes, I do know how to code. But do you trust me at launching, feature and functionality into, you know, a platform like one of ADP's?

Uh, probably you shouldn't do that. And I don't know enough to be able to question the AI from that perspective. And there's plenty of people in, in product that are, are similar. , Now, someone could argue, "Oh, well, maybe we just change the profile of the people that we put in product," but then,, will they have all the acumen that you need to actually go and, and do all the things?

Like, there, there is an art to being able to talk to a client and interview them about what they're [00:17:00] seeing, how they're feeling, and not introducing your own bias into the equation. , There's, , , an intrinsic, skill set to understanding how sales happen and what will push somebody to, to buy your product.

Um, you know, how do you market it? I think those types of things, you know, if, if I'm just sitting there and building and reviewing code and, and trying to push stuff, I, I don't think that actually is giving us the right outcome that we're trying to drive. , I think all businesses are, are there to serve a need in the market that they are in and what, you know, product people are, are, you know, essentially we're the salespeople to go and figure out like, what are those problems that we should be solving and go solve those problems.

So no, I don't think that we're going to end up being the builder. I think it really is an opportunity for product at this point in time to, like, really show the value of what we do, , and not how much we deliver in [00:18:00] terms of actual, like, features shipped and, and things like that. I think it's, it's more like, are we shipping the right things for the right problem at the right time for the right market?

And that's what product, , needs to really start refocusing our efforts on. And I think AI and the world of, of this new technology being introduced into the world of work, it gives us a, a great moment to actually take a step back and think about, well, how do we do that?

Because I, I do think that in, whether it's this company or it's other companies, that a lot of, um, organizations, you know, people in these roles, they're, they're mired in the how and getting the how done versus the what and the why.

And, we've spent a lot of time, and I'll kind of give you a flavor of what we've- been doing. You know, okay, well, if I don't want to spend a ton of time in the devil of the details what do I want my people to be doing? What are they doing today? So we've done a really extensive study on our [00:19:00] individuals in our teams and said, okay, from the moment that they - walk into the office, what are they doing all day long?

Like, what are the activities that they've got? What decisions are they making? Why are they making those decisions? What data sources are they using? We've basically created a jobs to be done for product management. , And then we've actually gone through the analysis of saying, okay,, which are the things that suck their time the most outside of, you know, the typical meetings?

It's writing stories. , It's creating that backlog, refining that backlog, , tasking things out, all of that work. Well, guess what? right? but the things that we do want them to spend time on, even, synthesizing data from win-loss analysis or competitive analysis, that takes time.

, You know, it used to be in our world, from the moment you came up with an idea to the time that you actually had hands-on code, it could take anywhere from three to nine months, depending on the complexity of what you were doing. [00:20:00] We wanna compress that and make our PMs smarter. So, what we're doing is looking at ways to introduce AI and, and the use of agents to, get rid of the busy work, take the friction out , from our people so that they can spend the time, even if they are using AI to help generate an opportunity tree, that they actually now have the time and the mind share to actually review the results properly so that they can go, "Yes, this is the next best right thing to do."

and it just kinda requires a bit of, you know, taking a step back, understanding what your people do, and then prioritizing where you wanna leverage AI so that you can leverage your time better.

Jeff: I had this thought as you were kinda going through just how you all are looking at it and how it's evolving, , I was talking to someone, uh, last night at, at one of the dinners we do, and they were basically talking about they're getting pushed to make everyone, you know, all the product team builders.

, And they've, they've been on this journey for a little while now, and what they've seen [00:21:00] is basically they, they kinda looked at it and exactly what you said. Are there a lot of engineers that have the acumen where you really want them talking to customers and really understanding the problem?

Are they going to understand it in the right way? , Are you, Naomi, going to be the best coder? I'm not gonna be the best coder either. but they kinda came away with... thought was this opens up a world where, where we might see kind of back to the goal is the goal, solving customer problems, a more fluid role set that's what's right for this combination of people.

'Cause we, you know, they kinda brought up they had a couple PMs who were really technical and a smaller number who had no comp sci background. And reliably, the less technical product folks were the ones whose teams were delivering better outcomes again and again and again.

It was solving those problems really, really efficiently versus, you know, some of the other teams where you had the PM kind of building and had a more technical background and they were coding more, didn't have the same rate of, of achieving that on time or, or, you know, the outcomes they had to kind of rework a little bit more.

And it's not to say, like, a technical PM [00:22:00] isn't going to be as good at delivering value. , It's that the non-technical person was great at making the team get there. And I've seen engineers who I want nowhere near a customer, and I've talked to engineers who are fantastic at talking to customers, , and some engineers who solve problems in really, really powerful, interesting ways that no one else has thought of.

I don't want that person spending time doing something else. I want them finding the way to build magic. , And they're all the right way potentially.

Naomi: I've had the same experience. There are some people, , some engineers that I've worked with that are just phenomenal in front of a client and, , they really understand what the problem is and can design a solution. So, you know, there are people with that skill set, but they're few and far betweens too,

so, like, trying to find a product person who's a good builder, I think you're gonna run into that few and far between

I think we are humans, and humans, , have intrinsically different, , ways of reading, , situations and , all the, the knowledge, skills, and [00:23:00] abilities that they have brought to their role.

I really don't see any particular industry where you can just say like, you know, Naomi and Jeff, , they experience the world the exact same way and they're gonna deliver the exact same thing. I just don't see that as possible. I do think AI can help you with coding and getting things more consistent.

But, you know, let's make sure that, you know, as we think about, , roles , and being more fluid, 'cause I do actually agree with that sentiment , from that individual that y-yeah, I do think things will be a little bit more fluid. But where I see the value of, of the product team is, is definitely, spending the time understanding the problems.

Like understanding, if I don't get my paycheck, how does that feel? Having that empathy for the user and then weaving that into your solution. And I want my developers, 'cause they're all really talented [00:24:00] individuals, they're really good at coding, they're really good at architecting solutions, let them do the thing that they're really good at.

And product people, we're really good at the other stuff, so let us be really good at that

Jeff: i've been doing this for quite a while now. I've worked at a lot of companies that have done really, really well, and a couple that have not done well. , And every product person who, if you look at, you know, who does the sales team love? Who does the executive team love? Who do you look at kind of over your career and go, "They are great at their job."

they're reliably, if they're, you know, on the product side, reliably the ones who, who sales brings in a lot, who engineering does go to, who everyone kind of across the org comes to, not because they're the best one at making sure everyone had their three daily stand-ups, , but because they tell the story in a way that sales can hear it and go talk to customers and explain why this is going to be valuable.

They can get on the phone and talk to customers in a discovery sense, or they can join a salesperson to help them expertly get a [00:25:00] prospect over a hump about, you know, making a decision.

Those are the people who, who I think back over my career of doing this, who are great at that job, and none of that is process.

Naomi: Yeah. I, I mean, like I, I view when someone asks me, what would be the one surprising thing about my job that, that most people don't understand? It's, it's the storytelling, it's the influencing that we do. , And, you know, coding doesn't help me do that, right? , I have to , be able to read the room, I have to understand people's, , affiliations and, and what they find really important or what's gonna be important to them.

And then, like being able to articulate that in a way that conveys the value of whatever it is that we're doing. And, that's, using creativity, judgment, , compassion and empathy , for the scenario that , we're going through. I think people who do that in product really well are usually the ones that you see are very successful. But without [00:26:00] a really great product narrative, , it can veer off. But I think the people who do well, they're relying on the truly human, um, things that I don't, I just don't think AI can take away from us.

It's that storytelling, it's that empathy, it's that creativity, , and those are the things that are gonna matter the most in this profession

Jeff: It's the same way you found a lot of value in kind of taking other roles on that were outside of core product.

It made you a better product leader in the end. The same way having some product sense is probably gonna make you a better engineer or a better salesperson or a better almost anything in the org. And, and so, all those people should do that and, and it wouldn't hurt us to understand how coding works a little bit better.

Some of those projects might be, valuable so we know how it works. But no, I, I really appreciate this kind of take on what it looks like at ADP on how is that moving forward, 'cause I think everyone, or there's a loud but probably minority subsegment, , that likes to, you know, [00:27:00] participate in the theater of AI all over of it's the end of product the role is gonna go away, and I just don't think it's true.

But I'm, I'm glad to be able to hear from people out in the field actually doing this on day-to-day basis and leading big teams and operating at huge scale that I'm not crazy on that, and to hear kind of what that looks like to you and how you all are moving forward. , So thank you for coming on today. This was really, really educational about kind of operating that way , and how you're looking at it , and how hopefully this is going forward and continuing to grow, .

Naomi: Thank you for having me. It's been fun

Jeff: Hopefully we can stay in touch. , And until then, , yeah, have a good rest of the day.

Thanks for coming on.

Naomi: You too. Thank you