In the immortal words of Bob Dylan, good times they are a change in.
And change on this scale is, well, it's a lot of things.
It's scary, it's exciting, it's unpredictable, and it's inevitable.
Regardless of how you feel about AI, it has triggered a paradigm shift in how we approach just about every aspect of product, especially at the leadership level.
Which of these new tools do we deploy and how?
How will this impact the structure and functions of our teams?
And as our organizations change, how do we need to change with them?
My guest today is the wonderful Greg Petroff, a professor, design thought leader, and seasoned executive whose resume includes companies like SAP, GE Digital, Google, ServiceNow, Compass, and Cisco.
And as Greg and I were discussing these change in times before recording the show, he made the point that we've kind of been here before with the dot -com era, but the difference is the pace of change, and in turn, the required pace of adaptation.
You're about to hear Greg talk through the tools, organizational changes, and strategies that executives need to be thinking about right now.
Because Bob Dylan says, and warns us very well, you better start swimming or you'll sink like a stone.
Let's jump in. Welcome back to the Product Manager Podcast.
I'm here today with Greg Petroff.
Thank you so much for joining us today, Greg.
How are you doing? I'm well.
Thanks, Hannah. Thanks for having me.
Yeah, cheers. So we'll start off the way we always start off.
I'd love if you could tell us a little bit about your background and how you got to where you are today.
Yeah, I am an architect originally in my career.
I started in architecture a long time ago and then I've had roles in sort of enterprise software space from product management to design leadership over the last 25 years, places like SAP, GE, Google, ServiceNow, Compass.
Most recently I was at Cisco.
And now at this point, I'm doing some independent consulting, a little bit of fractional design leadership and coaching.
and I'm teaching at California College for the Arts.
Busy schedule. So today we're gonna be chatting about some big topics, mindset shifts that leaders need to adopt in order to adapt this new AI era that we're all in and trying to figure out.
So to kick us off, in the past, you've drawn some interesting parallels between our current AI moment that we're in and the dot -com era, which was also a big shift in mindset.
So what are some of the key lessons from that earlier period of tech disruption that are currently relevant in this shift?
Yeah, I think there's a couple of things that are going on.
I think one, expertise isn't necessarily as valuable as it used to be.
You know, I think that we have a kind of a prediction framework of how we see the world and it's based on our experience.
And then when we start to look at work, we use that framework to help us navigate and do the next set of things.
And that's useful when the rules are consistent, but in moments of change, the rules may change and you may not see them.
And so curiosity is a very important behavior to cultivate right now.
And I think in the dot -com era, there were lots of companies that sat on the sidelines and didn't really understand what it was.
And then there were a bunch of people who didn't really understand what it was, but they were curious and just jumped into it and started making things.
And I think we're in a very similar moment where it's moving so fast that the way that you have to find your way into understanding how you might use AI is to be using it as much as possible.
Yeah, with everything shifting, that also kind of makes me think about how traditional roles, traditional as we see them now, obviously, traditional to us now is not really that traditional.
It's all changed so rapidly over the past several decades.
But can you elaborate on how you've seen some of the changes in role boundaries and product development just play out so far?
Obviously, it's situational.
So every company has its own culture and strengths.
You know, like Google's a very strong engineering culture and, you know, the other disciplines are important, but the engineering kind of like drives the car.
Other organizations, design's more focused than the center and others are product management's more focused.
So, you know, culturally, organizations have kind of a bent.
Also, I think some organizations are very orthodox about the role definition and they say, you know, this is what you do and you don't do things outside of that.
And this is what your cross -functional peer does.
And I think that worked for a while.
Well, I've never been really orthodox.
I've been sort of one of those people on sort of blended boundaries in my career.
And sometimes I've been accused of being a designer who does product management or a product manager who does design.
And my perspective is it's about product culture.
And I think one of the things that's happening right now is that the tooling that we're using is so different than it used to be.
It's so much faster and it's more accessible for a wider audience.
And so those of us who might've been in a silo can start to do some of the work that might have been a peer's contribution.
And the question is, you know, where do those boundaries map?
And so the Venn diagram is collapsing a little bit on itself.
And I think the future is going to be teams where, you know, there's this term T -shaped people, right?
So you have, you're very deep in one area and you can navigate sort of horizontally.
And I'm almost feeling like it's going to be a double T.
You know, we're going to get to a point where you're going to find these sort of hybrids someone who can design and write some code or someone who's a product leader who came from design or an engineer who you know loves product management and so I think the more important thing is that whatever organization you
find yourself in that there's an open conversation around the tools and what they enable and who's on first basically like who's going to tackle certain aspects of the product development lifecycle.
And it gives us an opportunity to shift from like an engineering led culture or product led culture or a design led culture to sort of a product outcome culture and where everyone is contributing, you know, based on the skills that they can bring to the table.
And so I think we'll see hybrid organizations that may look very different along the way.
You know, in the project management space, I think, you know, the definition of what to build is going to become much more important because it's becoming easier and easier to build things and so kind of the incrementalist mindset of just adding a feature or adding a piece of something you can do that but for the same
amount of effort you could do something that's much more valuable for end users and customers and you can imagine things that might have been not possible before and so that's the thing I'm interested in is like how do we create the space for that cross -functional partnership to be bolder in the things
that they're trying to do, because it's actually more straightforward to actually accomplish that stuff.
Oh, okay. You just opened three forks in the road here.
We have tooling. We've got the changing of roles and how those are evolving and just organizational leadership.
So there's three paths we could go down.
I'm going to choose tooling first, and then we'll double back on the other ones.
So let's talk a little bit about AI tools and product development, because you kind of hinted at, like, you know, the tools are changing, tooling is changing, and this kind of goes down to discernment, because we have a lot of tools available to us and we're really at an interesting juncture where we
really have to exercise good judgment about which tools do we decide to use and how.
So how do you help teams develop that good judgment or that kind of like, you know, gut feeling about when and how to use AI tools?
And also I think there's an important corollary on discernment when you are using an AI tool, do you believe the answer that it's giving you or do you have the ability to co -create or work together with the AI in a way where it's collectively moving towards the outcome you're trying to get to.
I think part of it is experimentation.
I mean, the space is moving really fast, but I think there are some immediate areas that make a lot of sense.
I think in product discovery, there's a whole bunch of tools now that you can do, you can build custom rag models on your research insights.
And for organizations that have multiple years of research, you can take all the transcripts from your research and build models that you can ask questions of.
It's almost like having a virtual persona.
I know that's controversial, and I wouldn't call it a virtual persona.
I would just call it making the knowledge base that you already have more accessible and easier for people to traverse.
And specifically, when you onboard new members of the team, helping them upscale their domain knowledge because they can have this course of information that's really useful for them.
I mean, it's not easy to do, but it's one that once done, you know, and I've been experimenting with that with some friends and, you know, the fact that it comes up with insights and elements of knowledge that may be commonly understood, but maybe not as clearly described is really interesting.
Certainly in the design side of the tooling side, you know, you're looking at, there's a bunch of things coming in the figma space you know figma itself is a new tool you know it wasn't here really five years ago and it's changed the way that we work i think teams are working straight to high fidelity
and i'm 100 sure that's the best idea because sometimes the low fidelity allows you to sort of see things that you might not see once you're looking at something that feels like it's a completed product but it's so much faster and so teams can iterate and make very very quickly so that when the design
team can make faster than you can think, then it's often useful for product teams to make to think versus thinking to make.
And what I mean by that is the conversation you have with mistakes that you make and the artifact that you're creating inform you about the outcome and the customer problem in ways that just talking about it sometimes are insufficient.
And pictures like a thousand words, what we're finding is that design teams that work with their product teams very early and just iterate and they're not really making the final product they're just iterating and making stuff can basically replace the prd with a prototype and vet the prototype and actually
have something that they know that would be a value in a way that was expensive to do in the past and took too much time and so so that's an example and then certainly on the engineering side I mean, you know, people are experimenting with things like Copilot and tools that allow them to move faster.
I think we're still early days there because I think engineering folks are on the fence about its utility.
But the fact that large parts of code bases could be partner written with you also frees up the engineering teams to work on maybe harder problems.
So all these things are there.
And I think one of the things I think we have to have a mindset of collectively is how do we disrupt our work?
You know, because most of us are trying to place these tools into our products and we would understand better the outcomes that they could provide by also using them in our day -to -day product development processes.
I'm right there with you.
I think that right now we're kind of looking at developing this muscle of using AI tools as an extension of our expertise rather than a replacement for the institutional knowledge that is still critical.
to have, because we kind of spoke about this before.
We're kind of in the position to oversee AI tools as if they're sort of carrying out some of the tasks that we would kind of have in our purview and that we're still accountable to.
So that kind of plays well into our conversation about the value of institutional knowledge, particularly in research teams.
I think that research is an area where the use of AI is a little controversial.
So how do you see that relationship between human expertise and AI -powered knowledge management evolving?
Yeah, I mean, sort of alluded to it earlier, most research teams have a corpus of content, you know, and they've been using, you know, years ago, it was really hard to share that content.
And you do a research project, and you present your findings, and then no one would ever benefit from that content again, because it would sort of go into an archive.
And, you know, also research is temporal, you know, it may have efficacy for a period of time, and then behavior patterns in your customer base shift or new technologies arrive, et cetera.
However, in large organizations, there's usually a lot of content available and not many people actually access it.
The research team would like more people to access it because they feel like it will drive better insights and those insights will drive better outcomes.
So I think one part that's interesting is building custom knowledge graphs of your research corpus and then enabling anyone in the organization to ask questions of it.
And that's not replacing research.
all that's doing is allowing you to see the patterns of insights that collectively you have and it shares that knowledge over a wider audience in the organization so it's not just owned by the researcher anymore the researcher has done the work and it democratizes access to that knowledge in a way it
sort of helps everyone understand like who are we serving and why and then it allows the research team to keep feeding that their job is then at some level to continue doing the work that they do.
And I'm a big believer in qualitative research and even quant methods where you're instrumenting, et cetera, and not giving that up to an AI to do for you.
The ability to synthesize that knowledge and share it more broadly, I think it's going to be something that's going to be really interesting.
And I've always looked at democratizing research.
I know people feel controversed around that idea, but whenever I've seen access to something that's value in an organization become more open and more available, the demand for expertise actually goes up.
And what I mean by that is that if more people see insights, the more they want them and the more they recognize that they need professional insight gatherers on their team to do the work that they know how to do well and do it in a methodologically solid way.
And so I think that's the area that I'm interested in is how do we make sure that everybody is deeply seeked in the knowledge of who they're serving and taking that information to make better products I think is you know things that actually make better products.
So we've covered this topic a little bit as well because yeah this I think is a really interesting area of innovation for AI.
We had a really popular episode on product discovery that was enabled by Gen AI with Craig Watson who's the founder of aero some time ago that was that really dove into how like these tools are really I like what you said about using a persona because like you said we're not really trying to just replace
the persona development that we need it's more about making that data interactive like what we have developed and what we have learned and similarly we we did a couple of episodes on the product analytics tools that are gen AI enabled that are really fascinating we did one with Mo Haliba who's the CEO
of DataWisp and also one with Maru Chabara at Quantum Metric.
The way they put it is the democratizing of data and making it more available and more interactive to people who don't have that data scientist competency or that skill set.
And I agree. I think that once, you know, once data is more accessible and we can really see, you know, no matter what kind of stakeholder we are in the organization, we can really understand how those insights benefit us and interact with them in a way that makes sense for our role.
Then it really does kind of open up the door for, okay, Hey, like what does a data informed culture, what can it really look like if we're really using those tools effectively?
So I think it's a very exciting moment in product.
Yeah, we'll see what happens.
I mean, I think domain expertise is tightly held.
It's not something that's universal in organizations.
It's also something that is hierarchical.
So in some organizations, you know, those who have the most domain expertise have the most influence.
I'm not going to say power, but the most influence in the organization.
You know, what happens in an organization where, you know, everyone has access to the to a deeper understanding of who you're serving and why.
And I think that part will be interesting to see how that unfolds and if it helps or if it breaks some conventions around the structures of how we see ourself.
That part's interesting.
The last thing is I get in trouble sometimes for saying this, but I think the role of research is to de -risk product decision making.
And what I mean by that is, yes, we are trying to understand and empathize with our end users and understand deeply the problems they're trying to solve and what outcomes are important to them.
Product leadership makes assumptions about what features and functionality will benefit end users and also make a great product that people are willing to pay money for.
And oftentimes some of those assumptions are loosely held, but are expensive to implement.
And they're not vetted in a way where you have some degree of certainty that if you do that, people will actually value it.
And so I think this is one of the things that researchers can do is to, if they want to kind of move up the stack in terms of importance, it's to be able to obviously give the general understanding of who you're serving, but also find the parts of the product development process that there are lots
of assumptions about that haven't really deeply been validated and use their strength to provide more signal so that when leadership makes decisions on what they want to execute on, they have more certainty that they do that work.
The expected outcome will be the expected outcome.
I'm actually surprised that you get in trouble for saying that, but I won't tell on you.
As a show, we are really, really on the side of the UX researchers and we think that they present an immense amount of value.
To me, I think it's quite surprising that if we're about to invest a great deal of money into producing a product that we really want to be absolutely sure that it's going to be resonant with our target audience.
It kind of eludes me why we would not.
The other thing that's interesting, too, like we now have access to do full circle, right, which we hadn't before.
So, you know, we have these tools like Amplitude that allow us to get, if they're instrumented well, get really great telemetry on behavior.
We have product success metrics.
We've got feature utilization for insight.
We've got, you know, in SaaS businesses, we have renewal rates, and then we can do cohort analysis over which customers are renewing with the least amount of effort on the sales organization, et cetera.
You could take all those signals.
And historically, they've been sort of information that has been owned by customer success or owned by the MPS team and owned by this corporate strategy team and owned by the research team.
And I think there's an opportunity for research to see all of that in a big 360.
And so that you can get kind of a health check of like the experience that you're creating, the business that you have, the behavior of your customers, etc.
That was just almost impossible to do before.
And it's not easy to do.
I mean, there's only a few people I know in the research community have done that.
I think that's where AI can also help is to start melding different data sets on customer success and user success together to get a better picture of the health of your product and then also what needs to happen next.
Yeah, I think that's one of the biggest benefits that we have with some of these conversational models is being able to train them with, you know, all these kind of siloed outputs and be able to kind of unify them into something that was a little bit more usable that we can really ask more pointed questions
of. I mean, like you said, we'll see how it shakes out.
I'm sure that there's there'll be a lot of kinks.
I'm going to say one last piece on that, too, which is then once you get the answer, another reason why you need a research team is you should have discernment and you should go double check because it may just be, you know, your data isn't that great And you're getting an insight that is really not real.
Yeah. I kind of wonder, yeah, as we start to rely more on these models, how data hygiene is going to become more part of the conversation about, you know, is the data that we're feeding into it of high quality?
I can't imagine the moment where you say, our AI thinks that you behave this way.
Is this true or not?
No, I'm kidding. You kind of touched on some kind of organizational and adaptation themes here.
So I want to dig a little bit into that.
So we're talking a little bit about the uncertainty of role evolution, people's roles changing, you know, things kind of melding and shifting.
And then there's also kind of this core expertise that kind of when we have many roles as an individual contributor or a leader, you know, I think that there's some questions about what is the core expertise that you're bringing to the table and how do you kind of defend that when you're in a situation where other
people have overlap with what you're doing, what you're contributing.
There's also AI tools that contribute some of that.
So how do we help teams navigate that uncertainty of role evolution and maintaining their core expertise and value and kind of protecting the area of expertise that they're bringing to the team?
Yeah, I almost questioned the last statement, protecting your turf.
I'm not sure that's what you meant by it, but I have probably changed my career like 11 times in the last 25 years as things have evolved.
I started as an architect, then it was 3D graphics, and then I was in broadcast media and then i was in dot -com and i was an information architect and i was an interaction designer then i was a product leader and i was a researcher then i was back to interaction design then i was a ux leader you know
and i think one of the things interesting about this moment is we've actually had stability in the roles for like the last 10 years and so a lot of people have grown up in that era and have a solid definition of their value and a solid definition of who they are and a solid definition of what they do,
haven't experienced having the rug pulled out from underneath them because there's some new way of doing things or a new piece of technology.
Some of us have been around a long enough, it's happened to us so many times that we just sort of see it and say, oh, okay, the rules just changed.
You know, like, okay, now we got to be more adaptable.
And I say, you know, expertise is really important, right?
You know, and so I think you should know what you're great at.
And I think the way I sort of coach people is lean into your strengths and value them, but don't get caught up in your role definition.
We're moving into a moment where it's more about the outcome and the problem definition and then the execution.
There are a lot of different ways to get there.
And if we hold on to the orthodoxy of our role or position, we might just be fighting the currents that are around us.
And so, you know, stay curious, have a mindset of evolving and constantly learning.
And at the same time, don't shift away from what you love and what you're good at, because the best teams are made up of people who are exceptionally good at something.
I'll give you an example.
When I was at SAP, this was like 15 years ago, I was part of a team.
We weren't a design team.
We weren't a product team.
We weren't an engineering team.
We were an innovation team.
And it was made up of, we had anthropologists on the team, we had engineers, we had product managers, we had designers, and we would be tasked with a project and we would assemble a team.
And the team was always an eclectic group of people.
And we would just look at the problem and figure out how we were going to work on it together.
And I anticipate there's going to be more of that kind of behavior in the future.
I think in large organizations, you have to organize in a certain way, you know, because it helps your product development process, but in smaller organizations, I think that we're gonna be looking at an environment where we're just gonna be more nimble about the tools and the things that we have.
And if we stay orthodox about what we do, it'll actually get in the way of actually doing the work.
Okay, so I'm glad that you brought up a departure from orthodoxy.
I wanna talk about leadership styles.
So you've observed that there's a bit of a generational shift right now that's happening in product leadership styles.
So we're kind of moving away from this very command and control top -down approach to something that's a lot more collaborative.
Now that we're kind of on this anecdote train, would you mind sharing a specific example of how a shift like this has impacted product development outcomes that you've observed?
I don't know which strain of product development will last or if they will both be there in the future, but there are certainly sort of two models.
There's one model of the really strong product leader who is not 100 % transparent with the organization and is sort of making moves along the way to move the project forward.
And it's very much kind of a command and control kind of environment.
And there are many organizations that operate that way.
And historically, there's been some incredibly successful people in the product management space who behave that way.
So many, you know, earlier career product leaders will look at those people and say, I want to be like them and I'm going to do the same thing.
The challenge I've seen, especially in large organizations, is that there's a behavior that can happen where if resources are constrained and the incentives are set up for you to deliver, product leaders will compete with each other for resources because if they over deliver, they get the next job promotion.
If there's no one at the top sort of saying these are the things that we're not going to do, incentivizes people to try to get more done in the time that they have.
And what they don't recognize in that moment is they place strain on the system because there's only a finite set of resources.
And so they're actually using those resources less efficiently because they've put too much into the system.
And therefore, you end up kind of get kind of a bit of crazy town.
And then people move into kind of command and control to kind of try to whack a bullet into place.
I've also seen the other side of it where you're seeing people who are like, hey, I'm entering this project and I don't know what we're going to do.
I don't have to be the person with all the answers, but I'm going to assemble a team and collectively we're going to learn together as quickly as possible and we're going to build a set of experiments along the way that allow us to learn as quickly as possible and we're going to collaborate and share that information.
And the project leaders who do that I find get more out of their teams, they have more clarity, There's more visibility on the work.
People feel like they have autonomy in that.
They can find their role in the work and the effort.
And it may be an indirect observation, but it feels to me that generationally, it's more earlier career or younger PMs who behave this way.
And I think it's partially because they're digital natives to begin with.
Some of the more senior people aren't really, if you look at demographically, and have grown up with great software and want to create a space for a value for the design team and for the research team and for the engineering team and the product team to collectively solve a problem together.
And, you know, I was at the Lady and Friends conference this fall, and it was just really fascinating for me to sort of hear the conversations around how that community of product leaders thought about how they worked with their cross -functional peers.
And it was really heartwarming for me because it was a very open conversation.
It was one where people were willing to be vulnerable about that.
They didn't have the answers, but they were organizing their team to go find the answers.
And yeah, that's a little bit different from feeling like you have to have the answers and your team's counting on you to have them.
And so you sort of fake it till you make it and pivot a lot until you get there.
Right. You know, and so I think there's sort of two strands that are happening in product development.
community that I would be curious to see if better outcomes happen one law or the other.
I don't have great examples for you, but I just these are observations of behavior.
I tend to agree with you, though, because I've observed that work culture in general has become a lot less hierarchical and a lot more collaborative.
And I really like that shift.
I think that we're going in a really positive direction in which vulnerability, attention to psychological safety with your teammates, these kinds of like the concepts of emotional intelligence that are making their way into the leadership sphere and are really sort of starting to have this nominal
effect on how people lead teams and work with people cross -functionally, it's really heartening to see how that's really enabling a lot of people to do some of their best work.
But I'm going to put you on the spot a little bit since we're talking about this.
You know, you're a leader, you're a seasoned executive, and you've managed a great deal of teams.
So what strategies have you found to be very effective for fostering, as you kind of mentioned before curiosity and experimentation while maintaining this high standards of quality well i think clarity is the biggest gift you can give a team you can't be transparent about everything in leadership and it
doesn't actually help people because you know there are a lot of things that happen in the life of a company that sometimes are transactional or are a little bit hard to understand and communicate and then if you know if everybody's talking about it then no focused on work.
But clarity is really important.
Helping people have ownership of that clarity, right?
So it cascades down so people can see their role and how it adds up to it.
It's hard for organizations to say no to things, but I think the organizations that declare what they're not going to do are, you know, very, it's useful because it stops sort of eager beaver behavior around like, hey, we could do this, or I have this pet project that I want to do.
And if you say, no, we're not doing that, doesn't mean it's not, we're not ever going to do it, just means we're not going to do it now.
So that people, again, that's a part of that sort of kind of clarity aspect.
I think giving feedback in a courteous way, but also holding people accountable.
I think the notion of creating environments where people feel safe makes sense.
And it's incredibly important.
But you also have, you can't shirk away from giving constructive feedback.
And when I was at Cisco, one of the tenants that we had that I really loved and it came from Duo, which was a startup that Cisco purchased about five years ago, and they had this tenant that they call, be kinder than necessary.
And what that meant was if you had spinach on your front teeth and you were walking into a meeting, you'd want someone to tell you that you have spinach.
It's not about you, it's just that this is something that you should know about.
And so I think it's about constantly giving feedback to each other and holding each other accountable to a high standard and making it about the work, not about you.
And that creates the conditions where people learn to listen to that feedback and don't take it personally.
They take it like, oh, okay, that's an opportunity for me to improve my game or that's an opportunity for the project work to, you know, to be in a different direction.
So I think those are sort of the two things that for me, I'm not saying I'm great at it, but I, you know, materially try to practice it is to try to be as clear as possible and to try to give as much feedback as possible.
I really appreciate those insights.
I agree with him. I'm sure you're just being humble.
Thanks for joining us today, Greg.
This has been a great conversation.
Yeah, I've talked about a lot of different topics that are really highly relevant right now.
So I'm hoping that we get some interesting feedback from folks who are listening.
And speaking of feedback, where can people follow your work or connect with you online?
Yeah, I'm on LinkedIn.
So you can find me there.
I have a profile there.
I have a sub stack called improbable futures.
So I do a little bit of writing on that idea around possibility.
And so you can follow me in those two places.
Awesome. Well, thank you so much for joining us here.
All right. Thank you.
Thanks for listening in.
For more great insights, how -to guides, and tool reviews, subscribe to our newsletter at theproductmanager .com slash subscribe.
You can hear more conversations like this by subscribing to The Product Manager wherever you get your podcasts.
