 Good afternoon, everyone. I am Mitch Connors, and we're going to go ahead and get started. How many of you have been around enough to remember Atari, the 2600 platform? Anybody? I know I grew up using the Atari, and now sort of things have come full circle. I just bought my kids an Atari for Christmas. Wouldn't have expected that, you know, 40 years later, but Costco had the special and I bit. They're loving their retro gaming. It's a bit hard to see in this shot, but that's actually an Atari cartridge in the hand of this construction engineer. There's a rather infamous story around this. The year was 1983. Atari was unstoppable. The 2600 sales across Europe, Asia, the United States were through the roof. Every single game was a hit, a moneymaker. You just couldn't go wrong with Atari. At the same time, there was a cultural phenomenon going on in the cinema. It was E.T. The Extraterrestrial had captured our imaginations. Now, what could sell better than the intersection between these two amazing products, right? Well, it turns out E.T. was not such a smash hit on the Atari. And this particular frame is from a documentary produced a few years ago. This was legend in the software industry for many years. And now it's been confirmed that there are literal landfills full of E.T. The Extraterrestrial for the Atari 2600. They went and found them there in the desert out in, I think they was in New Mexico, Algodonis area. So definitely Atari tried to bury this and hide it, but word got out. And so it turns out that the intersection of these two unstoppable market phenomena was a complete flop. And so we're left to ask ourselves what caused everyone's favorite friendly alien to end up at the top of a garbage heap. Now, this story has been explained over and over and there are as many explanations as there are times the story has been told. It's a supply chain issue that they had to produce too many in advance and weren't able to respond to demand dynamically. Or it's a marketing issue. They didn't really, they thought the marketing would do itself because it was E.T. So I'm going to go ahead and add my reason to the list of reasons on this. I think that what they had was a lack of empathy for their users. Does anyone here actually get to play E.T. on the Atari 2600? A cartridge on eBay today will go for well over a thousand dollars. So it's not surprising. Most of them made their way to the garbage dump. If you did get to play it, it was nearly unplayable. The game was unbelievably difficult to beat. And most people who played it never survived the first level of the game. You could look at this as an economic problem. Coin operated games had been the standard for Atari for several years. The 2600 was a relatively new thing. Coinop games, you want them to be fairly difficult because you want people to keep coming back. Another quarter, another quarter, another quarter. But once you've already spent $100 on your Atari 2600 and $25 on your E.T. Atari game, you don't necessarily want that same experience of perpetual death. Today, you know, games that are very difficult to play and notoriously hard actually have a niche market. Any Dark Souls players in the audience? Okay, all of the sad looking people just raised their hands. However, at that point in time, the target audience for E.T. the Extra Terrestrial on Atari 2600 was not a bunch of adults who might be willing to really buckle down and do something that's incredibly difficult and obsess over this thing. It was children. It was the seven-year-old who loved this movie and wanted the same experience in front of their TV screen. And so to watch their beloved characters die again and again and again really did not scratch the itch that these particular users were looking for. You could also look at it from the perspective of development because up until that point, Atari 2600 developers had largely been those who enjoyed playing games, right? Breakout, Pac-Man, these were things that developed obsession and those who obsessed over them considered how to make the next version. Well, E.T. was such a slow-pitched down-center for Atari that they put engineers who didn't necessarily play a lot of video games onto the development team. And of course that showed in the output here. So what we're going to be talking about today is how we can avoid making the mistake that Atari made. We all from the cloud-native community are developing products, whether that be open-source projects as a part of the CNCF Foundation or that be the tools and platforms built on top of them or that be the applications built on top of those platforms. Kubernetes is a platform for platforms and platforms deliver applications. So whatever layer of that stack that you're sitting in, you're going to need to release a product. And if no one uses that product, it does not matter how amazing the technology was, how perfect the marketing intersection was and the research done was. If no one uses that product, it doesn't matter. My name is Mitch Connors. I have been a software engineer for 19 years and that's really been my comfort spot. But six months ago I made what, we'll see, it might be a career fatal decision, but I became a product manager. I've resisted any other titles for a long time, but I went ahead and took that on. At Aviatrix, where I work, we provide multi-cloud networking software. I came in to add Kubernetes functionality and it became pretty clear that we needed a product manager to get this moving forward. It wasn't an engineering problem, it was a product problem. So I'm going to be talking about my experience doing that. But of course, in addition to my work for Aviatrix, I'm also a member of the Istio project where I sit on the technical oversight committee as well as the steering committee. We've had our own share of moments where perhaps a little bit more product management, a little bit more user empathy would have assisted the project and we're going to talk through those. And then I'm also a cloud-native compute foundation ambassador which is why I'm hoping that this talk is broad enough to apply to you whatever you're building within the CNCF and the cloud-native ecosystem. All right, well let's get started. So this is jumping back to my days as a software engineer for a SCADA system in an oil field. Technology had advanced to the point where wireless communication was possible. And you could take a sensor that had been at one point of a process and you could move it to another process. And so we developed software that once that sensor was moved, you could use your iPad and let the data collection system know this sensor is no longer on this pipe. It's now on that pipe and measuring this other thing from what it used to be measuring. You enter it in your iPad and all the calculations now update and reflect the new location of that pipe. Of course, if you're measuring pressure, you're probably trying to find flow rates. You're going to use flow rates to predict how much oil you're producing out of a particular well. We thought we had a really compelling product. And we launched it and we put it out there and what we found, no one ever opened the iPad app. It was open from computers. We had a lot of desktop browsing happening on the app. We had no mobile browsing whatsoever. And this created a problem because that sensor has moved and it's reporting back to corporate headquarters steam flow rates and oil extraction rates that are fake. They don't exist. And we would find that after about maybe once a month the operators in the oil field would sit down and they would update all of the sensors that they've moved. We've already reported a month's worth of wrong data at that point. It was too late in the process. And so we had to ask ourselves, what's the hangup? We made this cool thing. This is like 2011. iPads are cool. Now we've got Chevron to buy their employees' iPads. You would think that that would really be motivation. I mean, for me, for a nerd, I would be really motivated to carry that iPad everywhere I went. I'd be so excited that I got to work with that. These guys were not excited about it at all. Well, it turns out moving a pressure sensor from one pipe to another involves opening a pressure vessel. You have no idea what's going on inside that pipe and you're going to go ahead and create a hole in it. And you're going to be operating above that hole with your face, you know, right above it. So rather than this nice, clean diagram that I had in my mind for what the process of moving a sensor looked like, the real process looked a little bit more like this. Now this is on a bad day, clearly. But you get the point. The operators in the field, they're not particularly thinking about what corporate is going to think about the data they send their way. They're thinking about how do I make sure that I and all of my crew do not die as we do this? There's a priorities problem. So we really did not have a great deal of empathy for the end user of that product. Now why didn't we have empathy? Well, let's look at that a little bit here. Oh, by the way, this is not what he's thinking about in the photo, right? He's got different priorities than we're talking about here. Well, let's look at what caused that break in user empathy, why we couldn't anticipate the needs of our users. Well, this is my office or an approximation of it in the startup that I worked at at the time. This was the operator's office. There's a couple differences. This was the average software developer's uniform as he comes in to work in the morning. This was the operator's uniform. You've got protection for his head from falling objects. This is fire resistant clothing with high visibility so that it's reflective in the dark. All of it is optimized for not dying when you're working in the oil field. So the distance between my experience and his experience was quite significant. And so launching a product without understanding or appreciating that experience whatsoever resulted in what you might expect. Not a good match, you might call it a misfit for a product instead of product fit. This can happen to all of us because as software engineers, we're providing software for other people. Almost no software engineer aspires to write software by and large that only they will ever use. The whole dream of Silicon Valley is to write software that changes the world that everyone uses. And I think each of us in our own way are going to be pursuing that. But the fact that our users are not us means that we stand at a distance and we look at what they're doing and we see something different than what they see. This person looking at a mountain far off sees the snow line, sees the beauty of the clouds above and might be able to think, well the way that I would get to the top of that mountain is I would walk through these trees, I've got a trail leading that way and then I would just go up the mountain and I would be at the top. Well if you've ever attempted to scale a mountain, you'll know that up close things look a bit different. This is a favorite trail of mine in the Pacific Northwest where I'm from, Asgard Pass. The Mountaineer looks at this and doesn't see the beauty and the tree line, he sees the death area and how not to die. His priorities are very different from the person who stands far off and so if you're building a navigation app for Mountaineers, your priority will not be to use Dijkstra's algorithm to show the shortest distance between two points. You're going to have different priorities for the Mountaineer and understanding those priorities relating to them, being able to anticipate them is going to be critical to the success of your effort. If you're looking at a mountain from down low on the left side, if you're not very careful about your perspective you will conclude that the biggest obstacle between you and the summit of that mountain is these trees. If only we could get rid of these trees, if we can find a solution for the trees then all of a sudden we'll be able to get to the peak of the mountain because there's nothing between us and the peak of the mountain except for those trees. On the right your perspective from the summit is going to be quite different. You're going to be thinking about the crevasses that you had to traverse and how to make sure that as you're going up the glacier how do you know how much glacier is underneath you? Is there a lot? Is there a little? If the season is warming and you're late in the day the odds of new crevasses opening up underneath you increases so there's a whole different set of priorities and a whole different perspective for the mountaineer. I think that's a great analogy for what we need to be doing in software engineering. We need to not be standing far off from our users and saying, I understand what they do it's easy. Instead we need to build what I call this is not my terminology of course I think Kelsey Hightower at Google started this we need to build user empathy. Well, user empathy is the art of taking on the perspective of one's users or customers. It's all about being able to see things the way that they see things. What they think is hard what they think is expensive or unpleasant you think is expensive or unpleasant. It's not that you erase your own perspective and stop having it but rather that you have the ability to take on theirs to see the world from their angle. Another way to define user empathy is that without which your product will fail. Without user empathy there is not a path to success. So I told you all that I work on the Istio project and I promised in the CFP that I would be talking a good deal about Istio. Anyone here familiar with Istio used Istio? Okay. We got about a third of the audience. For those of you that don't use Istio today that's no problem. You'll be able to keep up with this talk. Istio is all about networking in the cloud and with the network by controlling every part of the network every little piece of traffic that traverses the network we can give you essentially three tiers of functionality. Traffic management that is if you have this header set you should go to that set of services we can do observability what's my success rate what's my latency we can even do trace spans across multi-service connections if you have a service dependency chain that is four deep we can show you that in your trace spans and you can see how much time each takes and then of course security everyone's favorite feature we use mutual TLS to encrypt all traffic that leaves any pod and then you can write auth policies built on top of that so that's what the customer get or the user of Istio gets this is a CNCF graduated project I've been a part of the project now for a little over five years the way that we accomplish all of this has historically been with a pattern known as the sidecar Kubernetes gave us this great opportunity to say anytime you run any software also run our proxy and by doing that by having a proxy everywhere your software runs we capture and control all the network traffic and we can apply all of these fancy cool policies on top of it provide all this value there's been a whole hype cycle over it you can visit the booth in the project pavilion if you want to know more but this whole idea of throwing a sidecar everywhere putting one absolutely everywhere your network runs it's sort of a brute force solution the interesting thing we wanted to prove out is is there value in a service mesh does anyone actually need this technology will it be useful we knew that our solution was not optimal but this was a quick way we'll sort of bypass some of those optimization questions and we'll work particularly on providing value well we're now seven years into the Istio project and it's time in sort of the software maturity cycle for us to look at optimization we've proven out pretty thoroughly that there is value behind these paradigms so can we provide that same value without a brute force solution that just throws a proxy everywhere and so we announced about 18 months ago ambient mode I'm not going to get into all of the technical details of ambient mode except to say that it's an optimization over sidecars you no longer have to have a proxy absolutely everywhere you could have 10 services running on one node that use one proxy instead of 10 proxies so we thought this was really great as an engineer I love the patterns I love that we're getting more and more optimal we're trained right from the very beginning of our careers to look at time complexity and space complexity well this substantially reduces in some cases 100 fold the time and space complexity of Istio so we were pretty proud of this pretty excited about it we launched it to alpha a year ago and the way that it works is splitting layer 4 and layer 7 you don't need to worry what those are layer 4 is really easy to do and fairly safe to do layer 7 is a lot of complexity maybe a little bit less safe so every node runs one layer 4 proxy it applies all of your security that you need at layer 4 which is that MTLS encryption that everyone loves and then layer 7 is more optional we'll say if you have one service with 7 instances maybe you run one layer 7 and you have a proxy for them because of the complexity we don't think shared proxies are probably a great idea at that layer so we're pretty proud of the technology the patterns look pretty clean we're excited about it and we launched it to alpha and we kind of heard crickets we didn't get a lot of feedback this happens in open source if you're a user of any CNCF project please contact the developers of that project and tell them what you think tell them the good the bad and the ugly because getting feedback from your users in open source is actually one of the most complex and difficult things that we do on a daily basis but we got crickets and we started to worry after about 6 months well let's look at the values of the ambient project from my perspective I'm not speaking for any of my teammates I've heard from some of them no I was never confused about this and that's wonderful for them but from my perspective the value of ambient was because operating a sidecar is hard if you've ever tried to upgrade Istio with sidecars it's very confusing which ones have been upgraded and which ones haven't they're kind of this magical thing and magic is always difficult to understand meanwhile building a platform doing platform engineering work and integrating Istio into a platform which is what we recommend all of our customers do that's easy right I mean I've never tried it but it sounds easy how hard could it possibly be compared to upgrading sidecars well what we did was we hosted a twitter space that Kelsey Hightower was kind enough to promote for us and get a whole bunch of attendees to where we asked our users like seriously we've sent you surveys we're not hearing back everybody join this twitter space and tell us what you think of ambient mode and I learned a lot from this event you can see some of the statistics about the uptake that it had in the community really thankful for the users that took the time not just to join and tell us what they thought but explain their reasoning here's how I got to the conclusion that I'm at and in particular we heard from platform engineers that perhaps operating the sidecar was not the most expensive thing that they did sidecars are a pain to operate I think there was general agreement on that but if you've integrated Istio into a platform you very likely have built your own automation to solve the sidecar problem I won't get into the details of how that works you encounter a problem as an engineer you know you're going to encounter it every three months as you upgrade Istio to keep it up to date what are you going to do you're going to automate it and they did which means that when we solve the sidecar problem for these users we're solving a problem they don't have anymore they've already written the solution to this furthermore in order to adopt our solution to the problem they're going to need to adjust their solution to the problem turning down the parts that were particular to the sidecar and updating their platform in order to reflect the new ambient mode so what do we take away from this well what I thought was difficult maybe had been difficult at one point in time if we had written the product this way from the beginning that could have been pretty valuable for these users and saved them time but they fixed it that's not a problem that they're facing anymore on the flip side pulling out the network from your individual developer platform or internal developer platform and sticking in a new version of the network is extraordinarily expensive any of you trying to hire for platform engineers at the moment even though the market seems flooded with talent and we're hearing stories about software engineers who put out 700 applications and heard back on two of them somehow it's still extraordinarily difficult to find platform engineering talent it's a very unique skill set and it's a group of people who have to understand in depth several dozen CNCF technologies all at the same time as well as how they map to legacy technologies for the 90% of enterprise apps that still run on VMs so it's really difficult to hire for that their time is very valuable and what we're doing with ambient and asking them to migrate is effectively wasting their time helping them to fix a problem that they don't have and realistically this chart probably should look a little bit more like this platform engineering is hard work these are busy people and they have more important things to do than adopt a new solution to an old problem and in part that's because I had envisioned the DevOps lifecycle like this it's a tight loop you're releasing software you're looking at how it can be improved and you're feeding that back in and then you're re-releasing software the DevOps lifecycle is wonderful for enterprise applications but for platform engineers it looks a little bit more like this it's an extraordinarily long cycle that's because if you're putting 60% of your engineering investment into your platform you're doing it wrong the whole point of an IDP is to empower developers not to distract them with Istio upgrades so I sort of had the balance on that wrong the development lifecycle for a platform what I've heard from customers since then is that probably they'll re-evaluate their network in five or so years unless they're given a compelling reason to do so so that was that was quite a learning from the project I made another assumption though I assumed that sidecar compute remember you're running if you have a thousand pods in your cluster you're running a thousand sidecars that seems really expensive and very unnecessary to me so I assumed that that was very expensive network egress though it's not really taking compute it's not really taking memory it's hitting the backbone that must be a relatively inexpensive component of your IDP well what did we hear on the twitter space many of our customers are running regional clusters and what that means is that some of the nodes traffic between nodes sorry what that means is that traffic in between zones are happening within the kubernetes cluster it doesn't look like it's leaving the cluster but it is leaving the building within a region and that leaving the building is quite a bit more expensive than traffic that stays in the building as a matter of fact we heard from several customers that their egress fees were much higher than their compute fees we were told you could erase you could pay our cloud bill if you don't remember and if you don't help on the networking side it will not matter to us ambient in particular makes this problem a little bit worse if you look over here on the right side of the screen you can imagine a sidecar with each of these services and the traffic stays within a given zone but once you schedule a waypoint which is where layer 7 value is added and you've only got two instances of the service each service so you probably only need one instance of the waypoint well guess what happens to zone b's traffic double egress so now what was extremely cheap has become extremely expensive the flip side is you could run a waypoint inside of each zone in which case you begin to ask the question what's the point of going to ambient if I'm going to run one proxy per pod I can do that in a sidecar as easily as I can do that in a deployment so these users told us loud and clear that ambient as it was today was particularly interesting to them so what I thought was very expensive sidecar compute turned out to be relatively inexpensive in comparison with the amazing expense that was network egress fees for our users so let's talk about what we learned here and how we revisit those assumptions in the Istio project really what we talked for several months about this how do we digest this feedback should we be making ambient does nobody want this thing and what we decided is for new users of service mesh ambient is the right architecture for old users it is the right architecture but it may not be worthwhile to migrate not worth their time perhaps in a few years they'll get to it so our expected uptake is that new users will begin making use of ambient mode very quickly and their costs should stay under control it'll be better for them but existing users who have already taken the time to integrate Istio into their platform are not going to go and retool everything that they've ever done in order to get a 5% cost optimization or negative cost optimization depending on their egress fees so as we went and decided that this was for new users we have gone ahead and moved forward we finally have announced beta our upcoming release in May we're going to make ambient mesh to beta we've debated the language here quite a lot because if you dig through our announcement you will find ambient mesh layer 4 is going to beta that layer 7 waypoint object is staying in alpha for now for probably at least another 6 months and the reasoning behind this is that layer 4 is what new users need at day 0 they need to have MTLS security across all communication that happens all of their security folks that they're not leaking data and then they need basic telemetry layer 4 is not nearly as valuable as layer 7 but it gives you a baseline it gives you a starting place layer 7 is going to be for more advanced use cases and we expect that we can have that to beta by the time those customers need those use cases so let's bring this back home to your experience as a CNCF member as someone interested in projects what can you do with this information you're going to need to answer these questions as you build a product and by need you will answer these questions whether implicitly or intentionally and if you don't answer them with empathy you will have built a project that is a misfit for the market these questions involved taking on the perspective of your user what do they love, what do they hate what are they worried about, what are they excited about what are they upset that they have to pay for what are they happy to pay for if you can answer these questions the same way that your users will you are much more likely to have a good market fit with those users and have high uptake but that really just kicks the can down the road all I told you is to answer those questions with empathy so go find some empathy I think it's in the hall out there and you'll have everything that you need to answer these questions and build great products now empathy is actually extraordinarily difficult to build but there are some tools that you can use to get better empathy for those users and the first goes back to that mountain climbing illustration don't stay at the visitor's center when your users are on the trail if you're far away you're going to have a difficult time understanding your users and so our first principle is that shared perspective is going to come from shared location or proximity and I mean this very literally go be where your users are I know we're all virtual today and we love video conferences thank you go actually sit with them if you have an opportunity if you're building monitoring tooling ask to sit with an SRE for a week and understand how they're leveraging monitoring tooling what is important to them what do they not care about what do they not care about what do they not care about what do they not care about all so go sit with them the next up is sort of figuratively proximity go do what your users are doing if you're releasing a cloud native project install it run a website on it even if the website does nothing and provides no value dog food your own work your own system this is going to be very important if you're releasing something that is supposed to be a part of a platform try installing it with Argo try running it with Backstage or one of the other many compelling platform engineering tools that are down in the down in the solution showcase this week get to understand not just what your product does but how does it play with others because that's going to be what your users care about that's going to be their day zero experience with your product and lastly never stop listening I've got even if you love your product no no no especially if you have put your heart and soul into a project it's really difficult sometimes to hear someone say I really don't like this and I don't want to use it that can be a devastating thing to hear it was a devastating thing for me to hear back in October on Twitter that if you can swallow your ego a little bit and set it aside and ask okay tell me more why is that not you're wrong I built the greatest thing ever and you should feel bad for not liking it instead really that's interesting I didn't expect that I'm sorry to hear that can you tell me a little bit more about what made this not work for you and what I might be able to change moving forward oftentimes users come to these meetings and they know you're an open source maintainer you've put your heart and soul into things and you're not actually getting paid for it and so they're very hesitant to say they'll say oh you know it was pretty good dig in say you know last time I used it and installed it I ran into this bug that was just infuriating I couldn't believe that I had released software that did this did you encounter anything like that all of a sudden you've paved the way for them to provide that information that you must get to to have user empathy you've made it safe for them to speak so invite that critical feedback I think one thing that this looks like is understanding and helping your customers navigate the giant puzzle box that is the CNCF anybody take a look at the landscape this week did you see all of it a part of it if you zoom out small or far enough you can get to where each project is a pixel and I think at that point you can on some very large screens see all of the CNCF landscape help your customers understand don't ship them a puzzle box ship them a picture it says hey if you're using Argo this is how it integrates here's how to put Prometheus in touch with this project and by giving them rather than a puzzle box a picture you're showing empathy for their experience they don't want to spend three hours trying to figure out oh now I have the picture and I understand what this project does and I don't need it you're going to give that to them up front and let them understand what you've built and together by following the principles of user empathy I think that we can make the CNCF and Cubecons a great place for developers, for users for all of us to continue this innovation that we've enjoyed doing for these years and I hope that you'll join me in doing it so that's all I've got for you today I'm happy to take any questions thank you so much for the talk I want to ask you about that part where you discussed that when you released the project you got your heart crickets first of all how did you emotionally deal with that and then how did you overcome it you're not going to fly to everybody's office and talk to them so how did you actually get to the point where enough people are giving you feedback that you feel confident in what they're saying I think the way to survive those crickets is going back to user empathy I used dozens of open source projects every single day maybe even hundreds of open source projects every single day and I've talked to developers on two or three of those projects about my experience I'm not using those tools because I want to participate in an ecosystem I'm using those tools because they make my life easier and so expecting users to come to you to take time out of their day to figure out where is the Istio GitHub and how do I create an issue and what type of issue should it be there's a lot of barriers to that feedback so going where your users are Istio has been famous for some users telling us just how badly we've gotten it and while we can withdraw from that and say well you know that's painful to hear instead go there and invite that and say okay I hear this problem so let's have a public forum and hear you out Twitter was a much easier forum for our users to join than GitHub and so I think that helped a lot Thank you My question is it sounds like with some of the ambient mesh stuff there's definitely a bit of a miss in hindsight you've got great stories from your users and got great input from what they really wanted In hindsight now what would you have done differently before starting the ambient mesh project I think in the first year we could have spent a lot less time worrying about layer 7 which again is for those more mature use cases we were thinking of it as something that we needed to make sure there was a migration path from side cars to ambient on day 1 I don't think that migration path is unimportant I think there will be users doing that but it's not a day 1 problem it's a year 2 problem Thank you for the talk How do you write up and share the user personas and the feedback so that you can then share it and analyze it and for those people who do want to help how do you then categorize them as a user base for whether their feedback is 80% or 20% The question about personas is spot on for the Istio project in particular Persona development and role development typically falls to product managers and product management is not something that we reward today in the cloud native ecosystem you might be a product manager for Microsoft or Google or Amazon but you're not a product manager for Kubernetes I think actually it would behoove us to have roles and to make sure that they are recognized within the community so that we can promote things like roles like personas so we've struggled with that in the Istio project we have a few documents we've written over the years we did learn a few things early on our initial APIs put all the levers in one CRD which it turns out from a security perspective is a bit of a nightmare so learning that there were different users helped us in that journey that's an ongoing problem in the Istio project that I don't think I could say we have a clean solution to as far as users who do want to submit feedback we have a monthly meeting called the community meeting where users are always invited to share their thoughts also please just tweet at us if you're a Twitter user like even if it's bad feedback we don't mind it being in public you don't need to feel like you're doing us a disservice if you have used our product and it hasn't gone well we need to know about that and that's really important so feel free to reach out that way we also have an Istio Slack that is fairly accessible that you're welcome to join and give feedback we're going to get in the habit of having user feedback summits over the coming year and one of the difficulties we've had with that is getting people to sign up it involves being on camera lots of people watching it'll be recorded and re-analyzed incredibly valuable for the project I'm hearing that we've run out of time I'll still be towards the back of the room for a few minutes if anyone had any follow-up questions thank you all for joining