wavePod

Applying Product Management Tools for a Better Employee Experience | John Cutler - Work For Humans | Wave AI Podcast Notes

Back to Work For Humans

Applying Product Management Tools for a Better Employee Experience | John Cutler

Work For Humans

Tue Dec 24 2024

Summary

Work For Humans: Applying Product Management Tools for a Better Employee Experience

Guest: John Cutler | Host: Dart Lindsley
Release Date: December 24, 2024

Episode Overview

This conversation explores how organizations can harness product management principles to rethink and redesign the employee experience as a "product." Host Dart Lindsley and guest John Cutler, a product leader and organizational thinker, discuss moving beyond rigid command-and-control management models towards a more agency-driven, service-oriented mindset. The episode navigates the complexities of scaling personalized work experiences, balancing the needs of the company and employees, and the nuanced challenges of designing organizations that people truly want to be a part of.

Key Discussion Points & Insights

1. Framing Work as a Product

Employees as Customers: Dart posits that, just like external customers, employees should be viewed as customers of the organization (02:19). Designing their experience should be as intentional as designing products for market.
Challenge of Personalization: Employees want unique combinations of “jobs to be done.” There’s “about a billion combinations” of what people want from work, making scaling personalization challenging (02:19-04:09).

“In reality, in the math and the physics of business, employees are customers... What people want from work is very different from person to person.” — Dart Lindsley (02:19)

2. Complexity, Scale, and Organizational Design

Relevant Dimensionality: John discusses how both product and organizational complexity grows as you add variety, leading to unsustainable models if unchecked (04:09-06:45).
Team Size Sweet Spot: John suggests optimal autonomous teams are around 30-50 people—“less than the Dunbar number” and with “two or three layers max of hierarchy” to keep autonomy and psychological safety (06:46).

“You can create an environment that is a better product for the employees...and potentially a better product for the company that is creating this ecosystem.” — John Cutler (06:45)

3. Lessons from B2B and B2C SaaS

Horizontal vs Vertical Products: Vertical products (focused on an industry) accrue complexity quickly; horizontals (spanning industries) still face hidden complexity due to varied use-cases and maturity (09:32-13:23).
Feature Bloat Trap: Stuffing all features into one product often leads to unusability and customer dissatisfaction (11:58).
Product Structure Shapes Org Structure: Early decisions about product direction (vertical/horizontal) “have far-reaching impact on your org design, the employee experience, what kind of org you need to build” (16:15).

“…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, [and] what kind of org you need to build..." — John Cutler (16:15)

4. Work as an Experience Offering, Not Just a Product

Service vs. Product: Work isn’t a reproducible good; it’s a context-dependent, mass-customized experience more akin to “bouquet assembling”—each arrangement unique, requiring managerial “hunter-gatherer” skills. (29:31-33:10)
Manager as Product Manager: Can every manager become a “product manager” of the employee experience? Dart wonders if this consciousness can be distributed at scale (33:10).

5. Real-World Stories: Santa Barbara’s AppFolio

Community as Product: John recalls AppFolio’s focus on creating an environment where employees stayed for years, grew professionally, and built deep customer empathy by visiting actual sites—a deliberate, thoughtful “product” for employees (21:30-26:42).
Context Matters: Attracting talent varies by region, company culture, and business model, sometimes requiring unique “marketing” just to attract employees to the company itself (26:42-29:31).

6. Product Management, Service Design, and the Limits of Analogy

Surface Area and Holism: PMs might own a narrow slice (“surface area”), or face broader, holistic challenges—much like managers with varying degrees of scope and agency (33:10-36:38).
Service Design Mindset: There’s a spectrum: some are laser-focused missile-style PMs, others (often service designers) view experience more organically and holistically (36:38-40:10).

“Most software as service companies are service ecologies. They’re not like a bunch of products. They’re literally a value network.” — John Cutler (38:00)

Language Evolution: Sometimes the language of “product” is useful for creating organizational focus, even if it’s not a perfect fit (41:28-43:48).

“We almost need to just surf ideas while they’re happening because they’re at the right point in the way of ways.” — John Cutler (41:28)

7. Organizational Capabilities, Levels of Abstraction, and Strategy

Punching Up in Abstraction: Strategic clarity often requires thinking at multiple levels—capabilities and “jobs to be done” nearly universal across firms, but tactical action is local and time-bound (45:42-50:06).
Practice and Tools: Most people can learn to connect daily tasks to larger goals if they have the right exercises and models (50:06).

8. The “Justs, Buts, and Cans” Model (54:57-61:08)

Gestures: Want overly simple solutions (“We just need to do X”).
Butters: Get bogged down by complexity and endless objections (“But what about Y?”).
Canners: Pragmatically acknowledge complexity but focus on the next actionable move.

“The ‘justers’ are too simple. The ‘butters’ are infinite... the ‘cans’ are, what’s the first step?” — Dart Lindsley (60:23)

Practical advice: Always arrive with a proposal. Recognize beautiful complexity; don’t be paralyzed or get stuck at either extreme.

9. Empathy and Agency in Management (65:06-75:11)

Empathy as a Core Skill: Essential for both product managers and managers designing experiences of work.
Agency: The best PMs see themselves as having degrees of freedom to shape experiences; managers need to see themselves as environment-shapers, not just enforcers.

“There is a skill set around design that is investing a lot more mental calories in certain ideas... the effects of what you’re doing.” — John Cutler (75:11)

Gardener vs. Controller: The future manager is a “gardener of experience,” stepping back from being a bottleneck and giving more agency to the team (79:44).

Notable Quotes & Moments

On Purposeful Work:
“I want to be a citizen of something... a participant in a community of people who's passionately solving these problems and having fun." — John Cutler (80:39)
Scaling Product Mindset:
“I do think you can scale this way of thinking... The limiter is that it involves a tool chest when you're talking about this type of work.” — John Cutler (82:03)
On Misapplied HR Product Thinking:
“Nobody ever hired their job to give them a better benefits portal. You hire your job to give you great work.” — Dart Lindsley (44:22)
Beautiful Complexity: “Beautiful complexity is local and is bounded and is vibrant and emerges. And we can't plan it all out.” — John Cutler (61:08)

Timestamps for Important Segments

Framing the Core Problem (02:19)
Scaling Complexity & Org Design (04:09–06:45)
Horizontal/Vertical Products & Feature Bloat (09:32–17:55)
Team Size and Autonomy (06:46)
Manager as Product Manager Discussion (29:31–33:10)
Spectrum of Product Management & Service Design (33:10–40:10)
Capabilities & Abstraction (45:42–50:06)
“Justs, Buts, and Cans” Framework (54:57–61:08)
Empathy, Agency, and the “Gardener” Manager (65:06–79:44)
Closing “Job to Be Done” Reflection (80:39)

Conclusion: Practical Takeaways

Intentional Design: The employee experience should be consciously designed and requires investment, not happenstance.
Mindset Shift: Transitioning managers into product/service designers of work calls for training, support, and a rethinking of their load and agency.
Complexity is Inevitable: Design for beautiful, bounded complexity, not sterile simplicity or paralysis by overthinking.
Scalable Mindset: Not every manager needs to become a PM, but adopting elements—empathy, agency, systems-thinking—can vastly improve the employee and business outcomes.

Further Resources

John Cutler: The Beautiful Mess (Substack)
Host: Dart Lindsley (LinkedIn)

Loading summary...

Transcript

A (0:04)

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.

B (0:44)

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.

A (2:17)

Thanks. Great to be here.

B (2:19)

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?

A (4:09)

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.

A (6:46)

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.

A (9:32)

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.

A (13:23)

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.

A (21:30)

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.

A (26:42)

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.

B (29:31)

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.

A (34:09)

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.

A (36:38)

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.

A (41:28)

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.

A (45:42)

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.

A (50:06)

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.

A (54:57)

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.

A (61:08)

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.

A (65:55)

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.

A (71:40)

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.

A (75:11)

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.

A (83:46)

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.