A (2:14)

Ooh, my craft. I love this question.

B (2:18)

Deliberately.

A (2:19)

Can you go first?

B (2:19)

Deliberately broadcast. Happy to go first.

A (2:21)

Okay.

B (2:22)

Other than where pearls come from.

A (2:25)

Huh. Important.

B (2:27)

I think something that I'm. I'm always relearning is that I'm better at this work when I'm a little bit more toward kind of the intense side of a continuum that maybe has, like, chill on the other end. If I'm a little bit more on the intense Side, I think I just show up much better and I am at better service to our clients and I have better ideas and I'm just like more engaged. But in order for me to do that, I have to take very seriously deliberately disengaging with the work on a daily or other sort of rhythm basis. Otherwise I can never really tap into that. And I'm always at this kind of lower state of energy that I'm bringing to the work.

A (3:10)

Interesting. I think what I have been relearning in the last six months or so is I think in my role is really important and we talked about this on the show, but I've been very focused on some macro level work for the ready. And what's interesting is that was a shift from earlier when there was like a lot of foundational just, you know, pothole filling to do. But what I'm relearning right in this moment because a couple of things that I've been focused on just in the last week is like, I really am the best at this work when I am also paying really close attention to the external environment. So there have been a couple of pretty significant trends percolating and some pretty big things like happening, like on the global economic stage that I just was not really engaging in to the extent that I should be for the job that I sit in to be smart on, you know, being, as you would say, ahead of the puck in terms of the future of work. So I think what I'm relearning right now is like, it's not enough to just be working at the strategic level of the ready. I need to really also, in order to do that well, be paying attention to a much, much, much wider environment, which is just easy to negotiate away from when there's a lot on.

B (4:35)

Yeah, totally. And I appreciate you putting it into terms that I'll understand.

A (4:38)

Yeah, no problem. I always forgot if you could go.

B (4:41)

Ahead and just use only hockey metaphors for this entire episode, that would be great.

A (4:46)

No problem. I will do my best. So the organizational pattern that we're going to dig into today is this idea that a lot of organizations have in their strategy or their values or their plans that they want to do something like adopt a product mindset, put the customer at the center of the experience, something like that. You know, user centered design. I hear this in lots of different places, both in terms of the external customer and in terms of the internal customer for functions that are more like in the center of an organization. But what we often see is that the OS that they're working in actually puts the opinions and the agendas and the desires to of the leaders at the center like that's really what is being designed for in terms of how the work gets done. And usually when the customer centricity is declared, but the leader opinion centricity is serviced, you only get the leader one. And with time and reps you have an ever increasing need for the customer centricity. Because the leader opinion thing is like sucking up the resources, sources and the time and the roadmap and, and, and, and so the customer gets left behind, which means then you have catching up to do. So said simply, we say we want product. What we actually do is leader focus, which increases our need for customer focus.

B (6:27)

Love it. So I'm going to do the rare thing and hearken back to our relevant check in round and I'm going to play the tiniest little bit of devil's advocate and say, Ronnie, in your check in round you described, you know, you being a leader in this organization, staying super happening in the environment. Why not design around your opinion? It sounds like your opinion is pretty well founded and you're doing the work to have good opinions.

A (6:51)

Oh, that's a really interesting question. I don't think that it's either or. I think it would be really dangerous for anyone who is making any decisions about the ready to only be paying attention to the external environment and not the customer voice. And I feel like I generally am quite in touch with our customers. So I'm able to braid those things together, not say we either design for this AI trend that I'm reading about or we design based on what our customers are saying. If anything, I think it's our job to bring that information to our customers and help them make sense of it. So what I believe and what I think is backed by the research that Jack gave us is like if you think about there being three sources, the broad environmental source, the customer source and the internal opinion source, I don't think that you can just do one. I think the job is always going to be to evaluate and balance and make bets. Informed by all three is my.

B (8:01)

That makes sense.

A (8:01)

I don't know. What do you think? I mean, why don't you listen to me is another way of asking that question.

B (8:06)

I think first of all, I take your word as gospel in all things. So nailed it. Just, you know, I guess going to sleep, listening to episodes of our podcast. I have a special feed that has just taken me out and it's just your voice. So I feel Like, I'm pretty well versed in the Rodney verse at this point. No, but I. My. My devil's advocacy there was very, very slight and mostly fake because I think a leader with an ego, a large ego, can take that question, I guess asked and be like, you know what, you're right, I am doing a great job and we should do what I'm thinking about. And that's not what you said. And I just think anytime we're dealing with a lot of complexity, which basically all organizations exhibit, I just get very skeptical of one person being the receptacle or the container of all of that complexity and trusting that what comes out the other side is the best thing that could happen.

A (9:04)

Yeah, slight tangent, but you really made me think about this because a lot of companies that we work with, I would not put in the category of, like, the most progressive organizations.

B (9:15)

Sure.

A (9:15)

But the READY is a progressive organization. And so what you saying that just made me think about is like, if I think sort of about the order of operations for someone who's stewarding something that is progressive in nature, I think the move is like, I want to know where the world is heading so that we can be edgy in that, knowing that, like, our customers will not be and not expecting to, like, drag them into the future. But I feel like I want the world to inform our perspective on where the puck is headed and us to inform our customers perspective on where the puck is headed. And the only way to do that is to, like, balance all the things that makes sense.

B (9:57)

That's cool.

A (9:58)

This question just made me think about that. I never, like, I, you know, I've never really thought about it before, but, like, it will be cool for me based on this conversation. Conversation, to think a little bit more like, specifically about that and what that means in terms of what I consume and what I do with it. So thank you, Sam, for doing something so smart and helpful within the first two minutes of the podcast.

B (10:17)

Well, speaking of smart, let's pull apart this clam and try to find a pearl.

A (10:22)

Let's pull this clam apart. My goodness.

B (10:25)

So what are the various aspects in play here when we talk about this pattern that you elucidated for us? Like, what? How do you think about it?

A (10:33)

I mean, the main problem that I see, and this is particularly true for infrastructure functions, but it can be true for product organizations as well. I have definitely seen this in large companies, is that for a variety of reasons that I'd like to brainstorm with you, we get into the mindset of we Have a solution that we're convicted about, and now we just need to find a problem for it to solve. And I think some of that is because of, like, expertise. Some of it is because of our own opinion. Some of it is because we don't have good feedback loops. Probably some of it is just like sunk cost, actual sunk cost and sunk cost fallacy too. But too often, what I see in a variety of different situations is like, I got this hammer, where the fuck be the nails? Because I need to go do something with it. And then the job also, and my comp and my metrics and my, like, promotions, my very existence are based on my ability to convince others that they have nails, which just is like backwards.

B (11:40)

Yeah, it becomes an exercise of I need to go do things with this thing we have made or this expertise that I have developed. And luckily for me in the organization, we probably focus quite a bit on outputs. So there's lots of nails or quasi nails for me to go find or screws that I can pretend are nails and go pump some metrics, some output metrics that will allow me to continue playing the game for the next quarter or the quarter after that. And at that point, we truly are playing a game and not doing what I think is truly difficult, which is required if you want to bring a product mindset to this work, which is thinking in terms of outcomes and really understanding what. What value is for our customers, for internal customers. That is often unglamorous, cognitively difficult work that is hard to make this the time and space for in most organizations, because we have this very visible game of output metrics to be playing.

A (12:50)

I think that's exactly right. And what you're making me think about is just that even if we can orient toward outcomes that we want, we still have to hold the path there really lightly in order to actually have a product mindset. And like, as someone who has brought stuff to market and worked with clients who do that, first of all, there's a lot of pressure to be right. So when you're like, I have a thing that I want to make and sell out there, et cetera, et cetera, it does get metric and it does get outputted. And all of the things that you're saying, I think creep in for product teams almost immediately. And often because of that kind of constraint, there's not a lot of flexibility for, like, just being really surprised by what users do with it or how it resonates. You know, like, we're having this experience right now with depth finding where we're in all of these conversations. And to be honest, the thing that I thought was the killer app of depth finding is turning out to not be the killer app of depth finding. And what's cool is there is a killer app. But I'm wrong about it now because I am, I don't know, constituted this way. I'm like, great, as long as there's something that has the impact that we want and gets the users the outcomes that they want, I don't give a fuck. But in a lot of organizations, you do very much have to give a fuck because it's not cool to be wrong, even if you're getting the outcome that was intended.

B (14:26)

Yeah, totally. And I think there is an element of just like, that's like who you are probably. You know, it helps in terms of like the position that you hold at the ready as well too, to be like, yeah, like, all right, that's fine, like we'll figure it out. And I have a lot of empathy for folks who are not, you know, stewards of their team, of their organization trying to bring that idea forward that isn't ironclad at that point and it might fail. See all episodes we've ever done on psychological safety and trust and experimentation and how you get cultures that support those things.

A (15:00)

Totally. And it's like, I think part of having a real product mindset that's exciting is like, if you can have loosely held opinions about what the thing that you're making is for and could do. It's very exciting to see people use shit in like creative and unexpected ways. As long as your job and compensation is not predicated on them using it the way that you wrote in the technical documentation that they were supposed to.

B (15:29)

Right? Yeah. And if your OS is that, then I mean, that's where we have to start to unpack some stuff. And I think people generally, generally act quite rationally. And you can analyze what is going on in an organization by just following the money, following the incentives, following the punishment. And I think people's behaviors, often you always have to leave a little bit of wiggle room for the non rationality of the human being to just do weird stuff. Because we do that sometimes. But in general, I think we can figure out why people are acting the way they are and not to immediately get into like starting to improve things. But it's not enough to just say we are now product led and actually, you know, looking at compensation and other things that are getting in the way from being able to do that.

A (16:23)

Totally. I mean, I am Curious what else you see out there? Because I do feel like, to your point, a lot of companies, and I see this in HR functions, I see this in other kinds of enablement functions. They sort of like we want to have a more platform mentality and be creating things that our users really want. I say that because I do feel like the explicit intention is there. And then what do you see happen?

B (16:53)

Yeah, I think quite a few different things come to mind for me. And the first one is just wanting to be helpful. And we talked, I think a lot about this with the future of HR stuff and how to try to get HR out of this service mindset. And you know, you can, you could probably squint at this and like, what do you mean? Like to not be of service. Like you're an internal service organization that's supposed to be helping people. I have a thing that I need help with. What do you mean you can't help me? And I think that's a very real thing. Especially if there's a long history of this function or this team just kind of dropping everything and giving this white glove service to anybody who shows up with a problem or any senior leader who shows up with a problem.

A (17:40)

Right, right. I mean, I was in a workshop not that long ago where this was under discussion and a guy I thought like very courageously was just like, yeah, it's all fine and good until like somebody with a certain title calls and stop, drop and roll. Like that's the deal.

B (17:57)

Yeah, I think, I think that's a very real and felt thing by a lot of people. And as we always talk about, it's not one thing or the other. It doesn't have to be binary. It doesn't have to be. You are complete service organization. You don't kind of fix things as they come up or help people as they come up or you are purely product and people are only interacting with you through this kind of durable product that you have created, especially in any time of transition. That's a who continuum to be explored and kind of managed over time. When I think about this idea of having a product mindset, I'm actually more interested in it from an employee experience perspective and internal teams adopting this mindset. I have been periphery to or just on the edge of a lot of very, very large organizations that seemingly hate their employees by what they force them to do or use on the inside. And I can't help but think that there is real psychic damage happening within these organizations every time somebody has to open up this half assed tool to go do a thing that they really shouldn't even need to do. And doing that multiple times every day or a couple times a week, like those sorts of things are where I'm actually most curious about how to change that dynamic.

A (19:21)

I mean I think that like the conversations that I'm privy to are very similar to like from the ivory tower to the external environment is like from the internal function to the internal customer, which is basically like someone or some small group basically being like we know what they want and we'll make it for them. That's it. And now it's on a roadmap and now we're metrics against it and now that's what you're getting paid for. And like we'll do an employee engagement survey and see it's like, dude, there is nothing about that that makes sense if what you actually want to. Your point is employees who feel like they are consumers of an organization that is putting them at the center. Like you know, I think employee experience is another buzzword that gets thrown around a lot and it ends up looking like sort of like bullshitty, like listening tours and surve driven whatever. And the reality is like usually that's still some sort of like concentration and some sort of powerful group deciding what the masses want and not really checking the efficacy of those decisions. And tooling is a great example of that.

B (20:34)

Yeah, now tooling is always just the most felt one because every time I'm working with a client and I'm using one of their laptops and I have to like interact with their IT help, that always tells me a lot of like, like what is this organization like if I call their IT help as an external contractor working to help with my company issued laptop, like how does that go? And sometimes it goes really well and it makes me not afraid to like open my laptop and get in there and like do work on their systems. And other times it's like I'm going to have to set aside an entire day to get this very simple thing fixed and I just, I just can't. And I'm going to find something else to do. And that I think is a very real thing that people are experiencing in organizations. And if that is the case, you're going to try to stay as small and default as possible to not cause problems. Because anytime a problem is caused, you're setting aside a day to like go get something fixed. And I'm not throwing it under the bus. It's just a very visible felt one for me personally, I guess Totally.

A (21:38)

But like, counter argument. When I worked in a large organization, those were basically like days off.

B (21:45)

Good point.

A (21:46)

And like, my day to day was so shitty that the day when my laptop stopped working and I had to deal with it and you just like dash off an email being like, sorry, everybody. And everybody was just like, well, that's it, that's it for Rodney today because we all know how this goes. She's going to the basement. You know, those days were the shit because, like, they were boring and stupid rather than being stressful and stupid. And they were like a little brain vacation. Which probably again tells you more about the traditional OS of like, full of like, nonsense jobs than anything else.

B (22:21)

Yeah, I guess I'm. I'm just the naive idiot over here being like, we could design a better way of giving you a little brain break than just having it be horrible to get your laptop fixed.

A (22:31)

Totally. Also, like, you're someone who like, gets to do good work and like, has a lot of control over it and probably also feels like I can determine like when my work is done and when my day is done. And I'm not like punching a clock or doing politics or whatever. So, you know, all of the incentives are different for us anyway. I would put, you know, I would put benefits into this category. I would put a lot of DEI work into this category. Expense systems that people have to use out there in the world that are like impossible to navigate in order to get reimbursed until they just give up. You know, these kinds of things, like, definitely do not feel user centered or product oriented. It just feels like somebody made a decision and everybody else just has to kind of like suck it up.

B (23:24)

Yeah. And I mean, I think it is pretty easy to kind of follow that line of thinking to, well, this is a cost center and we are going to minimize the cost center aspect of this. So give me the cheapest option. Hey, we don't need any designers to pull together this internal tool. The engineers, the software developers can just hack something together. And now we have a functional thing. And I think, you know, back to that idea of, of psychic damage. It's hard to put a monetary amount on.

A (23:55)

Totally.

B (23:56)

But it, it's a cost. It is a real cost. And it. Just because it doesn't show up on a budget spreadsheet somewhere doesn't mean that it's not actively harming the organization.

A (24:07)

I totally agree. I mean, I know a woman who does like fractional chro stuff and she often talks about the metric of like lifetime value created by an employee and that like that's the metric that HR should look at and how like HR should be creating products that increase every employee's value and ability to create value. And not in a shitty, like what's the ROI on every one of these people? But it's like, is HR providing the benefits to these people that make them able to do their job really well or, or to manage people really easily or to access development opportunities really seamlessly? And she like thinks of this in this very smart and customer centric way. And like she was telling me once that like she works a lot with scaling startups and when she goes into a company like the first thing she looks at is basically what they're paying for their benefits stack versus what employees are using. And she just rips out all of the cost of the unused resources. And she's like, this is not good investment in terms of employee value. So like redeploy this capital to something that your customers who are your employees will actually use and give a shit about and will make them better.

B (25:21)

Totally. And I think what is kind of connecting all of these ideas is that at the end of the day, if you want to take a more product focused approach to literally everything your organization does, what's hard about it is that it can create some very stark realities that we have to deal with. Because products, if we're, if we're staying product focused, we're staying very close to our customer and truly listening to what their challenges are. We are truly looking at metrics related to the things that we are building and maybe being forced to look at the fact that the thing we spend a lot of money and time on is not actually creating the value that we thought we are having to have some really tough conversations about what value even is for us and who contributes to it and who is getting in the way or what is getting in the way of creating that value. And all of this, it can be very stark. I don't want to say black or white or binary because it's not like everything here is, we're dealing with scales of intensity, but it's like real shit to talk about. And it can be a lot easier to set up a kind of a work sandbox and just let people go play over there, like make your presentations, we'll do our meetings and at the end of the day the leaders will just say what we have to make and we can just play the game of work in this artificial environment or we can do the real thing, which is going to cause probably some conflict. It's going to hurt feelings. There's going to be weird ego stuff showing up. But at the the end of the day, you are making something that you're proud of and that people are actually using. So like, are we willing to make that trade off or. Or not?

A (27:09)

Yeah. And like, I think it's such an important point and not one to be under emphasized because we were talking about this actually in the founder mode episode. It takes so much belief to actually create something with your point of view. You know, it like, it takes a lot of fuel for an HR team to be like, this is the new comp system. Or for the finance team to be like, this is the new way we do budgeting. Or for a product team to be like, this is the new feature that we're going to deploy. Like, it takes a lot. And so ginning up all that energy and belief and time and probably initial research and then holding it lightly enough that when you're wrong you can just be like, whoops, pivot. That's not easy to do.

B (28:01)

No, yeah, it's. It's definitely not. And I guess most organizations are not set up to where you can really love the problem.

A (28:11)

Totally, totally.

B (28:13)

Really get deep into like, what is really going on here? What are we actually trying to do that is truly time intensive and energy intensive and attentional intensive work to be done. And I mean, look at any of our clients and their typical calendars. Like, where is that work happening? It's not. And yet we have to kind of pretend that it is in order to keep things moving.

A (28:42)

Yeah. And again, like, tiny side tangent. But this makes me think about a lot of conversations I have about metrics also, which is like, usually when we look at metrics and when our clients look at metrics, they want to look from the perspective of like, is this good or not good? And if it's bad, what should we do? And there's so little time and space to like really understanding whatever the numbers are that are driving our business. And maybe some numbers that we don't typically look at, giving us enough time to like really marinate in that as a group, not just be like, it's green or it's red. What's next? And then starting to be like, what does this tell us? What does this mean? What is the story of these numbers? How is that story different than the anecdotal stories that we hear? How is that story different than what our customers are experiencing? It's very rare to see teams that make the space to do that and don't sort of rush to like, just finishing. Just like, we looked at the metrics, we checked the box, we moved on to what's next. And instead really being like, really having time for the sense making. To your point about loving the problem.

B (29:53)

Yeah. Well, we just gotta get stuff done, Rodney. We gotta.

A (29:56)

It's all about, we gotta execute. We gotta just keep, keep going forward. And I feel like that is also. I've worked in internal functions in companies. I feel like it's pretty rare to get real data on how you're doing. Like, I don't ever remember, like a finance person asking me if, like, how.

B (30:20)

Was budgeting this year? You get what you needed?

A (30:22)

Yeah. Like, did you get what you needed from budgeting? Like, when I was an HR person, I pretty rarely asked my clients for really specific feedback. And when I did, it was basically like service oriented. Like, am I a good partner to you? Do you trust me? Like, do you want me around? It wasn't like, did we solve the most compelling problems that your business had this year? Because the answer would have been no.

B (30:47)

Like, right.

A (30:48)

Hundred percent, I'm sure. So, you know, you had put in a point about like, feedback loops and.

B (30:55)

Yeah.

A (30:55)

I just don't think that we hear a lot because we don't really ask our customers internally the questions that I'm talking about.

B (31:05)

Yeah. Because they're hard to hear.

A (31:07)

Yeah.

B (31:07)

Especially if you're kind of early in a process where we're trying to do more feedback and you don't have years of like, taking what maybe others would pursue as difficult feedback, like, it doesn't feel great. And then if you're then enmeshed in an OS where you can't really do anything with that feedback, like, why am I going to solicit a bunch of shit I can't do anything with? So let's just operate under the assumption that if nobody tells me anything, it means I'm doing an amazing job, which is just easier to kind of operate with that fiction.

A (31:40)

Totally.

B (31:40)

Can I take us on a slight right turn to like. It's a more tactical thing that I think about with this turn.

A (31:45)

Sam, I've been waiting all my life for you to just take us on a turn.

B (31:50)

That's right. So building products is a inherently cross functional endeavor. And in a lot of organizations, doing anything cross functionally is death.

A (32:05)

Yes.

B (32:06)

Not possible. Let's not orient ourselves around a fundamental idea that makes us do a thing that we're bad at and we hate. And I think that's one of the reasons why people don't want to operate in this way or they want to talk about it. But when the reality is we're sitting around a table with my cross functional partners to do something, it goes poorly because we don't have working agreements, we don't have a history of working well together. We have a bunch of history of probably actively not working well together. And there's like just the whole basket of things around cross functional collaboration that seems to be a prerequisite or something that needs to be worked on in parallel with any sort of effort of trying to take a more product centric approach to anything that an organization is doing.

A (32:53)

I totally agree. And also when you work cross functionally in an organization, you're immediately opening yourself up to the kind of difficult feedback that we're talking about. Like if you're going to be sitting in a PMO and you're like, I'm gonna really bring together a bunch of folks to figure out what the workflow should be around managing this portfolio. Like pretty quickly you're gonna hear from a bunch of people about how your best practice is not good for them or what they want or meeting their needs. So it's like it is easier if you are sitting in the PMO to just like get all the other project managers together and be like, shall we? Looks good. You know, like high fives. Get the out of here. When you bring like the supply chain guy in and he is like, yeah, what you're doing is extra work. It's a tax on my day job. It adds no value to me. And I understand that it's just in service of people who aren't doing any of this work. Like nobody wants to hear that.

B (33:57)

Yeah, not at all. And I think if you're not having this product centric approach and you're kind of stuck in a more service mindset, being surrounded with your functional friends slash allies, like there's company and misery, misery and company. Like if you are all burnt out because you're all servicing in an insane amount of requests every day, but like you're all in it together, I think you can create, I don't know, this like self perpetuating identity around like we're burned out, we're martyrs, we're like doing everything and you know, this is just our reality and people don't understand us totally well.

A (34:38)

And I think that this is like a really fine point to put on this whole pattern, which is when we do what you're describing, when we insulate ourself from the end user's experience and perspective. What is very easy to do is cast to the end user as an idiot.

B (35:00)

Yeah.

A (35:01)

And that's fine, I guess except like who is it helping really to have an amazing product that no one can use? And you know, again, having worked inside and around a lot of internal functions, like it is a protection mechanism to just be like, my greatness is misunderstood and if these people knew what I know, then they would use what I made. And also who fucking cares? Like it doesn't matter. It just doesn't matter. And tbh, I think like we fell into this a little bit already. I think there was a time that we on occasion would be a little like precious about our ways of working and our convictions and our defaults. And, and, and, and, and, and it's like good on paper and good in practice, but only if you have a dance partner who will practice.

B (35:59)

Right.

A (36:00)

And if the clients are just like cool, you show yourself out, then it doesn't matter. And I think that like this is the biggest shift. Your idea doesn't matter. The potential impact doesn't matter if the person who has to use it won't.

B (36:16)

Yeah, exactly. And we have to decide do we care about that or not?

A (36:21)

Do we care about having a business? I mean that is.

B (36:24)

Yeah, I guess I was thinking more internally. Yeah, I think externally as well. But even internally do we, we have to decide? Because you can fake a lot of this. This is just back to that sandbox idea. We can play the game of work and I'll be very busy all day long, but not actually be providing a whole lot of value. And either we're just getting lucky in the market conditions that are allowing us to survive. But I wouldn't bet the long term success of the organization on us just being able to skate by with because of external conditions that we are somehow able to take advantage of.

A (36:57)

Totally. I'm realizing as we're talking about this, I held a role where I was such a perpetrator of this I cannot even tell you where. Like my job was to have ideas and to understand the thinking in a field and create material from that, et cetera, et cetera. And the internal users of that basically didn't want it.

B (37:23)

Yeah.

A (37:23)

And I was basically like, you're stupid. And like that's not right, that's not helpful. And like first of all, they're not stupid. But we did suffer from like, if I didn't make it, then it's not X, what's the expression that people use?

B (37:38)

Didn't build it here syndrome.

A (37:40)

Yes. Didn't Build It Here syndrome, which is like, a real thing, even when you're all working in the same building under the same operating name. Didn't Build it Here syndrome is still a real thing, and I see that all the time. And I think, like, you know, younger, more arrogant me was just like, the work will be so good that it will speak for itself and be undeniable. And like, elder wizened me is like, that's not how it works.

B (38:08)

Is that what you are now?

A (38:09)

This is the elder version? Yeah, I'm a crone now. Yeah. I'm just like, that's. Unfortunately, I think that I still think that's how it should work. And unfortunately, I know that it doesn't anymore. I have enough reps, both in my own lived experience and with clients to know that, like, that's just not how it goes. So we might as well just put that down.

B (38:29)

Yeah, totally. Question for you. Has this clam well and truly been pulled apart?

A (38:35)

I think so.

B (38:35)

Should we go look for that pearl? Do we have a pearl to offer you?

A (38:38)

Talk about clams like someone who has never eaten a clam.

B (38:41)

I actually, here's the thing. I know my way around a clam. I've eaten plenty of clams. I love seafood, but apparently I am not smart in the world of luxury jewelry.

A (38:54)

Oh. Huh. That's the problem, probably. Yeah. Let's give the people some ideas.

B (39:00)

All right, I'll go first. I tried to go really specific and actionable on a couple of ideas here. So I think a really valuable exercise to partake in is some value stream mapping.

A (39:15)

Ooh, nice.

B (39:17)

There are so many different ways you can do this. You can get really complicated really quick trying to do some value stream mapping. What I'm advocating for is the truly simplest version, which is basically getting a group of people together who are aware or work on a thing. And starting with on the far right, what is the value that the customer or the. Whether internal or external, like, what is the value they are getting from the thing we are doing? And then just working your way to the left, asking yourself, well, what must be true for that to happen? And you start to branch everything off. You just keep following those branches back until you've built that chain, that map of how value is created. Then you can go back over that map and start to have conversations about, well, where are things harder than they should be? Where are the friction points within this map? What are aspects of the map that we created that make no sense to us? Like, why is this whole chain even part of it like let's understand that aspect of it. And I've never not gotten a bunch of really actionable and useful things out of a 90 minute value stream mapping exercise with a cross functional team that is responsible for a thing.

A (40:31)

Nice.

B (40:32)

Yeah. Ronnie, what do you have?

A (40:35)

Okay, so a lot of times what I think people are looking for, they hop right from we want to have a product mindset to how do we get product market fit. We have a thing. We just need a market for our thing, either internally or externally. And I think there are at least two steps before that. Yeah, I think for any internal or product organization that's trying to make something, you need a period of time where you're just learning and gathering evidence that there is a problem worth solving. Like that is so fundamental. And harkening back to our Josh Burson episode where he and I talked about this, just like there is a real problem, that problem can be articulated. We generally know who has that problem. And very importantly and in a step that is often skipped, that customer recognizes and also articulates that problem. So I see a lot of internal functions going, they have a problem and we know what it is. If they don't see it as a problem and can't say it, just stop right there. Just stop. Don't go try to convince them that it's a problem. If they don't feel it, the problem.

B (41:55)

Also can't be they're not using our thing.

A (41:58)

Yeah, that's not a problem. Yeah, it's their problem, not your problem. That's a very good point, Sam, because that does actually get a little squishy. The second step before you pursue product market fit is problem solution fit. So do you have a tested and proven solution to their problem based on their feedback, not yours? Does it actually solve the problem that they say they have and are they telling you that they would buy it? I say this constantly. You heard me say it in front of a huge group of people the other day when I'm working with like we'll call it an HR function. And they're like, yeah, our hiring process and the hiring managers won't blah. And they're just not. And I'm like, if they wouldn't buy your service when competed against that service externally, you don't have it. You don't have it. Like if it's. If you are not doing something for them that taken away, they would source elsewhere and pay for out of their budget. You do not have product market fit. And so what you need before you get there is actual Problem solution fit and intent to buy. Like, these are the steps. These are sort of like the chain of custody in this thing that you have to go through before you're just like, we got product market fit, let's scale this thing.

B (43:17)

Yeah, totally. And one of the really difficult things about this is that we've seen over and over and over again huge difference between stated preference and revealed preference. So even someone saying they will pay for a thing versus like actually clicking the button and putting their credit card information in, those are even quite different things. And I understand that perhaps you can't get your experiment, your test to the point where there's like literal change of value, but just it's important to be very conscious of the fact that someone telling you they will buy a thing to your face, especially if you have any sort of relationship with them versus them actually in the privacy of their own home deciding to buy the thing are worlds apart.

A (44:04)

Totally. To this point, one of the questions that I love asking customers is how else have you tried to solve this and who else have you hired to solve it? Because if they're like, to your point, Sam? If they're like, no money and no one, it's just a thing that I think about when I'm walking my dog. Like, that's not it.

B (44:25)

Yeah.

A (44:26)

Yeah. Cool. Let's wrap it.

B (44:28)

Let's wrap it up. This is good. We found that pearl. Couple of pearls, actually. And now it's time to make a necklace.

A (44:35)

It's time to make a necklace and for Sam to learn about seafood.

B (44:39)

That's right. We're always looking for new topics for the show. Also on the down low, I'm also looking for new pull apart metaphors or ideas. So send those to me.

A (44:51)

Maybe ones that are accurate. Maybe like just as a thought starter.

B (44:55)

Exactly. So if you have an organizational pattern that you're having trouble changing, shoot us a note@podcasttheready.com this show is engineered by.

A (45:05)

Taylor Marvin and produced by Jack Van Amberg, who was trolling Sam in the comments of zencastr while we were recording. It was just an absolute delight. Our work with the READY is created by the ready, where we help organizations around the world change the way that they work, including shifting to product mindsets. Thanks for listening.