← Work For Humans
Work For Humans
Applying Product Management Tools for a Better Employee Experience | John Cutler
01:27:30
Loading summary
Transcript68 lines
- [00:04]
A
One thing I realized is that the idea that my customers, the people internally, my partners or whatever, it was so natural of an idea that that was a product and that I could treat it exactly the same as a product. I do think you can scale this way of thinking, leadership as a platform or information and decision support as a platform or any of those. I do think you can scale it across a company. I think that the limiter in many cases is it involves a tool chest when you're talking about this type of work, and a level of support that's often not immediately granted in those settings.
- [00:44]
B
Welcome to the Work for Humans podcast. This is Dart Lindsley. This is the second of several episodes where I talk to expert product managers about how to create an organization that delivers work as a product to employees. The big question is how many of the best practices from software product management can be adopted to deliver great work. Today I have John Cutler on the show. He's a seasoned product manager and researcher and we discussed the switch from in particular a mechanical command and control mindset to to that of a gardener, a manager who adopts a service oriented mindset, allowing agency and fostering growth and ultimately driving better results for both the product and the people involved. In this episode, John and I talk about balancing variety, complexity and focus in design, a service mindset for managers, and horizontal versus vertical products. We also discussed the three major challenges for for product managers, empathy and agency and management, the traits of a great product manager, and other topics. As always, continue to support Work for Humans by subscribing wherever you listen to podcasts. And now I hope you enjoy my conversation with John Cutler. John Cutler, welcome to Work for Humans.
- [02:18]
A
Thanks. Great to be here.
- [02:20]
B
So here's the problem I'd like to set out and I'm going to set this problem out to more than one person who is an expert in product management, product leadership. And it's this question, as you know, iframe work as a product and it's not just a framing. In reality, in the math and the physics of business, employees are customers. The word product can mean a couple of different things. And so depending upon how I decide to use it, sometimes that's a little bit more metaphorical. Or maybe overgeneral is the right word. But here's the question. If I were setting up a company to deliver this product, how do I structure it? And I'll give you a little bit more context, which is that all of my research and research of others have shown that what people want from work is very different from Person to person. So here's the nature of the product. The product is something that has about 35 different things that people can want from it in terms of jobs to be done. And they want them in combination. And because there are about a billion combinations that you could want, it means that everybody's a little bit different. The question is, how do you scale that? And I argue that what we need to do is we need to push product management to managers because that's where the scale of the organization is. That's my problem statement. And so as we approach this, you could say that's a dumb idea, that's never going to work. Or you could say, okay, that's acceptable and we can move from there. But that's how I frame the problem. And what I need to figure out is, okay, so how do we make an organization successful in terms of product leadership of this very complex product?
- [04:09]
A
So it's interesting, I'm going to draw an analogy with the customer facing products that people build. So what I mean by that is the product that we sell. And one thing that's very interesting that's happening in software as a service recently, in the last year, two or three, is that companies are really grappling with what it means to scale these products. And there's an interesting shift that's happening that when interest rates were lower, a lot of companies tried to go multi product. They tried to offer all sorts of products and that was going to be the main vector for growth. And I think what a lot of them realized is sort of a phrase I use, relevant dimensionality. They realized that the more products you offer, the more complexity you might have to bake into your business model and how your delivery model, et cetera. So when interest rates were lower, companies just threw people at the problems. And we'll get back to that. Cause I think this actually relates to what you're talking about. They threw people at the problem because they could, they could afford to do that. And in the last year or two or three, many, many, many of the layoffs were seen out there in the ecosystem were essentially triggered by the company realizing that the complexity overhead for how they had structured and scaled their businesses wouldn't scale efficiently as they were doing that. And what they've done now is had to rethink about how they structure it. There's a big shift from multi product to what we call functional product. Companies are talking about their whole product offering as a single product. And you get this shift back. But the first thing that came to mind when you were describing the problem is company being a product and employees participating in this ecosystem. And in fact, yeah, the employees are actually part of the product too. So that wasn't a complete misstatement from what I said is that I think what you're seeing in companies is that the relevant dimensionality creates a situation that they're very difficult to manage when you create this kind of baked in complexity. And a concept that I've been thinking a lot about lately is what's the largest size of a group of people that can actually be transparent, trusting, psychologically safe and independent within this sphere. And the conclusion that I've come to, which is interesting, is in the product space that I'm in, there was so much pressure for so many years for this idea of small teams. You'd have these three, four, five person teams. You know, give an engineer a problem.
- [06:45]
B
Get out of the way.
- [06:46]
A
We don't need all these people to do these things. And then in the legacy businesses you had groups of 2,000 people that were essentially coupled together and to ship anything, you needed all 2,000 people to be able to do something. These big non digital product selling companies or commercial goods companies or whatever. But the more that I think about it, the more I'm thinking that there is some size of group around 30, 40, 50 people. I think it's probably less in companies that are running more remotely at the moment. It's less than the Dunbar number, which was just whatever that number was. I always see that maybe that's been debunked or just, I don't know whatever happened to that. And that's the size of people that you'll have two or three layers max of hierarchy. There's not too many hops for information to move around. And then if you can generally get a group of 30, 40, 50 people together with some kind of P and L, some kind of autonomy for what they're doing, some amount of independence for what they're doing, that you can create an environment that is a better product for the employees who are working there and potentially a better product for the company that is creating this ecosystem or this network to produce value for other people doing that. So that's a thought. And so I'll summarize why I started talking about SaaS and everything is I think, just like in the product offerings we are offering to the people out in the world and customers from that regard, what you saw is companies throwing so many people at problems and creating so much complexity in their business models and in their networks. And that had the Net effect of both be not sustainable, bad for the customers out in the world who are trusting you to give them a product. And also not actually all that effective for the people working within the companies who were just bumping up their head against the cognitive load of that working situation. So that's the first instinct I had when you asked that question.
- [08:44]
B
Okay, I completely get that. I used to work for a hardware company, Kla Tencor, and they had this problem, it's way worse than hardware, which was that they had customers that were very demanding fabs. And so these fabs were big dollar events. And so they had a few very demanding customers and they built hardware with too much variety. And it's way worse in hardware when you are building products that have too much variety and too much complexity because for one thing, you're going to have to maintain them later. And so it's very, very challenging for them. And so I can see this in software as a service. Is there an example, like if you were to. First of all, I'm going to say it was probably B2B software as a service. It was probably not B2C.
- [09:32]
A
Yeah, I mean, this is the interesting thing about B2C and B2B is the idea of what I'd call the ultimate horizontal tends to be more common in B2C. A great example of this is if you are offering a search box to the world and people type what they want into that box and back out of it, it gives them search results. It would be hard pressed to imagine a more perfect horizontal in some ways. Right. That the relevant dimensionality of that problem is actually a lot lower. There's a lot of complexity that it's just baking into how the service delivery of that is. I love that question because in B2B, I mean, I worked at a company that focused on the restaurant business. One of the interesting things about the restaurant business is there's maybe five to seven or eight dominant service models within a restaurant, ranging from counter service to table service to curbside. You know, there's a lot of variations there. Then you have the added dimensions of the maturity of the restaurant. Is it just opening? Has it been around for years the scale of the restaurant? You know, is it one restaurant or is it a chain of 50 restaurants? You have the dimensionality of regional differences plus international differences. You have the dimensionality of is it. A different type of restaurant could have all seven service models. Another type of restaurant could only have three of those. So you start to see in business to business you get this problem that Even the business to business products that see themselves as pure horizontals. Like I worked in an analytics company. If you squint your eyes, you might imagine analytics to be a beautiful horizontal. This company will use it the same way as that company uses it. However, that's not the case. There's a lot of relevant dimensionality in there. The maturity of the company that's using it. Is it using it for marketing or using it for product? So you get the idea. So I like the question there in the sense that I think that B2B, if you imagine that the company absorbs the complexity of the product it's offering to customers, B2B software as a service. Even in pure horizontals, theoretically pure horizontals, you have a lot more of these levers that impact how the organization is structured, how many motions the company needs to support, etc. Whereas a lot of B2C products have a different scale. I mean, if you're selling your product for zero and advertisers are essentially giving you money, that's a very different ballgame than selling to a thousand companies that pay you $500,000 plus. So it's just a different scale of problem at that point.
- [11:59]
B
It's so interesting to hear you talk because we had Marty Kagan on the show a little while ago and in reading his books, the way product managers are supposed to think is they're supposed to think about how does this fit into our financial model, how does this scale? And you're doing exactly those things. And so it's very, it's very, very interesting to hear. So first I want to ask a question about this idea of meeting the diverse needs of a customer base. And so a part of the way I see that solved by software companies is, you know what, we're going to stuff all the features into one product or stuff them in there. Let's just keep stuffing them in there. And I did a study once where I worked for a company that had hired 400 recruiters. And we asked them about the recruitment software that they had used in the previous companies. The older the software, the less they liked it. In other words, the longer the software had been around as a company, the less they liked it. And it may have been because it was just old tech, but I think it was because they'd stuffed all the features in there until it was completely unusable for anybody. So that's one way to do it. And then the other way to do it is, no, we're going to split our product, we're going to have Two products serve two different markets. So when you talk about what people did with software and how they tried to satisfy all these different customers with different versions, was it one of those or both of them?
- [13:23]
A
Yeah, this is a fascinating thing because just get super product nerdy on folks but I think they'll be able to draw the analogies here. Vertical business to business products. Focus on a vertical business. So I worked at a company that focused on property management, a company that focused on restaurants. And these are verticals and there can be horizontals within verticals, but that's another topic altogether. So the funny thing is the general vertical B2B SaaS movement or motion might be changing a bit with AI is you can make tons of money. There are public companies right now who found companies that used on prem software used a jumbo. We had a joke at Toast that In the original S1, which is public, the founders of Toast said that they would walk into restaurants and see everyone see has been to a restaurant. If you look in the corner of the restaurant, there's a place where there's a power strip and it's a jumble of powered connected tools. You know you've got your POS provider and you've got your other provider and you've got your other thing. And probably if they're using any kind of online marketing, they also had their laptop and they had other little tools that people were using. This is around 2010, 2012. So one motion in vertical B2B SaaS is just essentially applying cloud computing, sort of modern productivity software, modern models, modern patterns to create what used to be just a known job performed by a jumble of spot products or these products in the property management space. The dominant company that we were disrupting would ship every six to 12 months a version of their product. And we could ship a new version of the product every day if we wanted. Now we had to play a lot of catch up to get the basics like the basics of the accounting, the basics of these things. We had to be a little bit opinionated. So we didn't get too much feature bloat, just sticking to what had been proven to work. And we had to adopt modern technologies like mobile and other things that the on prem providers had just completely ignored. To be able to do that in the vertical game, you basically either become a bank, you become a fintech provider. At Amplitude we had the three games of product. There's productivity games, attention games and transaction games. Vertical B2B SaaS is the epitome of a productivity game. You're taking a business, you're making it more efficient, making it more effective, you're modernizing them, you're sort of like a modern technology play that's coming into that. And so what's fascinating about that is so eventually you're becoming cloud computing and a fintech provider for a vertical that wouldn't be able to afford to build this themselves. And where the legacy software was just clunky, never worked. At Amplitude we dealt with Ford. Ford was trying to revolutionize fleet management is another vertical. And the current software was someone with a local PC running in a little shack on a lot with a bunch of cars in it. And so Ford could come in and give them like modern cloud solution to.
- [16:15]
B
Be able to do that.
- [16:16]
A
In horizontal B2B you will also play the productivity game but you're playing it across a huge horizontal. So for example an amplitude that is a horizontal, it's better decision making which is analytics worked at that company. So you could do that for one company over here and one company over here. We sold to a lot of other B2B companies who it was almost B2B2C in a sense or we would sell to a Ford or a Nike or something like that. So I think what's fascinating is and we'll probably figure out a way to tie it into the employment experience as from the perspective is a lot of the details that will govern your org design are set in motion from these very early decisions about Am I addressing a vertical? Am I addressing a horizontal? Is it an endless horizontal or is it actually a horizontal with a lot more complexity than we thought? Is it an endless vertical with a lot more complexity than we thought? There's a company here in Santa Barbara called Procore that does construction project management that's technically a vertical but that vertical is a billion probably, I don't know, worldwide trillion dollar market of construction that's not going to operate the same as mindbody that gave a tool for yoga studios to do their scheduling. That's a vastly different vertical size as you're doing this thing. So these early decisions about where you put your product and what product you're building probably have far reaching impact on your org design, the employee experience, what kind of org you need to build like a Cisco is not an upstart vertical. B2B SaaS company like completely different game which probably impacts then what the employee game is for those companies.
- [17:55]
B
Can you define horizontal and vertical?
- [17:59]
A
Here's a working definition that will help people. So a vertical would be something like property management, restaurants, construction it's if you imagined that you were to lay out all the businesses in the world right by side and then you started grouping them by similar types of businesses, they would create columns, you know, you'd have clusters. That is a vertical horizontals tend to be products that can sell across those particular things. So great example, HR tech is going to be a horizontal because you're going to sell that product to a bunch of different types of businesses. However, if you were specialized HR tech, if you were HR tech only for the restaurant business, because of the unique goals of getting people to come in and work for a restaurant, you might be a vertical provider of HR tech in those particular things. Google search box is horizontal because if you laid all the humans out in the world, every human can go to that box and find something from it. That's why it works. However, you could get super nerdy and specific with some very fine vertical amount. So hopefully that explains a bit what we're talking about.
- [19:12]
B
That does help a lot. And I can also see that it's useful and you have to squint a little bit.
- [19:18]
A
Yeah, exactly.
- [19:20]
B
So here's what I'm hearing. First of all, depending upon the nature of the product that you are producing and the market you are selling it into, you're going to structure your organization differently. The second thing I'm hearing is smaller is better when it comes to product teams. The third thing I'm hearing is trying to create a product that fits an infinity of needs is cost prohibitive. You have to be very careful about doing it for two reasons. One is it's expensive. B is you might satisfy nobody if you try to make the ultimate thing. But there's an angle on this that we haven't quite touched which is, as I think you know, iframe, once employees are customers and once work is a product, all companies are multi sided. And so now what we have is we have a platform which is attracting demand from the market from a traditional customer. And it's taking that demand and it's turning it into work and allocating that work with mindfulness about what different people inside the company want to do. And then in turn, people do the work and that flows back as value to the traditional customer. Now I want to turn your way of thinking toward the side of this business model that is facing employees. And one of the differences between product and let's say service science is that in true product you're going to be baking intellectual property into something that's reproducible. It's something that you can Stamp out over and over again. Software is the perfect example, but in service design, that product doesn't exist. What you're creating is you're creating a service system that can reliably reproduce certain kinds of experiences so there's no thing at the center of it, and so you don't get the same scale that you might get from a regular product. I can stop there, but that's the first turn I want to take and I want to make sure it makes sense.
- [21:31]
A
It absolutely makes sense. And I think one way I'll dig into this is with stories and ideas that this is triggering with me. I worked at a great company here in Santa Barbara called AppFolio. I mentioned it. It's a property management vertical B2B SaaS company. And there's a couple thoughts related to this one. I live in Santa Barbara. Santa Barbara is a nice place. The weather is nice, almost too nice. I miss existential east coast vibe, but that's not what's right here. But there is also a large college here called UCSB University of California, Santa Barbara. Now, one thing we did really, really well, and the company did really, really well is that John and Klaus were also teachers at that university and they had some large exits prior to starting AppFolio, like go to my PC and they were involved in the Citrix ecosystem, which is also located here in Santa Barbara. And John Walker, who was one of the founders, was on a podcast recently and he mentioned these things publicly. But when they started Appfolio, one of their goals was they wanted to create a sustainable business that was good in uptimes or downtimes. That's why they focused on property management, paying your rent. People need place to live. And also they were trying to create a quote unquote generational company here in Santa Barbara. People do not leave their jobs in one year in Santa Barbara. You might leave the university. Now, one thing that this is, 2015 that always stands out to me about it was that you would have a new grad come from ucsb. And it seemed like we specialized in making that person who is reasonably smart but really young and relatively inexperienced in the business, a competent product developer. I would hire many of those people three years into their career to be a product manager elsewhere. Because my job was actually a UX researcher. I had to take our employees out of the building and we would go and visit our customers. Developers would step away from keyboards, no typing. We'd go and visit customers together. And one of the funniest stories that I had there is we were At a property management company. We walked through a hall and there's a wall of keys. And the developer's looking at the wall of keys and again, we're talking about someone who's like 23 and it hits them like a brick. They're like, this is where all the feature requests come from. This is why we get requests for key tracking. I see the keys on the wall now. The story continues. Actually, there was a hack day. This is after I left, but they did a hack day. And I think that developer, the people involved, your hack day project was keyless entry. He figured out that the job to be done was not to organize your keys on the wall. The job to be done was to actually gain access to a property so that you could show the property. So it's like my favorite product story of you do this activity. You're a UX researcher. My job is to create an experience for our employees, more so than being a UX research specialist who would have gone off and done that research by themselves and would have reported back to for these things. The tail end of this story is you're in Santa Barbara. It's nice. Your students, they will leave because they can't afford to stay. In Santa Barbara. There is a company, it specializes in figuring out who some of those people are. People stay at their jobs for five to eight years here. The founders were dedicated Santa barbarians and they had sold a company. They organized their investment from their early investors so that there was not as much growth pressure as there was from other companies so they could grow the company sustainably. When we added 10 people at that company, it was taken really seriously. I've been at companies since then that would double their team size in one year and say, that's growth. That's what you got to do to survive in this industry. I was like, I don't know. I mean, 10 people was hard. Doubling is a whole new company. This story comes to mind with your question of you've got a city, you've got a university, you've got multiple tech companies. The Mars Land Rover was developed just down the street. You have a scientific community here. You have a company that was also in the ecosystem of other companies. You had founders, they did it. The job was to get people and make them competent. They loved working there. We do retros on the beach. It doesn't get any better than that, really. And that's why people stayed at the company for eight years or 10 years to do these things. So that was the first thing that your question made me Think of this.
- [25:39]
B
Whole story well, and I'll tell you why it's so relevant and why I think the way you're thinking about it is so relevant. Well, which is a company that's looking at a customer, especially a subscription customer, cares about customer churn. And the idea that this company was started, it may have adapted to its context, but it may have also been started with the idea that, you know what? This is a customer population of employees, of subscribers who we can attract and we can hold. And we won't have to pay the cost of churning because we're producing a product. And a part of that product is location and a part of that product is product reviews on the beach. And a part of that product is I'm going to help you transform from being a new college grad to being a product manager. And I'm going to do that in part by giving you lots of exposure to customer needs and translating those. That's a sexy product that's being described there. It's a very compelling product.
- [26:42]
A
What was so fascinating about that is now you're triggering a lot of ideas. I've since been about my career, met with hundreds of companies and I'll say why. I worked at this company called Appfolio and it's almost like that if you know, you know, you know. So I was chatting with a friend at Netflix. They're like, oh, Appfolio. There have been some people who eventually moved on in their career to Netflix. And they're like, oh my God, the quality that people were used to there, wow, you knew about that. That's like a diamond in the rough. And up in the Valley, when I was there, I would mention that. I would mention these prop tech or things and people like, never heard of it. What company is that? So we actually had a trouble in Appfolio when it came to attracting outside people to come to Appfolio. A it was expensive to move to Santa Barbara. People who were young, living in New York were like, I'm going to go from a company of 7,8 million people to 130,000 person town where 90,000 of them are older than 50 or something. It didn't make sense. So we actually had to market. The folks had to come up with creative ways to market. If we wanted outside folks to come, we had to do special things to attract them to come there. One thing that this also triggers for me is in my journeys at Amplitude, when I'd meet with companies around the world, it really did hit home with me how the dominant big tech machine that attracts grads to make lots of money, pay your dues, learn about how the quote unquote best companies work. This is my problem with Marty Kagan's work. And then you're going to go in, you're going to get the best experience, you're going to learn, you'll have that FAANG company on your resume. And then when my friends and I talk to there, they're like, it's a shit show where I work in this. But I'm hanging on here. And honestly, I'm learning a lot about great technology here. It's great. And so that loop that exists is so seared into how we think about it. But when you meet with companies from around the world and you learn about these local ecosystems or university ecosystems, or companies intentionally doing remote to attract folks from different parts of the world in different ways, when you see the intentionality that other places in the world have to put into evolving their model for doing this, it really puts it in perspective. The bubble that I normally would exist in, you know, I would go to us. I didn't go to Australia, but I did a lot of virtual stuff with folks in Australia. And I'm talking to like a plumbing supply company that does very well. It's a vertical in Australia. And I'm learning about how they attract folks after school and doing things. I'm like, oh, wow, okay. We don't talk about this a lot with the normal playbook that comes from the big tech where I live in California or big tech in California. So it is very interesting to me just how different it can be even within California. San Francisco to Santa Barbara is a different world with this dynamic.
- [29:31]
B
Hey, everyone, I want to let you know about some upcoming speaking events if you happen to be in the Great lakes area on September 30th. I'm keynoting the HR track at the UWEBC 27th Annual Emerging Best Practices and Technology Conference in Madison, Wisconsin. The conference pulls in some fabulous speakers to discuss topics across all of business, not just HR. Also in Oakland, California, September 17th and 18th, two of our past guests at Work for Humans will be speaking at the Responsive Conference. Brie Grof will be talking about her sparkling new book Today Was Fun. And Simone Stolzoff will be talking about his next book. So check it all out at responsive.org use promo code 11fold. That's one one fold to get a substantial discount. All right, hope to see you there. That's absolutely true. It is true that every town has its vibe and so there's something very fundamentally different about work as a product that I'm going to try to get at. And a part of it is this idea that it doesn't have a concrete product at the center of it. It's more of. Of an experience offering or a transformation offering. And it lacks the kind of repeatability of a product that we stamp out like software. And so Joe Pine would call this mass customization, that there's an opportunity for mass customization, but it's a little bit different from that because imagine you're a product manager and all you can do is go out into the field and pick bouquets and bring them in from the field and give them to people. That's what it's like, which is that there's this whole universe of work that can be done. Now, some of these are fixed attributes, how we compensate people. Fixed attribute. Our location is a fixed attribute. We might have policies that we set up that are more flexible than location. For instance, we might say we're going to have a policy that people can move jobs every one year. And so some of these are things that are, I'm going to call them area of effect spells. These are things that we're going to cast over the whole company that are going to create a context in which managers can be product managers of the experience of work. Now you're a manager and your job is a little bit more hunter gatherer than it is builder. You have to go out into the market of work inside the organization, and you need to bring together these literally, why am I saying bouquets? I'm saying bouquets because every flower is a little bit unique. And how we decide to assemble that for our teams, it has product instincts. And the reason I ask this, why that's such a challenging problem is let's say I have a company of 100,000. I therefore have, let's say, 10,000 managers. I'm not sure that it's possible to teach them how to be product managers assembling those bouquets. Yikes, that was a labored question. But it's the question of whether or not we can all be product managers and designers or if some of us just can't be. And so that's like one of the central questions that I have is can we distribute the consciousness of a product leader. I don't know. Throughout a company like that. So first of all, let me just see if the bouquet assembling metaphor works.
- [33:11]
A
The thing that jumps out to me about that question is that I'll sort of, again, lean back on my experience maybe, and then we'll pivot into it a little bit, is that there's a huge difference within companies around customer facing PMs that own a very bounded surface area of the company. So to give you an example, I was at Zendesk, you know, and there's the PM of the search experience in the upper nav and a PM would come to work every day and a group of people and think about that part. And then you had product managers who would step up a level from that and they would think about the agent experience. Okay, so what's the agent experience? So the funny thing, and probably a lot of people can relate to this, if you're in the product world at Zendesk, it'd be funny. You'd be working on your surface area and suddenly someone else's thing would pop up on your surface area. And you'd have to think, why did that thing pop up right there?
- [34:08]
B
What's an example of that? I don't even know what you mean.
- [34:10]
A
By surface area, for example, would be like you're an agent and you have your ticket management screen where you have to go in and knock out tickets and there might be some nav that has items related to different inputs into that. For example, if you get a text message versus a voice call and you could imagine that the voice call team would suddenly one day throw some new little badge or notification on your screen or would be trying to promote their product. You know, you'd see one of these little pop ups, like new feature right here. And the agent experience team would be like, that literally covers the most important information on this page. Why did you put that there? Oh, this other team would say, well, I don't know, we just use the defaults for the modal for things. We decided to start with a 5% of customers. Maybe it's not so bad. Why are you freaking out? There's all these types of things. And so my point is I never see this in black and white when it comes to it. I do see this as a spectrum. And you see product managers who are sitting there with a very narrow job to be done. A very back to your bouquets thing. It's only like one type of flower. It's only a flower used for weddings. It's only the post wedding flower experience only involves cleaning it up one way. No one's going to take the flower and sprinkle the petals into the creek afterwards. There's not a lot of dimensionality, there's not a lot of extra things going on with it. And then there's these things in companies that are much more integrated, they're much more holistic, they have just a lot more tendrils reaching out into all kinds of things. And so I think this is where product management itself attracts people who, I'm going to be honest here, are sometimes pretty short sighted. A lot of the product managers I know are like heat seeking missiles. You give them an area, you call their team independent, you give them a goal and they're going to go like crazy to achieve that goal. To use Alex's ideas. We're not talking gardeners here. We're not talking gardeners. We're talking literally olive vine specialists. Just want the olive vine to go up, whatever the wall or something.
- [36:21]
B
Little context. That's Alex Komorowski, who I'm also going to ask these questions and I'd say he speaks of gardening. The alternative is not the vine. The alternative is I'm building a house with two by fours. Yeah, it's not organic at all. It's not growing. I'm just making it a static thing.
- [36:38]
A
So it is a spectrum within companies and it's obviously different styles of thinking. I'm doing a talk at a service design conference coming up in December and one of the big topics there is service designers as a general category of human beings think really broadly. You're much more likely to hear a service design person talk about the back office and then the people involved in the back office and then the employee experience about why they're walking into the the back office and then the incentives of the community that they're surrounded in is why they're walking into the back office. And so maybe I was like a closet service designer this whole time because there are thinking styles and skill sets that seem to promote people in a certain direction. I think the limits of the product analogy, and it's not about how you're using the word product, is at a certain part. I think I wrote in 2018 that most software as service companies are service ecologies. They're not like a bunch of products. They're literally a value network. They're more like a value network or ecosystem. I wrote that because I noticed that in a lot of this dominant product led thinking, this kind of push, push, grow, grow small team stuff was actually moving us in the industry to a point where we were over pivoting on that type of thinking and under pivoting on what is the end to end experience of this look like. And I'll give you a great example and wow, the name is escaping me now, but maybe we'll in the notes I'll figure out who this was. When I worked at toast, there was an amazing researcher, UX researcher, and she did a whole study with her team on what an outage experience looks like at TOAST from the perspective of human beings in restaurants, from the customers of the restaurant to the employees of the restaurant to the people on on call rotation from our support staff. And it just blew my mind. And I would say one thing is that the executives in attendance knew that they were watching, they were watching a Mozart level performance. There was an awareness that someone had unraveled a layer of thinking into this that most people did not have. Her and her team just knocked it out of the park, like life changing for anyone who had been in that room. To think about how companies operate to do that. Dealing with an outage is as much about the fatigue of your team as it is about the human being in the restaurant waiting for their dish to show up because now your POS system can't access the Internet. And so I think that's where the product analogy starts to get difficult. I remember at Amplitude we were involved very much in this sort of product led growth movement. And a certain part I started to just say something like they would say, well, what does product led mean to you? And more and more my thinking started to evolve. I started to say using design data and technology to create sources of differentiated and sustainable growth that benefit customers, the company and the teams. That was my line. That's what I evolved. And I had to say it every single day because that's what I came to believe. That design, data and technology, service design, behavioral science, behavior design, there's a huge organizational development, organizational psychology, all these things are tools in this tool chest. The company is as much the product as the product is the product. And now maybe most product managers would say, John, you've gone off the deep end. But after thinking about this a lot, that's the conclusion I came to.
- [40:10]
B
Here's what I just heard about there and I really think this is right, which is that when I use the word work as a product, which I say a lot, I'm going to say what I really mean. I'm going to say work is a thing that we should consciously design the experience of and we should invest in it. I got to say that I recognize that the word product is a lot too concrete, it's too physical and lends itself to carpentry, not gardening the word. So I just wrote a paper that's coming out next year in a book that I wrote with two service designers, Connor Brewer now at Google, and Ali Hatfield at the University of Toronto. And it seems more fit for purpose. And it seems more fit for purpose in part because it's this idea that the way we are going to deliver an experience is going to be distributed throughout the entire company. And it's something that it will manifest as experiences. And besides that, it's going to be completely just sort of woven in to how the whole place operates. So it may be that despite just having published a Harvard Business Review article that said work as a product, that I might have to modify that language.
- [41:29]
A
Well, I think it's also, I'm noticing out here in the industry as well, I actually have a ton of respect for Marty Kagan and what he's doing is that he's read the tea leaves properly. With a lot of companies, especially outside of the United States, it's a ladder of thinking that goes along with this type of stuff, these companies. I have this funny chart that I do called the way of ways. And the Way of Ways just says that all the ways just go through this complete cycle. You know, you start with emergent ideas and then you have the first conference. And then by the end of the ways, there's all big five consulting offerings. We'll share it with folks. I have a post called the way of ways that people might like. But I think what's interesting is that we almost need to just surf ideas while they're happening because they're at the right point in the way of ways. And I noticed this at amplitude, where I would talk to companies that are operating like it's 2004 and companies that were trying to operate like they were 20, 30. And that's the nature of tech at the moment. There's probably a 20 year plus difference or 25 year plus difference, depending on the sector or what they're doing. So I used to get into these kind of semantic debates with people about product, but I realized that in a lot of companies this happens in the platform space. There was a heavy push to call in all the sort of DevOps communities. You would see these talks at conferences called how to blank as a product or how to think of your thing as a product. Now, people who are further along were like, yeah, but yes, I get it. But the people who weren't further along, it's actually kind of funny. I mean, a lot of them were like, oh wait, we just call our thing a product and we get budget. That's amazing. This is wonderful. But it was a useful container for thinking. And so for that group of people, for example, I hated calling my internal employees who use the platform that I was working on. I hated calling them customers because I thought to myself, we're partners. We're partners in this because I want to hold the customer outside the building as I want to know what that word means in my head, that's the customer, your partners. But then I started to learn from these other folks working in big companies that if an HR team started to call their team's customers, or if a platform product decided to think of their users or their internal partners as customers, it was a very, very important step for them to do that. And so I think that it's like surfing where companies are at at the moment.
- [43:48]
B
That makes sense to me. Working in hr, I always called internal customers clients. The only customers were outside of hr. A part of my argument is that employees are not inside your company. They are outside in the sense that they get to choose every day and every hour whether or not they're going to subscribe to your product. And so the idea that they're inside.
- [44:10]
A
Yeah, that's a great challenge for me. I love that. That's going to stick with me all day. That's great.
- [44:15]
B
Yeah, it's like a Zen cannon. If you ever want to get a whole room of HR people to pause.
- [44:22]
A
Yeah.
- [44:23]
B
It's to say, why do we say employees are inside? Why do we say that? Is it because we own them? Is it because they don't have choice? They do. And so, yeah, that is definitely a part of this philosophy is to think that employees are not inside. I'll tell you what HR organizations are doing. That is a mistake, in my opinion, which is that HR organizations have adopted the product language and they are applying it to HR services. I don't think that's a bad idea, except that nobody ever hired their job to give them a better benefits portal. You hire your job to give you great work. And so there's a fair number of HR organizations that I talk to where they say, we're already doing that. We've already organized into product groups and we're already thinking about product, but the product that they're thinking about is HR services, not the product of work itself. And so the truth is there's nobody really who is thinking about the product of work. And so I have friends who are selling software that is designed to improve work. They don't have anybody to sell it to because there's nobody in the company who's actually responsible for that thing.
- [45:42]
A
But this exact same dynamic is happening in companies too, about their customer facing things and even in the language around products. And I'll give you an example of that. I have this funny story and it might relate to people doing this. So there are these folks called enterprise architects. They've been doing what they've been doing now for 20 or 30 years or longer. And they have the most interesting definitions of things like capabilities. They'll talk about capabilities, there's dynamic capabilities, there's sort of operational capabilities, there's all kinds of things. And one thing that I think is funny is even in their community there's debate about at what level and resolution you're going to think about capabilities. You know, so when I think about a capability, I'm an absolute purist. I'm saying my definition of a capability is that we will be talking about the exact same capability in 20 years. That's the starting point. Let's go to the top of the chain at the moment and then someone goes down one level and they'll give the next version of the capability. A great example of this is I was doing a workshop for a large bank. We did a live pitch demo. And so someone pitched to me this thing and they said, a single centralized source of all the customer data, 365 degree view of the data. And I started to poke for fun at them just to show what I mean. I was like, what if we can get the same value with 365 views of the data instead of a 365 degree view of the data? They're like, I don't quite understand what it means. And then I said, well, why do we need to centralize the data? Do we really need to centralize the data? And I kept pushing on it these things like who uses this data? So by the end of the conversation we had sort of pushed up, we nudged up, we punched up to something in the 10 to 20 year category and he was able to fit his things underneath. And I see these a lot in the enterprise architecture. Someone's like, well we have to streaming data, that's the capability. And then someone will say, well why? Why do you need the streaming data? What's the capability? So the idea of this flat capability model and a great example of that, just so people know what we're talking about, is take something like Zendesk. At a certain point, you know, the goal is to help someone out in the world enjoy a product that they've purchased. Now we could talk about the agent experience as much as we want, but at a certain point, what if the agent isn't needed? What's the job to be done here? Why isn't there a robot out there fixing the person's product? Why do we need to help a company help their customers when they could just give us a script and then an LLM could go out and help out the person's things to do it? So that's like a common example of, I think that as organizations mature, there's this starting point where it feels comfortable enough to them and understandable enough to leadership and is not super abstract. And then as they deepen their knowledge of what they're doing, as they think about it more, they punch up. And I think that as they punch up you start to see more creativity. I also think that realistically you can punch up as high as you want and in every deck you have you can show that that punched up job to be done or capability. A lot of the work that happens in the day to day doesn't exist at that level. It's like, well, what are you going to do next quarter? What are you going to do this thing? So realistically, it takes a lot of stubbornness to begin every presentation with. And let me remind you what will be true in 20 years that is true today, that takes a lot of stubbornness. You don't get your raise for doing that.
- [48:58]
B
Yeah. And by the way, I come out of enterprise architecture, but not the physical layer. I was the operations layer. So I was an OVU business architect. And we live at a level of abstraction that what I always say is that we build models of how the company works end to end using operations. And that model, if you were describing a mouse, would be the exact same model as for an elephant except for some capabilities around the nose.
- [49:25]
A
Yeah, I love that.
- [49:26]
B
Yeah, that's because elephants can pick up straw with their nose and mice can't. And if you look at, well this was say 10 years ago, five years ago, if you looked at Apple and Google, you might see that they're actually the same animal except for that retail capability that Apple had, which Google didn't have. And so I like this idea of punching up in level of abstraction and how especially with a young idea, we might have to use ideas that are less abstract because they are legible. And so saying product for work might be more legible than saying transformation offering or something.
- [50:07]
A
You know, Matt Skelton and Manuel Police have this team topologies thing. I was doing this before, I think I read it in the book or I forget how our ideas. We were chatting a lot before then, but was this sort of as a service framing? And I'm just giving this as a joke because I was involved in software as a service. So an easy way to communicate capabilities was the X as a service idea. Anyone in the company would understand that game. You know, let's just say you're meeting with a team and they say it's onboarding as a service. Employee onboarding as a service. Ah, interesting. Okay, maybe that would be a feature in what product? What's the next level up from that? Someone would just be like, oh, we're the time to efficacy as a service. Oh, that's a little businessy. I get what that means for the business. But how does. Are you talking about efficacy from the standpoint of the person? Oh, okay. Maybe these are two services that actually relate to an even higher level thing. There's time to comfortable the person has actually onboard and is in. We're doing their job. But then from the employee experience side of it is time to feeling somewhat sane in this new place. Ah, okay, so what's the capability above that? And you're from your background, you're highly experienced, moving up and down that stack. One thing that's interesting is that a lot of people are not practiced at it, but they're perfectly capable of doing it. So I used to do an activity at amplitude. We would build these basically capability graphs about different things. And it was funny, I was called it my 2000 Jira ticket game. So if they were having trouble deciding on their strategy, I would say, your strategy's on the floor. And they would say, what do you mean the strategy's on the floor? And I'd say, let's print out 2000 Jira tickets and put them on the floor. They're like, what the hell are you doing? Put the JIRA tickets on the floor. And then I'd start at the first one and I'd say, well, if we're successful at this, what do we hope to increase or decrease this? And then if we're successful at that, what will we increase or decrease this? This. Okay, next ticket, next ticket, next ticket, next ticket, next ticket. And before you know it, within 30 minutes, the basic clusters were formed of everything. And I said, you know, you're having trouble deciding your strategy. Don't make up a new strategy. Your strategy is on the floor. It's right here. This is the work that you're doing. And so I think no one was incapable of Doing that thinking. In fact, once you got them on the habit, they were just zoom, zoom, zoom, zoom, zoom, doing it. But it was not a practiced activity for a lot of people.
- [52:33]
B
Jira tickets are customer tickets.
- [52:35]
A
Yeah. It's a ticketing tool made by Atlassian. And they're tasks essentially that developers are going to take the task and work on the thing.
- [52:44]
B
I see, I see. Got it. It's really interesting. The Greeks had a different sense of causation. They had a vocabulary for causation. And the material cause of a boat was wood. And the efficient cause of a boat was a carpenter. But the telos was what it was for. For an animal, the cause of teeth is chewing. The cause of a boat is floating. And so what they were talking about was that, especially in biology, that things have been created for purpose. And there's a way in which what you're talking about is that level of a company which is. Let's talk about this. Exists for the sake of what I'll tell you how many people will have heard this conversation. Many of the people who stopped listening 30 minutes ago, which is they're looking for practical solutions and have a very low tolerance for complexity. And so tolerance for that complexity, if it's on the path to product that paying customers are going to create is going to be higher. Then the tolerance of that complexity, if it's on the path to something that they're not sure that they really believe in, which is that employs our customers. And so I don't know what to do about that. It does seem to me, though, that there might be a set of simplified characteristics of the service design mindset that you would want to introduce into managers who are particularly in this role that we're talking about of creating work experience. And it can't be the whole complexity of what we were just talking about because we can't possibly communicate that to them. Can you think of something like that that we would distribute to lots of people in the company that could instill the right mindset?
- [54:58]
A
Yeah. I've been thinking about this a lot. I have this mental model I've been playing around with that actually kind of relates exactly to this. And I call it the justs and the buts and the cans and the justers in your company are like, well, we just need to do this. We just need to keep it simple. We just need to get them in the door. And then the butters are like, but have you thought of this? But have you thought of the third layer of the service blueprint? Have you thought about the Santa Barbara community. Have you thought about the ecosystem, of what it means to be doing retros on the beach? But, but, but, but, but, but, but, but. And I've been thinking that there is the third way, and the third way to me is the canners. What can we do that is not vastly oversimplifying the situation to the point where we're going to struggle because of it, and yet at the same time is not getting lost in like a sort of endless exploration of every single edge case. And not even just edge cases, just the sheer complexity of the situation that you're doing it. So I'm thinking that there's these canners, right? And this is my big personal challenge too, because it's easy to make fun of the gestures, it's always easy to have more buts. But it's really hard to say what can we do? And I'll use an example. I was talking to an enterprise architect in the last week. She believed that the company's direction at the moment was not going to end well for anyone. Yet at the same time, the CTO wanted something simple because they believed we do have to make revenue right now. We have to have something that's legible that the team could understand. And she was in these meetings begging for this epistemic justice. You know, she was begging for this idea that the CTO would go down the rabbit hole with her and understand things in all their complex glory. And I was having to explain to her, and I said, look, and this is just to get really swarmy product manager on this at the moment. I was like, did you just go in and just say, look, there are three factors impacting this situation. The push for profitability, our long term goals, this and this. Here's what we know and don't know about the situation. One, we don't know this. Two, we don't know that. Three things. What have we tried? We've tried this. How did that go? It didn't go all that well. My proposal is this, because I think ultimately our company wants this. Can't we all agree this is what product managers, we live and breathe that I'm joking about it, but we're good at Shark Tank. We're good at that stuff. And I can flip that switch if I need to, although I don't flip it a lot. It's kind of fun to flip that switch. But she was struggling to get here. So the first thing that came to mind is there's two Personas here. One is the person who goes down the Rabbit hole and then needs to be able to present something that's more legible. And then there's folks who I think are just generally curious about making progress in their organization. They dip into these ideas. My partner used to head up an operational effectiveness, the top HR function of her company. I was sitting there with her with capabilities and she was having to juggle in her mind. I know what you mean, John. That's not the language that's going to resonate. What do we do? I know we should have our capabilities organizationally and then layer in our employee competencies. I know we should separate and link these two models, but there's a strong desire to have a leadership development path across the whole company. Capabilities are making it too complex. So she's not a juster, but she's not a butter as well. She's just wondering, what can we do, John? Like I get you. I get you what we should do. And so here's some practical things that I can think of. First, you have to have a proposal. And by that I mean I rail against bringing solutions, not problems. And I think that it's bad for a manager to sit there and say, come back when you've got a solution to the problem. But I do think that there is a skill of embracing the complexity of the situation and having some proposal about how atoms might move in the next couple months. What is that thing? And to give you an example, another concrete example, there is a company called Cynefin Company. They make a product called Sense Maker, which is a really interesting tool for capturing the stories of an organization. I think it is by far a much more effective way to understand the spirit and what's going on in a company than an engagement survey. Yet it has triads, it has cluster diagrams, it asks the people to self assign their stories themselves before they are interpreted by a manager. Okay. And it's kind of funny. I've been running a sense maker for something that's completely different from this conversation, mostly around the experience of tech. At the moment, I'm running this Sense Maker with Tom Kerwin, who's a fellow explorer with this stuff. And we've just been noting how funny it is that what would the proposal be for Sense Maker? You're sitting there in front of an executive and you're like, is it. Do not do the engagement survey this year. Do this instead. Do not rush to interpret all the qualitative feedback yourself. Let people engage with the feedback anonymously and do it. Okay, now we're in a different ball game. That is A very hard conversation. Once you actually make the proposal of what we would think would happen if you were to do that internally in a company, company, it gets to be a lot harder. So I think that the one thing is you have to be ready to make a proposal. You can be as complexity, as aware as you want for your proposal, but you have to be able to describe how you will move atoms. Something will happen as you're doing it.
- [60:24]
B
Part of what you're saying is the gestures are too simple. The buts are infinite and good to be aware of, but they will absolutely get in the way of doing anything if you go too far with them. The cans are. What's the first step? I recognize the complexity of our future path. So I'm not just a gester, I'm a canner. Which is, sure, it's complex. What can we do? And then the trick is you can be aware of all the complexity. But when you're pitching it, be a canner, right? Or maybe adjuster. The difference between adjustments and a can, it seems to me the digest says we'll just do this and then we're done. But the can says, we're going to do this first and there's more to do.
- [61:08]
A
Yeah, exactly. And it's kind of building off of this is to think about it like, I've been having this idea lately of, okay, the next one. I have to start with a story. I played music a lot. I was involved in bands and we would tour around and we would make records and we'd do things. Now within the boundary of a band is beautiful complexity. It's wonderful. It's not a bad word. If you asked me to describe how to make a record, I would say, whoa, it depends. I mean, it depends on the thing. I would butt you all day, but what have you thought of this? Or, but of this. Now I could easily say, you just gotta get some talented musicians in the room and they're gonna do great things. I could do that, or I could go budding all the way, or I could do this thing. And so one of the things that I think that people who are complexity aware fall into the trap. They don't realize that most people out there in the world believe that complexity is universally bad. And their only experience with complexity is a huge wall of stickies that looks like no one could make any progress. Or the person saying, but the employee experience is a lot more complex than that. And I think what you need to be aware is that there's beautiful complexity that you can have. You need to be aware that there's only limited tolerance and capacity for anyone to go on that budding journey with you and arrive at the same cans and the same confidence in the things that you're doing. And I've had to learn this as someone who's just tied in this way and geared in this way. I've had to learn that. I've had to understand that that's the case to do it. And so there's a researcher, her name is Kat Hicks, and she studies developer experience and she had this great line. How funny is it that we try so desperately to simplify our work situations? Why don't we make our work situations easy to work on? The complex, challenging things that we have to work on. It's one of those quotes in the last two years has had the biggest impact on me. I even remember the quote, which it's something like it behooves me as a psychologist to say that humans are actually very adept at working at complexity. We're very adept at working within these boundaries and having these dynamic experiences to be able to do this. So the reason why I'm saying that is when the enterprise architect says it's super, super complex, or the employee experience person says it's super complex end to end, they are falling into their own trap of a God view of complexity. They're falling into their own. It's called the as is trap. We believe a system to be as is something. Ralph Stacey has this idea of the as is trap, which is you see a complex system and you're seeing population level effects, and you see it as if it's a brain. Sorry, it's as if. As if it's a brain. As if it's a bunch of stickies. As if it's a bunch of things when there's all these vibrant, beautiful interactions happening at the human level all the time. But we fool ourselves into thinking our own models are what they are. So I'm saying this speaking directly to the people who might. And then we'll get to the people who are on the other end, who maybe are the listeners of your podcast. There's maybe if you're coaching the complexity thinkers within your company, you need to coach them in this direction that we fall in love with our models and we fall in love with how we view these things and we relish the complexity of it and describing it. That's not how beautiful complexity works. Beautiful complexity is local and is bounded and is vibrant and emerges. And we can't plan it all out to do those things. And so I think that there's something really profound that I've had to come to grips with with all that. If you're a change agent in these situations about how you communicate about complexity, how you communicate about the benefits of it, realizing that your average fellow employee sees complexity equals bad to be avoided. That's the second one I'll give out there. If you're in the systems thinking ilk, you have to know that you are part of the problem. And I've had to realize I'm part of the problem with all this.
- [65:06]
B
Right. I'll tell you what I was thinking of when I was thinking of simple attributes that managers might acquire. The ability to empathize with employees. Take some practice, might be learnable, might not be learnable, but it's the sort of thing that you would want or agency. Now, this is actually something that I think is really important for product managers in general. And I think that the butters you were just talking about are examples of, no, we don't have agency. The agency issue is you want me to design the experience of work for employees. I don't have any degrees of freedom to do that. What is the nature of the agentic mindset for product managers? Good ones? Are they highly agentic? I mean, they kind of have to be. It's hard for me to imagine a product manager saying, oh, we can't do anything.
- [65:55]
A
You know, one thing that's interesting to me is I look at people who are drawn to product management and they often come from some different categories or let's say, just different influences. Of course, people are really messy and they might have all of these influences coming. So myself, I was this creative maker, lover of being on teams. The idea that I'm with a group of people that are problem solving together and this little merry band, in a sense, almost literally, and that we were able to make something that was not there now there, and people out there in the world would use it. I started my career as I had a video game company and I made this game. And to know that people were using it and that I was with this merry band of kooky people making this thing was the best possible thing that could happen in my life. I loved that. Now, what's interesting too is that some people are drawn to product management because they want to have a lot of impact in the world. That's like another thing. But there's some other groups. There's folks that are highly entrepreneurial. There's folks who maybe wandered in from business school. They Just generally like business. And this is a very sort of actionable way to be involved in business. There's other people who were designers but then realized that they couldn't have as much agency as they wanted as a designer, so they became a product manager. They do these things. So the reason why I'm mentioning that is that I do think that there are some kind of traits around either entrepreneurialism or collective problem solving or this messy problem solving mentality that people like about growing something, about making something that exists that doesn't exist before. There are some traits involved. And I do see that among product managers there is a diverse set of traits though. So sometimes the product manager who wandered in from business school, who's never been a designer and never been a developer before, they're actually really, really good at running the sort of McKinsey slide playbook. And they know how to describe a strategy really well and know how to present really well and be very persuasive. But they're much more likely to keep asking developers, is it done yet? Is it done yet? Is it done yet? Whereas the maker person is going to know, don't waste the time saying to the developer, is it done yet? Is it done yet? Is it done yet? You have to negotiate in other ways. I think that for folks who are trying to like, adopt, there is this whole idea of product sense or product thinking. And the way that I've boiled this down in the past is I would boil it into a couple categories. The first thing is disciplined and intentional problem solving. And this sounds like, well, isn't that all of work? Well, yes, but you're doing it in an environment that has inherent uncertainty. You're doing it where you're collaborating cross functionally with other people. You're doing it where you never have all the information you need. You're doing it in an environment that spans time, where the things you do today will impact the things that happen in the company three years from now. There's a nice cake of time that you're doing things. So really that is one of those skills. And that product sense thing is you have to be a disciplined problem solver in conditions of uncertainty. And there's a whole skill set involved that. And as a joke, you should see me planning vacations. You know, I'm kind of like, well, what are the three drivers here? What are their constraints? What are the floats? What are we ultimately trying to do here? There's a whole set of things that go into it. So that would be one area you could build Those particular skills in diverse situations.
- [69:24]
B
And in fact, it's a fairly complex sentence that you just said. Disciplined and intentional problem solving. So for instance, the problem being solved is an outcome related thing. It's, you need to be focused on where you're going, which you were just talking about with the travel. Disciplined means something intentional around what the problem really is that you're working on. Which is, by the way, why job to be done theory has been so central to this discipline is because that is one way to anchor your intention.
- [69:54]
A
Yeah, and I think that that's the. You know, it's funny, we just experienced an election. We won't go into that, but talking to my product manager friends, you know, it's like we're going off of different parts of the problem. And the positioning, the thing and, you know, going down this one rabbit hole. It's actually somewhat different than the conversation I'm having with my designer friends. Usually within the conversation with my product manager friends, 30 seconds after it being, you know, whatever, we're sort of processing the information. It's jumping into it. You know, it's sort of jumping into this. I had a friend who was very, very negatively affected by this election. And even him, within 30 seconds he's like, well, what did you think about the positioning? What did you have that is this? And I'm like, oh my God, there's been a huge election. Let's not jump into product yet. Let's not talk about this thing anyway. Yeah, so there's something wired in about this kind of problem solving thing. I think that the other skill or competency or thing to encourage in folks is I'm going to just zero in on the collaborative aspect of it, which is you are in the thick of it and you need to be able to develop empathy for understanding. You need to sort of understand how people think in certain situations and respond to collaboration in ways that maybe other people won't necessarily have to do that. And so, funny example, I remember working somewhere as product manager and we had a rule that if your headphones were on, you can't annoy a developer. And the developer on the team had a rear view mirror installed on his monitor. When he saw me approaching, he would immediately put on his headphones as if that wasn't super obvious that you were doing that. Now me, I was like, that's the funniest shit ever. Fair play, my friend. We're going to go that.
- [71:41]
B
Now.
- [71:41]
A
If you didn't know that, let's say you're just walking in some environment and you're like, I don't know. This person just literally installed a rearview mirror. And I started to walk towards them and then they just shut me. It was so obvious. That's an insult. How would they do that? Amy Edmondson has that professional culture clash in that great TED talk she gives about Chilean mine workers and lawyers. And so you have to be able to navigate professional culture clash really, really well. Otherwise you're not going to be very successful as a product manager. And so, you know, if these things are relevant for what you're talking about, great. If not, we can get through these. That's the second thing that I realize. I think that the third challenge that product managers face, especially in software, because I know product managers in consumer goods, in other spaces that are more stable, and in those stable environments, you know, it's more of a business role. Like, you've got P and L. You're going to do this segment of shoes or segments of whatever. It's kind of a business role. You're owning this. There's more ownership. Thing is that in most, at least in software, you're not fully owning this thing. There's other people involved. It is this sort of influence without authority in many cases. But you're juggling the authority you do have and the influence that you have. You're asking people to invest. I always say, how terrifying it is as a product manager that you're asking other humans to invest large swaths of their professional career in something that was so hard for me to accept initially, where I thought, oh, my God, this person's going to look back over the last 10 years of their career and say, yeah, 2022, that was the year Cutler dreamed up the crazy platform strategy. Like, that's 1 20th or 1 30th or 1 40th of maybe their active career you're responsible for. Right. And so I think that there's that element of coming to grips with the authority you have and the influence you have and the influence you have over the lives of other people that you're working with, that can be difficult. Back to my different types of PMs, though. I've noticed, for example, people who haven't had maybe arts backgrounds or other things where they were wired into work with other people. Don't think about that as much as an MBA goes in and says, well, that's why you signed up, right? That's why you signed up for this, for me to run this business and stuff. And so I think it's just interesting, depending on your background, you're going to have different perspectives on that, on what I just said.
- [74:04]
B
That's a very interesting thing because I do think that there's a little bit of the builder gardener difference in distinction that you were just talking about people with an arts background. It's very interesting. Most of the product managers I know well, most of the ones I know come out of the software world well, it's partially because where I work it's required for you to have a coding background. But also you mentioned something that I think is going to be an attribute that I really need to consider is that if a people manager is a product manager. I don't like the word people manager. Team manager is a slightly better. If a team leader is a product manager of the experience of work, that influencing the environment is a big part of what they are responsible for. And what's interesting about that is that it's very easy to think. No, the thing that I'm influencing is if you're my employee and I'm working on your experience of work, it's something between us. But no, because there's this universe, policy and habit and things like that that you might need to go out and change.
- [75:12]
A
It's just fascinating. Now I'm thinking about the differences between, in my mind, between manager, product manager, designer, in this particular case. Now my head's really spinning thinking about it because I do think there is a skill set around design that is investing a lot more mental calories in certain ideas, certain aspects of the connectiveness of what you're doing or the effects of what you're doing. My analogy here is thinking about the difference between someone who's designing an open space in a city and the business manager of that effort and what they're doing. And I do wonder, sometimes it's just too much for one role. I do think that this is a case where we're talking about. It's funny, this product thinking thing too. I have to remind people I'm not talking about product management thinking. This is something that's distributed on the team because it's a lot to fit in your head. It's like a shitload to fit in your head. And so I think that there is an element in some. We desperately want these super all rounder, business minded, entrepreneurial minded, maker minded, this minded, thus whatever it can get everything. I think that's also why you tend to see engineers fall into that role because it's similar to the Toyota chief engineer role in the Toyota production system where they spearheaded the idea that you would have one head of this whole unit. And they were the person who was out meeting customers in the United States before introducing Toyota, driving with families, and could go head to head with any engineer on the team about how to build a car and understood the business realities of trying to put a car into production. And I think ultimately they needed in many cases to come from the engineering background because that almost by default built you a level of empathy and understanding with the people that were going to do a lot of the work. Similar to. There was a CEO of Ford who had originally been at Boeing and at Boeing. He rose through the ranks because he was from an engineer from the ranks. And that's how he was able to successfully navigate that environment to do it. And so this is part of why I named my newsletter the Beautiful Mess. Because this idea that it is really just a funky mix of skills that we're putting in here and the idea that you kind of need it all in these cases. That Toyota example is one where companies have tried to emulate that and realized that there was something just so unique about the culture at Toyota and the product that lent itself to that. The CEO of Nvidia 61 direct reports or whatever, that's an example of maybe just the confluence of factors that make those things possible. But the rest of the world operating is navigating a much more interesting blend of skills and responsibilities. So you got me thinking there about design versus product, management versus management, where I mean even management. The difference I see in tech orgs between manager as promotion organizer, promotion driven development. You have a manager, they negotiate with the PM together. You decide what needs to be done. Then the engineering manager hands out the projects to people. Funnily enough, during promo season, all the projects get done and everyone writes about them. That's really amazing. And through that back to your thing as company is a product. That is the thing. That's the motion in those environments. Oh, pair programming, never do it. You can't understand who gets the credit on the project if you pair program. No, no, no, no, no, no. This is a give an engineer a project and get out of the way culture. An engineering manager is your broker, is your promotion broker. That's such a different environment from an environment of oh, we're going to write the perf requirements on team impact. Manager is the manager of the team predominantly and the individuals and they're caring for it. PM at that point does not write up a pristine prd. Just as back topic, we talked about writing product requirements documents in my research. The reason why the PRD process exists in many companies is not because you need PRDs, it's literally the brokering mechanism. It's so that the engineering manager can look over the PRD and say, who will I give this to? Is this going to be worthy of the team to be able to do it? And contrast that with appfolio. When I was working there, we didn't do any of that documentation shit. We didn't do any of that stuff. You didn't need that stuff. We would do co design sessions with the team and customers. We would evolve the design. It would evolve much more organically. There's so much stuff related to this. You get me thinking about manager, product manager and then designer as these sort of archetypes. Right.
- [79:45]
B
What's interesting about that is that your product was the product on that team as opposed to promotion as the product. And also what you're making me think is that we can't give traditional managers this additional objective without reducing their cognitive load someplace else. And my proposal is that the way we reduce the cognitive load is say, you know what? You don't have to be a controller of an asset anymore. We're not going to have you do that. You're going to be a gardener of an experience. It means you get to step out of the way of being the bottleneck, the cognitive bottleneck in terms of who's doing what. You give more agency to the team and you become much more of a gardener. So I'm going to go to my closing questions that I always ask. I don't know if you've ever made it to the end of one of my shows. At the end of every episode I ask, what do you, John, hire your job to do for you?
- [80:39]
A
Wow, that's going to be heavy because I've been thinking about it a lot lately. As I mentioned earlier, the Mary Band idea, for me, it really is safe community. I want to be a citizen of something. And this is has gotten me into trouble in the past if I don't believe in what I'm a citizen of or whatever. I want to be a participant in a community of people who's passionately solving these problems and having fun. And I wrote about that recently. I had this post about just fun product. As naive as it sounds, it just pains me that people are sort of doing their TPS reports and sitting, not having fun doing this. I'm one of those people who's, how much better could it possibly get than this? This is so cool. This is technology. We're making stuff for people out in the world we're having fun doing it doesn't get any better than this if we can create those conditions. That's when I'm in it, you know, like in it to win it in those particular things. And so I think that that's the job, that's the milkshake that I'm drinking in my car.
- [81:51]
B
And you said some of that earlier, which is that creative teams coming together, Mary band getting something done together, putting it out in the world, seeing it land. And I would imagine you felt very much the same making music.
- [82:04]
A
Yeah, and it's interesting because I do have this real interest in what I would call. I don't know how to talk about like service design influenced complexity, influenced systems thinking, influenced operations. I had a role as senior director of product enablement. So it's this idea of this sort of operations type role. One thing I realized is that the idea that my customers, the people internally, my partners or whatever, it was so natural of an idea that that was a product and that I could treat it exactly the same as a product in theory. But what I learned about that is that the operations mindset for a lot of people in a lot of companies is much more suited to either marketing, operations, sales, operations, finance and operations or other things. So a lot of the tool chest I brought to it and the reason I'm bringing out is it sounds like I'm talking, you know, just give me a merry band and I'm on my way. But I do think you can scale this way of thinking. The idea that it's a leadership as a platform or information and decision support as a platform or any of those. I do think you can scale it across a company. I think that the limiter in many cases is it involves a tool chest when you're talking about this type of work and a level of support that's often not immediately granted in those settings. It's tougher than one thinks about bringing those skills to this.
- [83:30]
B
What does your job cost you?
- [83:32]
A
Oh, what did it cost me? Yeah, colonoscopy. I had to pay for that. I was feeling really sick. Sorry, that's rude, but it's true.
- [83:44]
B
Many of our jobs feel.
- [83:47]
A
Yeah, it costs me the colonoscopy. I do think that we sort of have a limited especially I have a six year old and family. There's only so many chips on the table to put the sort of passion and thinking into. I'm thinking about my career. You don't know in advance, but a lot of times you invest a lot of passion in those things. And really, it's kind of on fairly low leverage things. In retrospect, you look at it, and that was a lesson I've learned. It's actually some tip that I think anyone can use is you're sitting in that meeting, you're about to play that card, and you're about to invest a lot of emotional energy in something and it's risky. Definitely project yourself forward 12 months from now and say, is there any chance in hell that showing this thinking or these stickies or this type of thinking at this moment will have really altered the course of things? Is this the best bet I could play with my emotional energy to do those things? So back to the cost again. As a product manager, we can place our energy in lots of places. Some of it has high leverage, some of it has low leverage, Some of it has negative leverage. That's the kind of. Maybe from the employee side of the equation. I think folks need to think about is what's the leverage of the passion that you're putting into it. But I think from the employer angle, it's interesting. Whereas, are you even giving the employees in your company the situational awareness and the feedback loops or any of the support to even make logical decisions about where they're putting their energy? So the number of times I see a passionate change agent walking into the meeting and basically butchering themselves forever, removing any chance of a promo forever doing this, because they didn't even have the information to know what is acceptable or not in that company. No one had bothered even describing it roughly. Here. We do not do that. When you have that type of presentation, you have to work through the chain. And they walk in the end of their 90 days and walk into that meeting and they're just like, yeah. Yes. And like, oh, crap. So if you think about it from the HR angle, that's what I think about a lot, is, yeah, people make decisions about the leverage of their passion. I work in analytics company. Are you giving them the feedback loops and the situational awareness? Are you describing the strategy in a way that could be used by any person to make logical decisions? That's part of the platform.
- [86:08]
B
I think that's interesting. There's a lot of things in there. One of them is the cost of my job is sometimes my future career.
- [86:17]
A
Yeah.
- [86:18]
B
But also the idea that the cost is wasted time on things that didn't have the right effect. Because if what you hire your job to do for you is to put things into the world that are great for people. So sometimes the cost of your job is a lot of time that doesn't result in that. Where can people learn more about you and your work?
- [86:42]
A
Substack I have this substack called the Beautiful Mess. You could sign up there and I write about this stuff a lot. LinkedIn for now while I try to figure out. I mean I'm going to always be on LinkedIn, but it's actually a way to semi try to get in touch with me at the moment, although it's hard to keep track of anything on LinkedIn. That's good for now.
- [86:58]
B
Thank you so much for coming on the show on very short notice. By the way, thank you very much for coming on the show.
- [87:05]
A
Yeah, absolutely.
- [87:09]
B
Thanks for joining me for another episode of Work for Humans. If you enjoyed this episode, please give us a five star rating. Wherever you listen to podcasts and share the show with one person you think would get value from it, believe it or not, this really helps us grow the show and reach more people who want to build the kind of work that people really want. As always, thank you to my producer Jason Ames at 9th Path Audio for his insights into content and his high standard for quality. Final note, the opinions shared here are my own and not the views of Google or Cisco Systems. Thanks again for listening. See you next time.