Discovering and Delivering Artificial Intelligence Products

Hello and welcome to this webinar on discovering and delivering A.I. products. My name is Doug Rose. One of the key things that I want you to get out of this is with artificial intelligence. You don't build products, you discover them. So we're going to find a little bit more about what that means. What does it mean to discover her product? Most organizations are very comfortable building out products, coming out with a sort of an idea and then building it out over time. And they're considerably less comfortable just kind of exploring different possibilities, having lots of questions and then trying to sort of discover a new product. So let's start out by talking about what it means to discover a product. I'm going to start out at the very beginning by talking about what it means to what artificial intelligence means, kind of have a working definition of artificial intelligence. So artificial intelligence is the ability for a computer to perform tasks that are commonly associated with humans. There's a couple of common A.I. tools to do this. You may have heard of machine learning, which takes massive data sets and then has the machine learning. How does the machine learn by looking at these massive datasets through machine learning algorithms. And then you have artificial neural networks, which takes these little sort of artificial neurons and uses the human mind as kind of, ah, the human brain as a map for how to deal with these these different sort of massive data sets. How you could learn something new from them by using sort of the brain is almost a metaphor for how how it can work. So then you have something called deep learning, which takes these neural networks and then creates several neural sort of neurons. This creates several layers of neurons. And the deeper these layers are, the more interesting, the more the better. Your your machine learning algorithms are at finding these really, really hard to discover patterns. And so if you have a really deep neural network, then you can see things and create patterns or the machine can see patterns in things that humans can't even comprehend. And so when you see something like Google Translate using something like deep learning, what it's doing is it's using a deep artificial neural network that's using these machine learning algorithms to look for patterns and how people speak. And then it translates these words. It sees these patterns and learns them, that it translates them by matching up new data to the sort of the patterns that it's seen in the past. And so there's a model and then the machine updates it by itself. So now I don't expect you to kind of just go out now and and with what I've told you and start building your artificial neural networks or start working on deep learning projects. But I think it's important to understand kind of what these things are. So think of them almost like you start out with machine learning, machine learning algorithms. You can look for patterns. Then you can use artificial neural networks with these machine learning algorithms to find really hard to discover patterns. And then you can use deep learning to see really, really difficult to detect patterns in massive data sets. And so when you see something like Google's self-driving car, they're using a form of deep learning to kind of collect these massive data sets as your car drives down the road and try to sort of figure out if it can see patterns. When I see someone crossing the street, then I know to stop because I've seen that pattern a million times and I've collected enormous amounts of data. So when you see those cars driving around, what they're doing is they're collecting these massive amounts of data. So these deep learning algorithms can find these very difficult to discover patterns. So these tools are getting cheaper and easier. But when you think about artificial intelligence in your organization, I don't want you to think start thinking about the tools. I don't want you to go out and start setting up an artificial neural network or, you know, start training everybody intenser flow or something like that. Instead, I think that the best place to start for organizations you want to discover products is to start by approaching their organizational mindset. And that's really the main obstacle that a lot of organizations have from any value from these new A.I. tools. So the last 50 years, most organizations have been focused on operational efficiency. There's the creating meeting and management objectives. They're going lean and they're trying to sort of make sure that the the operational part of the organization is efficient as possible. And you see this a lot with Peter Drucker, who is every everybody's always quoting that the enterprise must have clear and unifying objectives. You must be able to set these objectives and then remove a lot of the operational inefficiencies to meeting these objectives. But really to get value from A.I. tools, you have to sort of move away from that. You have to start thinking more about science. You have to think about a discovery. So but it's when you when you think about how most organizations operate, that's really kind of not the way a lot of people approach new products. A typical organization will approach new products by using something like the typical project lifecycle. So they'll start out by planning something new, this is, you know, when they come up with a project and then they'll come up with a requirements document, then they'll analyze how this project or product is going to fit in your organization and they'll try to map objectives to it. So if you were going to come up with a new tennis shoe, then you would go out and you'd plan it. We're going to build a new tennis shoe. Then you analyze it by looking at the market and map some objectives. You know, we'll want to have the shoe released in, you know, two years from now or in the next quarter or whatever. And then you design this project or a product, you'll describe the features, you design it out. And that's where you see like with shoes or whatever, manufacturing people will create schematics and things like that. And then you'll code the product. If you're working with software, you'll have developers that are coding out the product. If you're doing something like a shoe, then you'll have people who are manufacturing the product. But it's kind of the same result. This is where you're working to build out the product and then you'll test it. You know, in software you have quality assurance testers that will go through and test the product. And in manufacturing, things like that, you'll have someone who just puts on a pair of shoes, go for a walk, send them to some customers, see what they think, and then once assuming that the tests all clear, then you'll deploy the product and then you'll deliver it. Software will get deployed to servers. Shoes will get deployed to customers. So you have a typical project lifecycle plan, analyze, design, code, test, deploy. But eight products are different, some common products are a next generation business agent that pops up and can kind of answer questions that you type in on a website. There's object and pattern detection A.I. products. I once worked for a paper company that was trying to use object and pattern detection to mitigate against any sort of workplace injuries. They had cameras set up on the shop floor and the agent was designed to sort of look for spills or see if someone left a cup of coffee on top of an equipment equipment. And then the I would send out an email or a notice to try and mitigate that. And the most common is sort of these EHI assistance that you see for EHI products where you have like Alexa or Siri that uses natural language processing to kind of do some analysis in real time to learn from people's requests and give them back the information that they want. And so these are pretty typical A.I. products. So you can't really use a standard development lifecycle with a products for one. I mean, it's difficult to have a plan because you're going to be learning so much along the way. When the paper company was making the cameras the point on the shop floor, they learned a lot about the types of injuries that they might be able to mitigate. And they learned a lot about how people might get injured. So it's difficult to sort of plan that all out because a lot of it is going to be discovery and because it's difficult to plan, it's difficult to have a scope. It's difficult to sort of know exactly when to stop. What's going to be the scope of your entire product? I mean, when does the one with the company say, OK, we've mitigated enough injuries? Are they going for 100 percent or 90 percent? So you're just trying to sort of tweak and optimize the product over time. And it's also difficult since you don't have a plan in the scope to come up with requirements again, because a lot of these products are going to be learning as you go. You're going to be getting better at natural language processing. Then it's very difficult to sort of have very strict requirements. This is what you do to sort of achieve this level of functionality. And you don't know what the requirements are. You don't know what sort of tweaks to the machine learning algorithm are going to make it the result more effective because you're running experiments and you're trying to optimize. So it's very difficult requirements. Requirements depend a little bit on knowing that if you do a certain thing, you'll have some sort of outcome. You don't really have that as much with A.I. products, it's very difficult to sort of understand the quality of an A.I. product because things start out in a less optimized and you optimize it over time. So if you notice with Google, a lot of times they'll start out with sort of machine learning, sort of machine learning tools that are very effective, like when they started out sort of with the Atari twenty six hundred game that played against itself. I mean, that was kind of it was great and it was neat, but they were just starting out there and then they optimized it over time to the point where you could play go or you could play sort of more complex video games. And so it's very difficult to kind of understand the quality when you're always improving sort of what you wouldn't stop there, but instead you're sort of starting somewhere and then optimizing it over time. And because you don't have the plan, you don't have the scope of the requirements, you're not sure what quality is going to be. Where are you going to stop the quality then? It's very difficult to budget because you don't know when your machine, when you're a product, is going to be optimized to the point where it will be valuable to people. And so you kind of have to run these experiments and then improve it over time. And then if you feel that it adds real value, then release it again. When you see a lot of these companies like Microsoft or Google or Facebook, what they're doing is, is they're creating sort of like these deep learning products that might not have that much value. You have, like Microsoft that might be creating a deep learning product that can identify humor or comics, but that doesn't really have that much commercial value yet. But they know that you start out somewhere and then you optimize and improve over time. And so it's very difficult to run these to sort of think of these products the same way you think about a typical project. And if you think about it, if you if you list out sort of typical project objectives and you compare it to a typical A.I. product, you'll see that like a typical project might be something like develop a customer self-help portal where a typical AI product might be to better understand a customer's needs. Remember, we were looking at those agents are typical project with objectives might be to create software based on customer feedback, where a typical A.I. product might be something like a cell phone company trying to create a model to predict customer churn. Because if you lose your customer, it's more expensive than getting a new one. So are less expensive than getting a new one or a typical project might be something like create an online course. But a typical A.I. product might be like a machine learning algorithm that helps identify fake news. You hear a lot about that in the news lately with climate change and things like that. So coming up with an API product where you are trying to improve the ability of a AI machine, learning an agent to identify fake news is something that, you know, you wouldn't optimize and improve over time, which is much different from a typical project. Another typical project might be to something like create legacy code or convert legacy code and update the server software. And a typical A.I. product would be something more along the lines of stopping security threats where you have to be able to anticipate something completely new or look for patterns and identify patterns that might be hostile. And that's completely different from something where you can scope out the objectives and try to meet those objectives. So there's a big difference between A.I. products and typical projects where you can use project objectives. So what I like to do with customers when I work in A.I. products is to create an entirely different life cycle, which is more based on discovery, which I call the learning lifecycle so or discovery lifecycle. So what you want to do with when you're working on a product is first you want to kind of identify the roles which I call the identify, sort of just start out with identifying the roles. Think about the different people who are going to interact with your product, then ask a bunch of interesting questions about your product. OK, so how are we going to what what how will we approach this? What are the different ways that we could approach this? What are the different values that we what the different ways we can add value and then research, look at the data, try to get as much data as you can, try to crunch it, get something interesting out of it. If you have data science teams and you can work with big data to try and sort of do something, see if you can create an agent that's very that does something interesting with the data and then look at the results, share the results with other people in the company, discuss reports, try to see if if this A.I. agent is a product, is doing something interesting and then sort of gaining insights from it, learn to draw conclusions and try then in the end, create knowledge. And if you look at how a lot of sort of A.I. software companies are working with air products, you can kind of recognize this lifecycle, like I said, with with Google or with other with Microsoft, they'll start out with these small products that don't have much value. They'll ask some interesting questions. Can we use Deep Learning Network to have a video game play against itself and then do some research, create sort of have the machine play against itself a million times, a hundred thousand times whatever, and see if it's learning something new and see if you're getting any interesting results, if it's improving the model and then seeing what insights you've drawn from it, see how you can improve the product and maybe turn the product into something that can do something more interesting, like play a more complex game like go or some of the more complex video games and then see what you've learned. And so this is a completely different life cycle than what you have with a typical product lifecycle. And a lot of times we have seen organizations do is that they take this life cycle and they'll run them in small sort of knowledge, creating sprints almost similar to how software works, where they'll run through every phase of this life cycle, and then every two weeks see if they can produce something interesting in this helps the team kind of learn something new and then quickly kind of pivot if they find something. So I was working with a company once that was trying to create a machine learning algorithm to look through massive data sets to try and come up with credit card offers. And so they were able to sort of they're playing with the model and they could look at the results and they noticed that the machine was actually pretty good at predicting whether or not someone was having trouble paying their bills. And so they were able to run a few sprints and see if they could come up with a new product based on the fee, based on that feedback and the insights and the knowledge that they got from one of the shorter sprints. And so you want to kind of run these is little short cut of product deliveries and be able to pivot. If you learn something new, if you end up sort of tied to a really long life cycle, then it comes becomes much more difficult for your organization to learn something new because they're kind of tied into what they're doing and they can't quickly pivot based on new knowledge. OK, so now you've seen a little bit about what an A.I. product is and you've seen a little bit about how you can sort of change your life cycle from something that's focused on objectives to something that's a little bit more focused on knowledge and learning. It's nice to think a little bit about how you can change your organization to to actually be more exploratory, to be less focused on objectives and more focused on learning something new. So an AI researcher named Ken Stanley came out with a really interesting book called Why Greatness Can't Be on the Myth of the Objective. And he talked about how humans are actually much better at discovering something new when they're not focused on objectives, that it the that if you if you're able to explore if you're able to do something close to a scientific method, that a lot of these teams can be more creative and imagine when they're able to use their imagination and if they're able to take a more empirical approach, if they're able to sort of run small experiments. And he talked about how this focus on objectives is actually an impediment to greatness, that if you want to discover something new, then you shouldn't focus on objectives, but you should really tap into kind of human creativity. And one of the examples of this is that humans are actually really good at it being creative when they don't really have a lot of information or if they have massive amounts of information. Humans are very good at making sense out of nonsense, out of huge amounts of data. And so there was an interesting article that I read in The New Yorker which said that when they ask people questions that were sort of nonsensical, that they were actually very analytical about it, that they took a group and they asked them who was more what was more likely to exist, something like a yeti or a dragon. And people could actually go through the analysis and say, well, you know, I think a yeti is more likely to exist because it might be smaller, more nimble, living in places where there's a lot of snow, whereas a dragon, we would have seen these flying around, they're larger. And if especially if it's fire breathing, it's more attention getting. And they asked what's more likely to exist, a unicorn or a mermaid? And people are like, well, you know, we're probably a mermaid because it was in the ocean and much, much more of the ocean is unexplored. So even people, even though people are asking something that's sort of nonsensical, fantastic, that they're actually able to do some really interesting analysis and that's very similar to how you want your teams to think when you're working a product. A lot of the data that you'll be getting when you're working on a product will require some creativity. It will require you to sort of make sense out of nonsense. And if you're focused on making if you're focused on sort of being completely analytical, not being entirely creative, and if you're focused on objectives, then you can actually have a lot of trouble making new discoveries. And one of the things he talked about is you want your organization to embrace serendipity, you want them to be able to sort of ask interesting questions and to pursue interestingness, to pursue novelty. And some of the examples of organizations that have discovered something new through something serendipitous, like the microwave was discovered because someone was fixing radio towers and they noticed that the chocolate bar in their pocket was melting. And so it was kind of a serendipitous discovery. And they discovered how they thought about it. They were creative and they thought, OK, well, maybe we can make another out of this. Plastic was discovered serendipitously, a sort of byproduct, petroleum. Teflon was discovered serendipitously. And a lot of these products were not objective driven, but it was sort of a team was working together and they were creative. They were able to ask interesting questions. And so they were able to discover something new. And more recently, if you're a fan of Silicon Valley, there was an episode where one of the software developers was trying to develop an A.I. product that could identify whether or not something was a hot dog and called it the not hot dog A.I. product. And so he was created this product and it was focused on it and doing discovery and crunching data. And it was it ended up being really good, but it wasn't really commercially viable. Not that many people didn't want to find a hot dog. So in the end of the episode, he ended up selling it to Instagram, Instagram as a way to sort of filter out whether or not someone was uploading the wrong kind of pictures. And so it was, you know, this is a pretty good example of a product that started out going in one direction and then through creativity and looking for interestingness and pursuing novelty, it was able to pivot and do something else. And remember, you want to run this life cycle in short sprints so that you could sort of pivot quickly and do and look for something interesting. If your project is completely focused on objectives and you're going to miss a lot of opportunity to discover something new. And again, when you look at a lot of the companies that are focused on products, this is exactly what they're doing. They're working on products that might not have that much commercial value, but they're learning something and they're learning how to work with the technology. And the and the machine is the machine is updating its model and they're improving their algorithms. Professor Stanley described these discoveries is like stepping stones, is that each time you learn something new, you're taking a step closer to your product. So with not hot dog, with Google creating an Atari twenty six hundred algorithm, that each one of these is a stepping stone to creating something new. Now, these companies might not know what the end result is going to be because you don't really know what all the stepping stones are until your end at the end of the path. But each time they take a step, they're learning something new. And so you only know at the end your pathway going back. And this is exactly what's happened in a lot of the products I work with. With the shop floor, they learn something new and they were able to sort of optimize their algorithm with the credit card processing firm. They were able to spin off a new product that they completely didn't anticipate because each step that they took got them a little bit further than they weren't focused on objectives, but instead they were focused on learning. And so that let them develop some really interesting eye products that might seem strange to sort of use words like creativity and serendipity when you're talking about product development. But if you think about it, a lot of us sort of have very serendipitous things happen and we don't even really think about it. If you think about your career, maybe when you were in high school or college, you had very well set career objectives. But then something serendipitous happened. You picked up a job you weren't expecting. You got a promotion that you weren't expecting in your career, completely went in a different direction. And so the fact that you were able to sort of take advantage of that as a person probably really made your career, really changed your career. But as an organization, their teams are not very well structured to take advantage of the same thing. And so they would say, well, you know, this might be a separate, serendipitous thing that happened, but I've got these set objectives and so I really can't take advantage of it. So you have to really think about this. When you're trying to develop a product, you want to change your organization so they can think about these serendipitous stepping stones, learn from it and build out a product kind of like how you might do as a person. But it's much more difficult to do as a team working in an organization. And much like data science, I found that really small teams working on A.I. products structured in a way that's consistent with the scientific method, gets much better results. You have sort of this three person team, which is sort of focused on discovering we have a knowledge explorer, a data analyst and a servant leader working together in these tight teams to find new products. Now, a lot of times if you have a good data science team, they'll be structured this way. And then you could have your data science team also work on your machine learning products and sort of a natural progression, because data science teams are using the scientific method to explore massive data sets. And so they might end up using machine learning algorithms or artificial neural networks to crunch that massive data and then churn out data products. So it kind of makes sense that they would have a very similar team structure. But one of the most important roles in this team is the knowledge explorer, and they should sort of think about things differently than the rest of the team. If you're read, there's a book by Daniel Pink called A Whole New Mind, where he goes over some of the new skills that are much more valuable in organizations as they kind of start to invent and do more interesting things and develop products like some stuff with A.I. And he puts much more emphasis, which I think is correct on story over reporting, which is you want people in your organization to be able to fashion a compelling narrative instead of focus completely on reporting what's happening. You want people who can look at Symfony over detail. Organizations tend to favor people who are very detail oriented. But for A.I. products, you want to have people who can look at the big picture so they cross boundaries and be able to contribute pieces to the overall whole sort of someone who's able to see something really big picture instead of focusing on the details. But there's a lot of detail oriented people in your organization, so you might need to sort of train people up in this new skill set or find someone. And that these sort of people in your team should be called should have empathy over certainty. Instead of focusing on objectives, they should sort of look at what makes the their fellow human tick, kind of understand how people forge relationships and how might people might care for others. Now, the name for this role, which I like the most, which I've seen a lot of organizations, is the knowledge explorer, sort of the I think that this kind of encapsulates how this person should think about themselves as they're trying to gain organizational knowledge and they're trying to do it by kind of exploring the data with the team so this person won't be in charge of crunching the numbers. That might be sort of that the data analyst. But there would be the person who's asking interesting questions, making sure that the teams are focusing on objectives and instead looking at these sort of questions and seeing if you can learning something new and being able to help the team pivot. If you find something that's serendipitous, if you make a discovery that you weren't anticipating, which when you're working with massive data sets you're working with machine learning is not uncommon. Again, you're going to find a lot of new stuff when you start sort of crunching these numbers and when you start using machine learning algorithms to look through the data you already have. A really good example, this is a few years ago, there was a professor at Cornell called Professor Klineberg who came up with a really interesting challenge. He wanted to see if he could have his students discover on Facebook whether or not people were in a relationship in a romantic relationship. Now, I know on Facebook now at the time, they didn't have you tag whether or not people relationship. So he was just kind of using the data that was out there at the time to try and figure out if he could make this connection himself. And he used a very sort of nonobjective driven approach was to try to be creative. He he had he acted kind of as the knowledge explorer and the team acted as data analysts and they tried to figure out if they could make meaning out of this massive data set. And when they got together and they were asking questions and the question meaning they kind of talked it out, remember, you know, empathy over empathy, over certainty. And so he talked about sort of what it was that made people tick. You know, how how did you know when people might be in a romantic relationship? And one of the things that came up is that when people are in a romantic relationship, a lot of times they'll end up becoming friends with people that that's their new partner, that partners, friends. So they'll take on a whole bunch of different meet a whole bunch of new people that have been friends with whoever their new romantic partner has been friends with. And so they thought about how that could represent that in the data. And they came up with this chart, this little visualization here, which shows that you can see kind of the dark concentration of new friend requests in the Facebook data. And you can kind of see that a lot of people are meeting new people, and that was the way they figured out accurately whether or not people were kind of in a new romantic relationship with one another. And so that's kind of the way that you want to think about this data. When you're working on a product, you want to sort of be able to have empathy, be able to pivot the product based on the knowledge that you create. And if you find something new and again, they couldn't create sort of an objective, they couldn't say, here are the steps we're going to take to find out if someone's in a romantic relationship. They had to ask interesting questions and they had to explore the data to see if they could find something interesting. So one of the key things that I want to emphasize is that it's when you are building out the products, a lot of technology that you're going to get is going to be either free or not very expensive. You can use tens for you can download Python libraries. So a lot of the challenge around A.I. isn't really technical as much is cultural. You have to change your organization. And it's also about having the people who are on your team embracing the right mindset. So some of the key things that you should keep in mind is does your organization have kind of an agile mindset? Are they able to to think about things that they could deliver quickly? That's almost one of the first steps. Can they can they think about things and deliver value quickly? Does the organization already make data driven decisions? Do you have data science teams that are in place? Hopefully they're using more of these small teams, taking a creative approach to looking at their data. Does the organization tolerate and even value change? If you're in a very conservative organization that focuses on structure and certainty that it's going to be very difficult to deliver a product because a lot of it, you're going to be learning something new and you're going to have to be able to pivot and ask interesting questions and try to sort of discover something looked for. Interesting. This is Professor Stanley says. And does it have the right reward environment for people to experiment? I mean, if you're if you're start out by saying you want to do things one thing one way and then you learn something new and it's a better way to do it, are you going to be penalized or rewarded for it? So you want to be able to sort of have people be rewarded for discovering something new, discovering something interesting. And so you want to take these small steps with these products that might not have that much value at the beginning. And then through serendipitous discoveries, take these stepping stones to learn something new and deliver something that's valuable. Now, it might sound like that's completely different from how your organization operates, and it might be. But if you look again, if you look at how these A.I. products are being developed and some of the organizations that are using the mouse like Google and Facebook and Microsoft, this is exactly what they're doing. They're developing these products that don't have that much value and they're refining them over time until they do have value and they pivot based on what they learn. So this is kind of the way that you want to deliver these products. So here are five key takeaways I want you to have from this, so artificial intelligence are getting cheaper and more widely available so you shouldn't think of delivering a product is a technical challenge. The tools and you should think of it more as an organizational challenge. The tools are not going to help you unless your organization has the right mindset. Do you have people in your organization that are comfortable discovering? Can you create these small teams that can pivot and learn something new to deliver a great product? Have your organization. If you're starting out with they have your organization focus on exploration and not on objectives. You look at Ken Stanley's book and see how objectives are actually in the way of trying to discover something new. And he learned this a lot from his own research. Embrace and don't suppress serendipitous discovery. A lot of times when you're in a large organization, there'll be a lot of people there with different backgrounds and doing different things. And so you might discover something serendipitously. You might figure out how people are, the way people are getting injured on a manufacturing floor. You might figure out some way to predict that your customer might have trouble paying their credit card bill by looking at the data. Well, so you want those people to make these serendipitous discoveries and then roll it into your product. And finally, you want to work with small teams, much like data science. You want to work with small teams to explore your data instead of just having sort of one person who's an eye specialist or a data scientist. So small teams increase the likelihood that you're going to have a serendipitous discovery. And you also don't have to then focus on just hiring one person to take you to where you need to be. So all of these five takeaways will hopefully help your organization kind of get on track to start delivering these products. I hope you enjoyed this. And good luck. Thank you for watching.