 So the talk I'm giving tonight is about development of a new product and actually commercialization, which I'll define in a moment. If you're a coder, how do you survive in this environment and how do you thrive? This is the talk that no one gave me 20 years ago, so I'm sharing it with you. So here's the outline. I'm gonna take a moment to define what is new product development and commercialization that's gonna be helpful. And then I'm gonna give two extremes of how folks talk about new product development. Once again, I only got diversion from the MBAs mostly, okay? So I'm gonna give you the other side. That, I'm gonna define a couple of ways what it means to win, because I'm in this to win, not just to collect a paycheck. I'm gonna talk about something I've been developing myself called development options, so I'll explain what that is. And then the meat of the touch is gonna be six ways to synthesize and exercise more attractive options. So I don't wanna just say you have options, like two bad ones, I want two better ones. And finally, I'm gonna end up with something I'm just developing this year called focus and expectations, which is a little broader version of a topic that you might have heard of. It's usually called business and execution, which ties back into the two approaches to product development. And then in the end, you're gonna still get to code, but you're gonna be a coder with a better perspective. In fact, a more powerful perspective, you'll be more, I think perhaps if you choose to follow some of these steps, more respected even. So that's sort of the promise of the night, so we'll see if we get there. So as some of you know, I like South Park. And in season two, they had an episode about gnomes, and this is a spoo for that. But if you ask someone to explain what product development is, they usually go something like this, step one, idea, and then add enough to that idea to at least fill up one or two pages. So not just an idea to a napkin, but I'm suggesting you have to have at least one or two pages worth. And that might be things like who's gonna buy it, how much might it cost, how long will it take, some basic things, one to two sheets of paper. And there's various names for these, the format, but it comes down to enough to fill one to two sheets of paper. And then, that's step one. And then they go, and then step three is win. And usually, win means abundant sales, abundant profits, money, bonuses, whatever. And then you'll notice that's always in terms of what the MBAs like to think about. So those are typically what it's talked about when it talks about win. And then, as in South Park, then somebody raises their hand and says, what is step two? And they go, step one is an idea, and step three is win. They go, what is step two? And they go, well, it's just development. You just tell the guys what you need comes out magically. So we're gonna talk mostly about that question mark. We're gonna talk a lot about the question mark in the middle. So here's one definition of commercialization. It's from the Product Development and Management Association. And it's their pitch on it, but it basically covers the idea. So it says, beside coders, to get a product successfully to market means you have to do things like have something called launch, ramp up of sales. You might have to have some marketing. You might have to develop a supply chain, how these people get the product. Where do they buy it? They had any training to use it. And then what happens when it breaks? Or Apple pushes an update and it stops working. These and other things, this is the definition of commercialization. So it also means if you didn't catch it, it means that the product is sold, typically for money. It has competition. There are other choices. And when people buy it, they expect it to work. And if they don't, they get mad and do all sorts of things. So I picked the title, Coding to Commercialization, because you all know what coding is. And we're going to talk about commercialization, which essentially means you have to work with some other people. So this is going to come up a little later. But in the bottom right-hand corner are two snowmobiles, two people riding them. And we can guess that they're having fun. We can guess that when they want to ride them next time, they'll still start and they'll still go and all those sorts of things. So they produce more than one. And when this guy hits the ground, it's not like the tracks are going to fall off. So it's going to be sturdy and all that stuff. So we're going to come back to this idea of snowmobile. But the key thing is there are people riding it and enjoying it. And they paid for that experience. They didn't pay for a showroom photograph and a list of specifications. They wanted to do that. So that's called what? It's called user experience, customer experience. This is what they're paying for. So that idea is going to come up again later. OK, here's what gets a little more interesting. In step one, when you have this idea that to get to step three, there's a lot of forecast guesses, hypothesis, opinions. And that never had a good name that I understood. So I'm now calling it just expectations. So I conclude all those first items. And there's an expectation that my R&D folks and my marketing folks can actually do all the things that are required. They're going to meet their schedules. And they're going to, if you want a newer term, they're going to achieve product market fit. And they might make some minimum viable products if you want to put those new words in there. But there are expectations. But once again, their forecast guesses hypothesis. It's an expectation. That's my bucket word. OK, so there's also an expectation that some people and budgets and other resources are going to be available. Somebody decides they're going to have an expectation of certain metrics, milestones, schedules, and timelines. Once again, just an expectation. There's an expectation about what the competition is going to do next year. Once again, just a guess. There's an expectation that the next reorg is not going to ruin your team, that you're not going to get acquired and that I told somebody else. I've been on projects where one of the developers died. So you have some certain expectations going into this. But you're still expected to deliver something of value at the end. So my somewhat pessimistic statement is the probability of all these being correct is zero. No matter how much people argue that I know this or if we do this feature, my customer double sales, those are all guesses. But if you add them all up, probability is zero. OK, so that's what expectations are. They're a set of unknowns that have lots of names, but they're just guesses. OK, so I'm going to give just a very brief shopping list of a couple of them that are popular now. This one's called the Business Model Canvas. And this is popularized by colleagues and folks at Stanford. And they made this clever little grid and they put questions like, what is the value proposition? So you sit around a room and you figure out some nice words to put in there and you decide what you think of the customer segments and you fill out this box, this grid. And as you learn more, you update it. And then sort of the unwritten thing is when you get it pretty filled in and pretty confident, then you can hand it off to all the other people to implement. That's sort of how it works. So anyway, this one's called Business Model Canvas. It's some common phrases put in this box. And this is just a popular item now. There's other versions, but once again, this gets back to this idea of put what you know on one or two sheets of paper. They get you started. Here's another one. The winners always tell the story the way they like. So if you're dealing with management in most of the bigger companies around the world for the last 30 or 40 years, they had some version of this. And essentially, it's a flowchart. And the most popular implementation, this is trademarked. And it's called StageGate. And essentially, you pick some area. Oh, scoping is a good one. Someone decides where the specification is going to be. And then a small group of people work on that. And then on a certain day, those couple of people and 10 managers get together. And they ask them to explain their progress. And they ask them how much money they're going to need next quarter or whatever. And the managers at this diamond shape make a decision. And the decision is either go, stop, or wait. So these gate meetings in real life essentially means that all work on the project stops a few days before the gate meeting to get ready for the gate meeting. Then you have a gate meeting. And your hopes and dreams are crushed, maybe. There's also one guy that doesn't like something. And anyway, you work that out so that hopefully you get essentially funded for the next item. And then you complain about the meeting for a day or two. Then you get back to work. Often these meetings take a big chunk of productivity out of the group. But anyway, one can observe the new product development process from a management perspective. So that's like CX people, upper management people, budget people. They sit in the big chairs and tell you, yes, no, or wait. So they map it out. And you can actually hire the consultant to help guide you through this process. And anyway, that's from the manager's perspective. But that's not what we're talking about. I'm just putting it out there to say, there's this other perspective that's pretty popular. One of the other new ones also originated from largely from the people at IDEO, which are the people that commercialized the first apple mouse, so there's that word commercialized again. And they call their process design thinking. So they've elevated a particular group called designers. And actually what they did was they took out all the hard academic credentials, and they cherry-picked a few things, and they put it in this chart so that when they come in, they say, and we're not just managers, we're not designers. So the big thing is they talk to customers and empathize with them as one of the words. And they try to figure out what the customer needs. So they write it all down. And essentially what they're doing is saying, in about a year, when this product is going to be due, we've prepared some, not just a spec, but a sketch of the customer's hopeful experience. And they call it design thinking. So that's big at Stanford and University of Toronto. Now, in addition to a business school, they have a D school, a design school. Once again, this is from a certain perspective about how new product development works. Once again, there's no coders in there. This is just people saying, we have special knowledge and we want you to, we're gonna figure it all out, then we're gonna tell you what to do. That's what that is. And once again, just give me a couple of these, and now I'm getting to the one more interesting for you. So here's another way to think about it. I showed you a snowmobile earlier. I changed the picture a little bit here. This is some little hardware product that has an instruction manual. It connects to some other equipment. There's a website associated with it. There's some packaging associated with it and all the things. But when the person buys it, they expect it to interface with their gear and not break and when Apple changes, it still works and dah, dah, dah, dah. So anyway, once again, whenever you imagine that future product, instead of just showing a beauty shot, here's the beauty shot of the laser pointer with a hand model, you should really want somebody using the thing. So anyway, so that's, this box in the white is called user experience. What does the user think when they're doing their work? And that's ultimately why they're gonna buy it. Hopefully why they're gonna buy it. And I've coined this, one of the letters slew it off there. I've coined this other complimentary term, I call it development experience. And that is what the coders think and what the engineers think while they're slaving away to get this project done. What's their experience? Are they just, you know, contract people or are they, to use a derogatory term, are they just code monkeys or are they actually contributing to the project in some meaningful way or are they just, you know, overpriced people that want fancy dinners or something? So anyway, I've adopted this term, the development experience, once again, it's what the coders feel, what the engineers feel and another way of saying it is we're the people with skin in the game. If something breaks, we're staying overnight to fix it. And if it's gotta be due on Monday, we're the ones working on the weekend, et cetera, that's called skin in the game. So we'll be exploring this picture. So essentially what we got here is at the beginning, the times go on that way, at the beginning you might have this same group of three or four people that start to fill in the idea a little bit. So at the beginning of the user experience might just be a couple of documents. And then as things progress, you fill in, you build some stuff so that it starts looking like the actual commercialized product. So this is the environment that you actually work in. So in this picture, there aren't so many managers or designers from Stanford or High Price Consultant. These are the people that are working nights and weekends to fix stuff. This is us. Okay, so it's helpful, and I see it's critical to differentiate two words. We like to use the word done. The feature needs to be implemented. I evaluated it during my sprint, I did this, that and the other. I did TDD, I tested it. I moved the Kanban board from over here to the done column, it's checked in, it's integrated, it's done. So we like to do that and there are some people that like to play planning poker and commit to get and have a Kanban board in the background and make burn down charts and say that all these things were done. But in a commercialized product, not really done. Because if the user, if it doesn't make it to the end where users pay money, it was just a waste of time or it broke or it got erased or whatever happened. But it's, you know, we checked it in, but it's a, the key thing is it's a proxymetric. It doesn't actually mean we were successful. Just means we got some code checked in that may or may not get used. If our company gets sold, it may get thrown away. That's all that happened. It's a proxymetric. The real metric we want is winning. You know, I invested a year of my life in this. I, you know, missed the softball league I was gonna join. You know, put on 30 pounds, whatever. And at the end you wanna say I got paid but that was a terrible year of my life. Or that was the best project I ever worked on. So, this fellow that I've been studying, his name is, he ended up retiring as a colonel in the Air Force, his name is John Boyd. And it turns out during his career, he had, he wanted several things. One, he was a fighter pilot. He, very successful in that area. I could spend hours talking about that, but I'll just say he was a fighter pilot and he taught at the Fighter Weapons School, which is the Air Force's elite group of the best pilots in the world. So, right, a few years down from the Fighter Weapons School is the Thunderbirds, the aerial team. And so people went back and forth between those two groups. Like you could be instructor at Fighter Weapons School and if that wasn't good enough, you could be a Thunderbird. Then you could go back to, you know, bombing, you know, bombing some country and then back to Thunderbirds, whatever. So, this is a big deal. So, that's another whole talk, but he did that. By the way, he was undefeated. Big deal about winning, undefeated. Next, he basically said that the planes that we have aren't adequate against the enemy. So, when most fighter pilots complained, they just complained. This is, it's a dog, blah, blah, blah. But this guy learned calculus on, you know, nights and weekends and he interacted with the manufacturers and then eventually he developed this whole new theory called EM, which, Energy Manoeuvrability Theater Theory, which could compare a US plane to, let's say, a Soviet plane across the flight envelope, flying high, flying slow, flying fast, turning, da, da, da, da, so that you could say in a dogfight at 30,000 feet at this speed, this guy has the advantage or this guy has the advantage, et cetera. So, he, instead of just complaining about the problem, he puts some math and science and he actually stole some supercomputer time and that's a whole other story, but he was very successful in that. He won a Legion of Merit awards, you know, signed by the president, da, da, da. And then, oh, one of the planes he developed nights and weekends, F-16. Oh, that's, you can look that up if you want, but that's like the, one of the coolest, lowest-cost dream planes of any fighter pilot guy, F-16. And then, then he retired and then he developed, devoted his efforts to military strategy and showed the nature of conflict and some other things. He was asked, you know, what's a winner? And interestingly enough, he came up with a definition that's pretty much a product development definition. So, here it is. He said, a winner is someone, individual or group, who can, in a metaphorical sense, build snowmobiles. So, take a moment. Snowmobile, he was just using as a placeholder for a device that has, if you will, various mechanical components. You could say software. You could say gasoline. You could say tracks, motors. But it has a combination of components that come together in a new way. So, he didn't just say you have to build them. Then he said, the really important part, and employ them, use them, in an appropriate fashion, in other words, for Snowmobile, I jumped off this hill and I, catching my buddy and I came down and the thing was still, I was still at full throttle and snow was blowing in my face in whatever, in appropriate fashion. And he said, when facing uncertainty and unpredictable change. So, going back to those expectations, it was the same thing of what you might want to build and the people are going to build it in the schedule and the da-da-da-da. And with all those unpredictable events, you're still somehow successful. So, his definition of winning, I have adopted as a product development commercialization definition as well. So, that's Boyden, his work will come up a little bit later. Okay, so, I want to give you something simple. I wish somebody would have told me this 20 years ago. To define wins, well, there's a lot of ways, but I'm going to give you just two simple ways. One from a user experience point of view and one from a development experience point of view. The MBAs, I don't care about. And the CTOs, I don't care about tonight. I don't care about these two groups. So, I can pretty much summarize it. A user experience definition of winning. So, you build a product and the user experience version of winning is a bunch of five-star reviews. Okay, that means that it worked. When they bought it, they thought it was a good price that got delivered, it's still working. They told their friends, blah, blah, blah. So, if you see a bunch of five-star reviews, it's a pretty good indication of a good user experience. I mean, the opposite would be, this was really great except. That's usually a four-star review. So, if you want something just very portable, you can say that a good user experience correlates with a bunch of five-star reviews. That's what the user's paying for. Okay, what about the development experience version? The people like us? Well, this is a little team that I sort of headed with these mass spectrometers. They're complicated pieces of equipment with any of the results, new technology, new software, new applications, how to use it. And these two people were application chemists so they got to work with the unit a year before it was released. So, on the planet, they were two of the most knowledgeable people about that piece of equipment and software. So, if you wanted to train the rest of the world, those were two pretty important people. They have a year's worth of experience on something that's not introduced yet. And then the rest of us were in our own little development area. So, in this particular group shot, we created some multimedia training 20 years ago. Pritt, I've forgotten exactly, but let's call it 100 plus hours of training or something on us. No, that's too much. Two or three hours worth of training on a CD-ROM and then shipped it to all the customers so that when they got their new equipment, they got training from the two people in the world that already had a year's of experience. And anyway, we all got along. It was sort of almost like an unofficial project was something I thought was important and I just went and did it. So, I would borrow one person's couple hours a week and the graphic artist couple hours a week and Chris and Doug, I'd say I'm gonna meet you for three days next month and that's it. So, that was like a few hours. So, I brought them in, used them effectively and released them. So, the end was, we were a pretty happy group and sort of a little funny story. The one of the big conferences during the year happened in June and one of these was released a few weeks before. Doug was at the airport and it might have been like New Orleans or something and as he's coming into the conference, he's seeing you with some old friends and they're all smiling at him different this year. And that's the people who doesn't know are smiling at him different this year. And then finally, you can't figure out why they're giving him the goofy looks and they all said, we saw you on the training. And he was like, people you never met, but they knew him. It's sort of like seeing your favorite TV person or sci-fi person. Anyway, he got some, what's the word I'm looking for? He was a celebrity within this little group because of a CD. So, anyway, we all had a good time. So, it was a good use of our time and for me that was a great development experience and we sort of captured that with this one photo. Okay, so this list, just in case you haven't figured it out, means that as a coder, you have lots of responsibilities. One is to go in your room and code. Well, that's an easy one. And frequently that's because you're giving specifications. A lot of us prefer to work in isolation or as part of a small group of people that we like. Sometimes we get out of our little rooms and we're agents in a complex adaptive system. So, what that means is what we do impacts marketing and what marketing does impacts us. It goes both ways and what the competition does affects us and what we do affects the competition. So, there's that. If you're really good as a professional, you get to influence the direction of the product, not just be a code monkey and code what you were told, but you can actually say based on my research, we should be going in this direction. So, you can shape, if you have the proper tools and skills, you can shape the direction of the product skill. And then, finally, very important, you're an individual with other responsibilities. You'll be on other projects, you might have a wife at home, you might want to be learning a new language, but you have other responsibilities. So, if the project you're working on is something you don't like, now the new word this year is not engaged, then it gets less of your effort, it gets less of your best. And it gets, you know, like so what it, you know, it's, it compiled, you know, whatever. So, you have all those things that you have to balance, once again, in this question mark of what is development commercialization. So, that's what we're up against. Oh, there's the definition of complex adaptive system, which I just covered. Okay, a few years ago, there was this other guy, Talib, and he was interested in how things worked. And he wrote this book called Antifragile, and I'm just gonna give her like one or two points from that. He said that a development environment could be classified as fragile. And essentially what that means to us is, if one thing goes wrong, there's a big chain reaction in the projects later, the projects over budget or whatever, that's fragile. He talked about robust result, which I'm gonna skip. And then he talked about antifragile. Antifragile is a condition where, if there's a little bit of stress, the group performs better. If there's a little bit of uncertainty, the group finds new, amazing workarounds. So, part of the book is about what does it take to get from fragile to antifragile? Where you work better than you did before. Mostly, go over this quickly, doesn't welcome disorder. Things go bad quickly and fragile. Said that already. Oh, and this is a story I've never told in public. This represents a $475 million keychain. I have one of the few around. Now, if you want, I'll let you hold it. But $475 million, it's not the only one, but not very many of them. And the basic thing was, if you remember about 15 or 20 years ago, the development of Groupit & Tell was getting jerked around internally. I knew some of the people that worked there. And someone basically said, they forgot to fill in the rest of a table. And then in the multiplier section, they keep up with some wrong answers. And then that man said, it's some spreadsheets. You got the wrong answer. And it only happened in a few cases, but it was a big deal. They had to call all those processors back so there was an early pentium. And it was this thing of fragile. One bad thing happened. And somebody, I've never heard the rest of the story, some executive at Intel basically said, we're gonna take those processes and we're gonna make key chains out of them. So this is the $475 million key chain. So once again, you can look at that rare item. That's fragile. And if you're in a fragile environment, not likely to thrive. And I talked about antifragile. And we'll move through that. Okay, this is a picture that I just sort of composited to say what an environment may look like. A typical coding environment might look something like this where you have some people around desk, just actually just looks a lot like last night. Some whiteboards and these people all look and dress sort of the same. These are the coders. So how did they improve their ability to survive and thrive? So that's the beat of the talk. And I sort of gave you part of the answer is they develop better options instead of just doing what they're told. They get to input a little bit. So they contribute in new ways. And these development options aren't just choices like steak or chicken kind of choices. So they're more than just plain old AB choices. They're not real options where you just delay the decision till the last moment. They're not like stocks where you buy at a later date. And it's not just AB testing, it's more than that. As a developer, you can develop your options. If you've just mastered this new language that has great database access, you can say instead of what we were going to do, we can do it this way. Or there's a decision coming up and I don't know which is right, but we can develop two of them and we can test it. So the whole idea of development options is you develop new possibilities, hopefully with some new tests. And we'll talk about how you actually go about doing that. But that's a key phrase. And the basic thing I sort of hinted at is accelerate learning and they help make you more adaptive is the key item. So what you want to do is improve your ability to execute more attractive development options. And the next six items, which is once again the meat of the talk, I'm gonna briefly introduce something called requisite variety. I'm gonna introduce a concept I've been working on called pair development. I'm gonna hit a little bit on disintermediation, harmony and synergy over something called suboptimization. I'm gonna perhaps put a new spin on the word recursion. And I'm gonna finish up that section with mismatch detection over error propagation. So these are things I've been trying to make short little talks about to say, I'm not just gonna tell you develop better options, I wanna tell you some things you can do to get there. So requisite variety. It's gonna be a big deal, there's an equation, basically it says somehow in your development environment you have more potential responses than there are potential problems. So that's essentially what the definition says and W.Rosh Ashby is the guy if you wanna look it up. But greater repertoire is typically good. And then this is a picture I've not seen, I created this one. But the basic idea is if the task you're working on requires skills in orange, yellow and blue and you got two people on your team but no one person has all three of those, then you somehow have to work together to get those three so that together you have the requisite variety, the required variety to solve whatever this problem was. One person couldn't do it but together, combined, they achieved requisite variety by combining. That's the visual definition of requisite variety. And typically that means you have to work with somebody that's not a clone of you, they're gonna have some differences. Sometimes you get there by additional training, sometimes you get there by pulling in an expert, sometimes you get there through cooperation, but the point is without requisite variety you're gonna be blocked or take too long. With requisite variety, there's at least one answer available in your skill set between your group. And one of the other things, it's pretty, you know, past the beginner level is if you just say, oh, I've seen that problem before, I know on Stack Overflow I'm gonna copy this code, that's a pattern I've seen before, paste it in, hi, it works. Well, that's just pattern matching and that might be the insufficient response but you're not smart enough to know it because you haven't had enough requisite variety. So there's that to worry about. Fragile is also once again a bad thing. And then this thing, you don't want excessive variety. If there's too many opinions, you can't get anything done. So this phrase is pretty, pretty smartly named. It's called requisite variety. It's like just enough. Not too much, not too little. It's the Goldilocks one, you know, just enough. So there's that. And it's the basic thing is it ensures adaptability. You amplify the good, attenuate the bad, and that's the definition of requisite variety. The next one is pair development. And pair development is what do you need to move beyond what everybody else has been doing, what's been documented, what the familiar patterns are. So the visual on that is one guy says, oh, I've studied the problem and the problem is in the shape of a triangle. And the other guy says, no, no, I've studied the problem and it's a square with an X through it. And they each have argued vehemently and then they realize what the problem they've been looking at is really a pyramid. And they go, oh, it's a pyramid, I thought. Anyways, once you get put together two different viewpoints, produces a new perspective, in this case a sort of 3D perspective of the problem. But that's what I've defined as pair development, which is typically an intersection of disciplines. So you might have a developer and designer. You might have a marketer and a coder. And typically they don't show each other power points. This is typically most effectively done at a white board together where you're saying, let me talk about this problem, let's work through it, let's bounce some ideas. And you might spend half an hour and you go on about your business. That's what this, this is how I envision this technique. Once again, this is something I've defined and made the cartoon, so if you don't like it, I'm to blame. And the big thing is, it's a synthesis of new options and with the complementary perspectives, it has the potential to self correct your someone's focus and their direction. Once again, if the first guy would have continued to think it was a triangle, he would not reach his potential to win. But when he sees it as a pyramid, it's he was self, he was corrected and he moved on stronger. Okay, and if you want a Star Trek analogy, here it is, so there was this post and these people are arguing, it's probably on a Slack channel or something, but one person says, if you could have any Star Trek person to help you, what they were arguing between who they want, Kirk or Spock. And you can sort of guess why they were arguing. And then I basically said, I don't want Spock or Kirk. I want Spock and Kirk. So they have different viewpoints and it wasn't like Spock gets it and then Kirk gets a memo. I don't want that or the other way around. I want them in a room exchanging heated opinions coming up with a new solution. So this is a television version of pair development. Little bit different perspectives, comes together, better solution. Oh, it's not cross training. Spock's not learning to be captain and Kirk's not learning to be a science officer. They're just coming up with a brand new solution, so not cross training. And I covered that. Once again, this goes beyond pattern matching, so that's the summary for pair development. Oh, there's availability bias is a fancy name for, you present it with a problem, you go to the first thing that pops into your head, you think that must be the best solution because it's the first thing that popped into your head. That's called availability bias. And what you learn is, often your first thing you thought of is not the best. So that's just a fancy word for that kind of pattern matching. And once again, you hopefully reduce that with pair development. Okay, disintermediation is a nice big word. Let's see what that is. Means remove the layers between individual contributors and data. At one point in my career, it was sort of weird. If I wanted to talk to somebody in R&D, when I came there, you just walked over and talked. But then various people got territorial a few years later and these one set of managers, if I wanted to talk to someone in R&D, I had to make a formal request to my boss who made a formal request to their boss who talked to the person and they would try to come up with a solution while I had to stay at my desk. And it was like pretty stupid. So disintermediation is the opposite of that. If I need to talk to Zach, I go talk to Zach. I check to see if he's busy. I'm polite, I'm courteous, but I talk to Zach not to the other way. And it removes the decisions, barriers so that things get done faster. So that's disintermediation and how do you get that? Well, the key thing is one, you can exchange documents. That's not the best way. That means somebody has to spend time writing those documents and interpreting those documents. So if you want the fast-tracked, facilitate disintermediation, you talk to them face-to-face. And then if you want to see our customers think about your stuff, you can also have intermediation barriers between you and customers. So the way to fast-track that is instead of getting reports about customers, you go out and meet one. So that's disintermediation on the customer level, disintermediation on the colleague level. Once again, we'll just get a little high-level overview. Okay, this one's sort of fun. Harmony and synergy, at least one of those words you may not know very well. But to give you a fast-track on that, there's a little section of the score from Handel's Messiah. And if some of you are musicians, you realize that there are four parts there, soprano, alto, tenor, bass. And if I were to say one, two, three, four, sing. Could you do it? If you were the soprano, da, da, da, da, da, could you do it? Well, no, you'd have the training. Okay, so that's, in some ways, that's what it's like when I say, you four guys work together on this project. It's like, how could you be cooperative, let alone harmonious? If you haven't invested properly, you've been trained properly. So when you put these four things together, sounds pretty nice. Then you put an orchestra behind that that sounds even better. And that's, this concept of orchestration is what you'd like a development environment to work like. You'd like marketing and engineering to occasionally get together and work to produce something useful, which is opposed to the Dibbert version of those things. Okay, so that's harmony. Can I spend more time, but I'm gonna move on. Synergy is more fun. Synergy is beyond harmony. Harmony means that you're just working together and that pretty much means you're singing the same tune. We know it's hallelujah, and we know it's in a certain key, key of D, and there's a certain time, say, didger, and da, da, da, da. And actually it's very, the requirements are pretty much specified on that sheet of paper. Synergy is more fun. Synergy is when the output is greater than the predicted outcome based on the components. In other words, it's sort of like the idea of Spock and Kirk, when you put them together, you get more than the two individuals. So I've illustrated synergy in this diagram, network diagram, of these two guys are standing a little taller and they're bathed in light. They're producing something more than they could have individually on that synergy. So that's, once again, this page is just definitions. The question is how do you do that? Get these here. One is you improve group communication. So I'll give you a silly example. During my career, at the end of, near the end of a project, we also did a beauty shots of these mass spectrometers, and we used to pay the guy like 10 or $20,000 set up for a couple of days and take these pictures and they would go on the brochures, the shiny brochures. But we in post sales, that was pre sales, we in post sales also needed pictures, but the guy that was spending the 10,000 bucks never said, hey guys, do you, well I got the stuff in the room, would you like some pictures? So he would never even tell us when he was taking the pictures. He would never offer to share the, five minutes of the photographer's time. So it was just bad communication. So when we needed our pictures, we had to go round up the equipment again next week. So just a silly example, but improve group, improve communication would have made everyone have better use of the pictures. That's the same with code or other things. Another one is you need someone to put together people that need to chat. So someone says, I heard you were doing databases and you were doing a different kind of database. Maybe you should have lunch. So someone shapes that interaction. And then just to round up your vocabulary, synergy means a more positive outcome than predicted by the components. And there's an opposite of that. When I work with you, I get nothing done. That is a word is called disergy. So we shouldn't work together. I'm not picking on you. That's disergy. So if you need the opposite, you get less when you put two people together. That's not good. So if you're the shaper of this organization, we don't work together. That's fine. Now we have words to go with it. And then sort of the opposite is called suboptimization where you polish your code so that it runs 10% faster, 20% faster, and it's checked in. But meanwhile, I can't ship because this guy didn't do something. So you can suboptimize all you want, but in terms of getting it to the customer, doesn't matter because we lost over here. So, or it's also known as local opt-in, but the idea of commercialization, you want five-star reviews. If it's all not working, we all lose. And then I'd gone on to the next one here. Recursion is solving problems of the same type. So one version of testing is, I'm gonna performance test my search speed or whatever, but another version is in commercialization. So early in the product development, you have a few people, and you might only have documents, but you test that with a customer. And one of the things you wanna do is learn how the customer, what vocabulary the customer's gonna use. So that you learn early. Late in the product, you wanna make an advertisement, you need to learn what language the customer uses. It's exactly the same problem. So, recursion means you're solving the problem of what language is the customer using at the beginning, the middle, and the end. You're solving a problem of the same type. Well, how does the customer talk about this? Or how does the customer do his work? Or whatever those things are, but recursion is something that helps you make good use of your efforts. And here's a, see how clever you are, but here's a visual example of recursion. Anybody see it? What do you see? Oh, you were just yawning, I'm sorry. Anybody see the recursion? Yes? Yes. So what they're doing in the lab, mimics what the customer's doing in the inset picture. And if you could look further, there would be another version of the picture. So that's another conception of recursion, but it's solving the problem in the same type, individual kind of way. So that's recursion, good thing. Let's get to finish these up. Mismatch is an important quality to have in commercialization. With all these people that you might be working with, there's a lot of opinions, and it's usually, they start with, I know for sure, whatever, or the research is proven, whatever. There's those opinions, how regardless of how forcefully they're stated, and there's actual reality. And you can have an argument over lunch, and sort of cut a short story short here, but I was involved in a project where there was some intellectual during, and I quickly realized that no amount of during was gonna come to any good outcome. I would just be a waste of my time as well. So it was turned out it was a user interface problem. And the person that designed the user interface, I thought had done a terrible job, but this was a very well respected, coder that didn't really have user interface experience, but he was free for a couple months. And our group said it was terrible, and they said, Tom did it, and it's great. And it doesn't matter what the argument was, we were told that the product was gonna ship with that interface, so shut up and develop the training based on that interface. What was coming up on the end of the year, and we didn't like it and argued it wasn't gonna work, so finally they said, Mark, if you don't like it, you got 30 days to win this argument, which was supposed to make me shut up and go home for the Christmas or whatever. So instead, what I did was I developed two interactive prototypes, one with their interface and one with my interface, and then I got 19 pseudo customers, 19 people, some of which were internal, some of which were customers, and I basically asked them to do tasks with version A and version B. I did metrics, timed them, how errors and how fast and blah, blah, blah. And in the end, 18 of the 19 preferred version B, and the one person didn't wanna be politically committed, so he didn't vote for anybody. But anyway, no votes for A. So I went 30 days later when I was summoned to appear, presented my interactive results that they didn't know I was doing, and was ready for a fight, and the head of the group said, B wins, let's go. So anyway, the problem was I detected the mismatch, not by arguing, but by, in this case, A, B testing an interactive version with metrics, with errors, with speed, proved that B was better. I detected the mismatch, and the interesting part of the story for me is I finished this in 1999 on this product that I've been involved with from day one, so I had invested in the product. I was the first post-sale support engineer to develop the strategy worldwide for this product, so I was pretty attached to this product. And now it's 2016, and that interface is still being made today. So the work I did to win version B is still manufacturing today, so this little thing of mismatch sometimes has long dividends. You could detect mismatches on your own smarts, or you can gather people to help you, and if you don't detect mismatches, errors get propagated, and the potential for winning goes down. So once again, this is just an introduction to the term, but mismatch detection is a big deal. Okay, so we're pretty much the last few minutes of the talk. I've given you six approaches to win. I'll just review those briefly. One is requisite variety, just enough different opinions. You might have to work with a marketing guy for a half an hour at a whiteboard, but you get a different perspective, and the phrase to describe that's called requisite variety. It has an academic tradition, so it's just not some fad of the day, but it's a real thing. Pair development is something I'm championing where two people get together to create something new beyond the previous pattern, something novel. Disillumination is going to the source to speed things up for yourself, to clear up any misconceptions. Harmony and synergy, I gave the example of Hallelujah, where I can't just ask four of you to sing Hallelujah Chorus. I gotta prepare you, I gotta pick the right four people. If I pick the right four people, it's gonna come out better. If I give you a little training, it's gonna come out better, synergy, if I shape your interaction a little better, the results are gonna be better than individual components, that's synergy. And if you've ever been involved with synergy, it's one of the best feelings of your life. You go, I work with Bill today, and we did some amazing things. That's sort of a description of what it feels like in synergy, or flow is another word, sort of related. And then mismatch detection is taking a statement that you're told is true, or you should believe it, and going, you know what? We need to test that. We need to check the interactions. We need to put a customer in front of this. We need to time it with a stopwatch. We need to do something and see if there's a mismatch. Otherwise, the wrong things get built. Okay, so once again, the last couple slides. Another author has taken a look at this kind of problem, and he wrote this popular book called Drive, by Daniel Pink, who early in life was a lawyer, but he's come to see the light here. He decided, based on his research and others, that the three factors that drive coders and other people doing intellectual, what do we call it? Work that requires a rudimentary cognitive ability, okay? In other words, something more than flipping burgers. But he says that what drives us, are three characteristics, autonomy, mastery, and purpose. And autonomy means, if I think you're messing up, I have the autonomy, the capability for self-direction, to go, you know, develop a little new user interface and go test it with customers. I have the autonomy to learn a new language and see if the database access is better, but I'm not just told to shut up and do my job, but autonomy is I have, you're trusting my brain a little bit to also go out and find solutions. That's autonomy. Mastery is the basic thing of, last year I was beginner at Swift and OX iOS stuff, and now I've gone up two notches. I'm a little more mastery. So mastery is I'm getting better at my own craft, and perhaps mastery is I'm getting a little better at interacting with my colleagues to commercialize this product. And then purpose is the basic idea of the work I'm doing is important. So when I was working on these products, and you know, somebody was curing cancer and somebody was analyzing the spill from a ship or something, it was important work. So purpose means that the stuff I'm doing gets used and valued, that's the idea of purpose. So Dan Pink basically said these are the three factors that drive engagement or motivation. And what I've given you in those six items is a way to help say, if I want more autonomy, I might try, I might have to actually do requisite variety. I might have to pair with somebody to get more information. I might have to interact with that guy from marketing if I'm trying to win a marketing argument, but whatever. So anyway, you could, this is a nice book to read if you also want some ideas on what motivates people that do more work than rudimentary cognition. Okay, so here's the sort of the takeaway. I've been struggling for months trying to find words for this that are just real simple. So these are the two words I've adopted. So I'm testing them out with you tonight, first time. The two words are focus and expectations. So earlier I gave you my definition of, my set of items for expectation, and I said that was what should we build? What's gonna be important a year from now? What's the competition gonna be doing a year from now? What technology is gonna be important a year from now? It's what should we build, long term. And I gave you the basic ideas that the two extremes are. You could be told by the product master, project leader, CTO, whatever, that this will be important, shut up and just do it. That's one extreme. Or you could say, given this basic set of boundary conditions, I'm gonna help shape the answer. So that's expectations about what could we build a year if with all the mergers and reacquisitions in a presidential election and everything else, what could we actually do? So all that's in expectation. But focus is short term. Focus means what's important today. So the short version of that is doing your, becoming a better coder, that's important today. But spending a half an hour with somebody from marketing, probably should make that investment too. So that you can once again, understand and a better perspective, so that you can be a better contributor to the conversation, a more respected opinion. So focus is not just, should be something more than we got a backlog arranged by value, codeword, somebody guessed. And based on the backlog, he got the top and I came in five minutes late so I get the second one. I want something a little more substantial than that. So focus should be what's important. And once again, with informed opinions about what you're trying to do, how you interact, you can make a better short term decision. And expectations I talked about, but it's this idea of what should we build. And then I haven't completely, completely, come up with a great visualization for this yet, but this is my key insight actually last night. Whenever someone talks about expectations, they frequently draw a little place on a paper. And if they're a product manager, they call it a roadmap. Sort of the idea of if I want to go to Chicago, I know where Chicago is, I just follow the map and I get to Chicago, but the problem is Chicago doesn't move, okay? But products a year from now, we don't know where they're going to be a year from now because they don't exist yet. We don't know what our development situation, if the budget got slashed, if we ran out of seats in our room, if there was a merger, there's a whole bunch of things we don't know. So the next version of this picture, this expectation box, which is this top one, is actually gonna be moving around. It's gonna, might jump or something in the next version because we don't know what's gonna be in a year with all that big list I gave you. I illustrated a little bit here, if you notice this timeline has a bend in it and that's where expectations changed. Let's say that your competitor, that could have been Nokia when the iPhone was released, they suddenly realized that they should have changed, well, they were too slow, but the bend there represents a change and if you want to use Eric Reese's lean startup terminology, you could call it a pivot but it's basically just a new enlightenment you changed. So anyway, next version of this picture is going to be, the target's gonna be moving randomly because all those expectations change. So if you're working from a set of requirements that says in a year, this is what you're gonna need, you should hopefully now be a little smarter to go, those aren't requirements, those are hypotheses, they're guesses, they're projections based on unknowns and uncertainties. So the next version, this is gonna be moving but that's what I have today. Okay, so some of the what I've been talking about is lessons learned from the last 20, 30 years. I'm working on this book called Developing Winners. It has some stories in there about John Boyd, the pilot, aircraft designer, and military strategist I told you about. So hopefully the book will be out later this year so there's a site where that's happening. And once again, the title of the talk was from coding to commercialization to give you a broader idea of how you, as a coder, might fit into a successful, so that you could shape a successful commercialization effort to be a valued part of that community, perhaps shape a few things, derive a little joy and go beyond surviving to thriving.