197. How to Drive Outcomes Over Output, with Josh Seiden

Speaker A: This is the Innovation Engine Podcast from Three Pillar Global, your home for conversations with industry leaders on all things digital transformation and innovation. Welcome back to the Innovation Engine Podcast. I'm your host and Three Pillars Chief Evangelist, Scott Varho, and I'm thrilled to be joined today by Josh Seiden to talk about how to drive Outcomes Over Outputs. Josh is a designer, strategy consultant, coach, author and speaker who has worked with a number of companies that are household names, including t. Rowe Price, JPMorgan Chase, Fidelity, Hearst, PayPal, and 3M M. He helps companies launch new products and services and in the process create a more agile and entrepreneurial organization. In addition to his consulting work, Josh is also a prolific author. His latest work, which we'll focus on today, is Outcomes Over Outputs. Why Customer Behavior Is the Key Metric for Business Success. Prior to that, he co wrote two books with Jeff Gotthelf, Sense and Respond and Lean UX. Sense and Respond was nominated for Thinkers 50 distinction in innovation, and Lean UX has become widely regarded as one of the top UX books of all time. Joshua, we are so excited to have you on the Innovation engine. Welcome.

Speaker B: All right, thanks. It's great to be here, Scott.

Speaker A: So, you know, and you know, from the intro, I feel like we could do an episode on each book, uh, that you've written. There's, uh, a lot there and certainly that's relevant to what we at Three Pillar, uh, do and think is really important. But we are going to focus today on Outcomes Over Outputs. It's a relatively short book, but there's a lot to unpack. You start off the book by sharing a personal story that probably feels familiar to a lot of people in our space, uh, that you worked with. The team that spent a couple of years building a stock trading app for a large finserve company that never got out the door and never shipped. What did you learn from that experience?

Speaker B: I mean, the lessons are endless. You know, you spend two years working on something that doesn't ship, um, there's a lot of conclusions you can draw. But I think that, you know, the reason that I started the Outcomes book with that story is I thought it was a really good example, a great illustration of the problem, which is that, look, building great software is hard. It's hard to design, build and deliver great stuff. But at the end of the day, building stuff isn't the goal, right? And, uh, at the end of the day, the goal is to deliver value to your users, your customers, and the organization that you're working for. And so two years of building something that we believed would deliver value in the future was two years poorly spent. And so I think my goal since then has been to figure out how do you keep that long term vision. My background is in product design and so I want to build wonderful things that may take a long time to create. How do you hold to that vision of delivering great stuff while delivering value along the way? Can you create value along the way as you're getting there? And that's a hard problem. But I think that's the problem that the book is about, which I think

Speaker A: is a, it is a really important insight. Um, because it is amazing to me even, even when I've worked with really great product leaders who understood the initial need for the product, like why is this thing even happening? Lose sight of that very quickly and it becomes much more about execution and even leadership will get more focused on even if the product fails. It's never that the hypothesis underpinning that product was faulty or had gaps, um, but it was an execution problem. Um, I think this is a really important insight for our industry and clearly you did as well and that's why you wrote the book. But I think it's important to acknowledge that all products are hypotheses. And do you understand the hypothesis and can you take in new information and maintain vision at the same time? I think really savvy product, uh, leaders can so kind of going further into this if outcomes are natural partners with hypotheses. Um, and that obviously is something that really stuck out to me because that humility and curiosity that you need to build great products just makes sense when you realize that your product is a hypothesis. So what does that mean that outcomes are hypotheses? And why is it such a foundational concept to grasp?

Speaker B: Yeah, I mean, I think the challenge for us in product development is that it's easy and natural to think in terms of solutions. It's kind of the most concrete sort of way of framing what we're doing. Oh, we're going to build X, we're going to build this thing. Oh, we should build this thing. You know, it's uh, you know, it's how I think, I think it's how most of us think. Right? It's, it's, that's, that's how we frame and describe what we're doing. But the reason that we're doing that, reason we're going to build this thing, is to create some effect for some result for our, for our users. And so, so then, so then the question is, will this thing create the outcome that we expect and we want to be certain. But the fact of the matter is humans are weird, unpredictable group of people. That's an oxymoron. Humans are weird, right. And they're unpredictable. And so we think that this thing is going to problem. It's going to, you know, we'll put it in the world and people will use it the way we anticipate. But that stuff is hard to predict and in some cases it's impossible to predict. And so this, the idea that a product is kind of an embodied hypothesis is the sort of natural conclusion there. It's like we think this is going to work, but we're not sure. And so how can we validate our ideas as quickly as possible? And there's some amount of validation that we are used to doing in product development before the product ships. Right. But that's not sufficient. We, at some, at the end of the day, at some point, we have to put some things in people's hands and see, uh, what they do with it. And so when you, the rubber meets the road, when we put our products in people's hands, and that's when we can start to validate our hypotheses.

Speaker A: One thing that struck me when, uh, you know, I was leading product teams, which, uh, which is most of my career before three pillar, uh, app product companies, I was always really surprised at how often users used, even internal stakeholders. If I'm delivering APIs, let's say to other departments, how often they would deviate from what I thought they were going to do with those APIs. Um, and it was fascinating. And I started developing this interesting metaphor for maybe we should be paving the lines in the grass. Maybe instead of putting the paths in the grass where we think people are going to walk or where we want them to walk, we should pave it where they do walk, um, and get okay with that. We don't need to see that as deviant behavior, but start to shore up because clearly they're getting value from it. But in each of those teams, I always sat between upper leadership and the team executing on this vision, on these ideas, these hypotheses. I wish they were framed that way. They never were. But how do you speak to that leadership and the way that teams are working against their goals and often have quite a bit of altitude difference between them. Um, and so how do you bridge that gap? Because that has always been a struggle,

Speaker B: I think the hardest. So my experience working with the most senior leaders is that they tend to really have an intuitive understanding of the idea of an outcome, once you explain it to them, they're very practical, they're results oriented. And if they're being candid, most of the time, they will tell you, look, I don't know the answer. Sometimes they dream up the answer when they're having a shower, and then they get very attached to the answer.

Speaker A: That's the type of executive I'm used to. Yeah.

Speaker B: I mean, those people. There's like a second strategy for, um, what my business partner Jeff calls, uh, uh, uh, my co author Jeff calls a epiphanous shower moment. But most of the time, I think senior leaders really, really get, like, what they're trying to do is they're trying to get a result. And so what. What happens, I think, is that in the process of translating that from sort of framing the problem to execution, as you say, we lose the script. It's hard to execute. And some. And up and down the organization, we start making promises. It'll be done in a month. Yeah, uh, it'll be done in, you know, and it'll be great. It'll be done in a month and it'll be great. I think this is how people respond to the sort of inherent uncertainty of product development. We were just talking a moment ago about this idea that products are hypotheses. We don't know if they're going to work. And so, um, that uncertainty is really, really uncomfortable. It's uncomfortable for everybody. And so I think the right, uh, my personal feeling is that the right way to handle this is for everybody in the room to be able to say we don't know. But we're working as hard as we can to find the answer and have confidence in us because we're experts at finding the answers. Uh, right. But too often the conversation is we don't admit, no one in the room admits that they don't know.

Speaker A: So true.

Speaker B: And so we just say, we're sure this is gonna work. It's awesome. It's the greatest thing ever and it'll be ready on Monday.

Speaker A: It's brilliant. Um, yes. Well, and, and it makes sense. I mean, uh, you know, so having sat around that table and looked into the eyes of the head of sales and said, this is the hypothesis, nothing more, that's not a good day. Uh, the head of sales has a quota to hit, um, client success, has clients they're trying to delight. Um, and so they're going to be like, okay, well, you don't know. Why don't you know? And what do you need to do to Know, uh, before you go, inflict this on our customers. And the answer is, there's no certitude. I can increase confidence, um, but I can't give you certitude no matter how much we spend, uh, doing a research. And uh, I do recommend some level of research. Right.

Speaker B: And it's hard to combat that. If the head of sales or the salesperson says, well, you may be uncertain, but I'm not uncertain because I've got a deal on the table worth X. And all you have to do is say yes and we've got revenue X certain. Right. It's hard to fight that.

Speaker A: Mhm. Very much so. How do you.

Speaker B: Well, I think you have to make a choice if you're going to be sales led or product led. And I know that none of this is pure, but the organization has to survive and it has to be healthy. But you have to balance being sales led and product, uh, led. And if you really, really want to be product led, you have to say no to deals. You just have to do it and you have to be prepared to do it. And I get it. That's hard to do. Like, I'm not saying, oh yeah, you've got it.

Speaker A: When it's not our money invested, then yes, it's much easier. But you know, And I absolutely 100% agree with that. And I think it's, you know, there was a, uh, my. The last CEO that I reported to at a product company, whenever sales would come to the table and say, we need X from, from Scott. Um, from my, from my team, from my organization, the CEO would say, okay, great, well, so how much additional quota are you signing up for? Because the only way I'm changing the roadmap for Scott is if you're signing up for more quota. You know, the quotas were set with the existing roadmap in mind. So you're, you're, you're. And I just thought that was the most support I ever got in my role ever.

Speaker B: Yeah. That's amazing.

Speaker A: It was incredible. So I try to encourage all CEOs to use that with their sales teams because otherwise you become, you know, hey, I need to say yes on this rfp. So can you make a, uh, mobile app? And it's like, what will this mobile app do? I don't care. I just need to say yeah, then just say yes in the rfp. Like, why are you bothering me? This isn't how we build products. Uh, I don't know what to tell you. So you have these three magic questions that you you talk about in your book that help product teams shift from, from focusing on, on outputs, um, to focusing on outcomes. Would you mind sharing those with us?

Speaker B: Sure, sure. In the book I, I write that they're the sort of the three essential questions when we're trying to be, um, when we're trying to use outcomes, uh, to frame the problem. What are the, what are the user and customer behaviors that create value? And, and I mean that broadly value for the user, value for the customer, value for us. What are the things people do that create value? How do we get people to do more of those? Second question, how do we get people to do more of those? And then the third question, how do we know we're right? And it's a little bit of a, kind of a meta question, but it goes back to that uncertainty. And so using those three questions, getting your team talking about those three questions, they're very simple and they're intentionally very simple. They're the sort of questions that you may look at them and go, well that's, those are obvious, but it's amazing how often we don't ask the obvious questions. Right. So what are the behaviors that create value? How do we get people to do more of them? How do we know we're right? And just working through that cycle continuously, uh, I find is very simplifying and sort of powerful, uh, tool.

Speaker A: Well, one of the things that strikes me in those questions is as you mentioned, it pulls in uh, humility, um, so it forces us sort of to grapple with the fact that we don't know we're right and then maybe put additional hypotheses on the table in terms of how we can drive those behaviors that accrue value for us, which is also incredibly empowering then for a team that's engaged in that endeavor, because that's a conversation that they can. That's actually when you give a team, uh, uh, we need to increase revenue by 30% this year across the board. That's not something that a team can really grapple with at their level. And you do such a great job of separating out business impact from team outcomes and outputs because I think that's really helpful for people to think of those two levels. It's um, one of the flaws that I've seen in the OKR structure when it gets implemented. A lot of times, um, you get these high level business goals translated down to teams and they're like, I don't know, I can't even connect to this. I don't know what, what you want from me. But this behavioral model that you've introduced is, is much more tractable and anyone can, can participate. Um, have you found that to be true?

Speaker B: Yeah, I mean, I think, I think one of the, one of the big challenges in, in working right is, is the question, you know, what should we be working on? You know, there's so much, there's an infinite infinitely long list of stuff we could be doing. And so how do we know what we should be working on? And a lot of the sort of strategic direction that we get, even if it's like really insightful strategic direction is vague. And so how do we as a team of people who should be working on something, there's all this noise. How do we get to the very concrete specific, what should we be working on wrong? And I think the key to the sort of framing of outcomes is that uh, if you use the definition that I use in the book, which is really kind of a very, very reductive definition of outcomes. An outcome is a change in behavior that creates business value. Um, you can argue that there's other definitions of outcomes in the world, fine. But for product development, just using that really simple and concrete definition, a change in behavior gives teams real clarity about what to focus on. If you can then as a team be really, really, really specific about the behavior, right? You want to tell a very specific story. This is where kind of user journey mapping comes in and telling a specific story about. First the user does X, then they do Y, then they do Z and what they're. And to be able to tell that, that story and understand why they're doing those things. And, and then to be able to pick the like the key moments in that story that you know, that actually make a difference. That, that's a, that's a, I say that's like an analytical framework that helps us cut through the noise, right. And makes us focus on what's really important, which is at the end of the day, what are our users trying to do. I think it's very grounding and it has a way of taking these big ideas and um, making them sequentially more and more concrete so that we can actually work on them.

Speaker A: Josh, one of the things that I think is interesting about that and I'm curious your thoughts on the transition, um, that has to take place for typical feature factory style teams, right? Like my, my I am successful if my stakeholder is successful kind of model, which is pretty typical, um, and found in a bunch of places. But the, the head of client success, if I pick on that role alone or the head of sales, they have opinions about what should be done and they have, you know, they certainly have a. A dog in that fight of what's going to be worked on and what's not gonna get worked on. And it is interesting to think about. If we're able to focus at a higher level on how our business relates to customer behavior, then we get out of trying to reduce, let's say, support ticket time and instead try to focus on better serving clients and not needing support. We can move upstream of some of these issues, but it also requires, I mean, certainly in the gap, uh, there's a relinquishing of control. I'm not in a roadmap conversation anymore as a head of client success. I'm not able to specify the five top bugs that I want address necessarily. How do you deal with that transition? How do you advise leaders going through this? Because it can be. It can feel like you're giving up a lot of control, I think.

Speaker B: Yeah. So, uh, I wish I had, like, one answer for you, but there's like, there are a handful of things that you need to make this work. And I think one of them is recognizing that this approach is really good when you don't know the answer. Simple things in the roadmaps, like, uh, you know what, we just need to fix this bug. M. We're getting 10,000 calls a week about this bug. And if we fix this bug, we will not get those 10,000 calls. Right? Yeah. That's not a place where there's, uh, a lot of risk in that hypothesis. Right. And so it's like, sometimes you just make stuff because you're pretty certain it's going to work, but then there are other things where you don't really know. And maybe the conversation is such that somebody in the room is asserting that they know, but actually we don't know. And so for me, that's a lot about the conversation in the organization. And what do we do? Have you ever been in a room where you're debating aggressively whether it should be feature A or feature B or feature C, and everybody's got an opinion and they're making all these super articulate arguments. That's a room where no one knows the answer. You know, there's not enough information in the room to make a good decision? And so it may be that one of those people has enough information, but the others don't share it. Right. And so that conversation needs to change so that there's kind of. You don't have that information Asymmetry. And maybe what it means is that the head of sales and the head of customer success and your product lead need to go do that discovery together. Right? And try to get that, try to build that shared perspective and shared understanding so that there is enough information to start making collaborative prioritization decisions instead of just saying, hey, my org needs X and my org needs Y. I had the uh, the.

Speaker A: Well, I think I was punished in a, for, for prior crimes and prior lives. But I got to run identity and access management for Pearson, uh, back when we had Financial, uh, Times and Economist and Penguin Books and um, massive um, education, uh, suite spanning K through 20, um, and post uh, secondary education. It was an incredible array of stakeholders that I was managing and they refused to talk to one another. They were like, no, no, no, no, I make revenue. You need to listen to me. You're um, a tax on my revenue. I was like, okay, but if I give it to you in the proportion of my total budget, then you get six minutes. So this is not terribly effective. We could do this Hub and spoke thing all day, but I would really, well, uh, appreciate you joining, uh, joining the broader conversation. Uh, but it was, it was incredibly difficult. Uh, incredibly difficult.

Speaker B: Yeah. And I think, you know, honestly like, like I do a lot of um, like training in methods and process and stuff like that and there are just some problems that are not methodological problems, you know? Right. Like there's just like, there's some problems that are really like culture or organization or just like, as you say, like getting people to talk to each other. And you use any method you want. It doesn't matter. The method is not your problem.

Speaker A: That's right. That's right. Uh, I had a stakeholder behavior issue. Totally. I would have so loved to get into a, uh, more cogent conversation with my executive stakeholders around what is it that we really want out of this? You're spending northwards of $10 million a year with me and my team, which is an incredible sum of money for what I do. I know that I'm not allowed to go down. Don't forget that it's very expensive for me to make sure that we don't go down. Um, infinite scale globally in 16 languages is not easy. But then they had this drive to innovate and so they thought they were on the hook to change their business models, their access models and all that stuff. And I was like, that doesn't scale. I can't provide, uh, so much business logic that only serves, you know, Pearson Higher Ed Italia. That's not going to scale. So we're going to need to come together and have some conversations. I used to always tell my most opinionated stakeholders, make some friends. Get to a critical mass so I can deliver 10 really high quality things rather than 50 low quality things. That'd be great.

Speaker B: Make some friends.

Speaker A: I love that they didn't think it was fun.

Speaker B: There's a book for you.

Speaker A: Find a friend. Um, so, you know, um, Roadmaps to nowhere. I love that line. They certainly don't sound like something that anyone would really want, but they are incredibly common. And this probably kind of brings us back to the thing that we were talking about, but outcomes based roadmaps. Can you give some texture to what an outcomes based roadmap would look like and how that's different from a, uh, well, roadmap to nowhere or an output based roadmap? I know what those look like.

Speaker B: Yeah. So we use roadmaps to communicate with our stakeholders where we're going. And usually the agreements that we make with our stakeholders are agreements to build certain things by certain dates. Right. So all based on outputs and like we talked about, all based on the hypothesis that these outputs are going to create some value. And so what I think is really valuable is to bring more context into that conversation about what we're working on and why we're working on it. And so the why we're working on it is the outcome. We're building these features because we want to generate this result. And so having a uh, roadmap that expresses sort of, you know, if you can kind of picture a row along the top of your roadmap, maybe the title of your roadmap is your objective and then below that are your key results, which by the way are outcomes. And so you've sort of got this orienting thing on the top of your roadmap. This quarter we're working on 1, 2, 3 important outcomes to deliver those outcomes. Well, here are the features that we're working on. Right. Some of them are cut and dry. Right. We're fixing this. We're working on the bug list. Right. But some of them we're not sure. Right. We're trying to grow subscription rates. We're going to try this and this and this and this. There's one more piece in an outcome based roadmap. Right. Um, so you've got the context, why we're doing it. You've got the traditional kind of roadmap content, which is these are the things we're going to, we're planning to deliver in this time period. Below it there's a new row which is the discovery row. These are the questions that we're answering this quarter so that we can start to approach the start, you know, so that we can figure out how to deliver these outcomes. And so I think uh, a uh, roadmap that has those features. Right. The why uh, at the top. This is why we're doing it. We're trying to create this outcome. And by the way we'd like to be measured in terms of the outcome. Right. This is like the agreement we'd like to make is outcome level. These are the features so you know what's coming that's important for the organization. Organization needs to know what features are coming. And these are the questions and the risks that we're trying to manage as we get there. I don't know how you can have a conversation with stakeholders without talking at all three levels. If you only talk about what you're delivering. Uh, for me you're not doing your job as a uh, product manager, as a product team. I think uh, a roadmap that reflects those three things. It starts to reflect the complexity of the work of a product team. Um, that I think makes for a better conversation one of the things too.

Speaker A: And you can tell me if I'm on the right track. I salivate. I mean I'm very fortunate to be now at Three Pillar where we have incredible. Our UX is really grounded in the value of research, um, and doing embedded research with the build process so that we're constantly mental mapping our users and trying to understand execution at a really textured level. Um, uh, level really understanding our users mental model and how that relates to our product mental model and um, figuring out how to bring those into sync. Which sort of leads me to this idea that what if product teams could help your company be more competitive by understanding your users better than your competitors do? What if we were mining for those insights and flipping the conversation from I'm here to execute on a list of agreed features to um, I'm here to make us a more competitive company. It's a very different role for our product team to have in a company than what they're typically tasked to do. But that's, I mean essentially what you're talking about would lead to that where we would discover something about our users that our executives and even our users themselves don't know about themselves.

Speaker B: Yeah. And I think that's the pitch for product led growth. Right. Is that uh, we are. I often tell the product teams that I'M working with that. Your job as a team is to be the world's foremost experts in what your customers are trying to do and then the best in the world at delivering solutions that help them do that. And you can't do that if you're just dreaming up answers while you're on the bus to work.

Speaker A: Well, a lot of executives think that's how innovation happens.

Speaker B: Um, which, you know, the three, the, the three Bs of, of scientific innovation are, are bed, bath and bus. That's where all the great breakthroughs happen. Right.

Speaker A: That's great. I love that. I'm gonna, I have to use that.

Speaker B: That's. That.

Speaker A: Yeah, that's great. Um, well, Josh, we, we are always looking to innovate ourselves. Um, and uh, we actually turned to ChatGPT to generate some, some questions for our, uh, our uh, episode today. And we selected the top two. Are you ready for some AI questions?

Speaker B: Yeah. Can I answer them with AI?

Speaker A: Uh, actually that would be fascinating if you did. Uh, but hopefully you won't need to. How can product development teams effectively balance the need to deliver immediate results with a longer term focus on business outcomes?

Speaker B: Yeah, so I think that goes back to the first question you asked me, which is how do we get out of building for two years? Right. And delivering value continuously along the way? And so to me that's about, I think, first building the muscle to do continuous discovery and continuous delivery. And so can we deliver something valuable every two weeks? Right.

Speaker A: I was just gonna say I often use a gold mining, uh, analogy here. You know, there's hopefully before you go digging an actual mine, there's a set of steps that you take to improve confidence that there's actually going to be gold when you dig. And anyone who knows anything about gold mining knows, yes, there's a lot of steps before you dig.

Speaker B: Right. You want to, you want to know where to put the shovel down, but you also don't want to spend 10, you know, two years studying where to put the shovel down. Right. And I think, I think a lot of our traditional, uh, market research and product research methods, you know, we would spend, ah, certainly when I started my career in design consulting, we would spend a lot of time doing research and a lot of time doing design before we started building and delivering things to end users. Uh, I also think it's possible to throw away that whole process and just start building and delivering. I don't think either of those are the right answer. Uh, I think you want to, you want to deliver things unreasonably early. But you want to be doing that based on good and continuous customer insight. And you want to be using each delivery to create value and to create learning. Um, and so even if you're working towards a long term vision, and I think you should be right, I think good teams work towards a long term vision, you're still finding ways to, to sort of, uh, deliver, uh, incremental value along the way.

Speaker A: Yeah, well, and I'll add to that. You've got the learning, you've got the incremental value, and then with that comes the confidence that we're onto something that is valuable. So that you're not discovering two years.

Speaker B: Right. Or you're delivering things that are landing like lead balloons and you're like, oh, we better pivot. Right. Let's not wait two years to pivot. We've delivered every two weeks for the last, you know, quarter, we've delivered something that hasn't worked. Yeah, yeah, that's, that's some evidence we might need.

Speaker A: Yeah, we might need a new set of hypotheses because these aren't working, right?

Speaker B: Uh, right. Exactly.

Speaker A: Absolutely. No, I love that. Well, and it's also really, I. One of the ways that I try to bring executives along on this, and I'm sure you, you've said, uh, some version of this as well, is you want that increasing certitude that your money is well spent, um, and this model affords you that. Um, it's not about fidelity to your original idea. It's about fidelity to business results, which, as Marty Kagan and I kind of got into it over this, he was kind of like, no, they're dying to let go and let teams drive. And I'm like, not. The executives that I've worked with, they want more control, not less. Um, but once they realize that they can empower a bunch of humans to really chase the same target that they have and not be so stuck on the originating idea that this has more value potential than slavishly forcing teams to follow an original idea. That is where you're like, if you let go, it'll set you free. You have the possibility of greater innovation, um, and finding out things you don't currently know. Um, and that's a good thing. It's a good thing for your business and your own success. So ChatGPT has got another question for us here. Can you provide examples of organizations that have successfully made the shift to a business outcomes focused approach in their product development, and what were some of the key factors that contributed to that success?

Speaker B: So Uh, a couple of chatgpt did pretty well. Yeah, those are pretty good questions. So uh, I worked with a small nonprofit that uh, a few years ago that did a really good job. They came to the consulting company uh, I was a partner in at that point and they wanted us to build a two sided marketplace and they had a big fat requirements book and uh, not correspondingly fat budget, nor a correspondingly fat timeline. Um, they said we have to launch this marketplace in six months. We said look, there's a lot of stuff in this requirements document that seems risky to us. We just don't know if you need it. Can we just talk about like when you launch in six months, what will be the results? What, what will people be doing? What's the evidence that the uh, that we need to demonstrate? And they said oh well we need the amount. Marketplace needs to be up and running. Okay, that's an outcome. People are doing something. Marketplace needs to be up and running. We need to have this many companies registered on this side. We have need this many people registered on that side. That's an outcome. People have registered for the marketplace and we need to have this many completed transactions in the marketplace. It's an outcome. So we said, okay, if we could do that without building any software, would that be acceptable to you? He said no, we're paying you to build software. We need this to operate. We said okay, if we could do this with building less software, is that acceptable to you? And they said well yeah. Okay, right, so now we're getting somewhere. And so we launched the marketplace, we focused on, we operated. We had I think a uh, 20 week timeline, something like that, don't quote me on that. But we started operating the marketplace manually before we had any front end. And we started with simple static web, uh, front end web, uh, pages to so that people could see what was going on, that we manually updated each time there was a transaction. And then once we started to understand the dynamics of the marketplace, we were able to then start to build um, uh, dynamic front pages and back end that supported it. And we launched the marketplace. They wanted it launched in 20 weeks. We had it launched in three weeks but it was operating manually. And then we had something that was appropriate at their 20 week deadline. So that's an example of um, a greenfield project. I will say that in existing organizations the sort of two keys to unlock it are, have data. You need to be able to understand what your customers are doing. You want to change their behavior, you have to be able to observe, measure uh, their behavior. So you have to have systems that let you see what your customers are doing. And then you have to have a culture in place that you know, or you need to start working on creating a culture that does what you've just been talking about, which is sort of changes, uh, the way leaders have control. I don't really think they're giving up control as much as they're changing what, changing the control point from, you know, you're going to make this thing to I'm going to hold you accountable for this outcome.

Speaker A: Mhm. Although, what do you do if the, I mean, oftentimes I deal with very ambitious leaders, um, and if they're, if their goals are sort of out of whack with reality, um, that. Is that achievable. How do you have that conversation?

Speaker B: Well, we don't, you know, that's another thing where we don't know. It's like, okay, we don't actually know if this, if this outcome is possible, but we're going to sign up to discover what's possible. Right. And usually along the way it's like we're going to grow this number by 75%. Okay, well, this month we grew it by 10%. Should we keep going? Yeah, that's good. Keep going. Right. At some point you're going to hit a ceiling and you're going to go to this leader and you're going to say, look what all the great stuff we've done, we couldn't get to 75%. But look, we've been, every, every week we sit down and we show you the numbers and the experiments and we're managing this conversation together. Right? And so to me, that's the way to go. Right. Which is you don't put your neck on the line and say 500% or you can kill me, but you say like, okay, like 500%. Let's, let's try, let's, you know, let's see what we can do.

Speaker A: Let's chip away at it. Let's see, see where we can get to.

Speaker B: Yeah, yeah.

Speaker A: I think, I mean there's, there's, I mean there's so much human psychology right in this.

Speaker B: Right.

Speaker A: Whether we're talking about the teams, whether we're talking about the stakeholders, whether we're talking about the customers. There's a lot of, of hopes and dreams. And then, and of course then there's the magic wand of technology in between not knowing what all, uh, technology can do.

Speaker B: Yeah.

Speaker A: But it, it is so interesting to root, to really ground this not in the technology, but in the humans. And that's one of the, one of the really wonderful things that I took away from your book, Josh, was, was you got to come back to the humans. It's always about the humans.

Speaker B: Yeah. And, yeah, and I think that's the, that's the. For me, that's the power. I'm glad you said that because for me that's the power of, of the, of the question. What do people do? That first magic question, what do people do that creates value? Let's just focus on that and then let's try and get them to do more of that.

Speaker A: Yeah, yeah, absolutely. This is fantastic. I mean, I'm already a huge fan of your book.

Speaker B: Um, thank you.

Speaker A: And definitely recommend to our listeners that they check it out. Um, uh, the case study on HBR was also really enlightening hearing, um, about some of the, the emotional challenges that leaders had going through this process and letting go of that feature roadmap and, and some of those things because, yeah, I can't imagine, um, my stakeholders, uh, in past lives being okay with. No, I'm not telling you what feature you're getting on what day. That's, that's not how this works. We're, um, going to, we're going to chase after a problem that we both think is worth chasing and, uh, how that plays out.

Speaker B: So much of this is about trust, you know, so.

Speaker A: Yeah. Oh my gosh. That's, that is the currency of our realm, as I like to tell people here. Um, well, fantastic. So we're, we're. Our time's almost up, but I'd love to subject you to a speed round, uh, of questions if, uh, you're, if you're game.

Speaker B: Sure.

Speaker A: All right. On your website you write that you like to take photos in your spare time. Um, and you have some great photos up there. If you were going to shoot on the streets of Brooklyn. What kind of camera and lens are you bringing? Or are you just going to bring your phone?

Speaker B: No, I have a Sony. I, uh, have an A6500, um, nice DLR.

Speaker A: You're showing it to us. It's got quite a lens.

Speaker B: It's got this really nice, uh, 16 to 55, 2.8, uh, wide angle zoom lens on it.

Speaker A: Brooklyn's changed, but you wouldn't be worried about having the camera taken from you or anything like that.

Speaker B: Listen, I grew up in New York City and my first, my first skateboard wrestled from me when I was 12 years old on the sixth train at 90, uh, 6th Street. So I'm used to that. And, uh, I have. I, uh, don't know. I'm not used to it, but I

Speaker A: have instincts rather than being, uh, afraid of it, uh, or what have you. You're like that. I'm emboldened. I love it. So, you know, one of the questions that, uh, we always love to ask our guests is, is recommended, uh, reading, um, besides, obviously the text that you've written, what are some things that have been transformative or impactful to you, uh, in this space?

Speaker B: All right, I'll give you one business book and one non business book. Okay. Uh, so business, uh, book, I would say good strategy, bad strategy. The Difference in why It Matters, that is by Richard, uh, Rumalt. And I think it's. It's just such a good book on strategy. I think it, it just, uh, for me, it sort of blew away the fog around the topic and, and kind, um, of helped me rethink, uh, what it is, uh, what it means when people say the word strategy. So I just think it's a. It's a great book.

Speaker A: That's. That's a really important topic. Yeah, that's. I'll have to check that out.

Speaker B: Okay. And then non business book, I would say let's do today, let's do Writing down the Bones by Natalie Goldberg. Writing down the Bones is a book about the writing process. And she talks about. In that book, she talks about the power of the sort of writing and writing and writing and writing and writing and not editing while you write. Just, you know, and for me, there's something very analogous, uh, or useful for the product development process, which is that you're not going to get it right the first time, and you shouldn't try to get it right the first time. That you have to. You just have to make things and you can make you make them, then you evaluate them later. And I think that's a really powerful lesson for anybody who's trying to do something creative. And, um, I think product teams are trying to do something creative. And, um, so I got a lot of personal inspiration from Writing down the Bones. I read that book first in college and I come back to it when I'm feeling stuck. And, um, uh, I think it's good for anybody who's working on creative things.

Speaker A: Well, and I know we're in a speed round, so I shouldn't do this, but I do have to call out the product teams as a creative endeavor or that is something. I mean, the number of people that focus on product teams as velocity, you know, productivity metrics and they really look at it as a manufacturing. A quality and manufacturing process rather than a creative process. But obviously our entire conversation suggests otherwise. Um, that this is.

Speaker B: No, I think it's a studio process.

Speaker A: Yeah, absolutely. Um, I love that. Um, so when is. Do you. When is your next book coming out? Are you working on another one?

Speaker B: Yeah. So, uh, with my co author and business partner and friend, Jeff Gothelf, uh, we are working on a book about OKRs. Oh, nice. Uh, if Fortune Smiles, it will be out, uh, this year.

Speaker A: Excellent. You know that, uh, I'm sure that Marty Kagan is a big proponent, uh, of okrs, um, and I've been subjected to OKRS done poorly. So I'm excited to read what you, uh, put out because, uh, it is really difficult, I think, for executives in the wrong mindset to grapple with what it means to do OKRs. Well. So, yeah, I'm looking forward to that. That's fantastic.

Speaker B: Yeah.

Speaker A: Excellent. Well, Josh, I am so grateful for you to come onto our podcast. Like I said, I'm a huge fan of your work already and have been using it, uh, in conversations with clients, uh, here at Three Pillar. Um, sorry about the intellectual property infringement.

Speaker B: Um,

Speaker A: no, I do give credit where I can, but, uh, you've been really influential for me and for the folks here, so thank you so much. We really appreciate having you on and talking to us.

Speaker B: Well, it's very kind of you. It's great to be here, and I really enjoyed it. So, uh, thanks for having me on.

Speaker A: All right, thank you. This has been an episode of the Innovation Engine, a podcast from 3 Pillar Global. 3 Pillar is a digital product development and innovation partner that helps companies compete and win in the digital economy. To learn more about 3 Pillar Global and how we can help you, visit our website@threepillerglobal.com thanks for listening and see you next time.