Climbing the confidence ladder with Lean UX - with Josh Seiden, Consultant & Author

Welcome everyone to another episode of the Product Bakery Podcast. I'm here today with my dear co-host Christian, as well as a special guest, Josh Seiden. Hi folks. Before we jump into today's episode, I quickly wanted to share with everyone that, as usual, you can find all the episodes on our website with some episode minutes and also the possibility to leave your comments, leave your questions and interact with us, as well as the speakers if you have some questions for them. Besides that, feel free to check out our social media channels for all our alternative content. And with that said, I hand the word over to Christian for a first introduction. So hi Josh, it's a pleasure having you. And as Alex already mentioned, we always introduce our guests. Let's talk a little bit where you are coming from, because you started your career in the early nineties, which means you are quite around for some time in the world of product and design, and you worked in several positions. And just to mention some of them, you work as managing designer, as design group manager, program director. You've also founded a couple of companies, which is super impressive. So that's definitely a good starting point for today, I would say. But I would like to highlight that you are these days working as independent coach and consultant, as well as author, working for big clients such as American Express, PayPal and HSBC, just to mention some of them. And I read your book, Lean UX, and I'm pretty sure that people who are listening to the Product Bakery podcast know your book, and people who are working with problem statements and hypothesis-driven research and development definitely have heard about your name. But before we talk about the methodology, I'd like to start with a Lean question. What's keeping you busy these days? First, I just want to say it's great to be here with you guys. So thanks for having me. Yeah, it's funny you mentioned the book, Lean UX. That's my first book. I co-wrote that book with my co-author, Jeff Gotthelf. And that book, first edition, came out in 2012. And what's keeping me busy literally today is working on the third edition. So Jeff and I expect the third edition to be out this year. So our deadline is fast approaching. We're working fast and furious. What has changed from the first edition to now? I would say a couple of things that are significant. One is obviously the technology keeps moving. For example, I was just working on the section today about design systems. And I think we take design systems for granted now in 2021. But when we wrote the first edition of the book, they were a new thing. And I felt like we were telling people about design systems for the first time. So that's obviously something that's changed. The other thing I think that's changed a lot is this sort of ubiquity of user experience design. And big companies then didn't necessarily think design was important. And now most large companies that have a digital operation, they've implemented design or are implementing design at scale. In the same way that they're implementing product management at scale. And companies are trying to figure out how to do this. And I think in some ways, it's some of the same battles that we were fighting 10 years ago. But it's not a battle to get hired into these places. It's more like, how do we figure out how to do the work in these new contexts? And we've seen certainly the rise of things like design ops and research ops. And so the context has changed somewhat. And so we're writing about some of that. I couldn't agree more that I would say people still think these days that design isn't that important as well as product in some companies. And if we talk about design ops, design systems, et cetera, we have addressed these topics already in the podcast. And we would also love to hear from you today, your experiences, as well as establishing a mindset that is, for example, focused around working with problem statements and hypothesis instead of just throwing something into a team and just saying, do it, which would be a super example of a wrong implementation of design and product driven mindset. Yeah. But also here, I think while you say, Christian, people maybe still don't see the importance. I think people do see the importance, but it really comes down to how to actually work with it, because they might know how important it is, or they might know that companies who manage to apply also design thinking and so on in a good way or can be more successful. And I think a lot of companies struggle to really apply this. And I think, yeah, getting your view on this, Josh, is also super, super interesting. I think the conversation about whether design is important is maybe we're a little bit past that one, but I think the conversation about what design is, is still present and how to use it is very much present. And I think you hear a lot of people talking about the commodification of design or the production line implementations that you see in large companies, which is what you guys were talking about, which is make a thing. Come on, stamp it out on the assembly line as fast as possible. Don't ask questions, just stamp it out. And I think that remains a challenge for technology teams and product development teams. But maybe if we just stop here for a moment, because you said defining what design is, if we would talk about the definition of design, and I think maybe to designers listening in who have to advocate or still show what design is in their companies, or maybe for founders who are listening in that want to understand what design is, how would you define design in a couple of sentences? Oh man. So this is the kind of question that's going to get me in trouble. So I think the limited understanding of design is that it's how we define great solutions to problems. I think the broader understanding that designers have understood for a long time is that design is about defining the question as well as defining the answer. So that it's about understanding the problem and opportunity space and helping to define where we're going to play in that problem and opportunity space, and then coming up with the solution for that. The thing that's changed a lot in contemporary practice is I think it used to be that sort of all of that work happened in advance before construction or implementation. And now teams have to figure out how to do that work continuously. We're always looking at the problem space. We're always looking at the opportunity space. We're always looking at the context and always trying to figure out what the next question is, and then come up with the answer. And then we do it again and again, hopefully in an iterative way. And that's the context that technology has brought to us. That's the sort of working context that Agile has brought to us. And that's sort of where Lean UX comes to be useful because it's a way of doing sort of the traditional work of design in this continuous, never-ending context. As far as I remember from your book, defining a problem or identifying problems was a bigger part of your book that you elaborated on. So I would be curious learning about what are the steps to define a problem in the right way? And what, for example, makes a problem statement a good problem statement? I think a good problem statement is one that sort of understands in a simplest way, it understands and articulates the needs of the people that the design solution has to serve. Designers for years have been thinking about this as a sort of a user-centered design problem. And so UX design always starts with this idea of who are the users and what do they need. But a good solution also has to, we sometimes don't call that out in design practice, but we need to, it has to understand the needs of the business and the needs of the user. You need a good problem statement at a minimum, at a very minimal, to understand the sort of contextual, the strategic moment of the business and what the business or the hosting organization, the sponsoring organization is trying to do. And the needs of the user, that's a simplest case and what they're trying to do. And if you can solve for both of those things, a good problem statement sets it up so that it makes it possible to understand both of those things and then hopefully solve for both of those. These days, the systems that we're building are not always as simple as having a company and a user. In a business to business context, you've got a customer who buys and a user who uses. And then increasingly, you've got systems like, I'll just pick on Uber for a second. Uber has users and they have drivers and they have lots of people at the company who are working to keep riders safe. And so all of those people are users. They've also got the potential for bad actors in the system. So a good solution really starts to articulate the points of view of all of these interested parties. So that's one element is that it's broad. The other element for me and a lot of my work these days is that a good problem statement is expressed in terms of the outcome that you're trying to create. And so a lot of times, companies that make things tend to look at the solution as, well, we'll put this thing in the world, right? Whether it's a phone or a pen or a piece of software, and then we're done. But you're not actually done. You're done when the user gets value from it. And that means he or she can use it to achieve some outcome. For me, a good problem statement expresses what people are trying to do and expresses the outcome that you're trying to generate. Which, if I remember correctly, brings us also a little bit in the direction of the way you need to have assumptions and the way you then use them also to write your hypothesis. So maybe we can also talk a little bit like how to write a good hypothesis and to then really bring it into the product process. Yeah. I think a lot of the traditional ways that we used to talk about design and engineering and product management, we were dealing with a different category of thing that we were making, right? So we were dealing with, let's just say, cars or bridges or things that were hard to make, things that were hard to make well, but things that were physical goods that could be specified with great certainty. A lot of the design world grew up around designing for print, where you were designing for a magazine to go to a printer. You knew what the technical requirements were. You knew what the product was going to be. With software, we're moving from what complexity theorists say, we're moving from complicated products, right? Like a Ferrari or a Rolex watch to complex products like Twitter and Facebook and Uber, where you have all these different actors in the system who are behaving unpredictably and the relationship of the parts is unpredictable. So we put these systems in the world, we're not sure what's going to happen. Even as we're building them, we're building them with lots of maybe some things we know for certain, but some things are many of the things that we, much of the information we use to build these systems are guesses, they're hunches, and they're what we call in the Lean UX book, assumptions. We think the user is this person. We think they want to do X. When millions of them are on the system, we think this is what's going to happen, but we don't know. A lot of times we can't know until we put some of this stuff in the world and start to see what happens to it. Instead of a traditional process where we write down the specification and then we build it and we put it in the world and we're done, we say, no, our goal is always to learn our way forward and to figure out, especially paying attention to our risky assumptions, putting things in the world in a way that helps us test our risky assumptions. We do that. We express our risky assumptions using hypotheses, which are borrowed from the scientific method. They let us express our guesses or our hunches in a way that lets us test them. All of this, by the way, this set of notions is really something that I picked up from the Lean Startup world and from Eric Ries' book, A Lean Startup. That's really the reason that Lean UX is called Lean UX and not Agile UX. It works in an Agile context, but it uses the approaches of Lean Startup to do its business. You mentioned that technology gets more complex and also we don't know what's going to happen with all the systems that we're building. I'm trying to understand how the work or the methodology of problem statements and hypothesis are harmonizing in multi-product environments. So not only talking about complex system that we have, but also many different products that we have that then have, for example, overlapping personas or users. So how can we establish or implement such a methodology in a complex environment, so to say? Yeah, I think it's the same problem. It's just a question of scale, right? It's with where are you looking? Because your starting point is you're trying to put something in the world, or you're trying to make an intervention in the world to change something. You want people to use your new social network to share photos of their kids, as opposed to using last year's social network. How do you get them to do that? How do you understand that environment? How do you create the spark that causes that transition to happen? I think it's if you look at any environment that you're deploying your solution into, if you look at it from the right angle, it's a complex multi-product environment. But at the same time, hearing this, it also feels like a little bit sometimes we really need to also find a problem. Because I think, especially if we talk about which is the next social media, there is already one out there that tries to solve specific problems. But then if you want to find your place in the market, and obviously now hear a lot of also adoption and product markets which comes into place, but you also need to find this problem that might not be super obvious, but might be the one reason that makes your product successful, right? Yeah, a problem or an opportunity in a lot of what happens in social networks. And I'm no expert on social networks. I'm sure that there's a social network experts out there listening to this who are going to take me down for this. But you know, a lot of what goes on there is sort of generational. And to some degree, it moves like fashion. I don't want to hang out there. That's not a cool place to hang out. Or those people aren't the cool people to hang out with. I want to go hang out with the cool people. However you define the cool people. And if I look at who's on Facebook now, who's on Instagram, right? That's a huge generational divide. If I look at who's on Clubhouse, it's moving through social groups. And so it may not be it may not be a problem as much as an opportunity. What's the dynamic that we can take advantage of to solve the same problem in a new way that is attractive in a way that the old way wasn't, right? And on top of that, I think no matter which problem or let's say which hypothesis you define to identify the next big thing, you should always combine it also with success criteria to as early as possible figure out if you're on track or if you're moving into the wrong direction. Talking about the world of Lean Startup, I believe that defining clear success metrics or understanding what you want to measure is definitely a crucial step to be able to be successful in your validation afterwards. Yeah, I was talking about it with someone recently, and we were talking about climbing the ladder of confidence. You have a new idea, you don't necessarily know very much about it. And so what you want to do is you don't want to spend a year building your test, right? What you want to do is you want to learn as much as you can about it as quickly and cheaply as possible, right? Because if it's a bad idea, you want to spend a day on it. You don't want to spend a week on it or a month on it. You want to know as quickly as possible. And so having to your point that the success criteria in advance, what do we have to see to know that this is a good idea? If I put up a landing page and I get 10 signups on my landing page, is that good or bad? It really depends on the context and the team. If I'm selling $5 widgets, it's not good. If I'm selling $500,000 sports cars, maybe that's pretty great. Absolutely. And I think as we're going also in this direction now, one thing where I would be curious to also get your view on is the topic of MVP. And we touched on this in a couple of episodes. And I think you also, you had examples of MVPs that could be something also as a very low fidelity paper prototype. And I hope I'm not quoting you wrong here. Because I feel like when you look into product companies, whenever the word MVP falls, it's usually a product that makes it out of the door. And a lot of the time it stays there as a product for quite some time. Sometimes forever. Yeah, absolutely. So I would love to try and define MVP a little bit further. So MVP is one of these terrible phrases. It means a different thing to everybody. If it's the first version of the product that goes out the door, okay, you need to ship a first version. So I don't think that any of the definitions are inherently bad. Some of my guess is like the cheapest, crappiest thing we can ship and never pay attention to. That's just bad practice. But my point is, it means a lot of different things to a lot of different people. And so I try these days not to use the phrase MVP. But when I do it very specifically in the lean startup sense, which is it's the smallest thing that you can do or make to learn the next most important thing you need to learn. So if we go back to what we were just saying, you have an idea, you don't know if it's a good idea or a bad idea, right? An MVP would be a cheap and fast thing that you do to start to get a little bit of confidence that the idea is either good or that you can throw it right away. So an MVP is a thing you might be able to do in a day or a week for very low investment. Once you've got some confidence, the next thing you need to learn might take you a little longer. So your next MVP might be something that costs a little more money and takes a little more time. But for me, MVP is, in my definition, MVP is a method for learning. And so I think it's clearer. And with the people I work with, I tend to use the word experiment to represent that idea. Because experiment has, I think it more clearly represents this idea and it's got less baggage associated. An MVP is an experiment. Now, I think the first person who used the phrase MVP, and forgive me, I'm forgetting his name, but it was before Eric Ries, really did mean it in the other way. It's the smallest thing that satisfies your market. That's a fine definition. That's not the lean startup definition. I think some people use that definition, but I try not to use the phrase just because there's so much confusion attached to it. Yeah. I fully agree. And that's also why I was really curious to get your version of it, because I keep having this conversation with different people and everyone has a different idea of MVPs and putting it as an experiment and a way to get more confidence or climb the confidence ladder. That's a really nice way to also describe it, if in that context of experimentation and not viable product on the market. Let's take it in our conversation as an experiment. Josh, what are the biggest mistakes you see when people build or launch MVPs? Yeah. So I think there are a couple of possibilities. One is you're not sure what you're trying to learn. And so if this category of experiment that is less of a scientific experiment and more of a kind of an artistic experiment, like an artist drops a pebble into a still pond and says, I'm going to see what happens. Oh, look, it's beautiful. Like they weren't trying to learn anything. They were just trying to see what happens. That's interesting. That's valuable. That's viable. But for product teams, like just seeing what happens is an easy way to waste time and money. So I think the first thing you want to do if you're thinking about this is really having some clarity about what you're trying to learn. And then the second thing is having some clarity in advance about what success and failure looks like. If I, again, to go back to the earlier example, if I get 10 signups, if I build a landing page and I try and get people to sign up for my mailing list or get signed up, sign up to learn more about this product. If I get 10 people to sign up, is that good or bad? And so having a conversation with your team about what kind of results you're trying to get and what success looks like, what failure looks like and what ambiguous results will look like. That's another thing that I think teams sometimes another place that people stumble. And then I think the third place that people stumble is over-engineering or gold plating your MVP, right? You can learn a lot by when I did a great, I did a workshop, a sort of a startup weekend workshop a few years ago, people were trying to learn about, they had an idea for a product that would help homeowners hire people to help them with home repair. And their MVP was they went and they stood in front of one of the big hardware stores in that city with a big sign saying, home repair advice, $1. That was their MVP. That was awesome. That was awesome because they got to talk to all kinds of people and learn all kinds of things and had very little relationship to what the final product was going to be. But it was a great example of not over-engineering your MVP. Yeah. And I feel like this might actually also be a big problem, especially for designers that love perfectionism. I think for designers, it's like really hard to create a certain level also of pragmatism to launch something that's not great yet, just for the sake of learning, or to literally just stand outside of the building with the sign and learn from it because they want to build these shiny interfaces or products. But I see this also on product manager level, that there are a lot of product managers who also tend to rather go to a full-fledged version or a more complex solution instead of just taking it easy and going with the most pragmatic way. I think in both cases, one of the things that happens is that we get used to this idea that we only get one shot at it. And I think that happens for a lot of reasons. It happens either because we work in a waterfall context where we only get one shot to make it great. And so we've got to make it great before we hand it off. And then the other time that happens is in bad Agile processes. You build it once, you ship it, and you never go back and look at it again. So a good Agile process is iterative, and you can ship a crummy version of it, and then a week later, make it better, and a week later, make it better. And you get to work on it for however many weeks until it's great, and then you can move on. And so I think teams that have that experience of really collaborative, iterative work are much more comfortable putting something out in the world that's not fully finished. And I think that applies to designers and to product managers equally, and engineers. I think the best thing you can do for a team of craftspeople is to get them shipping and iterating on a regular cadence, because that really gets rid of that perfectionism, or I don't know if it gets rid of it, but it's a powerful way to combat that perfectionism, and say, look, the first draft is going to suck, then we're going to edit it, we're going to edit it, and we're going to edit it until it's pretty good. Shifting the mindset. Yeah. And I think way too often, unfortunately, it also happens that you have so many priorities on the plate that when you're working on shipping that one version, it will probably take some time until you can touch it again, because the next thing is already standing in front of the door. And I think this might also be the reason of this mindset of having only one shot, because so many things just stay there. Yeah. There are a lot of things that drive that feature factory mindset, but it shows up as having too much to do. But in fact, it's a problem with product strategy, right? Because if you had clear product strategy, you wouldn't have too many things to do. You would have one thing to work on, and you'd have a clear rubric for saying no to some of that shit work that distracts teams and keeps them from doing a good job. Yeah, I agree. One thing that I also wanted to ask you, especially in regards of testing approaches, for example, standing in front of a building with a sign, which I love. To me, there is nothing nicer than finding some creative approach to guerrilla test some things. But how do you see this current pandemic also affecting, for example, the way we test experiences, the way we test prototypes, or the way we interact with our users for user research? Yeah, it's certainly changed things. I guess that's the understatement of the year, huh? I think the work continues, and I think the teams that I've seen that are continuing to do this have made a pretty good shift to remote. And so there's some things you can't learn remotely. There's something special about sitting down next to someone at their desk, and working with them for a while. And then a co-worker comes over and interrupts them, and you listen to that conversation for a little while. And sometimes that can unlock the key to an entire problem. So there's something special about being there in person. But I think that the remote tools are pretty good. And I've seen a lot of teams do really interesting work. I've seen it opens up the possibility for a broader geographic reach in user research. One friend of mine is working on it. The team that works on international versions of their product, they're based in the US, but they have a global presence. And the international team typically spends a great deal of time on the road, traveling to whatever country to do in-country testing. And now this in-country testing is being done with the team not traveling. They're just, they're working remote, working with local partners. And I think it's offered some opportunity. Cool. Josh, to wrap up our conversation, there's one last question that we have. Actually, one of my favorite questions, because you have so much experience. And from the day you started working with hypothesis and problem statements until today, what was for you personally, the most important thing that you have learned? I don't know if this is the most important, but I think it's one of the most important things, if you're thinking about Lean UX, which is what we've spent most of this conversation talking about, which is that Lean UX is really about taking an experimental approach to design work, saying we're not sure what the answer is going to be. And so in order to find the answer, we're going to experiment. And a designer I worked with about six years ago by now, a terrific designer named John O'Maloney said to me, it's not an experiment if you're not willing to kill the idea. And I really think that's the key to the whole Lean UX mindset, which is that if you've got a feature spec and a product requirement, and you have to deliver that, Lean UX isn't going to help you. Lean UX works when you have an opportunity to really sincerely embrace a learning approach to the work. And it starts with admitting you don't know the answer and going from there. So I would say if I want to leave people with one bit of wisdom, it would be that. It's the choose the approach that fits your situation and then embrace that uncertainty and go for it. And don't be afraid to kill it. I think these are great closing words. Josh, thank you very much. Oh, thank you so much for having me, guys. It's been great to be with you this afternoon. Amazing. Thanks, Josh. It was very nice talking to you. Before we close the call, I remember you mentioned about your most recent book. So maybe we can quickly share also with the audience what it is about. Yeah, thanks for asking. My most recent book is called Outcomes Over Outputs. And it's a short book about methods you can use to connect design and agile and to create more effective agile teams. I'm leading a 90-minute masterclass on April 28th. And we'll put the link in the show notes. And I'd love it if listeners could join us. Amazing. You have more than a month to sign up. So listen carefully and sign up to this workshop. Terrific. Cool. Yeah. Josh, enjoy the rest of the day. See you. Thanks so much. Yeah. Take care, guys. Bye-bye. Alex, I think last time you promised that we're going to talk to more people from the Lean series. So we did today. What's your debrief feedback? To be honest, it was not on our roadmap. Josh, so nice. It's an interesting story. Yeah, but we were really not planning on having this session launched today. And we are actually like fiddling it in because I think it fits very well also with last week's episode. But sorry, I got distracted. What was your question about my roadmap? No, my question was, what is your feedback? What is my feedback? I thought, what is my roadmap? My roadmap is to have more people from the Lean series. We're coming to an end soon. I wanted to have a proper definition of MVP. So I think I can take that box off. I really wanted to hear Josh's version because I just remember it's been a while since I wrote a book. It's also curious to read the new version. But it was like one of the things that made me think because he literally like mentioned or he literally described MVP as something that he used to test the different ideas and not as like a product that you need to launch to the market. And there were examples of paper prototypes. I can assure you if most of the companies I worked with, if I go in and I'm like, here you have your MVP and it is a paper prototype, I will probably not get my salary. But here, I think a good question to our audience. Just remember back on all the projects that you have done. Was there ever the time where you could have put out a prototype and saved much more time instead of building something? I would love to hear your feedback on social media if that ever have been the case. And I think the ones that are doing it are on the right path or doing it the right way. So I would actually be also curious to hear some good examples because I'm pretty sure they are out there. But more than just the experiments, I think one thing that I would also love to hear is about products that you didn't launch because in the experiment, you actually didn't manage to prove your hypothesis. Because I think this is something where probably I would have the biggest difficulties with like in really saying, okay, this great idea that I had is not successful. I'm not going to launch it. And I'm taking whatever I've done until now and throw it to the bin. And I think this is something I assume many people would struggle with as well. And yeah, curious to hear your stories. I think maybe at some point, we should make an extra episode like a kind of fuck up night, fuck up not launched night, to talk about projects that have never been seen the light of production or have been in touch with customers. I remember once a colleague of mine, he was working for 30 years in product. And he told me that they worked on a product for more than a year. And then they decided to cut it off. And these experiences can be very painful, but they have to happen. Did you ask him if there was an easier way to test that? It was a very waterfowl-ish approach. And they just at some point realized, no, don't do that. But this is also the price you have to pay if you dictate things top down instead of choosing the way of experimentation. And that brings me also to my key learnings today, because just simply the reminder to think about what you want to learn and what you want to achieve out of an experiment and out of an MVP is the very first step. And I catch myself sometimes not doing that and being too fast. And I think it's a very good reminder from Josh today to highlight that and to really ask yourself, what's the outcome that you want to have? Cool. Take a look at his book. Take a look at the masterclass. It's highly recommended. Subscribe to the new book launch. I mean, there is no one yet in the calendars, but keep an eye on the new book. And if you have some time left, don't forget to follow the Product Bakery podcast. And share it with your friends. Transcribed by https://otter.ai