Josh Seiden broke into product development from the designer’s perspective, crafting beautiful things he could be very proud of. Sometimes they worked; sometimes they didn’t change human behavior at all. “That deafening silence that comes when no users engage with your product is just a terrible feeling,” he says. So what we’re always trying to do is generate the maximum outcome from the minimum output.

In this episode of the Product Momentum Podcast, Josh presents a simple but thought-provoking framework, called The Logic Model. The framework introduces three important levels: outputs, outcomes, and impact. Outputs, Josh adds, are the stuff we make. Outcomes are what we get from having made the stuff. Impact is the change in user behavior that drives business results.

To change human behavior, Josh adds, product teams need to do three things: understand how their work aligns with the overall strategy; express that strategy in terms of outcomes – not outputs; and be aware of the big uncertainties that are out there. That requires discovery.

“Discovery may reduce your team’s delivery velocity,” Josh says. “But it also means your product development is more efficient. Prioritizing the things that create value…outcomes over outputs.

Tune in to catch the entire conversation with Josh Seiden.

Podcast: Play in new window | Download

Sean [00:00:19] Hello and welcome to the Product Momentum Podcast. This is a podcast intended to entertain, educate, celebrate, and give a little back to the product leadership community.

Paul [00:00:32] Well hello and welcome to the pod! Today, we are excited to be joined by Josh Seiden. Josh helps teams design and deliver products that people love; helps companies of all sizes create the culture, practices, and processes to do that better; and he’s the author of Outcomes over Output (2019), and he has co-authored both Sense and Respond and Lean UX in 2017. Josh, welcome to the show.

Josh [00:00:54] Oh, thanks so much. It’s great to be here.

Paul [00:00:56] Absolutely. So you’ve spent a lot of time with companies helping them understand what outcomes are, which begs the question, why is the concept of outcomes so hard? It seems like this intuitive thing. It seems like a word we use every day, but it seems also to be sort of a paradox of sorts. What is this thing called outcomes that we’re going to jump into here?

Josh [00:01:17] Well, you know, that’s actually kind of the basic reason I wrote the book is that the companies and clients that I was working with were trying to be more effective in their work. And so they would say things like, “we’re trying to be more outcome-focused,” you know, and then when you actually started to dig into what that meant, it meant lots of different things to lots of different people. Right? And so sort of part of my motivation for writing the book was to say, “Well, let’s be specific about what we’re trying to do here; let’s pick a shared definition, and let’s really kind of follow it to its logical conclusion.”

Paul [00:01:50] What is that definition? Is it a big red button that people push and… What is the outcome that a product team can focus on?

Josh [00:01:58] Right? No. You know, most product teams start with that. “Let’s make a big red button,” and that is output. That’s the stuff we make. The outcome is the results that we get from having made that stuff. So I say that the definition is it’s a change in human behavior that drives business results, change in human behavior that creates value for the user, the customer, the organization that’s hosting the service. And when you do that, you’re really kind of shifting teams away from the big red button as the focus of everything. You still need a definition of what you’re going to make, but you balance that definition with, “OK, well, let’s be specific, what are the results we’re trying to create?” And we’re going to talk about that result in terms of a change in human behavior.

Sean [00:02:45] All right. Well, you’ve been in this business a long time.

Paul [00:02:47] Yeah.

Sean [00:02:48] As have we. And it seems like it comes up over and over again like we need to focus on the users and these outcomes, but we always tend to go back to outputs. You know, every large organization I’ve worked with has this hyper-focus on features for dollars, you know, code that’s getting pushed out the door and measuring the outputs over the outcomes. Why is that?

Josh [00:03:10] Yeah. I think there are a couple of big reasons for that. And you know, I think the first reason is that, you know, when we talk about planning, outputs tend to be what we think of first, right? I’ve been doing this a long time, I’ve been teaching teams to use outcomes. And, you know, my brain goes to outputs first, right? I’m a designer. I think about solutions, you know? And so I just think there’s something about the way we think that it’s easier to think in the concrete terms of what we’re going to make, rather than in the more abstract terms of what the results are going to be. So I think that’s part of it.

Josh [00:03:42] But I think the other reason that it’s hard is that it’s easier to manage if we tell people what to do. Right? We have a tendency and a legacy of this kind of micromanagement. You know, “I’m the boss and I’m going to tell you, team, make me that thing. And it will be easy for me as a boss to tell when you’re done because you’ll show it to me and I’ll say, ‘Oh, look, it’s done.'” Right. And so I just think so many of our systems and so much of our history is that this is how we manage the product development process that it’s hard to break out of those legacy patterns.

Sean [00:04:15] Do you think there’s also a tendency for teams to… I have an observation. You tell me whether or not you think it’s wrong, but like when there’s any sort of like lack of psychological safety, there’s a tendency for the teams to want to just be like, “just tell me what to build.”

Josh [00:04:29] Yeah.

Sean [00:04:30] “Just give me the order and I’m just going to build what you tell me to build so I can say that I got it done and I did what I said I was going to do.”

Josh [00:04:36] Yeah.

Sean [00:04:36] You know, and it’s almost like it’s a squashing of the creativity of the teams for the sake of being able to say, “I finished something, I got it out the door.”

Josh [00:04:44] Right, right. Yeah. “Don’t ask me. I just work here.” Right?

Sean [00:04:48] Right.

Josh [00:04:48] Yeah. You know, I think that’s a really important point to call out, you know? So why are outcomes useful, right? Outcomes are useful for a couple of reasons. They’re useful when it’s not clear what we should do. Like, we’re trying to get people to spend more money on our website or we’re trying to get people to read more of our content or whatever we’re trying to do, and we’re not sure how to do that. So when we frame the problem in terms of the outcome we’re trying to get, right, we tell teams, “Hey, get people to spend more time on the site, get people to read more reviews, get people to check out at a higher rate,” whatever that is, we’re admitting none of us know the answer, right, and we’re giving the team permission to go figure it out, and that’s a big shift, right? And a hard one to do, as you point out, when there isn’t psychological safety. Because if there’s no psychological safety, there’s no safety for the boss to say, “Hey, I don’t know the answer, you all figure it out.” And there’s no safety for the teams to go try a bunch of different things until they succeed. Right? Because that means failing until they succeed. And so this way of working with outcomes implies, one, that we don’t know the answer, and two, that we have the permission and the space and the wherewithal to do product discovery.

Paul [00:06:11] Yeah, you’re starting to, I think, come to a really helpful conclusion to this definition question. But I do want to go back to one thing that you said just a moment ago about, it’s easier to measure the thing that we got done, or it’s more concrete to plan things that we can see and say that we accomplished. That kind of begs the question in my mind, why is that not wrong, but maybe unhelpful? Why are those things maybe not the most optimal targets that we should be shooting for? If we say the team got the thing done, just to tie a bow on this definition question, why are those less helpful or less optimal planning devices than outcomes per se?

Josh [00:06:49] You know, just because we built it doesn’t mean it works. You know, and it can kind of work in the technical sense, right? Like I press the big red button and whatever is supposed to happen in the requirements happens and it passes all the tests and all of that, but it may or may not create value. And so when I say “we don’t know if it works,” what I mean is we don’t know if it creates value. We don’t know if it creates value for the user, the customer, or the business. And so we have, like, amazing technical prowess to design and build incredible things, you know? But we don’t know if those things are going to generate value for us. And so, you know, I spend a lot of time working with scrum trainers. Scrum has this idea of the definition of done, like a piece of software is done when it meets the sort of team-defined set of definitions, right? And we know, OK, it’s potentially releasable when it meets the definition of done. We need the definition of done. The definition of done is valuable, but then we need a second thing past that. There’s done and then there’s validated. And validated means, “OK, we shipped it, it works, we put it in the world, and then we observed it to see, did we validate that this thing created value or not?” Right.

Paul [00:08:02] That’s profound. I think that is a missing piece, and I think it bears repeating that we test. We have unit tests, we have automated tests, we have this definition of done. We have code that’s shippable. We have user stories and full vertical slices. We have all these extremely discrete definitions of how we ship code and how we build features. But that thing that you just said, there’s almost a “so what?” missing at the end of user stories.

Josh [00:08:27] Yeah.

Paul [00:08:28] “As a user, I want to X, so that Y.” So what? And there’s almost this missing clause in Scrum that really is worth defining. That’s a great definition.

Josh [00:08:37] I think for me, this goes back to an insight that I credit to Eric Ries, who wrote The Lean Startup. And Eric Ries always said, you know, “the important question is not, ‘can we build it?’ But ‘should we build it?'” You know, and I think a lot of the sort of Lean Startup methods and a lot of the product discovery methods that I’ve spent a lot of time in my career working on are about trying to do as much validation as possible before you actually build stuff, you know, so that you don’t waste all of that time and money and effort building software that doesn’t deliver value.

Sean [00:09:10] Yeah. Do you think there’s such a thing as an ultimate outcome? Like, we know we’ve got to deliver value, but beyond delivering just value, most of us are building software products that people use. And I love your concept in your book about, like really don’t think we should be measuring for value is behaviors. And in my opinion, like, if they come back and they keep using the product, we know it’s delivering value.

Josh [00:09:31] Yeah.

Sean [00:09:31] So there’s some level of engagement there. At the highest level, they’re willing to help us invest in making this thing even better.

Josh [00:09:37] Yeah.

Sean [00:09:38] I call that an advocate, you know?

Josh [00:09:40] So in the book, I use this framework that I adapted from the nonprofit world, and it’s a framework called the logic model. And it has sort of three important levels in it that I talk about in the book. We’ve talked about output, right? That’s the thing you make. It’s the big red button or whatever. And we talked about, like when you put that thing in the world, what will people do with it? Right, that’s the outcome. That’s the change in behavior. But there is this higher level that you’re talking about, which in the framework is called an impact, right? And so these are sort of the hard-to-define precisely, but obviously valuable things that we’re trying to generate. So they’re things like revenue and profit and loyalty and satisfaction and, you know, advocacy, right? And so the challenge with those is not that they’re not important and it doesn’t mean that you shouldn’t measure them, you should, but that they are complex, and so they’re the result of lots of factors.

Josh [00:10:36] So if I’m thinking about my product teams, I’ve got a team of three or four people working inside GE or JPMorgan Chase or any big company in the world, right? And I can’t go to a team of four or five people and say, “you, you make customers loyal.” Right? Like, I can’t do it, you know, like, their work could contribute to it, their work could make it or break it, but they can’t do it by themselves. And so what you want to do is you want to have this sort of smaller scope to the team level targets. Those are the outputs. And they contribute to the bigger ones. So you say when we’ve created customers who are advocates, what do they do? Well, advocates leave reviews on our site. Advocates recommend us to other people. Advocates sign up for our beta programs. And then you can encourage teams to sort of work on those specific behaviors. But you sort of have to work backward from those big, hairy goals because they’re hard to work on or perhaps impossible to work on directly.

Paul [00:11:36] Yeah. One thing that a listener hearing that definition of I have a key result that I am laddering my output to align towards might be instantly thinking you’re talking about OKRs.

Josh [00:11:50] Yeah.

Paul [00:11:51] And when you’re aligned to an OKR or a goal-oriented plan, it can be helpful, as you said, but it might not be necessarily an outcome that you can put into a roadmap or a backlog. Is an OKR the same thing as an outcome-driven plan?

Josh [00:12:09] Yeah. So I do a lot of work with teams that are implementing OKRs because it can be another way to talk about the same sort of thing. Like ultimately, we’re saying, what are the goals that the organization is setting? Outcomes fit nicely into OKRs as a system when you use outcomes as your key results, right? So we’re trying to launch this moonshot. That’s your objective, whatever it is, right? And we’ll know we’ve succeeded when… What? What are people doing differently, right? And so a lot of times what you see is in OKRs, you’ll say, “Well, the KR is something like well we’ve launched this platform.” Who cares? That’s not a key result. That’s an important precursor to getting the results, right. But what you really care about is what people are doing with the platform.

Paul [00:12:59] Yeah. And not just what people are doing, but which people and what results are you measuring? Right? How specifically are you being with your KR?

Josh [00:13:06] Right, right. And I think part of your question, too, is that you know, OKRs kind of nest within each other, right? And so you kind of break them down and break them down and you’ve got company level and team level and you know, they sort of should sort of flow into each other.

Sean [00:13:21] So one piece of criticism you probably hear a lot of is that being outcome-focused instead of understanding and talking about what we’re going to actually build will lead to waste. How do outcomes enable agility and hypothesis-driven work?

Josh [00:13:34] Well, you know, from my point of view, it’s sort of more the opposite. Like, the reason that you’re focusing on outcomes is you’re trying to eliminate waste. And that focusing on outputs, you’re building stuff, but you have no guarantee that that stuff will work and you can spend a lot of time, you know, gold plating a solution that doesn’t work before you ship it and then you ship it to the deafening silence of no users engaging with it or whatever. And so, you know, I think if you’ve worked in product development for any length of time, you’ve had that experience of building something that you think is going to be great and building it, putting it in the world, being really excited and then nothing.

Josh [00:14:16] So I think what you’re always trying to do is you’re always trying to generate, and this is kind of a framing that I credit to my friend Jeff Patton. Jeff says you’re always trying to create the maximum outcome with the minimum output, right? What’s the smallest amount of stuff we can make or do to get the maximum result? And so you’re always looking at it with an eye towards eliminating that waste. What’s the smallest amount of stuff we can do to get that result? As opposed to, what’s the most beautiful or greatest or best product we could put in the world for whatever other reasons? And listen, like, I’m a designer by background, like, I got my start designing beautiful things that I was very, very proud of and that took a lot of, you know, design and engineering skill to get into the world. Sometimes they worked and sometimes they didn’t. And when they didn’t, that’s just a terrible feeling, you know? So that’s kind of the point.

Sean [00:15:11] Yeah. There’s a lot of language in our industry that’s floating around OKRs and, you know, outcomes over outputs and living in the problem. You know, Marty Cagan likes to say, “you got to love the problem.” Or is that Dan Hudson? Or both of them?

Josh [00:15:24] Yeah.

Sean [00:15:25] Like spend a lot of time in the problem before you solution. You know, and design sprints are kind of engineered that way as well. We got to solve problems at the end of the day. If we don’t solve problems, we’re not going to get anywhere.

Josh [00:15:36] Right. Yeah, I mean, one of my early bosses, my first job as a designer, I worked for a guy named Alan Cooper. Alan wrote a couple of great books. He wrote a book About Face. That was the first user interface book that really got me excited about this kind of work. And he called his design system goal-directed design and it was all based on the notion of understanding what users are trying to do and then designing solutions for that. And so I think you’re right like there’s lots of language that we can use to describe this. And, you know, I like this system of outcomes. I think it’s pretty precise and useful for a bunch of reasons. But, you know, I think there’s lots of other ways to slice this apple, so.

Paul [00:16:17] Yeah. You just started talking about system and building a process on top of this thing. And it is a well-worn discussion in our industry about, what are the jobs to be done, what are the ways that we can turn the abstract into the tangible? And I wonder, you’ve got an entire master class about this exact topic, so I don’t expect an entire condensed version of it right here. But what would be some of the hallmarks of a sustainable process that generates the outcomes we want to see in the world?

Josh [00:16:46] Well, you know, I think part of it is that teams have to understand, first of all, how their work aligns to strategy, right? And you think that that’s kind of an obvious thing to say, but it’s actually pretty surprising, like very few organizations have a clear line between the work they’re doing and strategy. So I think that’s the first thing is really having those conversations and then being able to translate those conversations, if you’re thinking about outcomes, into understanding, “when we are achieving our strategy, what are we doing differently? What are our customers doing differently? What are our users doing differently?”. And so being able to kind of then, like, express your strategy in terms of outcomes.

Josh [00:17:29] So one, understand your strategy. Two, express your strategy in terms of outcomes. Three, understand kind of what are the big uncertainties here. Like, “oh, we don’t know how to get people to do X,” right? Whatever that thing is that, you know, when our strategy succeeds, people are doing X, but we have no idea if they want to do it or if they can do it or how to get them to do it. And so that then implies discovery, right. And so I think as an industry, we’re pretty good at designing and building stuff, you know, and we have lots of methods for designing and building stuff. We have lots of methods for discovery. You know, there’s a lot of very skilled researchers out there, but we don’t, as an industry, prioritize discovery as much as we need to. Right.

Josh [00:18:15] And so we have the methods. We know it’s important, but we’re still obsessed with cranking out as many ones and zeros as we can crank out, you know? And I think when we start to actually look at what it costs to do discovery, even though, you know, my argument is doing discovery means your product development is more efficient. It looks expensive because spending time on discovery reduces a team’s delivery velocity. And so do you want to deliver the most stuff or do you want to deliver the right stuff? And I think having a sustainable process, to come back to your question, means a real focus on delivering the right stuff, and that means a real prioritization of your whole team oriented around discovery.

Sean [00:18:58] Yeah, it’s even more complicated than that, because rare is the product that solves one problem or that we’re looking for one outcome from.

Josh [00:19:04] Right.

Sean [00:19:05] In today’s day and age, the things that we’re solving are complex and intertwined with other things that are going on in complicated people’s lives. So this is our challenge, and this prioritization problem, I think that’s the key problem that we have to work on solving for product leaders.

Josh [00:19:19] I think that’s right. And I think prioritization is super hard because it really actually means saying no to stuff, you know? And that seems to be a difficult thing to do, to say, “you know what, we’re not actually going to work on this feature request this quarter.” You know.

Sean [00:19:35] I like that. I like to say that objective prioritization is impossible.

Josh [00:19:38] Yeah.

Sean [00:19:38] You have to experiment and release things in iterations and see what works and what doesn’t.

Josh [00:19:43] Yeah. And we don’t know, right? We have hunches and some of us have louder hunches or more powerful hunches than others. But, you know, where does that get us?

Paul [00:19:52] So if our listeners have been enjoying this conversation and they want to learn more about how to put outcomes into processes that can be predictable or replicable in their organizations, where might they learn more about how to get ahold of you, get ahold of your information? The book, obviously, but what else do you have out there?

Josh [00:20:13] Sure. Well, you know, you can always reach out to me on my website, which is joshuaseiden.com. You can kind of see what’s on offer there. I’ve got the book, obviously, that’s a great place to start. The book is really short, designed to be read on a flight from New York to Boston if anybody’s flying these days. And there’s a companion course, it’s a video course, that goes along with the book. It’s about an hour of discussion about the topics that are included in the book. And I offer private training and coaching and that kind of thing. So always happy to talk to folks.

Paul [00:20:45] Outstanding.

Sean [00:20:46] One last question for you. As a practitioner in this industry, how do you define innovation?

Josh [00:20:52] Oh. How do I define innovation? I think about it as meeting an unmet human need in a new and valuable way.

Sean [00:21:03] Great.

Paul [00:21:04] Love it. Josh, this has been a pleasure. Thanks so much for taking the time to spend and chat with us today.

Josh [00:21:10] Awesome. Thank you guys so much for taking the time to talk. Appreciate it!

Paul [00:21:14] Absolutely. Cheers.

Paul [00:21:17] Well, that’s it for today. In line with our goals of transparency and listening, we really want to hear from you. Sean and I are committed to reading every piece of feedback that we get, so please leave a comment or a rating wherever you’re listening to this podcast. Not only does it help us continue to improve, but it also helps the show climb up the rankings so that we can help other listeners move, touch, and inspire the world just like you’re doing. Thanks, everyone. We’ll see you next episode.