Learning to Build - The five bedrock skills of product managers and innovators by Bob Moesta

Hi, Heinz.

Yay. But also to kind of realize that I'm more of a receptacle of all this learning and that my job is now to kind of pass it forward. And in doing that, I had to acknowledge and reflect and kind of really appreciate my mentors who have all passed away. And so one of the things I will tell you is that the. See, I think it's eight. This is my office, and in my office, I have my four mentors who look down at me every single day. And they're Dr. Willie Moore, Dr. Kenichi Taguchi, Clayton Christensen, and Dr. Deming. I happened to meet Dr. Deming, if you will. Let's see if I can do that. Dr. Deming is the first one. He was the father of quality. I met him when I was 18, and he was 85. I asked him 52 questions in 22 minutes, and he just turned to me and said, boy, are you a curious kid. How'd you like to be an intern this summer? And so I had no idea what that meant. I didn't even know who he was. I thought he was somebody's grandfather. It turns out I had to go to Japan to learn a whole bunch of new methods and tools to help Ford reduce their product development cycle time. The same time I met Genichi Taguchi, I that year and had been befriended him and basically had been friends with him for over 10 years and worked side by side with him. And then my first boss at Ford was Willie Moore, who was a particle physicist, which I'll tell a little bit more later about Willie, but she was amazing. And then the last mentor that I would say had the greatest influence on me was Dr. Clayton Christiansen from the Harvard Business School, who is the father of disruptive innovation. And at some point in time, you can consider me lucky. But my mom would always say that at some point in time, luck is really not. Part of it is we have opportunities in front of us all the time, and at the same time, you have to be able to seize them and have conversations with people and interact. And so part of this is to realize I might have been lucky because they crossed my path, but at the same time, I had to have a way to engage them out of this. I've kind of synthesized what I call the five bedrock skills. The things that, like, if I really look at really good entrepreneurs and innovators and people who build product, if you will, like, what do they really have? Right? And so let's just. I'm going to go through them, and then we'll dive into them. But the five are really empathetic perspective. Uncovering demand, causal structures, prototyping to learn, and making trade offs. And the reason why there's these five is you start to realize that part of this is about seeing the world. Part of this is about basically digging into the world. The other one is understanding how the world works. And then there's one about basically realizing that we don't know. There's way more unknown than there is known. How do we actually learn? And then ultimately we can't make the perfect product. And so ultimately what are the trade offs we have to make in order to launch? And so part of this is to realize that these are inherent skills that I've been using for over 30 years. And what's interesting, over 40 years. But what's interesting is I believe that we all possess them. Most people would say innovators are born, and I don't believe that. I think innovators are made and they're made by basically building skills throughout time and space. And so I want to basically dive deep into each one of these as we go. So the first one is a really interesting one to me. And it's this notion of what I call empathetic perspective. And people who with the skill can really kind of detach from their own perspective and see subtle but important differences between many, many different perspectives. So they can see things from the past, they can actually project themselves into the future. They can see things at a very micro level and a very macro level. They can see things from an investor's perspective, they can see things from a customer's perspective. But on top of that, they know how to connect the dots to find out where the conflicts are going to be. And so you start to realize that the skill of being able to actually kind of see the world from many, many different perspectives. So the way I always kind of look at it is like it's. I got to always walk around the problem or walk around the opportunity and many, many views before I can see it. And it's something that I inherently learned, I think, because without the ability to read, I had to ask questions. And I couldn't ask questions to just anybody. I had to ask questions to a lot of different people. And I realized nobody actually had the same perspective on things. So I want to share a story about kind of how I really learned this at one point in time is that I was working with Dr. Willie Moore, who was, she was the first African American in 1970 to graduate from the University of Michigan with a PhD in particle physics. And she happened to be my boss at Ford in supplier quality, where at the time, when I was working at Ford, we were trying to reduce particles, basically, product development, development time from 72 months to 36 months. And with the guidance of both Taguchi and Deming, Willie was kind of the person who was there to kind of make let the rubber hit the road, I'll say, no pun intended. And one of the things that was happening is I got a problem very early on in, like, almost my first week, which was we had a rear view mirror, which is this mirror that kind of sits, you know, sits on the windshield. And basically what was happening is that was it was being made in Atlanta, Georgia, where it was very, very warm. And as the car was kind of the person who was there to kind of make let the rubber hit the road, I'll say, no pun intended. And one of the things that was happening is I got a problem very early on in, like, almost my first week, which was we had a rear view mirror, which is this mirror that kind of sits, you know, sits on the windshield. And basically what was happening is that was being made in Atlanta, Georgia, where it was very, very warm. And as the cars came off the line and they sat in the lot, the glass would pop out and literally fall down on the dashboard. And so part of it was being able to understand what in the world was happening and why was this happening there, but not necessarily at the other plant in Chicago. But at the same time, the fact is, we realized that it had to do with the casing wrapped around the mirror, and that the traditional approach would be go spend more money or spend more, you know, spend more time and effort and money to basically go figure out how to make it not shrink or expand during heat, right? And so we knew the cause was basically too much heat. But the way that Willie took me about it, she says, look, we can't spend any more money. These are things where we have to actually figure out how to solve them technically without actually spending more money. I'm like, okay. And so she said, what I'd like to do is become the molecule. Like, the molecule of what? She says, I want you to understand how a piece of plastic or underlying molecule becomes this case, and why is it sensitive to so many different things? And so eventually I had to go learn chemistry, though I was an electrical engineer by training at that point, though I went on to get a master's in chemistry. I learned a lot about how basically the different molecules worked, which then how are they actually you know, basically, how did they come together and ultimately how were they produced? And as we walk through this, it's about understanding each one of the really critical pieces of it. But it's almost like what happens to me when I'm made and what happens to me when I'm put together with a bunch of things. And then ultimately, what happens to me when I'm, you know, tanker card over to basically the plant where it's going to be made. And then ultimately, how does it work in the injection molding machine? And. And ultimately, how does it turn into that rearview mirror? Right. And so part of this was, as we walked through it, what was very interesting is that we were able to kind of look at this thing and say, all right, how do I actually make this mirror, this case around this thing, more or less sensitive to changes in temperature? Because what happened in the beginning was I was able to solve the problem in one way by understanding basically how to make it less sensitive to heat. But what happened was, is that when it got really cold, it would actually constrict more and it would actually crack the lens. What happened is I ended up solving one problem and creating another. Willy's whole point is, no, we need to make things more stable by understanding it. What we did is we zoomed in on the injection molding machine and was able to run an experiment that actually helped us figure out how to make that mirror more robust or less sensitive to the changes in temperature. And to be honest, we were able to kind of reduce or increase the dimensionality of the mirror. But at the same time, what we were able to do is speed up the line. And so we actually made it better and improved productivity, which reduced cost. What's very interesting as you start to go through it is this notion of being able to take on a problem and see a problem from very, very different perspectives. And so, for me, one of the things I do all the time is trying to actually see things from a very micro level to a macro level, or from a macro level to a micro level, or to study the history of something over time and to understand different people's perspectives on it. And what you realize is this, is that this is an essential skill. Whether you're building software or whether you're building hard product or whether you're teaching. It's all about being able to understand somebody else. Perpetuity, perspective. The crazy part about this thing is that as an engineer, and I'll say more of an introvert than an extrovert, what you realize is I really don't like to do this. And the only place to really learn it is in theater. Theater is one of the greatest places where you can actually learn to play a role of somebody else and almost detach yourself. And so a lot of times I will. As I mentor people, one of the things I talk about is they should take an improv class or go join a. Go join a theater company volunteer, if you will. And being able to see things from all these different perspectives and emotionally connect with people is one of those underlying skills that almost all really good innovators and entrepreneurs have. The second one, the second skill builds on the last skill, which is this notion of uncovering demand. And that most people, most entrepreneurs who really are very, very good is they realize that their products don't create demand. Demand already exists inside of people. And that in a lot of cases, what you start to realize is that we don't, you know, we think that the cause and effect is our product causes demand. But the reality is, is that demand starts from a struggling moment. And that, that, you know, people, we are creatures of habit and we'll do the same thing over and over unless we struggle. And that struggle then causes us to literally then start to seek better ways to do things. And so most people then start really good. Entrepreneurs know how to uncover demand by studying these struggling moments and understand the progress that people are trying to make in a very specific circumstance. Right. And so in Japan, one of the things that was so interesting for me is they kept talking about how do you end up talking about the requirements of the customer, that we're totally agnostic or totally devoid from the solution. So don't tell me what the product is that customers want. Tell me what customers want where I can have many solutions. The way that we do that is we use the jobs to be done framework as a way to look at. Look, there's some circumstances people are in. If they're not struggling, they're not looking to go anywhere. At the same time, the fact is that if they just have a struggling moment, but they don't have an idea of where to go. This is where people complain a lot, but they don't do anything. It's the moment that they struggle and have an idea of where to go is when progress has started. And so part of it is to realize why in the world are you here and what do you think is going to happen when you're on the other side? And ultimately, if this is a river that people are trying to cross, how many different ways can you get across there? Well, it turns out there's hundreds of ways. I can dig a tunnel, I can build a bridge, I can get a boat, I can teach them to swim, I can get a dock, I can on and on and on and on. And so what happens is you start to realize if I can actually describe demand in a way that's independent or devoid of, if you will, the solution now I can actually start to actually innovate and see things differently. And so it's this whole aspect of being very, very granular and understanding kind of that circumstance and what pushes people and what are the outcomes that pull people and being able to frame, if you will, the problem space. So then I can put multiple different solutions in it. And this is where we start to realize that most people wouldn't think that a bridge and a tunnel and a boat and learning how to swim all compete with each other, but they do in certain circumstances. And so it's uncovering demand that's really important. The other part about uncovering demand is that there's this, I call it the greatest lie that was told to me in engineering school, which was this aspect of the way I describe it is it's build it and they will come. And to be honest, it's one of those things that early in my career I would build it and they never showed up. And I realized that in a lot of cases that I was what I call supply side oriented as opposed to demand side oriented. What I mean by that is that I think of that there's two real sides of how, how building happens, right? There's a supply side of what we can, what we can build and deliver to, to the, to the market. But then there's this other side called the demand side is, is. It's the reasons and the, and why people pull things into their lives. And ultimately there's this huge wall or this disconnect between basically the supply side and the demand side, right? And again, I did so much training on the supply side of like having a business system, understanding strategy, figuring out how to build specifications to get a product, and then taking that product and figuring out who wants that product, right? And what are the features and benefits and then ultimately the experiences and attributes. But typically we climb up this wall, which I think of is as being 100ft, 10ft thick and 100ft tall, and we look down on the demand side. And what we do is we see markets and segments and Personas and prospects and like, we have all these different descriptions, but we never talk about why somebody does Something. So if we look at it, and so I helped, if you will, a mattress company, basically, who built mattresses, enter a market almost five years ago. And one of the things that you realize is as you go through this is that if I have a mattress and I see the product, you think about, well, who buys this? It's well, colleges and hotels and furniture stores and individuals and things like that. And so they end up segmenting everything out. But ultimately, what is it on this side of the world that causes people to say, today's the day, I need a new mattress. And the interesting thing is when you start to realize it is that there's usually some current product that they have some context or new context that's wrapped around it that causes a struggling moment. And ultimately that new struggling moment says I need to get something else, which then creates desired outcomes. But those desired outcomes usually never match the product. And primarily because at some point in time, everybody's desired outcomes are just a little bit different. And so they look at candidates and ultimately have higher and fire criteria and make trade offs. And the cool part about this is that you start to realize that the competitive set is completely different. So if I'm on the supply side of the world, competitors for mattresses here in the US would be Serta and Simmons and Sleep Number and other mattress companies. But when you look at it from the demand side, one of the greatest competitors to a new mattress is a product called Zquil, which is a sleep aid. And what we realized is we started to advertise things like how many bottles of Zequil do you need before you realize you need a new mattress and we got 28% increase in sales, or the reality is we end up running specials at 2am to 4am in local times because we realize the people who can't sleep are actually looking for mattresses. And so you start to realize there's a whole bunch of understanding is that by understanding this side of the world you then can actually build requirements. Right. The other thing is to realize that, that, that people buying things are not random. For some reason, we've gotten to use math as a substitute for knowledge. And so we keep building funnels. But, but of, you know, if I had call 100 people or if I do, you know, I'll get 20 to pick up, I'll get, you know, 10 meetings which will get me to two sales. But the reality is like everybody buys for a reason. Nothing is really random. Random is a way in which we describe the things we can't understand. Again, there's way more unknown than there is known. And so part of this is, how do we actually dig deep and understand the causation behind what causes people to make progress? It turns out that there's these forces that we talk about in jobs that is like, there's a push of the situation. So for anybody to switch from product A to product B, let's say from email over to basecamp, or from one CRM system to another CRM system or, you know, to working on sleep. And part of it is there's got to be a push of the situation, meaning something about the current thing that doesn't work or that is bothersome enough that they have to do it again. Irrelevant of what they're going to do, but why in the world do they need to change? And then the other part is then when they see this solution, what are the things that pull them towards it, that make them actually start to realize, like, okay, this would be a great outcome for me, but at the same time, with those two pushes and pulls, which is not really new, again, pains and gains, you can think about it that way. But the other important aspect is what I call stuff below the waterline, which is the frictional coefficients. David Schoenthal wrote a book called the Human Element around this concept. It's really about the anxiety of the new and the habits of the past. You have to give up in order to make that progress. And so part of this is to realize that at some point it's a system and that if we can understand how people decide to change, we can actually do it. And so really good innovators and entrepreneurs understand this causation aspect of what causes people to make progress, and that they're humble enough to know that their product doesn't cause demand, that the struggling moments cause demand, and for them to move on. The one other aspect of this is to realize that I had to go learn criminal and intelligence interrogation methods because I realized that most customers lie, and they don't lie on purpose, but they lie to conceal. They lie because they don't know. They lie because at some point they, you know, they're lying to themselves. And so part of this is realizing, how do we actually unpack that language to get to the causation? And so I talk about these three layers of language, and one is called the pablum layer. And I would say that the number of times I've got from marketing the requirements saying, you know, basically, I need it easier, faster, more fun, and cheap and lower, lower price. I'm like, oh, that's all great. And ultimately not knowing how to make the trade offs. And so part of it is, if even you take the word easy, it turns out that the word easy in context has almost 22 different dimensions to it. And so what happens is you start to ask people, well, what do you mean by easy? And they go to what I call the fantasy layer where they talk about, well, easy would be, is like, I don't have to think about it, easy would be magic. All these words that you're like, okay, that doesn't really help me. And so ultimately you have to be able to figure out how to get to what their definition of easy is. And it turns out 90% of the time, if you ask them, so what's hard about this? They can tell you 15 different things. And so you have to get down to the causal layer that really helps you understand this. And so as you talk to people, focus groups for me don't work none of those things because you get group think and you stay at this pabulum level. But if we do one on one interviews and literally dig deep to say what caused somebody to say, today's the day I want to buy a new mattress? Or what what caused you to say, today's the day I needed a new CRM, or I needed a new I wanted to buy a house, and you start to realize that out of that I can actually start to get very predictable about what's going on by understanding the job to be done and the pathways of progress through that causal layer. And so segmentation to me really gets down to this causation aspect as opposed to just understanding kind of the words that people use. That's number two. Number three is most people would say entrepreneurs and innovators and product people are creative people. At the same time, they're very curious people. And I believe that they're more curious than creative in some cases. But at some point they need a level of curiosity to know how things work. And that as I kind of unpack this, and I again reflected on all the people I worked with, is that there's a really big understanding of how to think about how things work and that they actually end up having mental models at this very, very detailed level about how things work. And I was taught some very powerful mental models that, to be honest, allowed me to work in so many different industries. And what you realize is again, most innovators and entrepreneurs, they have these default views of the world. Some are good, some are bad, but most of them have multiple. There's never just one. And it allows them to see things from different perspectives. So think of it as the causal structures are the different lenses that they can see the world through. Empathetic perspective. One of the things is Dr. Deming. The funny part is in working with Dr. Deming, he was 85, I was 18, 19 years old at the time. And one of the things I did not realize is that when, when you're hard of hearing, you speak louder because you can't really hear yourself. So you, you speak at a voice that you can, that you, you can hear yourself, but you're actually screaming. And so at some point in time I always thought he was screaming at me. So I have these quotes in my head of every time we would, we would be together and I was always like, afraid of like, why is he screaming at me? It turns out he needed hearing aids. But the, but the, but the aspect is like he'd always say, if you can't describe what you're doing as a process, you don't know what you're doing. And so to me, if you can't describe how something works, it's really, I don't know what's going on. And so part of this is that quest for knowledge of how things work. And so you start to realize that causal structures is this aspect of having the mental models and having a way in which to see the world and being able to kind of put things together. And so one of the things that I was taught very early was systems thinking where basically there's inputs and actions and what we would call control factors that, that go into some product or some, something we do that, that creates some output that goes to some customer. And that there are what we call control factors, things that we are responsible to set like the, the injection pressure and time for the injection molding machine. But there are noise factors like the temperature and humidity of, of the, of the, where, where the product performs or the loads, etc. But the reality is, is that, that my model has evolved over time to basically be a little bit farther, which is that, that ultimately that customers don't want just some output for some product. They need to actually achieve some outcome with it. And so ultimately this whole aspect of being able to understand how to build something is that I'm not just trying to build a product that gets to some set of outputs or performance outputs. But what are the outcomes that people really want to be able to understand? The simplest way I can describe this is that recently I've. Through the pandemic, I Was able to lose almost 70 pounds. But the interesting part is, like, my goal was not to lose 70 pounds. My goal was to actually go skiing with my family. Because I had gained so much weight, it was very difficult for me to ski and I was missing out. And by understanding that this was all about me getting to a better outcome, to be honest, I didn't really use weight as a metric, but it was one of those metrics that everybody said, oh, you're losing weight. They only know how to describe it that way, but they didn't understand the outcome. I wanted to. And ultimately what I learned was the fact is that if I just controlled the calories I took in, the sleep that I got and the exercise that I did, which are, to be honest, those would be what I call specs or like, how many steps did I get in a day? I would call them lead measures. Ultimately, if I did those things right, I wouldn't have to worry about the weight because at some point in time, it automatically comes off. And so part of this is to actually understand and see the world from this larger perspective of outcomes, Consumer outputs system, and move what I call right to left. Right. And so ultimately, that's the other thing that's part of this in my mind is that I ended up most of the time right when I build something, when I design something and I test something, I'm actually moving constantly what I call from right to left. Right. But the thing is that I think because most people read left to right, they always think about having to have the idea first and have to have what if I have these inputs or I have the system, who can buy? And we always try to move left to right. But one of the keys to building very successfully is to actually don't think about your product first. Think about the customer and the outcomes they want and then figure out what are the important outcomes, outputs you need to actually produce. Then what are the system I can put together and then what resources do I need? And so it's. It's almost working backwards, but in some cases it's actually in my mind, it's working forwards. Right. The fourth one, the fourth one is really about this whole aspect of what I call prototyping to learn. And what what's really interesting is, is in that book that I have, that, that I showed you in the beginning is that this is written in 1990, is that. And it still holds true today, is that most people think of AB testing. And to be honest, I was always taught AB testing was the worst, most inefficient way in which to test anything, and that at some point in time it's not reproducible, it's very hard to know why something is better. And ultimately you don't know how to prioritize or do different things. And so what's interesting is in my notes it would say something to the effect of in the west, we test to prove a hypothesis that something is true or not true. In Japan, they would basically test because they didn't know this whole aspect of do you form a hypothesis and prove it, or are you not even smart enough to have a hypothesis? So you have to test to learn about what's going to happen. And again, as a dyslexic, I always felt like that was one of my things, is everybody would have a hypothesis of how something would work. And I was never smart enough to have a hypothesis. So the first thing I would do is go run some tests to look for the anomalies to figure out what's going to happen. And so I actually end up learning design of experiments as a way in which to kind of test. So I can start with the lowest cost system possible and only add things that add value. Where the way I was taught in school was to build the best thing and then figure out how to take out the things afterwards. And it would be hypothesis building. And ultimately I would never look at it properly. Right. And so this really came true in how we studied when I was at Ford, basically what we call red line development, which is as we go from the concept of what we're building to basically building it out. And if this is the number of changes that you have on the vertical axis and this is time on the horizontal axis, we'd actually, you know, we'd make changes, but we'd make very little changes in the beginning. And as the system would come together and to be honest, we would have, you know, everybody's system would work perfectly independently. Oh, I got this to work. I got that to work. But when you started to put together, you started to realize all these interdependencies. And ultimately the fact is the changes would go up, you know, over as we get closer and closer to launch. And then we'd make this Nike point decision where, like, just do it, just launch it, we'll fix it later. And ultimately you'd see the changes go up after launch, and then you'd see them go down, and then ultimately they would tear off over time. But if you really start to think about the cost of a change, the cost to make Changes upfront are way cheaper than making costs on the other end. And so you start to realize that the fact is that at some point when we looked at Toyota or Honda and Mazda and how they actually, you know, they were actually able to beat us as there's two things is that they actually did a lot more experimentation up front to know how things were interdependent. And they did it in a way that actually would cause failures before they would happen so you could learn. And so ultimately their pattern of change looked like this and that they were doing almost 10 times more prototypes very early in the system. Part of this thing to know how it would break so that when it did break, they actually knew what to do where here in the red line, we'd always be doing things where we would be reacting. And Dr. Taguchi would always call it whack a mole. We'd solve one problem and cause another. Part of this also goes back to the notion of how we think about prototypes and the kinds of prototypes and that ultimately I think about there's two different types of prototypes and that there are, there's actually many different types of prototypes. But there's, there's what I call divergent prototypes contrast to create the meaning. And then there's convergent prototypes which actually then help us basically decide which, which thing to do to make the trade offs. And so you start to realize that at some point I feel like that one of the keys is that I would always build sets of prototypes. And those sets had such a deep meaning to them because they would help me understand kind of what worked, what didn't work, and being able to get perspective on things where most people are just testing AB and if B is better, they don't really know why B is better. They just move on. And then they do another AB and then they do another AB. And by the time they're into 10 ABs that they realize like they have a house of cards because they don't really know the interdependence of how anything works. And so to me, really good innovators and entrepreneurs know how to actually cause problems. They know how to actually make things break. They're okay with it. And they're, they're not so dependent on hypothesis proving kind of prototyping, but more prototyping to learn. And I'll say the rabbit hole here is that in teaching young people these days how to prototype, the first thing I do is just try to have them think about three really different things or different ways to do something and use that contrast to create the meaning. But at the same time, the fact is the body of work here is really around design of experiments and what we would call robust design of experiments or rdo, and learning how to actually be very efficient at the way we actually build prototypes. But realize that I don't know the outcomes I'm going to get from them. I'm going to use math to help me make sure I cover a space. So Instead of building 200 prototypes, I can build 10. And out of those 10, those 10 help me represent the space that actually then I learned from and how to figure that out. And so to me, this is a really, really critical skill that I feel is the number one thing that in software, specifically, because we do a lot of AV testing and we wait for it to break as opposed to trying to break it. The last one is a very interesting one as well, because we always talk about optimization and trying to be the best at everything, or we want it to be all of these things. But the thing I would learn or tell you that I've Learned over the 40 years of building is that there's never a product good enough, there's never a product cheap enough, there's never another product fast enough. And so ultimately I have to make trade offs to figure out what are the most important things. And one of my colleagues that I've worked with for a long time, his name's Jason Fried, he always says, you're better off with a kick ass half than a half asshole. And the reason why this is such a powerful statement to me is a lot of times is that what you realize is that we try to build the perfect product. Because again, I think we've been trained to build the perfect product and that we were told that there's a solution and we shouldn't compromise. But when you start to look at both the cost to get there and the time to get there and the resources to get there, the reality is that a lot of times something that's a kick ass half is way better than a half asshole. And so you start to realize, how do we actually figure that out? And so part of this is being able to actually help people understand how do we actually think about the scope of something, the time of something, the cost of something, and the quality of something. And ultimately what's very interesting is most of the time we have fixed scope and then what happens in fixed quality, and then when we can't reach it, we then vary the cost or the time, more money at it, more time at it, et cetera. And what I've learned over time is that it's actually. And so we'll talk about Ryan Singer in a little bit about shapeup is that what we actually do is we actually fix the scope. We fix the time and the scope, and we make it fix the time and the cost, and we then have variable scope that allows the team to actually make better decisions along the way and be able to manage trade offs. Because we usually plan the project when we're the stupidest, and then we're held accountable to our stupidity by management and innovation to basically go hit that milestone when the fact is, halfway through the project, we discover 20 new things we have to do that we didn't know before. And we either ignore it or we try to fit it in and we don't get it all done. And so part of it is empowering the team to actually think a bit, a little bit differently and thinking about kind of being able to manage by understanding the trade offs we have to make. And so ultimately it's this aspect is you have to be able to think about as a customer, desirability, viability, and feasibility. Right. To me, desirability is what does the customer want and what progress are they trying to make. Viability is economically viable, and that feasibility is, can we actually do it? And you start to realize there's two kinds of value. There's supply side value, which is profit, and there's demand side value, which is progress. And so part of it is to actually understand how do we get to the right progress so people will pay us as much as they can, but at the same time, how do we do it in a way that limits that we can do it so we make a profit. So a lot of times you have really good products that, that help people make progress, but economically they can't make money. Or we have the other way where people make a lot of money, but they're actually not helping people make progress. And so it's, it's ultimately, how do we actually figure out that, that, that sweet spot in between all of them, right? So as we go through this, I got a one, one, one quick case study to talk about how we apply all five skills. So this is one of my, my very good friends. His name is Ryan Singer. He was the head of strategy at basecamp for almost 17 years. And his boss was Jason Freed. And Jason went to Ryan and said, hey, I'd like you to write a book about how we, you know, how we build product here at Basecamp, because I think that's Interesting for people to learn about, right? And Jason's written, you know, some amazing books, all of them New York Times bestsellers. And Ryan has never written a book in his life. And he's to the point where he's like, why don't you write it? I don't really want to write a book. And at the same time, the fact is, what I always say is really good innovators and entrepreneurs, when they don't know what to do, they actually know exactly what to do. And so I want to talk about Ryan's journey in writing his book. And so he sat down to try to write this thing, and he's like, at some point in time, he just got all kind of locked up, and it's like, what am I supposed to learn? What do the people want to learn? What should I teach? And he started at it from the supply side, and he goes, okay, I got to think about this from the demand side. So the thing he does is he announces basically going off in 2018. November, right? He literally says, this is November, and by December 3rd, you have to have an application. He's going to run a workshop for one day called Shape and Ship about teaching people how Basecamp builds product. And he tweets this out. And when he tweets it out, he actually builds a form that allows people to. Well, he first, he builds a website for people to kind of sign up for it. Gives a little understanding of what it's about, gives his thoughts around it is no. No real material, but literally gives a very short period of time, and then has a very long application, right? And out of this, within a week, he has over 200 applicants. And out of it, right after he built kind of that survey out, and the. And the application took a long time, was a very long form application. Out of the 200 people, he picked 20 people. And then what he did is, is that, all right, got it. We're going to have this thing in December. And he sat down to write material, and to be honest, he wrote an outline. He built, you know what? I only have eight hours. What can I actually put in? Eight hours. He had some thoughts of it, but it was more. Not like this was the answer, but let me give them at least a bunch of things that we do that would be interesting to them. Right out of that, he goes and runs the class, right? And what's interesting is the class. I was there. And one of the things that Ryan was saying is, like, I'm not sure. I think I only have a half day's worth of material. It turns out that he had probably four days worth of material that he tried to pack into one day because there were so many questions and comments. But ultimately this was a prototype. Not to figure out what to do or what was the content, but more about why did people come. So what he did is after, and right after the New year, he sat down and interviewed people about why in world would you spend a thousand dollars to come to a class around how we build? And it turns out that there were four different jobs, right? Help me shift responsibility. One of the reasons was, look, look, I end up having to do all this work and I end up trying. They always come back to me to answer the questions I need to actually figure out how to push responsibility down to the team and enable them to actually be better. Another one is help me make progress in building product faster. Another one was help me bring my team along. And the last one is help me put the ideas in a form that other people can act on. And so as he looked at that, he said, okay, if this is what demand is and this is why people are coming and I have to do that, what are the things that I can do to help them get to these outcomes? And so out of that, basically, he came to the office and we sat down and we wrote this very large. Not expecting you to read any of that. But the reality is, as you look through it, it ends up building systems to say, if I teach them this and then I teach them that, I can help people get to their outcomes. So ultimately, he built a set of systems of shaping, betting, and then basically building that helped him actually kind of then figure out what were the common things he had to actually put in there.

And.

And thinking about each chapter as a system, about the. The inputs, the actions and the outputs and examples. And so that gave him then the chance to kind of now go off and write chapter by chapter. And he would start with pictures, right? And then ultimately would add words to the picture of kind of what they were trying to do and was able to write the book basically in about three months. At the same time, what he did is he went off and found a couple of people who wanted to implement it. So what he did is, as he wrote the book, he built a version of it where people could come and see it, but not as a PDF but as a page by page so he could actually see who was spending more time on one page versus another and being able to see what was going on. He literally recruited people like Chris Speck and Ilya Staron and Andy Weispecker to say, hey guys, we're. Would you be willing to try this in your organizations where Chris is at a company called Auto Books and Ilia at the time was at a Lifetime Fitness and Andy was at Target. It was all different kinds of organizations to basically see how it works. So again, prototyping to learn to say what, what language is resonating, what language isn't resonating, what's going on. And then eventually he basically ran another workshop and in running this other workshop now he had the materials, he did the same thing and basically recruited specific people who were in those struggling moments and wanted the progress that he had designed the book for. So it wasn't just accepting anybody, it was actually trying to make sure that we could understand who would really make progress with this book and whether it worked or not. And so ultimately, how did Ryan do in building a book? Well, again, this is a first time author, never wrote a book before, right. This is just the web traffic that he had when he first launched the web part, which was, I want to say it's in like July is when he finally got like kind of in a complete form that they made it public. Right. He ended up having almost 345,000 unique visitors in 90 days. He had 10,000 downloads when the PDF became available. Right. He's sold over 100,000 copies since he's launched it. And part of it was this whole aspect when Ryan Singer didn't know what to do, he knew exactly what to do because of his five skills and how good he is at those five skills. In conclusion, these five skills really relate to the supply side, demand side thing. And I always think of demand side is really about who, when, where and why. And ultimately to understand the demand side, I need to be able to understand, if you will, kind of how to build things. Right. And the product is what, how and how much. And so if I can actually understand design requirements from the customer side and system requirements from the, from the, from the, the product side, I can ultimately then map into the five skills and that what you start to realize that empathetic perspective is needed for all of this. And I be, if I'm building, I got to use it on the supply side again on the demand side. At the same time, uncovering demand is at the center of being able to get to design requirements or customer requirements and being able to understand the progress they're trying to make. Ultimately causal structures help us understand the systems that we have to build or the technology to Pick and then ultimately using prototyping to learn and making trade offs as the key to get that wall to just disappear so we actually have better fit between the product and the other side. The other part is that these are not independent things. And so again, I, I had 10 things at once. I had it down to three, I had sometimes 12. It went back and forth. But ultimately these, I feel, are like the five real bedrock things. And when you start to look at all of these, and I say, if I work on empathetic perspective, does it help me with uncovering demand? If I work on uncovering demand, does it help me with empathetic perspective? And so this is where I talk about the notion of that. And I learned very early that there's a natural priority to the work. And that if you do this thing called an interrelationship diagram, you can start to realize, like, at some point, as things interrelate to each other, we start to realize that there are some things that are more important than others or that we should be doing in a different sequence. So if I just simply think about the ins and outs of each one of these things, and if it has more outs than ins, it's ultimately a root cause. And if it has more ins than outs, it's actually what I would say, an effect. And so if you look at this, you start to realize empathetic perspective has a lot of outs. And it's probably the number one thing, four outs and one in, where making trade offs is one of those things that, if I understand these four things, making trade offs is easier to do. And so ultimately there's a hierarchy of this that then we can translate into basically how do we actually study or work on these things? And so the thing I want to be able to really emphasize is that we all have these skills. They're part of what you do every day. Right? And ultimately, the fact is, we do this when we plan a meal, when we're trying to plan our week, when we're going out to a restaurant, when we're planning a vacation. We have these skills. But innovators and entrepreneurs and product people, the really successful ones, have learned to take these sets of skills and ramp them up from a level 2 to a level 10. And so my suggestion is to identify the skills that you need to work on in the book. I basically talk about different resources and skill, different exercises and things you can do to kind of help you build out your skill set. The other thing to realize is that I don't believe anybody is good at all five of them. And that. This is the other part is when you start to build a team is that what I've found is very successful teams might have two or three people who have very, very good expertise. But. But. And two or three of them. But the team as a whole has the core of all five. Right. And so this book was really written as what I call the supply side learning how to build. I wrote another book called Demand side Sales, which is how do we help people make progress? And these two books come together to help us understand, if you will, what's. What's going on? To learn more, I just started a podcast. We just ended season one called the Circuit Breaker. And it's literally us talking about not only these things, but just building in general. And if you like the listeners, we're looking for ideas for the season two, we're just starting to record it out. Best way to reach me, if you will, is on LinkedIn. More than happy to just connect that way. And then I post most of my stuff there between the circuit breaker. And then for the most part, right now I teach at the Kellogg School in. In Chicago or in Evanston. And then I still build products. I still build my own products. I got four products I'm building right now. I got two software products, two books. And then I help people build products every week, which is so much fun. So now hopefully we have questions and there's still people there. Let's see. I want to stop sharing here and exit.

So thank you very much, Bob. Really sorry.

That's very hard to do when you're. When you're so. Hold on. What am I doing wrong here? Let's see this. Is that me or you?

I think it. I think it's not sharing if something wrong with us. Okay, no problem.

You have a very. There we go. I have a very sophisticated camera system, so, like, I have. I can change my views.

I think I did it wrong. It was my fault. I'm supposed to sit here, I guess.

Yeah, but I have, like. So how can I. So what are the questions?

Great. Thank you very much for the talk. There was so much stuff in it. It's like, unbelievable. I mean, I had the advantage to read the book beforehand and still there was so much stuff. I was like, processing heavily. So question. I'm sure there is a ton of questions. So who wants to go first? Robert, here in the back. Let me throw the microphone to you. One second.

Yeah.

Well, thank you very much, Bob. I mean, Thomas has taught me so much, and by proxima then you have taught me so much more. So thanks for that. You mentioned at the trade off stage I used to work with corporates innovation quite a lot and you said so management has to report or you basically have to report to management. When you run a project then you get all these variables and then you kind of try and squeeze it in and you make these trade offs. From your experience out of the past working in organizations, how do you best manage your managers to give you a bit of flexibility so the reporting is not too stringent so you can make, don't have to make too many trade offs.

Well, I don't. So the thing is that you have to realize innovation to me is very different than manufacturing. And we've tried to use manufacturing analogies to run innovation but, but the big difference is, is that in, in manufacturing we know a lot, we know how it works, we know how we put it together, we know what's going on. But in innovation or entrepreneurship there's so many unknowns that, that we really can't build a plan that's comprehensive enough. Because think of it as like a weekend we learned so much more that like there's stuff we missed or we thought something was going to be easy and now it's hard. And so I think it's more about preparing them for the trade offs and realizing that I'd rather have budgets and tell you where I'm at and help and helping me make the trade offs as opposed to trying to say like we're going to get to this outcome we plan when we're the stupidest. Right. And this is where like, like, like somebody's asking me, you know, so I, somebody asked me the other day, it's like, all right, we need to build a budget for the next 24 months. I have no idea what we should be spending next September, but I'm guessing and then when I get there that might be completely different. And so part of this is to realize that the way we do it is we reserve capacity or we reserve budget and then we let the team decide the best way to use that in order to make progress because they know where we're going and they know where we're at. And the reality is this is where I feel like I call it the Church of Finance because the Church of Finance is trying to actually figure out how we're spending, what we're doing. And the point where a 25 year old, you know, finance person can sit across me and say I'm not innovating enough. I literally want to, you know, go like, really? The fact is they don't know what I'm doing as well. Well, you plan this and it's not there. It's like, yeah, but if you don't understand how innovation works. And so part of this is setting expectations with management. And to be honest, it all starts with something I call a postmortem. Let's go look at the last three or four innovation projects we did, maybe one or two that were successful and one or two that weren't successful, and start to understand the characterizations of the unknowns and how we prototyped and how we actually went AB testing as opposed to design experiments. And so postmortems are the best way to set expectations with managers of saying, how do we learn from the last couple of innovation projects to do a better version of the next innovation project? And it can start to break down some of those barriers at some point. If they don't understand innovation, they're going to try to manage it just like a manufacturing process. And my belief is that's very difficult. Is that helpful?

Yeah, absolutely. Thank you very much.

I have a question as well. In your book, I mean, you have a lot of examples with hardware products, yet we live in a world and there is a lot of software product development here. So can you elaborate a little bit about the difference between hardware and software and set some emphasizes on what's important?

Yeah, yeah. So one of the things is this is that so I had software examples, but nobody would actually let me release the software examples into the book. So I had to go back in time to one demonstrate it. But Ryan Singer and I are kind of working on ways in which to articulate software examples around it. But think of as you think of Basecamp, for those of you who know what Basecamp is basically project collaboration. It's been around for almost 15 years, 16 years, and it's wildly successful. But the thing is, what you realize is that it's not for everybody. And to be honest, it's one of those things that what it's trying to be is actually at the low end of the market of it's better than email and a shared folder. It's one of those things where it's starting to organize in a certain way, but it doesn't have resource allocation, it doesn't have Gantt charts, it doesn't have all these other things. Part of this is that all if you start to dig in with these lenses into other products, you start to realize Intercom is another one who is very good at this. But at the same time, the fact is these principles are true, and the fact is they work very well. And then part of it is to basically understand these different areas. So, like one. One quick example is at Basecamp, people kept asking for a calendar, and Basecamp really didn't have a calendar. It had a place to schedule, but it didn't actually have a full calendar because they've figured, like, most people use Google or Outlook or whatever, and building another calendar doesn't make any sense. And so when we dove into kind of why they wanted a calendar, it turns out that in Basecamp, we would talk about all the things that you had identified and when you're going to do them, but it never actually talked about where you had capacity. So what they would do is they go to basecamp and they had to do something, and they couldn't figure out when to schedule it. And so. And they kept asking for a calendar for that reason. But what we ended up doing is learning about it in such a way that instead of building a full calendar, what we ended up building was basically an inverse of what your schedule was. So you could see the spaces. And the moment that we built that, which only took about two and a half weeks, the moment they built that, people said, oh, my God, thank you for the calendar, but they never built a calendar. Right. And so this is where there's many examples around that have that. But it's like uncovering the demand of what people really meant. It's about seeing it from other perspectives and why. It's about prototyping to learn to say, is it really a calendar? Or is it just this or this or this? And they literally took, you know, almost like what they do, you know, at Apple, where it's like, let me show you where you have dots. Let me show you where you don't have dots and your overall macro calendar so you can actually figure out how to schedule things. And so it was a very interesting example where a calendar would have taken almost 18 months to go build a pretty good calendar. And the reality is they were able to actually solve the problem in two weeks.

Nice. All right, so let's do one more question. Who wants to ask a question?

No.

Oh, yeah, we have question.

Hi, Bob, thank you for your talk. One main question at the end, you said, yeah, or like, you had only one of your slides. Incorporate this kind of approaches in your daily life. What kind of approach?

And how do you train on a daily basis?

These skills? Yeah, yeah, yeah. So. So to be honest, I. When I'm When I'm just so. I'm very bad at small talk. Like, I don't really know how to pass the time because it's one of those things where I. I'm very introverted. And so the way that I practice is I literally, as quickly as I can, I get to something that. Trying to find something somebody struggles with. And I'm constantly asking them what they're struggling with, what they're doing about it, how they're doing it. So I. I'm literally practicing in my small talk of just figuring out how people are. I go deep in terms of trying to uncover the demand of what progress they're trying to make. So, for example, I'm doing a book right now on what causes. So there's a huge employment problem here, at least in the U.S. i think it's around the world, but I'm not too sure. But I've been studying why people leave one company to go to another company. I've been doing that for five years. It all started as small talk, and now I have over 400 interviews. I've built some processes around it to help people understand how to define progress. And I'm building a coaching platform to help people figure out what's their next product. And so all of these things I try to apply to cutting my grass, to. I have a sailboat. So when I sail, like, all these different things, I'm constantly trying to weave it into my daily life. And practice. And practice, and practice. It's almost. It's very, I'll say, Eastern kind of philosophy of like being in the moment and being able to practice this, the skill. Cool. Thank you.

All right. Thank you, Bob. Thank you very much for that talk. It was really amazing. I put the bar very high, but you jumped easily over it.

I don't know about that. I don't know. I think I ran through it because I had so much material. So it's more than jumping over it. It's more. Probably just at some point, there's. And there's so much for me to share, and I want to be able to share more and more. So I truly appreciate you having me. I really wish I could be there in person, but at the same time, I can. I've been. I've literally traveled. Like, I've had eight flights this week. And so it's just been a crazy, crazy week. So I appreciate not having to go, but I would really wish next time I'll come. I'll come there and see you in Munich.

Yeah, hopefully. Hopefully we can do that in the future. Thank you very much. That was really, really good. Give him a loss.

Thank you.

And I mean, literally, if something triggered you in this, in this talk and you think, like, that's really interesting, I only can recommend. Most of the stuff is really described in more depth in the book. Get the book. Read it. It's really helpful. I love the stuff he does. Jobs to be done is one of the most helpful things, I think, in product management. It really aligns or gives you a direction where you need to go. Thank you, Bob, for all that stuff. Okay, wonderful. We see in 15 minutes again, here, Siggy will talk about how he created AI portfolio at Siemens. Yeah. See you later.