 When I use Google Docs, it just works. And so how do you approach quality when building a product? Is it doing the little things right, or do you have some directing principles that you always have to keep in mind when building a product? Yeah, so that's a really good question. And I'll tell you, that is a constant battle, because quality is somewhat subjective. And the bar changes depending on the value you're providing. In other words, the willingness for people to put up with things. So I think this is actually a really important thing, is the other benefit we had being at Google was we were building for scale from day one. We weren't building in a way that would be something that we expected to have to rewrite it. But if I'm going to start up, I would gladly take speed and give up some long-term scalability and say, let's just get this thing out there. And if we get, OK, and if my engineers say, OK, it can take basically, call it 100 QPS, or 1,000 customers, I'll say, great, let's do it. Put it out there. When we start hitting 800 customers, let's start rewriting it. Let's start scaling. But we don't even know if it's a good idea yet. Whereas at Google, once we knew it was a good idea, we were committed, and we were building for scale. Because we were Google, and we knew, even if it was terrible, we were going to get some crazy traffic, potentially. And the founders of Google, and at the time, we were a pretty small 5,000 people or something. So the founders were in my ear constantly. And it was like, you don't build something that can't scale. You build it to scale. You build it as if it's going to succeed, and you make it so that it's got to be good enough for people or attracted to it without advertising and all these cultural things. But it's expensive, really expensive, and really hard. You need amazing engineers. I had one engineer from my team that came into Google that made real-time collaboration work. And for some reason, if he ever watches this, I'll just say his name, Michael LeMonic. So Micah made it work. He was the engineer that really architected our collaboration layer so that it would work. And it works to this day. And of course, other great engineers joined and made it even better, and the team grew and things. But it is the same architecture that made that real-time collaboration work. And I have to say, whenever I talk to another group that's doing something competitive with docs, I always find that what bothers me is what you're saying, Isaac, you loved about docs, which I feel the same way, which is it always works. And it works really well. It's fast. It's reliable. My stuff never goes away. And those are the principles. So going back to your question, those are the principles that we did build to. Like number one, from the day we started, even before we launched externally, but when we launched internally at Google, we all kind of shook hands and gathered together and said, we will never lose anybody's stuff, period. That's the most sacred thing, because if somebody uses this thing and they're using sheets, and even if it's experimental and they're starting to get into it, and they enter 10 rows of data, and then they fail and they can't find their data, we're done. They're never gonna come back. And that's a terrible thing to do to someone. So we made that like an absolute sacred rule, never lose anybody's stuff, and that lasted. I still have things on Drive from pre-launch, like when we, and then it probably is known that we bought rightly to do the document side. I have documents on my Drive from when rightly was like an experimental mode outside of Google. And so we always said, hey, we're gonna make sure we migrate people's things over to Drive and we're never gonna lose them. I have crazy old things there, like me and Micah actually having a conversation on a document just to test rightly before we bought it, you know, that kind of thing. It's just crazy, but it's, those things are really important again, but you have to make some trade-offs early on. And if you have to, you just have to be really clear. Hey, you might lose your stuff. If you wanna experiment with this experiment, don't use it for something real, until you're ready to say, hey, we're ready, we're ready for something real. What do you do if, you know, because especially in a big ecosystem, like Google Drive and all the products involved, you've probably had quite a lot of experimental features and the things you've tested out. What do you do if they don't, you know, they just don't work? You know, it's, if it's a bad idea or it technically doesn't work, how do you go about that? You know, this is what's so hard. And it's funny only in hindsight, I think, can I say this, is try to set up expectations on things that might not work as if they are somewhat fungible, or, you know, they might go away. And that's, I think that's the key is when you launch something, make sure it's clear to your customers whether you're launching it for real or you're launching it for test. And it's always nice to hedge a little and say we're just, we just wanna see what the interest is, this might not last. And so we created channels for things like that. We created, you know, again, early days what was called beta, except when, you know, everything was beta from Google for a while. I don't know if you remember this but Gmail was in beta for like, I don't know, five years or something. And it was an epic decision to take it out of beta because we knew that that had an implication about the beta label generally. But anyway, I think creating channels. So we've actually created channels for people to use non-final things at Google. At Zapier, we don't do it as much. We don't, you know, have a need necessarily to do it as much, but we do have the ability to launch things experimentally and just make it really clear that it's experimental. That said, we have launched things, certainly I don't have this experience at Zapier but at Google where it was a feature, it was final and some people loved it and we still had to pull it, you know, it just wasn't working and you have to be willing to do that. You know, you really do. And mostly that experience came super early on in Google Sheets because we were a little more flippant about what we would launch. We launched a feature. There's something in the U.S. which is a big basketball championship and we noticed Google Sheets was used for this basketball championship. You know, I don't know if you know at the NCAA, it's called March Madness. You know, it's a big, and again, I think it turns into more of a social thing because everybody's, you know, basically doing their own little pools, the office pools and things. And people were using Sheets. We would have this huge spike in activity and we finally attributed it to March Madness. We're finally like, oh my God, that's what everybody's doing. And we launched this feature that would create tournament brackets inside of Sheets. And it was literally my co-founder who, you know, helped implement that because he was just, he wanted to have that in there and it was like a function in Google Sheets. And it was, we had, you know, that had to be killed ultimately. It was so niche and so specific and it certainly wasn't global. So, yeah, there are definitely times. Oh no, that's not there anymore? No, it's not. It was like, I know, I think it was actually called like in a spreadsheet if you're familiar with the nomenclature. It's like equals Google tournament or something like that. It was crazy. But then we, but we've done other things like equal Google finance. I don't know if you know the Google finance function. That was epic. And that was, you know, I'm really proud of that one because I still use it to this day. And it lets you get stock prices and things, you know, from global markets inside of a spreadsheet in real time. And it's, you know, semi-real time. And that was more of a legal, you know, thing that we had to create, you know, agreements to get that data. But yeah, there are times, I think the key is to go into it assuming that it might not last and letting your customers know it might not last. And then when you're ready, say, okay, this is the final feature.