 Everyone, thank you for coming. Can you hear those? Was OK? Yes. So, hi. Our topic is the future is messy, and this is because we believe that companies all around the world are causing great disruption in various industries. Sometimes governments are causing disruptions in various industries. So in today's talk, we'll be talking about how we see digital leading this change, and how we believe that inculcating a mindset of design that's user-centered is actually going to help us navigate this disruption and make some sense of it and build something useful at the end of this. My name's Sneha. I've worked with ThoughtWorks for several years. At the time of submitting this talk, I used to work with ThoughtWorks products, products division. I used to manage an agile project management tool, which when it was launched many years ago, we believed was the first digital card wall, which is now so mainstream. Since though I've moved out of that role, I currently work with our clients in Southeast Asia, startups in various stages, helping them with their product strategy, and setting up teams of show that can help them execute on that strategy. Hi. So I started my journey in ThoughtWorks in 2003, played roles of business analyst, program manager, project manager, with different clients, like small clients, about 10 people to about clients which had about 200 people in our teams. I've also interspersed that with doing some roles within operations, running an office, starting off practices, being part of the demand team, and working with the market in Europe. My current role is that of the head of operations or CEO for ThoughtWorks India, where I basically look after how we are servicing clients, how we are bringing on board people, and how we are basically looking at improving the way we actually deliver software to our people. So as Cia mentioned, we would want to share with you our thought process in terms of the journey that we have taken as an organization, because we have been using Agile pretty much since 1999, 2000. And a large part of the conversation that we'll be having today will be using examples. Some for clients that we'll name and some for clients that we won't be able to name. But it'll talk you through the design thinking approach and how we'll be able to do that. All right, so oh. So it's Uber, right? OK. Thank you very much. All right, so we believe that the world has seen four industrial revolutions so far. The first was when steam became a way to mechanize production. And that changed the way various businesses were run. It opened up opportunities for new ways to run businesses. The second industrial revolution started with the advent of electricity, because then mass production was enabled. And that created more opportunities. Then we believe the advent of the internet brought about the third industrial revolution, because that spawned off some of the internet businesses and changed the way people were doing business. The World Economic Forum dubs, what we're in right now as the fourth industrial revolution, where technology is at the heart of value. And what this really means is that businesses today no longer see IT as a separate department, as a supporting department, but actually crafting business models around the technology that's available at that time, which is right now. For example, if you take Netflix, if streaming as a technology had not come about, Netflix would have never figured out a business model where they can use it to create a new offering for their customers. And now that they have, traditional cable companies are at threat completely. And they don't know how to deal with this change, this kind of disruption that's happening in their industry. And all the time we're hearing about this. Every supermarket chain is worried about the threats that Amazon is posing on them. And they're wondering how to catch up. And that's where really all of the industries is really, it's very hard to think of an industry today that's not being disrupted by some sort of technology advancement that's happening in this space. So what we're really thinking about, and something for you to think about as we proceed today, is tech is no longer a separate function, which is just getting requirements that are thrown over a wall to them, and then executing and throwing something back. Tech is actually at the heart of every business. And a business is crafted around tech. And the scale at which this is happening is unfathomable at this point. Most industries, most companies don't know how to get around the sort of complexity that this is causing. Entire systems have to now be rethought. Because in the past, if you think about it, when steam came in, when electricity came in, it was about automating manual processes, to make them faster, to reduce manual labor, to make things higher quality, for instance. But today, what the kind of disruption we're thinking about is it's not just to automate things. It's actually to think about things being done, things that were done a certain way for several decades, being done completely differently, like Netflix has. So it's causing a kind of complexity that no one's ever dealt with before. And today, we'll be talking about some of our clients and how they have steered through that. So before we do that, let's just look back in terms of how we've actually got here. And around that, Srinath spoke about the third industrial revolution. And that brought to the fore certain ways of actually looking at problem spaces, breaking them down, and actually solving them. So Arnold Smith introduced this whole way of what we call reductionism, which essentially takes up problem space, which is well-defined, well-understood, and then decomposing it into component parts, subcomponent parts. A large part of it was, how do you break down a problem, decompose it into small parts, analyze, solve that specific problem, and then decompose it, bring everything together to actually finish the solution. Now, this kind of problem spaces, if you look at it. So the y-axis is showing uncertainty. And the x-axis is showing the scale of such problems that you could solve. Essentially, you're talking about ones which are fairly certain. So the uncertainty is low. The change is low. And you can actually scale it out in terms of this particular approach. What this does mean is that it does take a fair degree of time. Like, some of these projects could actually run for years, where you're doing the problem understanding, the decomposition, the analysis, the build, and then decomposing and putting everything together. Now, if we were to look at the other end of the spectrum and start thinking of what this led to. So a large part of what this whole approach, in terms of decomposing well understood problems, doing that analysis, led to is management structures, which really started resulting in ways in which the primary objectives was to actually reduce and mitigate the uncertainty. So it was all about risk mitigation. How do you put in structures which were around approval, command and control, which really meant that all you're trying to do is, as the different components were being decomposed, you were putting an approval process to ensure that the respective steps were done the way the approval had been given. So that when the whole thing was composed back together, it would work, because you had very little ability to actually adapt and respond to change in this kind of a model. So this is basically at one end of the spectrum. And today, as we move forward, we brought about another end of the spectrum, which is types of problems where you know that there's going to be a lot of change. There's a lot of uncertainty. So there's a fair degree of discovery which has to be done. So in this kind of an approach, there was this whole need of looking at a problem space, picking up a very specific small problem, and then trying to see that, OK, what can I learn about that space? What can I go and try out there? And basically use this whole cycle of the test, learn, evaluate, apply, and then again, learn. And this became very apparent with a lot of the things which started in the lean manufacturing world, where there was production processes, production systems where you didn't want to really impact operations. You wanted it to go as per plan, but at the same time, you wanted to bring in improvements. You wanted to bring in incremental change. And this kind of approach is what basically allowed us to move ahead. Now, if you look at these two, the second one deals with uncertainty, deals with change, but you have to do it at a small scale. So what it essentially means is that as we start looking at the class of problems that we are encountering today with the kind of rapid change which is happening, the fourth industrial revolution, there's this huge white space which is over there. And this white space is something which we will have to tackle. But before we get into that white space, just move a little ahead in terms of seeing how in terms of understanding things which are changing a lot faster than, let's say, of a standard SDLC model, led us to another way of actually solving software problems. So in the early 90s and 2000s, there were opportunities where with the internet becoming pretty much accessible to a lot of folks, there were digital products being built, especially on the web and mobile. Now, this allowed that whole approach of looking at change, addressing that uncertainty, and starting to iterate through what essentially became the lean product model, where you started to understand a class of users, come up with a solution, take out MVPs into market, and then iterate through the product. So this allowed us to start, and a large part of what we talk about in agile around failing fast, doubling down, pivoting quickly, started actually getting ingrained in the way we work. And this essentially was a big change that we started seeing. Now, I spoke a little while earlier about this space, the right-hand side still being an empty space. Because now you have two ways of solving problems. Problems to well understood, problems which were not that well understood, and you were trying to tackle some degree of uncertainty. The class of problems that we are now starting to encounter brings a quantum leap in terms of the uncertainty. And this is what we are referring to as the messy middle, because in terms of the scale at which we are having to solve these problems, they are a much larger scale. And if we start thinking through what causes this kind of complexity, so a lot of this is in terms of the different types of users there are. It's no longer a single user and a single type of user who is basically giving you requirements. We are literally trying to figure out a solution where you can't make everybody happy, but you are trying that. There are innumerable connections which start coming in. And this is in terms of the different processes which may be there. So we are talking about large scale digital transformation. Organizations trying to change from being a traditional business to a digital business. So that means the existing system, the process, and all those interconnections have to be overhauled. At the same time, like in today's world, in the fourth industrial revolution, the speed at which technology is changing means that you don't always know that the technology that you're going to apply, whether it will solve the problem. So you're going to take some incremental steps to try things out. That means solution architectures, technologies that you try out, they also have to be trialled out and put out there and have to go through that whole feedback and pivoting loop. So net-net, like when we are talking about building these systems, so you don't have any patterns which you can drop on. A large part of what we did over the 2000s in the agile world was being able to apply patterns. There are so many books which have been put out there in terms of design patterns, patterns in which you build certain types of systems. But this whole paradigm is what's shifting right now. So we are not really good at solving these messy problems. And as we said, we want to take the whole approach around design thinking to see, can we solve these messy problems? How have we had some successes? I just want to take a feel of the room. How many people are familiar with the design thinking steps, these five steps in design thinking? Cool. I'll spend a little bit of time on this then. The design thinking approach is all about thinking about the users much earlier in the lifecycle of a product, rather than when the requirements have been firmed up and then you're starting to build and then you're testing with the customer. This is about actually trying to design your solution itself around the end user right from the start. So not only at the point when our solution's already figured out and it's already gone into development, but much earlier in the game where you're trying to figure out the idea itself by understanding the user, rather than by understanding the process or the industry, but actually put the user at the heart of every solution and design around them. So typically, this process is broken down into five steps when first you try and understand what an end user might look like, what are the day-to-day motivations and gains and what's irking them right now, and how we can start to solve some of their problems. And defining the problem statement from the perspective of the user, rather than a problem that exists in the industry that needs to be solved. So how we define the problem itself, how we articulate the problem, has to come from the perspective of the user. And then we brainstorm, do blue sky thinking and figure out all kinds of possible solutions to this problem. Some things that may not even exist today, right? May not even be possible, but just to keep our options completely open and then see if we can innovate using those ideas which are really blue sky. And then we don't go out there and start to build out the whole solution. And this, I think, is familiar to everyone where we first start to build out small prototype or a quick minimum viable product and test that, get feedback on that with the same users and iterate as we go. So the process of involving the user and keeping them at the heart of the process starts much, much earlier in the product lifecycle. And that's really what design thinking is all about. So what we'll be doing is spending some time on examples where we think our clients and we have worked well on each of these different places, where they put the user at the heart of the problem and done a good job with dealing with that messiness that's up those talking about earlier. Sure. So we'll take some examples. And what we're essentially trying to do is try to talk through what each of these steps predominantly looked like in one of these examples. But each of these examples had to be solved by going into the entire whole talk. So just to help from an audience standpoint for you to understand where did the primary step coming and how did we actually go about looking at that solution. And to start with the first example, so Hemant Khandilwati is basically a friend of ThoughtWorks. And when we started having conversations with Rivigo where he actually plays the role of the person who gets innovation, like we started to get some insights into the way Rivigo was starting to look at the kind of users that they were working with, which were permanently track drivers in the logistics space. So how many people here are aware of Rivigo? Not too many, so fine. So let me just quickly give you an idea of what this landscape of logistics looks like and this whole landscape of delivery looks like in India. So in India, like obviously, we still are investing in building infrastructure and we do have a very constrained road infrastructure set up right now. What this essentially means is that the costs of moving freight is pretty high and from a comparative standpoint, if it takes about 10% of the GDP in the US and about 8% in Germany, India is about 30% to 14%. So it means that there's a lot of investment needed and a lot more players who need to come up with innovative solutions where they're looking at the kind of problems which are there and trying to solve. Now, in terms of productivity, one way in which productivity is measured in the logistics industry is how long do you travel in a particular time duration? So for India, it is about 15 kilometers an hour in which people are able to travel distances. Now, what this means is that we're all taking advantage of the e-commerce boom in India, right? But we have a constrained system out there. So it puts a lot of pressure in terms of the people who are actually working in the space and a large part of it are truck drivers. So truck drivers, in terms of trying to cater to this particular need which is there, there's already a shortfall of about a million. A lot of truck drivers are looked down as a low-cast and we have that problem, something that we have to acknowledge in India. At the same time, they spend about 25 nights away. So in terms of looking at it from a truck drive as a user, they really have a pretty bad space to be in right now. So Rivico started looking at this and started thinking through, how do you solve this particular problem? And that's where starting to empathize with what goes on in a truck driver's life and how do you improve that led to the solution. Now, in terms of the solution, a large part of it was looking at, how does a truck driver operate? What is the entire process in which it's happening? So a key innovation that Rivico brought about is to bring in some form of a relay system. What it essentially means is that you obviously invest in technology. You put in tracking mechanisms, GPS systems into each of the trucks. So you're collecting a lot of telemetry data. You are collecting at what speeds they are traveling, what the bottlenecks are. You basically throw in all the algorithms around optimization, scheduling and all of that. But along with that, what Rivico did is that by putting in this relay system, so drivers had to basically go from point A to point B, which was roughly about 200 to 50 kilometers before that same truck was picked up by the second driver and that with the relay system continued. At the point where the relay or the big exchange happened, that the first driver used to take a truck to come back to the point of origin. What that meant is that it allowed the drivers a lot more time at home. You're not spending 25 days on the road. It led to obviously a lot of improvement in productivity because more engaged drivers, you're tracking a lot of metrics around them. You're basically going to make their life a lot more successful given all the constraints around road infrastructure. And what it meant is that productivity shot up about three times. In India, about 25% of the rolling stock, which is basically trucks, are usually like setting idle. And Rivico was able to actually improve that turnaround time by about close to about 50%. And so this driver relay model was one of the great things that at least we started learning about when we started having conversations with Rivico. So I'll hand over to Sneha to talk about the next step. Again, in any of these examples, we had to go end to end in terms of the design thinking approach, but we'll focus on some key steps. Oh yeah, so empathizing with the users the first step and being able to understand what motivates them and what problems are really worth solving for them in designing around that is important. But what we do with all of that insights that we get from understanding the user is that we start to define the problem from the perspective of the user. It's something that we're used to doing in the agile world with a micro level with stories. We say as a user, blah, blah, blah. But this is about stepping back in ideating itself from that process, from the perspective of the user. So it means that we apply that thinking, that user-centered thinking, right from the start, right? From before we even got an idea. So I'm really inspired by clients that we're working with right now who's in the insurance space. I mean, insurance traditionally has been a complicated space, right? I mean, it's a messy domain and there's so much documentation. There are so many different types of insurance cover. And our client now is focusing on employee insurance that's employer provided. And it's a messy place to get in because I don't know about you, but my experience is while we have great cover that's provided by my employer, I've never really clear what my policy covers, right? And it's not easy to get that information. It's always a few steps away. It always feels tedious to get to that information. There's so many times I've not put in a claim because I know that the process is so heavy. There's so many steps. There's so much documentation that's required. Generally tend to stay away from it. It's not something I enjoy doing or that I can do painlessly. Is that relatable or do people feel that way as it just wouldn't? Insurance is just like a messy area, right? That we don't want to get into. From the employer side as well, a lot of HR time is spent adjudicating these claims, right? Because if you look at every claim that comes in, see if it's covered by the policy, see if there are any other things they need to look at and then approve or rejects that claim. And a lot of employers do want to get into this space so they outsource it to somebody else, which is a big expense as well. And then adds to the process because now you also have to send it somewhere and there's that paperwork as well. And most insurance policies that are out there these days are all about curative care. I think wait for you to fall sick, go to the hospital and then reimburse your hospital bills or cashless of you. If you can do that, but it's about first falling sick and then using your insurance. What our client is doing, you could step back. Step? What our client is doing is actually thinking about preventative healthcare, which is a fantastic idea because the founder believes that has studied this extensively and believes that in Asia, heart disease and diabetes are hitting people in Asia 10 years before it hits the West. This is something that's underreported so it's not something that's as well known. And she believes that preventative healthcare should be the way forward. This is what will disrupt the insurance industry. So giving employees the cover for gym memberships or making lifestyle changes such as like an anti-tobacco program or things like that. She's saying that's where your insurance cover should really be, you should be allowed to spend it there. And so what she's doing is she understands and we've been helping her with this is that the end user doesn't really like to get into this messy area of insurance like you and me. So by actually understanding that user better and seeing what really their problems are and then articulating what we can set as a goal for ourselves, but from the perspective of that end user, it makes all of the difference, right? So she's basically scrapping existing insurance processes not constrained by the way the insurance industry is working right now, but it's thinking about redesigning it from scratch from the perspective of the user. So in this particular case, she's thinking if an employee is resistant to submitting their claims, there's a few reasons why. And so let's try and make it better. Let's put the wellness of the employee first. Let's have all of the employees start to think about their healthcare in a sort of preventative manner. So they're thinking about having better lifestyles and creating better versions of themselves. And that's a great goal to have and that's how we define the problem in this for this particular client. And this is something that's hard to measure, right? The one that says better version of themselves. We put what we call measures of success on it so that we can track how we're doing on this. These are actual values that we're hoping to give that end user. So that's how we'll track whether we're getting that user to that goal. And so then we extrapolated from there. We said, okay, great. So the end users, the employees who are actually availing of the service of insurance are of course our primary stakeholders. If you take a step back, the HR also has problems, right? They also have the hassle of going through all of the claims manually and then figuring out the paperwork around it and all of that. So if you can understand their problems and create a goal from their perspective, define the problem from their perspective and then put some measures of success on that, that's helpful as well. And then we took another step back and said, distributors who are actually providing these insurance products to the employers who are in turn giving it to their employees, how about solving their problem as well? And so then we defined a problem from the perspective of the distributor, the insurance product distributor itself, as well, and then created a measure of success from it. And then what we did was, this became our guide rail for developing the product, for figuring out what kind of features need to go into the product. Because if a feature did not help us get better at one of these measures of success, there's no way it was gonna get us to this goal. And so we defined our product vision from the perspective of the three individual users in this system. And we talked about it in terms of what value they will get at the end of it. And it wasn't really process-oriented, right? What man, about automating a process that's to allow for adjudication of claims, which is mostly manual. It wasn't about just automating that system, but about actually rethinking how we can redesign the whole process of insurance altogether. So, moving ahead, so in, we so far spoke about really empathizing, defining, but a lot of times like while we have been talking about being tech at core, sometimes tech is an enabler. And in some situations, tech may not actually be the solution. So we also wanted to talk through one of the examples where really the whole power of ideating becomes very important for the way you solve a problem. And you could take a process where you look at similar class of problems and come up with a solution which is very convergent. Or you could look at a class of problems, see solutions, and then come up with something which is very, very divergent. And so we wanna talk through one example where we came across where we felt that the way this was solved was really unique in terms of the approach that was taken. So, how many of you are aware of Arvind Eye Hospital and the approach that they did? That's great to hear. So I'll try and talk through what they've done. And maybe some of you can chip in like if you've had a chance to experience them or actually understand much better how they work. Now, so blindness is a global problem. So worldwide, we have about 45 million people who are blind and every year, there are more people who are being added to the list. India contributes to about 25% of global blindness. And this is a problem which can be solved. Essentially 80% of the cases are preventable. What it needs is a good set of ophthalmologists which are available to actually work with patients, do surgeries, bring in preventive care. And in certain cases like there are these intraocular lenses which are available which actually help alleviate it. Now, in India we do have a constraint system again like similar to what we were talking about really go in the transport sector. And this is more in terms of the lack of doctors, right? Lack of trained ophthalmologists. So a typical surgeon can do about 400 surgeries a year. But clearly like if you look at the scale of the problem in India, which we have 25% of the population which is affected by blindness, it is not something which is solvable. And at the same time like importing some of the the intraocular lenses of products, it's fairly expensive because each costs a bomb for the typical traditional Indian out there because they are constrained in terms of money as well. So if we look at this constraint system and think about okay, how does one hospital with maybe one ophthalmologist, one nurse, one operating room actually solve this, it is not something which is solvable through the solution. So no matter how much of technology you throw at it, the constraint is really in terms of the kind of people who can actually solve the problem. So the way Irvind, IK basically went about trying to solve this is what really brings out the whole aspect of like how do you ideate something and come up with something which is a really divergent approach. Now what Dr. Govindappa did is that near Mathurai, he started going out to villages where he started recruiting about 100 women and training those women to actually become nurses. So in a way they were being trained to actually support ophthalmologists, become semi-ophthalmologists. And essentially along with that, there was also investment that he did in trying to figure out like how do you manufacture these intraocular lenses at a much lower cost. Now a combination of these two, it may have been enabled by systems. It may have been enabled by software products that Irvind IK obviously either built or leveraged off the shelf. But net debt, the solution that they came up with in terms of like actually training a set of nurses to actually solve the problem around the constraint on doctors, meant that there was a five x productivity. So instead of a doctor being able to do 400 surgeries in order to do 2000 surgeries in a particular year, the cost reduction came down because instead of a $150 intraocular lens, the manufacturing cost brought it down to $5. With the nurses who were basically being trained and supporting, the cost of the surgery came down for people. So what this is allowed Irvind IK to do now is that they are doing close to half a million surgeries in a particular year. So again, we wanted to talk through this particular example because this is one where technology is an enabler. Technology is not the only solution. And there are ways in which you could solve problems where you don't always have to depend upon technology. Ideating and improving the way and taking a divergent approach is something which also works. Yeah, so moving ahead, before that, did anyone want to share something that they are aware of Irvind IK and any experience? Yeah. What I read is that going the pub and igniting the idea about how we can go about it through the McDonald, the bar counter. So that's where the mass production was at the low, I mean, high volume, low cost. That's where it triggered. Yeah. Yeah. Thank you, Shalini. Okay, so moving ahead. We're moving on to the other end of the design and thinking stages. We were talking about prototyping or building something really simple and getting feedback on it before we're actually going Big Bang on the launch, which is a concept that I'm sure is familiar to all of you. We worked with a client that initially started out as a ride-hailing service that onboarded hundreds of users, thousands of users onto their platform, as well as thousands of drivers onto their platform. And then they chose to open up more product lines where you can actually order a masseuse to come to your place and give you a massager or get someone with a salon specialist to come to your place and give you some sort of service. And they really widened the spectrum of offerings that they had because they had the assets for it already. They had a customer base. They had a driver base that they could leverage. So they started to increase their product lines. And so now they work with all types of merchants and vendors and not just drivers anymore. So the problem that they were facing was on how to create a sort of settlement process with all of the vendors that they were working with, all of the different types of merchants. If you can move to the next one. So tracking the cash flow itself became messy. Settlement itself had to be largely manual with these people, spreadsheets flying back and forth. And they thought this might be an interesting challenge to solve. And this is something they could potentially build as a new product that is available on the merchant side. Because basically what they've done is aggregated all of these apps into one super app. So they thought maybe on the merchant side this is another product they could introduce where settlement can happen through the app. So, but what they found was that it's not as easy as all that, right? Because each merchant has a different settlement process. They have different payment payout methods. There's a lot of paperwork and manuals sort of tracking of all of these expenses that has to happen. So what they decided to do was to start really small to deal with this. What they did was they took one actor in this entire system, which was their own people. And they said, you know, let's try and figure out if we can solve cash flow problems within our organization. So let's do expense reimbursement that our employees, you know, any expenses they have and they're traveling and so on. How can we start to automate some of that in-house? And so they built this product. They tested it with their own customers. So they sort of dog fooded that product and said, are we able to build this out? Is this something that, you know, is this an area that we can get into? They didn't want to invest very highly in this because this is not really in their space. But they wanted to build something simple to see if that actually is worth building out further. So they did that. They dog fooded it. They created an expense reimbursement application that was being used internally and that went okay. But it was a point for them to look at it and say, hey, are we doing okay? Should we continue to build this out? Or should we just trash this product now and move on to something else, right? And that worked out okay. So then they looked at another set of actors. You know, they look at one set of merchants and look at the transaction between their company and that one set of merchants to see, okay, can we now solve the cash flow problem between this set of merchants and us? Because now we're extending that problem a little bit. Okay, so the previous product sort of worked as a POC to create this new product, right? Because they were just extending on that. And again, they were at this point where they were like, okay, hey, let's go test this with this merchant. See, does this work? Does this not work? Should we scrap the product? Should we stop where we are and go back? Or can we continue to build it out? And so this is what they continue to do. After a period of time when they started to build out this product to satisfy different types of vendors, they found that this really wasn't a product that would scale well. They realized that one single product couldn't really solve the problem that everyone was having in the system. So then they stopped. They decided to stop where they were and continue to use the product for whatever little it could do. But they decided this was a good checkpoint for them to say, should we really invest in this further? Maybe not. Let's channel our efforts elsewhere. So the whole concept of your product itself being a proof of concept for you to build out the next version of it is a fairly powerful way of thinking, especially when money is tight. So we have another 10 minutes, so we'll try and see if we can wrap up the rest. So we spoke about the design thinking approach and I think by now a lot of you would have realized that it needs teams which really come in with a very different mindset. And this mindset is possibly when we're talking about solving big, messy problems, that mindset is something which is plus plus agile is what I'll call it right now. But really the class of problems I'll be talking about it essentially means that the entire team and when I talk about team there are different roles, different actors who start coming in. The way they start interfacing with each other, the way they start influencing an organization has to really change dramatically. And if we think about where this complexity is going, like it is just going to grow bigger and bigger. And there are a lot of organizations who are basically going through this digital transformation. They're trying to become digital businesses. Essentially a large part of it is more different types of users, more interconnections, processes which have been baked into the system which really have to be overhauled completely. Now what this leads is that in terms of some of the kind of personas, some of the kind of teams which really become start becoming successful in an organization is ones which can deal with the tech complexity, the business complexity as well as the complexity of how do you grow and onboard people to be able to work in this kind of a culture. So as we have been working with a lot of clients the last two, three years, especially clients who are trying to become digital businesses, what we have been realizing especially in ThoughtWorks is that there is a lot of need for actually having people and teams who are not afraid to cross silos, who are not afraid to go across departments when it's needed. So it's basically like people who are actually willing to break down walls. There would be initiatives which are possibly faltering but a set of go-getters who are going out and actually rescuing these initiatives and taking the onus on themselves or actually bring the transformation because a large part of design thinking is less about process, it's less about the technology. A large part of it is like how do people apply themselves especially through it and it goes without saying. It's like a leader with no need, right? You lead without a mandate and that's what becomes important for people as well as teams. So in terms of how the world is changing, let's just do a comparative analysis and say if you can talk us through that. Yeah, so we were to rewrite the agile manifesto today given what we know of how the industry is changing. We wrote our own agile manifesto style and it's where there are two things. The thing on the right or bottom in this case is good but the thing on the top or the left is we think is better and that's where we need to channel our efforts. And the first one I'll talk about is about not really being, not focusing all our efforts on delivery plans because we obsess over that a fair bit, right? Every time we're in agile team we're like all story points, velocity, scope. That's what we're talking about all the time but if we change the conversation and talk more about the value, the measurement of value that we're giving to these end users whom we've started to empathize with right in the beginning, that would be a better way. We'd be building more valuable products rather than worrying about whether we'll do it on time and whether we've got the right scope in place and all of that stuff. Not that that isn't important, that should just be an aid but really we should be tracking progress by the kind of value that we're giving to the end users which really means putting the user at the heart of the problem rather than trying to meet metrics that the business has decided, putting the user at the heart of the problem and the solution in figuring out if we're making their life better. And like Saptoh said earlier, we need people that are willing to play dynamic roles and not being restricted to the role boundaries that traditionally we've all grown up seeing but we have a fixed job description that we all fall in but rather somebody that's a lot more dynamic who's able to move across different roles in different departments to do the best job possible. And what this means is that you can't have an IT team sitting in a silo saying, hey, we're good at tech, we'll do tech well but instead you, because business models are being crafted around technology, your tech folks also really need to understand business well. They need to be able to wrap their head around business models and build for it rather than being, waiting for requirements to hit them over the wall and then throw something back again over the wall. And really what we're looking for every team to do is to be able to take a step back, not just look at the immediate problem that they're trying to solve, but look at the larger picture and see the ecosystem that we've told you in all of the examples. So the problem is not a point problem, right? It's all about taking a step back and looking at the larger ecosystem and seeing are we really making an impact in the larger ecosystem. And required elicitation is a very transactional process that we're used to, right? Because at the end of the day, we wanted to create like a spec document. But what we really want to emphasize now is having meaningful conversations because that's how you bring about empathy and that's how you bring about curiosity in your team to solve the right problems. So having more meaningful conversations, challenging, questioning what users really want and whether our solutions actually solving a user's problem will require much more meaningful conversations than we have traditionally had. Yeah, in addition to like those conversations around users, a large part of it is like helping with the entire change in issues which organizations have to go through. Which means conversations which are also in terms of working with teams which have built and maintained systems for ages and how do you change that given some of the choices which have to change? And finally, we can no longer have roles in teams that say, hey, I'm not a techie, right? I don't get technology. We can't afford to have that anymore because technology is so ingrained in everything that we do that now understanding technology where then figuring out what business problems this tech can be applied to or how you can leverage the tech to create a business model is going to be more important than just being aware of what it is. Think again about Netflix, right? If I didn't understand what streaming was like, there's no way I'd be able to create a business model around it and offer that as a service to my customers. And to flip it on its head, it's also technologists who come in not with a specific solution and this is the technology stack that we would want to solve a problem. But sometimes maybe technology is not going to give you the solution as we saw in one of the examples with that in the decade. And that is the kind of collaboration with people that we're talking about. And so while those are some good things to keep in mind for teams, as we go forward, the kind of people that we would like to recruit into these teams, we have to think about whether they bring these traits to the table, right? These are traits that we will have to work. If we don't already inherently have it, we'll have to start to learn to develop it because this is what is going to be valued. Interview processes should ideally be designed to figure out if people have these traits inherently in them, right? Because empathy, like we've said, is such an important part of the world going forward. Being having sort of the resourcefulness and taking leadership, being able to be dynamic, these are some of the traits that you will start to value in people more and those are the kinds of people that we will want to bring on and more teams going forward. So we want to end with a small video. I'll just give you some context around that video before we start it. So this is a client that we work with in Toronto called Natural Food Markets. And essentially it's a grocery chain and they sell a lot of organic produce. And in terms of one of the key problems that they want to solve was how do they make payments seamless within one of their stores and then take it out to different stores. So the video will talk through the obviously the approach that has been taken and the whole collaboration which have to be done between business leaders and natural foods, people in ThoughtWorks having to put on multiple hats to really understand it from a design thinking approach and then how do you solve it specifically for this class of problems? Significance of the new restaurant and store concept was to integrate number one, first integrate a market concept, a what we call retail food concept into a food service concept. From there we felt and knew that we needed to really operationalize the space and make it very, very efficient. It's in a mall, it's one of the largest malls in all of Canada, it's one of the most populous. We have hundreds of thousands of people who are passing by the restaurant on a weekly basis. And we knew that we had to provide a great service to those customers through offering food quickly to them as well as offering great food which is providing organic and natural food, food that is antibiotic free, hormone free, that is local, has been a real focus of ours and bringing that all together was really what we set out to do. From day one, he had a very, very clear vision about creating a very unique customer experience whether it was in their restaurants or if it was in their grocery formats. And that's I think what grocers and retailers today are faced with. It takes them from being undifferentiated to being completely differentiated. We knew that everything had to be consistent from both the customer experience and also behind the scenes for the data. And so we decided to pick technologies that were both mature enough to support what we needed but not so bound up with their decisions that it dictated the vision that natural markets was able to take. When we opened the Rich Street natural market restaurants here at the Eaton Center we put together the best in technology to really allow the customer to have their choice. Our goal is to let the customer pay any way they want throughout our entire market area from an operational perspective. We really wanted to find a way to bring together many ways of ordering that is transparent to the customer so that they can order while they're on a train and pick up their meal that are expressed to go. At the same time, we wanted to be able to allow a customer to stand in the kiosk in order for multiple kitchens while sitting at our foundation bar and enjoying a drink. We created a mobile application that allowed our customers to quickly download it associated to a credit card and then utilize it at every station, keep track of their orders and it'll enable them to really feel like they had one form of payment that they could quickly utilize or furnish across these stations without having to take out a credit card or without having to see multiple transactions on their bill. Our core focus was how are we gonna really improve payment and people being able to enjoy great food across multiple areas. So getting in depth with MarketPass, we took a multi-pronged approach to this and we started with a minimum viable product. The minimum viable product hits at the core of our message around service augmentation and allows a customer to check out quickly. That's it. Another area that we really focus on was children, making it a family-friendly environment. So you can see what we did with the children's interactive wall. We call it the market garden. It's a farm type theme so it's consistent with the Rich Street Natural Market brand but it allows kids to have a good time. We have tables nearby where parents can enjoy a meal while their kids play and have a good time. Natural markets is really doing something important for society. The importance of getting healthy and organic food to people during the midst of a busy work day through their location and shopping centers, their grocery stores and the combination of stores like the Eaton Center here with a restaurant and a grocery together, we truly got excited on getting behind us. The industry itself is growing and to have a player with the integrity of the natural markets folks doing the bold things they're doing, you know, we couldn't ask for a better partner. We've got to continue to strive to take a mobile experience which is a very individual experience and really make that personal. So in terms of going into a grocery store and buying food on your mobile phone and not even having to interact with a cashier, that's something that we absolutely want to do, but we also want to ensure that we're still providing a great experience.