 Okay, good afternoon again. And thank you so much for having me here. I'm very honored to be here. This is the second year I've been here. It took me all year to convince Bapu to invite me back, so I don't know if I'll be able to do it again next year. But I'm going to try. I might work on Dominique for my third trip to India, which I absolutely love. And I also want to thank the organizers of the conference. It's just that they've been incredible as far as helping everything run smoothly from a presenter perspective, and I haven't seen any complaints. Even though I tried to get them as part of my workshop, I had a persona exercise where the persona was a conference attendee, and part of the exercise was to embody that person and complain about the conference experience. So there was very little for them to complain about, and I applaud them for the work that they've done. I also want to echo something that Sara mentioned, and again, applaud Bapu and the organizers. I'm going to cover some of the things that have been spoken about by Liam and by Sara and by Mark, but I'm going to be very tactical. This is not going to be so much of an inspirational talk, and it's not going to be as broad in its scope and reach as some of the others as far as affecting change in our organizations. But it's going to be very practical, very tactical. So a little bit about me, as we've mentioned, my name is Ray Della Penna. I'm the director of strategy at Catalyst Group in New York. We're a consultancy, and I've been a consultant for most of my career except for a small stretch where I was in-house, and I've mostly worked for large organizations. So I'm going to talk a bit about trying to embed an effect change in those organizations, particularly from the perspective of Lean UX. So the goal of the talk today, the specific topic here, is how we can introduce a Lean methodology in a large or an enterprise organization. It's very similar to that diagram that Liam showed about the innovation influence coming into the cell and growing. And it's also in line with what Sarah just described about how to effect change in the culture. But I've attended conferences for many years. I remember actually one of the first talks I heard in UX was a talk by Mark, which was very inspiring about the effect that interaction design can have on the world, and I just wanted to go out and save the world. And then I had to go back and design data entry forms and redesign homepages. And that push and pull is very difficult, particularly when we hear these amazing and inspiring talks at conferences, and we want to go back to organization and implement some of these things, but we're constricted by the tasks that we're given and the constraints within our organizations. So what I'm going to talk about today is just one example of how we either as an individual consultant or as an individual team of one in an organization, a large organization, I can sort of sneak in, you know, cross that threshold and introduce a methodology that we're now calling Lean, but I've had many conversations with many people here and other places about how Lean UX is just what we're calling good design now. We're focusing a little bit on some aspects of the design process as Lean, but they're really just good design, and this is a way for us to inject a good design process into an organization with a lot of constraints. So a couple of terms first, the title of the talk is MVPOC, and you're going to forgive me for introducing a new acronym. I don't want you to use it, but I'll define a couple of terms first. So on MVP, a lot of confusion about what this term is, and for the purpose of this talk it stands for minimum viable product, which has been used in many ways. It's used in agile methodology or terminology as well, and more recently and frequently in Lean methodology. It's a minimal version of a proposed solution, particularly as we think about a proof of concept context. The idea here is that we're going to learn from customers by measuring the effects of or the outcomes from releasing this product into their world. It ensures that a solution meets a need, so that's one of the focuses that Lean UX emphasizes is that there's a connection between the products that we provide to users and the actual needs that they're fulfilling, and it's used to repeat, used as a vehicle to repeat this process, this loop that at every Lean conference you see one time or another, and this cycle of thinking or doing some analysis, making something, a product or prototype or a test, checking the performance of that product in the real world with users, either in the form of a simulated test or by actually releasing it into the market, and then measuring those results and thinking about how to iterate your product in response to that. So the MVP in this context is the artifact, the product or the prototype in most cases that's used to get through this cycle. So what is the proof of concept? I know you've been asked a few times already, and I know a large portion of the audience works at large organizations, and during my workshop I asked how many people are involved in creating new ideas or being responsible for the creation of new products in their organizations and how many have worked on the proof of concept, so I'll just define what I mean by that. There's a sort of list of attributes that are common among proof of concepts, and those are that they contain a list of functional requirements. The purpose of the proof of concept is to obtain funding typically to go ahead and design and build a full product. They usually follow some sort of a marketing report or some analysis that says there's an opportunity in the market or some need, and we want to try to feel that need or we want to try to get a piece of that market to increase our influence or our revenue or the service that we provide to our customers. So there's a list of functional requirements. There are development estimates. What is this going to cost us to build? What's the investment we need to make? There's some initial designs, and we have to visualize this thing in order to test it, evaluate it, in order to sort of get that approval to move forward and design and build the thing. And ultimately, there are typically also some performance projections, usually in the form of financial projections, but that could be in the form of the market share we expect to gain by introducing this new product or the revenue increases we expect or the new types of features that we hope to release. So you mash them up and you get this MVPOC, minimum viable proof of concept. And I say, don't really use this term. I'm using it a bit tongue in cheek. And again, going back to this idea that is lean all that different than agile, all that different than good design. Not really, but if there's interest around the way we're marketing or talking about doing good design or talking about it in one way or another in these terms allows us to focus on aspects of doing design well, then I'm happy to call it whatever we like. And the reason this term has been sort of a successful internally in our organization to sort of infiltrate enterprise groups with this lean methodology is because there tend to be fewer restrictions on the creation of a proof of concept in a large organization than there are in the full development lifecycle or the product release lifecycle in enterprises. So the MVPOC is this sort of canned approach that will allow us to inject a bit of innovation and a bit of positive change in the design processes. So the next thing I'm going to do for the rest of the talk is go through essentially a traditional design project phase, each phase of the design project starting with the initiation of a design project. We always want to establish what are the goals of our project. And in the case of a proof of concept, we obviously have to create a proof of concept that contains all those elements that I just outlined a few moments ago. We also usually end up with a product roadmap, which means that the entire set of features and functions that we want to include in this new product will probably not be in the initial release, especially as we're designing what we think it should or could be. There's going to be some constraints that say we're going to have to start off with a subset of all of our features. And then map out how the rest of them will be implemented or how the product may grow. And finally, we want a validated product. Typically that means it's feasible to build, ideally that people will want it. And I'll talk about the differences in accomplishing these goals when we do it this way as opposed to the traditional way. So to embark on a project like this, from my perspective it's usually as a consultant and this is where I'm putting together my proposal. When I propose a project to a client either in response to an RFP or just through our connections with our existing clients, I'm aware that there's a new concept that a company wants to build and they come to us for design and research assistance and strategy assistance. First, I need to get buy-in on this methodology. We often approach them and offer them two options. We can do it the regular way, the old fashioned way, or we can do it this new way. We talk about the pros and cons of doing it either way. So we need to get buy-in on the process and on the methodology. We need to put together the right team. This is one of the other key aspects that differentiates lean, or I should say good design, from the way things are traditionally done in organizations where we want to improve things. And then establishing the process we're going to use for this particular project. Even though I'm going to give you almost a step-by-step recipe, I don't encourage you to follow it as dogma. It's just an example of the approach that we've seen be effective and I hope potentially could be a template for you to start from and modify as is good for your situation. So in order to get buy-in, one of the first things we need to be able to do is understand what the objections may be to convincing the stakeholders or the decision makers to try what we want to try. So that has to do with understanding the potential risks that they may feel are inhibiting them from trying this method. We need to work within organizational constraints so we know that in large organizations there are a lot of them. We're not going to try to go around them. We won't risk the relationships and reputation that already exist. There are existing products and sales that we know that especially working in a lean methodology where we say let's just put something in the market and see how customers react. That's a big red flag to organizations with established products and services and he almost most important is we'll work within the established budget. We'll do what the work that we need to do in this new way for the same cost that we've got available to us in the old way. But what are the rewards of doing this? Well, first we've got a customer validated concept. We're going to be presenting these proofs of concept to our customers in a controlled or simulated way versus releasing them to the market. So we'll have information on the performance that we can expect in the real market from our customers. We'll have a more informed road map so we'll have a better understanding of what works and when and what we need to iterate a bit more as the product is released and rolled out. There'll be less risk that there'll be sort of an utter disconnect between our market and our ideas and almost as a byproduct, we'll have a better understanding of our customers based on the team that we have and the methods that we've used. And key as we've talked about sort of as infiltrating a new methodology. We'll have a repeatable process that we can either continue to use for proofs of concept or we can sort of begin to influence the actual product development life cycle and by demonstrating its effectiveness in this more isolated arena. So speaking of the team, we've talked a lot about I've talked to engineers, I've talked to designers, I've talked to people who are not necessarily even involved in the product development life cycle. But the roles that I like to bring together for a project like this and that are typically involved in lean methodology include those from the business, design, development, and customers. And within the business, I like to consider the sort of the stakeholder as part of that as well as the product owner and the domain expert. So the team that is involved in this project from start to finish includes all of these roles. And the value of that is the collaboration and the input from all those roles at every stage which sort of facilitates a shared ownership of the product and a shared understanding of the challenges faced by all those roles as well as the customer's point of view and what works and what doesn't work for them. So how do we do this? This is, as I said, a fairly traditional progression of activities. We're going to do a period of discovery where we need to understand the business and the customers. There's going to be a period where we ideate, where we create concepts to address the needs. And then we'll validate them. We'll make sure that those needs are addressing the goals that we've set out for the project and ultimately we'll iterate. For the purposes of this formula, this MVPOC approach, we recommend that we iterate three times and we'll talk about why to validate and refine. Once again, even if you're a UX team of one, handed a list of requirements to create some wireframes with no other input, you go through all of these activities, even if only in your head. You have to understand the context around which you're designing. You have to create concepts and you have to understand the users. And the validation in most cases has to do with presenting it to stakeholders and adding their feedback and responding to that. And that's what we tend to iterate on. But hopefully this methodology will be able to expand on that and involve customers. So again, going back to the lean cycle, entering into that cycle, a phase that's not often talked about in the literature, we add sort of a look. And those four phases that I described to me are about the transition to or the overlap between the sort of main bubbles of the diagram. So during discovery we're looking and transitioning into the thinking part. And when we ideate, we're sort of transitioning from thinking to making. And then making and checking is the validation what we need to make and how we need to check it is part of that transition and that path. And the iteration has to do with receiving the output or the results of our check and understanding how to process and synthesize that to repeat the cycle. So the first phase of the actual work, assuming we've got buy-in and we're going to embark down this path, is the discovery. This is where we look and think. And this consists of three important parts, equally important parts, which are to understand the business, understand the customer, and understand how the product serves both. User-centered design, so the importance of understanding users. Sometimes, at least in our discussion, obscures the importance of understanding the business and understanding the other half of that relationship between a customer and a business and the products and services that they provide. But I think it's equally important to understand the business as well as how the product will serve both. And we need to design products that are beneficial to both the customer and the business to keep that relationship growing and moving forward. I've seen lots of numbers flying around, but I hope they're not. Okay, so where do we start? So understanding the business has to do with several aspects. We have to understand the domain. We have to understand if we're in finance, we have to understand finance a bit. If we're in healthcare, we need to understand healthcare a bit. This is one of the things I love about being a consultant is I get the opportunity to sort of delve into and understand new business domains. But even as an in-house employee at a large corporation, you only are benefited by understanding the domain in which your business works. You need to understand the existing products and services that your company provides, if only to see where this one will fit in and how they may complement or overlap with others. You need to establish the goals of the business. And I say establish, I use this term quite a few times because they may already exist. But you want to sort of codify and make them clear and make sure everyone is on the same page. And if they don't exist, you want to make sure that we create them or we agree that we've got some specific goals that we want to attain. And we need to understand existing or previous strategies. If there's an existing product or organization, as we're talking about in this context, there's been some thinking about how we can succeed or continue to succeed. So we need to understand that to determine whether we should continue with that strategy or adjust it or create one if there's none that's apparent. And finally, we want to be able to measure, so we need to define or analyze metrics that will help inform whether or not we're doing a good job. This is one thing that's key to the lean methodology. And again, as I keep saying, to good design in general. But in lean, there are a few aspects of measurement and how we conduct experiments that are just sort of being brought to the focus. And that's why I continue to use that term. It's the new hotness as Liam mentioned in California and also here and around the world. As far as understanding our customers, there's probably some existing understanding of our customers, even if only in the form of assumptions that we make. So I think during the discovery process, it's important for us to start off with exposing those assumptions. So that's why I always like to start off with a proto or a provisional persona that gets, again, keep in mind that these exercises include the entire team, business, development, marketing, etc. So we want to expose as a group, what is our current understanding of customers? And these will be built upon, 10, my God. These will be built upon as we continue to research and develop our products. There's a presumed life cycle. So how quickly do customers go from sort of an understanding and then using and being advocates of our product? And then we want to perform some research, whatever our budget allows. If it's generative or analysts, analysis of existing history with customers, we want to make sure that our understanding is correct. And we want to understand how our relationship might work. What is the journey that we expect our customers to go through with our business and with this product, which typically goes through these stages of awareness, evaluation, acquisition, support, and retention. So now moving into the ideation phase. For this method, I like to rely on a design studio technique that Will Evans, who was supposed to be here, could have talked a lot more about than I can. And Todd Zachary-Wolf will, you can research this technique. But it essentially brings together all of these roles in a collaborative ideation session where we sketch and critique and share ideas in a number of rounds. And we create concepts as a group involving customers. The reason I choose this methodology is because it brings together all these roles. It creates a volume of ideas and it evolves the team's understanding of customers and their perspectives as we generate those ideas. When you're doing this in this context, we want to also use this as a discovery activity where we sort of evolve our understanding of the personas and of the scenarios, have a discussion with and between customers and expose the rest of the team to that discussion. So really get a better sense of how customers feel about the product and about our services. And then finally, this is where the sort of flexes its muscles or what it puts to the forefront. And that is in the validation phase. How do we make and check the assumptions we're making and the products that we're hoping to put into the market? And that has to do with identifying those assumptions and making them explicit about the business and about the customer. And then creating our initial versions of the product in the form of an experiment, which means creating hypotheses from our assumptions. Building a prototype based on the objective of testing them against those hypotheses. And then conducting a formal and structured test. And that could be field research, that could be paper prototypes. But we definitely want to use best practices and a somewhat rigorous approach to who we test and how we test. So that we can rely on our observations and utilize them. So to identify assumptions, there's sort of these three parts. There's coming up with a problem statement. There's clarifying our business assumptions and clarifying once again our customer assumptions. This section, all of you can talk to a lot of you who are reading the Lean UX book and Jeff Gottelf and Josh Seiden have done a great job in sort of codifying how these lean practices can be applied in a UX context. So a lot of this comes from a section of the book that's referred to in the slides from my workshop in particular. But this is sort of a template to expose the general problem statement that the business has and helps to solve by the initiative that you're sort of addressing with this design project. But it can also be used to describe the problem that the business proposes to solve in general. And it's got this format of why the business was created, what goals it was created to achieve. And then what the problems are that it's perceived that, where it's not meeting those goals. And what it thinks the adverse effects are on the business and how we might improve the service to more successfully meet the needs of both the customers and the business. Moving to how the business will succeed, this is where we try to decide what are the assumptions we're making about our customer. So what are the match between our capabilities and their needs? And how will we generate revenue for the business based on these products? And how do we compare to the competition that we face in the market? And what are the biggest risks as a business? Moving into the customer understanding, most of this will already be represented by our persona and our journey mapping. But again, to go through the exercise of calling out those assumptions and clarifying what we know about our customers, their needs, the most important features that we can give them and how the product should be designed from a look and feel perspective. These are the things that we want to once again call out and be clear about the assumptions we're making about all of these entities. Given all that, we take our assumptions and we want to now convert them into a hypothesis. Which is that we believe the sort of the first two bullets, the left bullets can be used to create the hypothesis for the business in general. We believe that our business does the following things and we'll know we're right or wrong when we make the following observations. The second level in are what are referred to as the sub-hypothesis in the Lean UX lexicon. And that's more about we believe these particular features and functions will serve these particular customers to achieve these specific outcomes and we'll know we're right or wrong when we see these measurable results. These sub-hypothesis are the things that we use to essentially build the requirements for our prototype or for MVP so that we can conduct our experiment. So given those hypotheses and given those sub-hypothesis, we then create the prototype which will determine which features for which target personas will achieve which expected outcomes. And then we only build or we build only what's necessary to test these hypotheses, that's the M part of the MVP. And then we conduct a test. There's another aspect of this Lean sort of terminology called Goob that a lot of us has heard which stands for get out of the building. And the idea there is that you're not going to be successful designing your solution sort of in a bubble or within the walls of your organization or within your group. So the idea is get out of the building, interact with your customers and find out from them what works and what doesn't. Sometimes that can go too far when the idea is have your whole team involved, which is great, but we found that sometimes bad research can be better than worse than no research. So what we want to do is recruit properly and this is one of the roles that our persona helps us fill. We've defined some attributes and some needs and some potential solutions for a particular group of people. So that's what's going to guide who we recruit and who we engage with when we conduct these tests. Record thoroughly. So make sure that we're capturing the results of the interview as it happens. Typically we do this with two people conducting interviews and one recording only and the other facilitating. And then repeat or be prepared to repeat this process. If we're going to do this in an iterative way, you'll find that the first few times you're conducting research, it's a scramble to have the equipment and the procedures and sort of approach to getting out and recruiting and conducting and synthesizing research is something you get better at over time. So when you prepare to do this, be prepared to repeat it and be focused on the activity as something that you want to evolve as well as just getting to the results. And finally, iterate, repeat the process. And I say check and think three times. So for this process, I say three times and the reason I choose three is first of all we found that three rounds of iteration, which we typically do in two week cycles usually fits in with the budget that we tend to have or see for MVPs or for POCs. And the reason three works is that the first time it's your first opportunity, you've created some concepts, you've done all this research and thinking. It's the first time you're going to see how your customers react. So obviously we need to do that first time. The second time, once you've synthesized that, is your first opportunity to see how your reactions play out. How well did you understand what they did and how well do your adjustments work? And then that third time is the opportunity for you based on those reactions. You may need to pivot, you may need to do things entirely differently or you may need to, that may be your opportunity to iterate and improve on your MVP POC, your concept. So obviously once again, do as many of these rounds as you can. But if you can get to three, you'll either have been able to perform a pivot and you'll have some validation of that you're on the right track, you've made an adjustment, or you'll have had two rounds of improvement to a product given your first reaction to customers. Now if you've gotten through three rounds and you still are getting a bad reaction, well then you might need to rethink the concept or rethink the initiative. And if you can get a budget for more of these or get approval for more of these, then all the better. That's why we choose three. So at the end of this process, what have we done? We've validated our product idea. We've got a proof of concept that has been presented to our users or our customers, has been validated more than once. We've been able to adjust and hopefully improve. We've created a team wide understanding about the product, the customers and the fit between all of them. We've got now probably buy in from developers, from the business, because they've been exposed to all these activities. And most importantly, we've established this methodology. When I've done this with groups in large organizations, they've been shocked that, why don't we do this for every project? They've been amazed that first of all, how long they could be after that first shot against the clients. We've got a great idea, we spent a long time in marketing and in the business thinking about it and designing it. And we put it in front of people and they don't get it or they don't need it or they don't want it. So when we're doing this methodology of having three rounds to adjust to that, to adapt to that, and we've gotten to a place where now customers didn't get it. But there was some nugget of what they would want, did a little bit of an adjustment and said, okay, we think this is what you guys want, yes, this is what we want. And then one round of iteration, customers are now excited about the possibility of this new product. You've got a stronger argument to be made when you present this proof of concept for approval and you've got buy-in from everyone involved in the team, as well as in the product and in the process. So ultimately, this is one way that we've found to sort of cross that threshold, introduce a seed of innovation that hopefully can sprout into sort of methodology that can grow and a way to do good design, if you call it lean or you call it whatever you like. A way to do good design in your organizations. What comes next? Typically, establish those metrics that will drive the product forward, scope that initial release, and then repeat with buy-in from the company and buy-in from your customers. Thanks, I'm too bad on timing, second one.