Eden Full-Goh: Hey, Nick and Adam. Thanks so much for joining the How It's Tested podcast.

Adam Oxner: Thanks for having us.

Nick Newell: Yeah, thank you very much. Pleasure to be here.

Eden: We've been getting to know each other over the last few months of working together with our companies, but I've never actually gotten the full scoop on the founding story of MySwimPro and how you guys came to work together as a team. I'd love to just learn a little bit more and have our listeners learn a little bit more about MySwimPro, and also maybe your backgrounds as well.

Adam: Yeah, sure. So I'll start. I'm Adam Oxner, I'm co-founder and CTO here at MySwimPro. We were incorporated in 2015, but still a small team. I think we have about 14 people on the team right now. But the founding story is my co-founder, Fares Ksebati and I, thought that there would be a great need for delivering workouts for swimmers to mobile devices.

At the time there were cycling apps and running apps, but not really a lot out there for swimmers so we thought it would be pretty fun to build... Honestly, we started out with it would be fun to build a software product or an app that would help people swim. MySwimPro's mission is to help people achieve their fitness and performance goals through swimming, and to that end we have the MySwimPro app. But I'll let Nick introduce himself as well.

Nick: Yeah. Hey, everybody. My name is Nick Newell, I'm the VP of Engineering here at MySwimPro. I have been on the team for 18 months, so prior to joining MySwimPro I was leading engineering teams at another larger company for about 17 years. I have a variety of experience in the telecom world. When I came to MySwimPro, I did not know how to swim for fitness.

I could swim for survival swimming, but I could not swim for fitness, and it's a testament to the product that over the last 18 months I've gone from not being able to swim 100 meters to being able to swim a mile, which is pretty awesome. I'm learning breaststroke and butterfly and everything now, different types of swimming.

But it's been a wild ride. I lead the engineering product and design team here, and so I have a lot of fun stories and thoughts on quality and quality assurance, so I'm excited to be here to chat about that today.

Adam: Nick's been crushing learning how to swim since joining, so we've seen a lot of progress. We've made YouTube videos about him if you want to look it up, it's Nick getting better and better at swimming since he joined. But, yeah, it's been great to have everyone on the team swim.

Eden: That's awesome. Adam, I think I read online that you were a varsity swimmer in college, is that right?

Adam: Yeah. I swam at the University of Michigan and luckily enough after swimming basically my whole life, I still love swimming. I know some of my friends got burnt out because if you do something for 20 or 30 hours a week for 10 or 20 years you get burnt out. But I still love to swim once or twice a week. I'm not as competitive as I was anymore, I like to swim because I love being in the water. I love using the MySwimPro app and built it first with myself in mind, and then since people ended up loving it, we've since expanded our mission a lot.

Eden: Yeah. I guess since you guys started the company five plus years ago now or more like eight actually, how has your vision of the platform evolved from you being a varsity swimmer and designing something for you, an experienced swimmer, to then also now incorporating and thinking about the product from the perspective of Nick?

Who knows how to swim for survival. But then how do you design a program or a product interface that makes folks that are less experienced with swimming excited to swim? But then also reconciling that with folks who have been doing this for 10 or 20 years, how do you make that all happen in the same platform?

Adam: Yeah, it's really challenging. We've gone through lots of pivots and, even from a very high level, we are just offering basically a workout library at the very beginning and we weren't charging for it for the first year, at all. It's since expanded to be much more personalized, so I would say the introduction of our personalized training intervals which personalizes your workout to you, so when you join our app you can say what strokes you can swim and what your speed is for each stroke, basically, more or less.

Then from there, the app can recommend and tailor all the workouts right to you so no matter if you're coming in... Most people can just swim freestyle starting out. If they're interested in swimming laps, that's kind of the base level, or front crawl, you say, "I can only swim freestyle,"then the app will just serve you workouts for freestyle.

The personalization is what has helped us expand from writing the workouts for just one demographic or one type of swimmer, to being able to adapt to many different types of swimmers. There's still corners that we need to cover, but we are really proud of the progress we've made so far.

Eden: I guess in terms of the MySwimPro platform, I know there's an iOS app and there's also an Apple Watch app. Do you guys have an Android platform? Do you guys have a web platform? What are all the different pieces that your engineering team has to oversee?

Adam: Yeah. We have an Android app and an iOS app. The iOS app also has an Apple Watch counterpart app, and we have a web platform on a technical level. But mostly it just services web transactions, purchases when people are subscribing to us.

Sometimes we drive traffic to the web platform, but in terms of functionality for the end users, our members, it's all on the iOS and Android apps. Our premier experience is definitely in the Apple Watch app, so I think we'll get into the Apple Watch stuff a lot more later in this conversation. But those are the areas that our members use.

Nick: We also integrate, I'll add on there, with Garmin. We integrate well with Garmin where we can, similar to the Apple Watch experience, almost as good where we can push personalized workouts to a variety of Garmin watches from our platforms and you can swim a customized workout on a Garmin watch as well.

Eden: That's really interesting. I guess I'm curious just thinking about the changes in technology and in the industry, just the availability of data and syncing from one platform to another. How has that really changed in the last eight years? When you first started the company to where it is today, because it does feel like Apple Health has a lot more capabilities than it used to. How do you listen and follow those trends and those integration opportunities and build that into your company roadmap and your product roadmap?

Adam: It's a really funny story, actually. A lot of this is driven by waterproof hardware. When we started in 2014/15, there was only Garmin, and a few hardware device manufacturers that made swim tracking devices. Of those, the capability of developing custom software for, like a third party developer like us would build, was very limited.

So actually when we first, in 2015, that's the year that the first Apple Watch came out which is now called the Apple Watch Series Zero is what people call it. It wasn't built as waterproof, there was no swim tracking. But we had two hackathons here internally just to drive innovation and have fun with the platform, and so with... I think this was our first hackathon we had, I built an Apple Watch app for MySwimPro.

It did basically the main things that it does now, it walks you through the workout, taps your wrist when you need to push off the wall, everything like that, shows you the time so you don't need a clock. We just built it internally, and then were like, "Well, we can't ship this because there's no swim tracking and it's not waterproof." Then we just shelved it and said, "That was fun. Maybe one day we'll get to build something like that."

Then in 2016 the Apple Watch Series Two came out. It was waterproof, 50 meter waterproof, and Apple, which was huge for us, Apple shipped it with swim tracking. So building a swim tracking system is no small feat, and in fact we rely on the hardware right now, we rely on the hardware manufacturers to do the swim tracking for us.

But when the Series Two came out, that was waterproof, I found that old code, that old branch that was really from a year ago, pulled that back up and we built out the first version of MySwimPro on the Apple Watch so it was ready. I think it was just two weeks after the Series Two came out and we were lucky enough to be selected by Apple as the Apple Watch App Of the Year in 2016, which was really good.

So in terms of swimming technology trends, I think a lot of it has been driven by hardware. Since then, all the Apple Watches developed since then have been waterproof. Garmin has opened up their developer platform to allow us to push workouts there and read from them. But again, there's even more swim proof hardware coming on the market every year actually, so that's very cool.

Eden: Interesting. I guess from a data accuracy perspective, I don't know how much you guys are balancing testing all the different Series Something watches over the years. Do you feel like the technology is getting more accurate? How does that impact your product?

Adam: Yeah. It's a very interesting point, because like I said we're not building the actual measurement of laps or strokes per lap or whatever. We rely on Garmin and Apple mainly for these functions, and they have been getting better. Part of it is they retrain their machine learning models, I think every once in a while. Also the sensors are getting more accurate in the hardware.

But it's getting better. I think Nick will agree with me that we would like it to be more accurate, but we understand it's a very difficult task so we're not the ones building the lap tracking and there's a reason for that. It's very difficult, and so we're grateful for the progress that has been made so far.

Nick: Yeah, definitely a challenge. For example, we just launched a feature called Test Set where you're trying to go as fast as you can for 100 meters and timing is everything for swimmers, especially when you get to a level of competitive swimming. So even 100th of a second or 1000th of a second really matters, so we do hear from a lot of our members that it is great, but they wish it could be even greater because we've got to get down to hundredths or thousandths of a second because that does matter when you hit the wall and you're trying to get your best time on a 100 meter swim.

Eden: Sounds like it's probably a matter of time over the next five to ten years as things continue to progress, and it only benefits your platform. You are then presented with this opportunity to integrate with all these great providers.

Adam: Yeah, exactly. It just seems to be getting better every year. Even Apple Watch OS9 that came out last year added kick detection for swimmers, which is when your arms not even moving, it can detect when you're using a kick board which is just when you use your legs to move through the water. That's been a great addition for us and our members are really grateful for this addition. But yeah, we're making great progress in this space.

Eden: That's awesome. Nick, I'm curious with your background, having lead different engineering teams, how does having this hardware element that you have to respond to, but also develop for... How has that changed the way that you've lead engineering teams and worked with engineers? How has that contrasted with other teams or companies that you've been part of?

Nick: Yeah, good question. It's a big challenge, there's no doubt about it. I've worked with embedded systems that are out in people's homes, but I think the most unique part about this challenge is that we have a wearable device. That's one thing, that's really challenging. But this thing is in water. We have a wearable device that's in water.

One interesting fact that most folks may not know that's kind of surprising, it was surprising to me when I joined the company, is we still can't get waves like Bluetooth waves... they don't travel through water. So while the member is in the water, we can't communicate with the watch.

It really is an embedded system, it's there in the water, moving through the water we're trying to run. That's really, really challenging. It's challenging to build something like that, but then as we've worked with you, Eden, it's challenging to test something like that. So really coming here to MySwimPro, even though I've had 17 years experience testing other things in the past, and even those being embedded systems, it's truly a unique challenge.

Like you said, the physicality of the devices going forward, they're on your wrist, they're everywhere on your body, they're moving, they're moving quickly. It really is a fun time to be in engineering, trying to solve some of these problems and I really appreciate the opportunity to be able to do this out in the wild. I mean, we're not only in pools but we have these out in the ocean and lakes and rivers. It's fun to have such challenges to try and solve these problems. It's really neat.

Eden: I'd love to hear a little bit more about your day to day, week to week, engineering team processes. Is the iOS app and the Android apps and your backend and the Apple Watch app, all on the same release schedule? How is your team structured? Are different engineers full stack? Curious to hear a bit more about the composition of the team.

Nick: Yeah, I'll talk a little bit about the team and then I'll let Adam talk a little bit about the release structure. So we are a relatively traditional, Agile software development team. We have a regular daily standup, we have sprint planning every two weeks, we have a sprint demo every two weeks, we have backlog refinement, we have retro. We have those usual practices. We are a completely remote team.

Adam's calling in from New York City right now, I'm calling in from Denver, Colorado. We are completely remote, our developers are around the world actually. We have some that are on other parts of the world. Every day we have a daily standup. We are over communicating both in Slack and together as a Team to figure out what are the things that we need to do, and just really working well together.

I'm very grateful for the team. We have a really awesome team culture, everybody is a swimmer. Even if you just started when you came to the company, everybody is a swimmer and so we work really well together to make sure the client is integrating with the backend and we're sharing data. We're of course using data analytics to make sure that we're seeing the right thing out there in the field and working well together there.

So yeah, team-wise, team structure-wise, how we're approaching things is over communication, the traditional Agile software practices of a biweekly sprint and releasing on that cadence. That really keeps us on the same page, focused and aligned. I'll let Adam talk about under the hood of what's happening from a software perspective.

Adam: Yeah. Our three main platforms that we release regularly to are iOS, Android and our backend. As I think most software teams aim for, it's continuous integration and continuous deployment. Though, with iOS and Android apps you can't quite ship as soon as things get merged so for iOS and Android we have a weekly release cadence which we're pretty proud of as a team, where all of the work that gets done through the one week gets cut into a beta and that goes out to our beta testers.

You can sign up to be a beta tester at MySwimPro.com/beta. So there's that, and then the beta testers get that release for a week and we can get analytics and feedback on that from our beta testers, as well as our internal team. We do also have nightly builds. Nick swims almost every day, I see. I swim once or twice a week. But throughout the week, the team members will swim on the latest code and provide feedback as well and point out any defects that might appear.

It's a weekly release cadence for iOS and Android with a one week beta soak period. Then on the backend we're slowly creeping our way through to CICD and right now we release every Tuesday and Thursday mornings, and we have a similar development staging and production server on those as well. Those, for example, our beta at .2, the staging before it gets to our production servers.

Eden: So does actual swimming happen with, for example, on the iOS app, test flight builds? Or are you guys sometimes going even earlier and there could be, I don't know... do you swim off the developed branch?

Adam: I do, sometimes. I'm swimming the code everyday. Like I say, we have alpha builds that go out on test flight and that's what most of the internal team swims with, just whatever the last nightly build is. We'll auto update over night. Nick wakes up at 4:00 in the morning or whatever to go for a swim, he likes to go very early. But sometimes there are riskier fixes or changes that we do test before even merging into the nightly build, or experimental code that I like to load onto the watch and go test.

Nick: Yeah, it's fun. I mentioned earlier we have one or two developers that are overseas in Europe, and so we'll be talking about a feature during the day here in Denver time, that feature will get developed that night in Europe while I'm sleeping, and I'll get up at 4:30 AM, put on my watch and it'll be on my watch for me, ready to swim the next morning.

Right on the alpha build there, and I'm giving feedback by 6:00 AM so later in the day, some of the folks here in the US can even solve some of the issues we have there. So yeah, very fast, continuous integration, continuous deployment. We have opportunities for improvement, no doubt. But certainly very proud of what Adam has built and what we've been able to maintain from a CICD perspective, for sure.

Eden: That's really interesting. I feel like it's a part of normal regression testing for an app, you contest the functionality and an app crashed. Really obvious stuff you can pick up. But how do you know while you're swimming that the product is performing as expected? What kinds of feedback do you get from your testing while daily swimming, or even the beta testers?

Are you looking at actual metrics and comparing? Since you guys aren't actually managing the actual data collection, are you looking at the integration of the data that comes in and how it compares to a prior release? How do you actually know that it's working correctly?

Nick: I'll jump in here and then, Adam, you can add in. A variety of things. Yes, we're there in the water, in the water looking at our watch, it's giving us the data about our swim and it's telling you, "You've gone 25 meters. You've gone 50 meters. You've gone 75 meters." It's giving you the time, it's instructing you on how to do your guided workout. Most of the time that's going really well.

There are sometimes where while I'm in the water I'm catching a defect, and there have been multiple times where I've actually paused my workout, jumped out of the water, grabbed my camera, reported the thing that I'm seeing on my watch, sent it over Slack to our team, and then got back in the water and finish swimming my workout. Yeah, that has happened on multiple occasions when I was on an alpha.

So yes, while in the water we're getting that. Then after you get out of the water. Now, we're moving into the locker room. Now I'm looking at my phone so I can see all of the data for the processed workout on my phone, and see what my splits are and lap times, and how all of that compares. As a swimmer, you start to get a good feel for what your times actually are in your head, so then you can compare it against what you're seeing on the watch and on the phone.

Then of course when we get back here to the office, our home office, then you can look at more data that is coming from the workout in the backend, but also through our data analytics platforms like Amplitude, and see what else is coming in there on properties that have changed and events that have fired and all that good stuff. So there's multiple levels, weekly or even daily, that we are swimming as a team when we're looking at the data.

Then all of that is captured within the week. Obviously, as you know, Eden, we are also working with your team, partnering with Mobot to run a test suite every single week that is taking a different angle on that. That is saying, "Hey, last week when I ran this test, I saw this screen on the Apple Watch. This week when I run this test, I am seeing this screen on the Apple Watch. What's going on?"

Because with all of this huffing and puffing and panting in the water when I'm tired, sometimes we miss things. So that's why we have Mobot to catch those things on a little bit more disciplined basis. Every week we're testing beta that way as well. That's my perspective. Adam, I don't know if you want to add anything onto that.

Adam: I'll add that the most frustrating thing when you're using a product during a workout, is for it to fail right in the middle when you're working so hard, you're out of breath, there's not a lot of blood in your brain, then things go wrong. We experience that as an internal team, probably, hopefully, more than everybody else does that uses our product because we are using riskier builds before they get out to production.

I've been in many swims where my watch will just stop the workout and I am left floating in the pool, figuring out what to do so we feel the pain that our members do in the pool as well. We know how difficult that can be and we find that really helps us prioritize the defects that we're seeing to.

Besides just catching them is prioritizing them and feeling empathy for our members, and because we're dog fooding our own product, that I think it really shows in how our first priority is making sure you're getting through the workout. Then all the rest of the stuff can come later.

Eden: Yeah. You guys touched on CICD, you have Agile, you run a lot of best practices that a lot of other engineering teams are doing, but what are parts of DevOps methodology or engineering best practices that you've had to specifically adapt or change or throw out because it wouldn't apply to the kind of product that you're developing that has all of these real world complexities?

Nick: That's a good question. Wow. In general, the biggest challenge we have that others may not have this challenge because they're not a wearable device that's in the water, is just automated testing on the platform, on a simulation. So you mentioned this earlier, Eden, about how physical the device is.

Believe it or not, there's not a ton of advancement in quality assurance in wearable devices, especially when it's in the water and you can't communicate with it.

So that's actually the biggest reason why we partnered with Mobot, is because there aren't a lot of options out there to be able to test a wearable device. Mobot is one great option, using actual robots to test the watch. Some of the things that you could do where you could release, like you hear about Netflix and these other big engineering success stories that are releasing every minute, every five minutes, every ten minutes.

We can't have enough automated testing to do that. We just can't. We have to insert manual testing into it, as Adam and I have spoken. Our team, literally our team doing alpha testing in the water every day, every week. We have a beta community that's testing on one week's upgrades that Adam mentioned, that's happening for a week.

We have Mobot testing. It has to be a balance for us between automation and manual testing, and there will always be that balance until the robots get way more advanced where we can literally have them swimming in the water, and the whole robot is waterproof. So because of that, Adam and I love to go fast, I love to go fast, Adam loves to go really fast, and we're blocked a little bit by our ability to do automated testing for everything.

We have a good balance of automated and manual testing. I would say that prevents us from doing the best practices of everything of DevOps, when you read the stories of DevOps and CICD out there.

Adam: Yeah, I agree. I think the biggest difference is the Apple Watch or the device connectivity. It makes it really hard to move fast when you're trying to test and even simulate connection lost and stuff. I think the industry has some ways to go on tooling, which is where Mobot really helps us out.

Eden: Do you guys have unit tests that you write that are more maybe for API level testing or code level tests that are also running on every pull request before it actually gets put into the mobile builds?

Adam: Yeah, exactly. Every pull request that gets opened, there's a suite of tests that run against it. We do have unit tests running, and then we have API tests on our backend as well that testing deploys to a dev server and hits those before promoting it to staging, before promoting it to production every week or every day, really. So yeah, it does start with the unit testing in the code and propagates through there. I guess at the end of the line the people testing in the pool is probably the most important part for us.

Eden: Yeah, that makes a lot of sense. I'm glad that Mobot gets to be a part of this journey in creating this product. It's very unique. I think there's a lot of really interesting features that you guys have, specifically for swimmers, and it solves a very important use case. You're right, there's so many of these other apps out there that do jogging or biking or running, but there hasn't been enough visibility and accessibility for actual swimming tools like this. It's been a privilege to see how much the product has evolved over the last few months that we've been working together.

Looking back through all of these advancements that we talked about, you talked about kick detection, you talked about more accurate timing. Do you feel like the pace of the hardware that's being developed by these other companies, whether it's Garmin or Apple, have they basically been what you expected these trends to be like? I'm curious, what features are on your wishlist for the next three to five years that you hope will be developed, that you can then integrate with?

Adam: Yeah, I think for my part, I've seen the hardware come a long way. In fact, I've been impressed by the hardware itself and how quickly it's been moving. I don't know how to get around this challenge, most screens are capacitive touch screens, and if you know, you try to touch your phone screen when your finger is wet it doesn't work very well. Imagine, Apple Watch has a capacitive touch screen so when you're in the pool, you can't use the screen at all. It just doesn't work.

So Apple Watch has a feature called Waterlock, which does a great job for what it does, but we would love a better way to interact with the screen. There's buttons. For example, Garmin has tons of buttons. Apple Watch just added the Action Button on the Apple Watch Ultra which has been fun to develop for. We would love more ways to interact with the device when you're in the water, and like Nick said, we're limited by physics because Bluetooth waves don't travel more than an inch underwater, I think.

Wi-Fi only goes a foot, maybe, I think. Maybe two feet. So we are limited by physics. I think what I would like to see a quicker pace of innovation on is probably the software and swim detection. This is very selfish for us. Obviously we're very focused on lap detection for swimmers, and there's a lot of other types of things that this hardware needs to be able to do.

But we would love more accuracy for lap detection, one of the metrics we track is percent of lap coverage, how many laps did the Garmin tell us that person swam versus how many laps did the person tell us did they swim, and then comparing those. We would love to get that closer to 100%. Like Nick said, seconds count for swimmers, or less than a second, so more accuracy there. I'm sure we will see continuing evolvement in the models that are tracking or doing the lap detection for swimming.

Eden: Yeah. Out of curiosity, and I'm sure you guys have analytics about this or you've done some product and UX research, but I would assume that most of the time the athletes that are using your product, viewing the workouts. Nick, you were saying earlier that you do that afterwards when you're in the locker room and you're scrolling through and making sure that everything is as you expected. But the actual interaction with the watch is more just like starting, stopping, pausing the workouts. It's not like people are doing a full analysis or really intensive UX stuff on the actual watch itself. Is that right?

Nick: Mostly right. But you might be surprised how much a swimmer is looking at the watch and looking at some of the metrics during the swim. Obviously probably not while they're in the middle of a stroke, but we hear from a lot of members that the moment they touch the wall, they know exactly the time that they see on their watch. The moment they touch it.

It's like I'm reaching out with my right hand, and I actually did that this morning. I swam a 100 meter breaststroke, which I've only done one other time and I was trying to get a best time. So the moment I hit the wall, I looked at my watch and it said 1:52. Well, it wasn't then until about 10 minutes later when I got into the locker room where I opened up my phone, I looked at it, and it was exactly 1:52.

But I knew in my mind it was 1:52 because I saw it on my watch. You might be surprised how many swimmers are looking at their watch more often during workout to see some of the metrics that are in there, because that's very important to them. The timing is very important to them.

Adam: Even there's competing forces for this. We have people saying, "I want more information when I'm swimming, on the screen." Then sometimes the same people saying, "I can't read the screen. The text is too small because the wearable device has such a small screen out of necessity." So it's a balance of providing the most relevant information at the right time, which we're always trying to work on.

Eden: It's fascinating because I remember the series two or series three, you would get a small 36 inch watch face. But now they have the 42. It's all so similar with phone screens have also gotten bigger too, but then there's this constraint of it can't get that much bigger than your wrist.

Nick: Yeah, it's a real design challenge on the watch, for sure, to figure out what is the best, most important information to be putting on the screen at any given time because it's very limited.

Eden: I realize that we actually didn't have a chance to even talk about your UX and your design process, or the other teams that your engineering team interfaces with. I know we're probably running low on time, but I'd love to hear a little bit more on that if you wouldn't mind sharing.

Nick: Sure. We call our team EPD, engineering, product and design. We're all on one team, the whole company is a small company but we're all on one team. We have a full time designer, Gisela, that is a member of the engineering team and a part of every single thing that we do with other members of the team. So we are design first, everything we do we design upfront.

We spend time on design, we iterate design, we talk about it, we review it before we ever touch the code and get in there and do any code on it. Design is a very big part of our experience. We went through an entire redesign on the phone app about... Gosh, it's been about a year ago. That was transformational for us to be able to bring in different experience to the member, and we're always thinking about what is the member experience.

We just recently in the last few months brought a bunch more communication to the member, thinking about it as a user experience and communication as a part of that. We're really trying to make this a holistic experience for our members. Design in terms of user interface, but also user experience. Design, what is the full experience that you get? I'm glad you brought that up, actually.

I should've said that earlier when I was talking about the team makeup and how our team operates. Everything is done as a design first ahead of time, and we have the benefit, the luxury of having an amazing designer that gets things done so quickly, so high quality that we can discuss that as a team before we ever waste time in the code. So we're very thankful for that.

Adam: I'll follow up and brag on Gisela, our designer, a little bit more. She also swam in college, specifically she was an international swimmer which is really important for having... She swam in international competitions, so it's really important for having good contacts on what works and what doesn't work for swim workouts.

I'll repeat the complication of testing in the pool for design. Something that you think might be a good idea when you're sitting at your desk and you get to the pool and you're swimming, you're like, "Wow. That text is way to small." Or, "Wow. I thought the text would be motivational, but actually it just makes me want to swim slower."

Or, "Wow. It would be really helpful if this haptic when it taps you on the wrist, if it was stronger or shorter or longer." Or this thing is distracting and you don't know until you're in the thick of a tough workout and you have one second or less to look at your watch. It makes a huge difference, so again back to the manual testing in the pool, it means a lot to our team.

Eden: It's really refreshing to hear about the importance, in this conversation and talking with you guys, the importance of just the human perspective because I feel like sometimes I have all these conversations now where, "Oh yeah, CICD, A/B Test everything, deploy and try it out, and if the experiment fails we'll swap it out." But the intentionality that you guys take to making sure that this is a good experience.

It's different, right? The stakes in some ways are higher, right? You have to make sure that the MySwimPro users are having a great experience in the pool, and it's not always that simple and there's all these other new and exciting constraints. I'm really excited to see how the industry continues to evolve. Our team at Mobot is watching this as well, since we'll need to be prepared to support those kinds of engineering teams.

Nick: We're both engineers, so hopefully it means a little extra for us to talk about the balance between human and technology because by nature we're going to err on technology. But hopefully it really demonstrates the importance of that balance, hearing a couple of geeks and engineering nerds talk about the importance of human interaction that's happening in quality assurance. For sure, yeah.

Eden: Thank you for making the time to talk about MySwimPro and your engineering team and product and design processes today. It was really awesome to get to deep dive on that, and I hope the listeners learned a lot about your company as well.

Adam: Good. Thanks for having us, Eden. It was a lot of fun.