PodSearch

Under the Radar

255: The Discontinuity Principle

 

00:00:00   Welcome to Under the Radar, a show about independent iOS app development. I'm Marco Arment.

00:00:05   And I'm David Smith. Under the Radar is never longer than 30 minutes, so let's get started.

00:00:09   So there's a funny pattern that if you really, really, really paid attention to Marco and

00:00:16   my work, that if you really looked, every other Thursday is a slightly more important

00:00:24   work day than the other days of the week. And this is because, so usually Marco and

00:00:31   I record on Wednesday, and while we have a good discussion on the show and hopefully

00:00:36   this is useful and helpful, typically what ends up happening is we just sort of have

00:00:41   a conversation generally for a little while thereafter. And we often are talking about

00:00:46   work stuff, I mean sometimes it's personal stuff, but also just we have a nice conversation

00:00:50   and very often I feel like that conversation leads to one of us being able to make a decision

00:00:56   about something work related, to start something, to stop something. We can be a sounding board

00:01:01   to each other. We're both in a situation where we've been doing the same kind of work for

00:01:05   such a long time that we can hopefully give each other good advice. And we had a very

00:01:11   recent and public example of this the Thursday after our last episode went up, where you

00:01:17   made a pretty big announcement about Overcast.

00:01:20   Yeah, I posted on the site and on Twitter that I'm going to discontinue the website

00:01:27   player, or at least most of the functionality of the website player, sometime next year.

00:01:33   I came to this because, as listeners know, I have had a heck of a year just trying to

00:01:40   keep up with server stuff and trying to optimize it, trying to prevent scaling problems, trying

00:01:46   to deal with the scale I already have, and largely getting very little progress in that

00:01:54   area. I've been underwater with server stuff and it's really getting me down mentally

00:02:00   and stress-wise, but also it just sucks for the app because I haven't had a lot of time

00:02:05   to focus on actual features for the app and improvements to actually make it better for

00:02:10   the customers. So that's a bad place to be. The reason why I decided I've got to kill

00:02:18   the website is because – and by the way, I actually might not need to do it, but I

00:02:26   wanted to leave the option there to do it. Because if I can kill the website, or at least

00:02:33   the functionality that I cite, which is basically user data functionality. So what I intend

00:02:37   to keep, no matter what, is the site for hosting share links for episodes, having a little

00:02:43   web player there. Certainly file upload functionality will still be possible. I don't know exactly

00:02:48   how yet, but that will still be possible to answer a frequently asked question. But I

00:02:55   don't want to have to have the servers and the website need to know about your user data.

00:03:02   Because that way, so basically I don't want the web player to know your list of subscriptions

00:03:09   and your progress within each episode or whether episodes are marked, deleted, or played, or

00:03:13   new. So basically the user data part of what I store, I would love to get to a place where

00:03:19   that is hosted on CloudKit. And while there are ways for servers to interact with CloudKit

00:03:26   data, I have used them before. They are terrible and unreliable, and I don't want to build

00:03:32   any features that rely on that. So if I'm going to leave the door open to use CloudKit,

00:03:39   the website player has to lose all user specific functionality and the ability to sync your

00:03:47   progress and things like that. And so most of the website player's functionality will

00:03:52   still function in the sense that you can still go to the website and type a podcast into

00:03:57   a search box and find it and hit play on something, but that progress won't sync back to your

00:04:02   account or anything and it won't know what you're subscribed to. That's the thing that

00:04:05   I'm trying to leave the door open to do. Now, in the grand scheme of things, I haven't used

00:04:12   CloudKit yet, and I have a lot of testing to do and a lot of evaluation to do. And so,

00:04:17   it actually might turn out that I don't go down that path and that I do something else

00:04:22   instead. But I wanted to leave the door open to go down that path. And I thought, you know,

00:04:31   I have analytics on how many people use the website while logged in every day. So it doesn't

00:04:39   count share link follows and stuff like that. Just people who use the website while logged

00:04:43   in. And it's a really small percentage. It's something like .2% of active users. It's very,

00:04:48   very small. And it ends up being, in absolute numbers, a good amount of people, but in relative

00:04:55   numbers, it's quite small. And so, I don't want my architecture decisions on the website

00:05:02   to be bound by trying to keep this one feature alive for such a small percentage of the user

00:05:09   base. So, therefore, I posted it. I said, "You know what? I'm just going to discontinue

00:05:15   this sometime next year. I don't know when yet. Here's why." And that's that.

00:05:19   And again, I don't know if I'm actually going to follow through with actually doing it because

00:05:25   if I can, in the meantime, figure out server stuff in a way that is far more efficient

00:05:31   and far less needy of my time, then maybe I could keep it. But frankly, I don't see

00:05:37   that happening. I think it's more likely that I will proceed with this plan and I will move

00:05:41   to CloudKit for user data, which will mean my servers will no longer access it. And people

00:05:45   have also written in to say, "Hey, if you don't want to make the website player,

00:05:48   hey, why don't you open up an API or hire someone else to do it?" And the issue is

00:05:53   not maintaining the website player. I mean, that's an issue. But I've said my website

00:05:58   player is terrible. And that's partly because I don't put any time into it and partly

00:06:02   because I don't have the skills to make a good one anymore. But also because it's

00:06:07   not that I need the help on the web end. It's that if I proceed with this plan, my servers

00:06:13   won't have user data anymore. They won't have access to it. User data would be entirely

00:06:18   in CloudKit and my servers would be only doing the public side of the data, so things like

00:06:23   feed crawling, keeping the database of feeds and episodes and doing notifications for new

00:06:28   episodes, stuff like that. And so that's the architecture plan I have in mind right

00:06:33   now. So that's why the user-specific functionality of the website might have to go soon.

00:06:41   Yeah. And I mean, I think it's, hey, I'm so excited. I remember we were having a

00:06:46   conversation about this and I think I got very excited about you doing this because

00:06:52   of the doors it opens up for your future and the simplifications that it creates for you

00:06:58   as you continue to try and make Overcast better and more featureful or more, just all of the

00:07:06   things that make Overcast better seem to be being held back by the fact that you currently

00:07:12   have this big, it's like the amount of data that you are shuffling around and managing

00:07:18   right now is very difficult. It's just, even just from the perspective of the amount

00:07:25   of it, that there are so many podcasts, so many users, you're multiplying the number

00:07:30   of podcasts and the number of users together to end up with this terrible n-squared amount

00:07:35   of data that you have to deal with. And it's like, that's terrible. You can see over

00:07:41   time how having to manage and maintain that, the reality is it feels very much like it's

00:07:50   not a one-person-sized job in practical terms. We've had many discussions, I'm sure,

00:08:00   over the years about, "Why are we just one person?" Rather than, "You could hire

00:08:04   five people and it could turn it into a whole thing." That's so transformatively different

00:08:08   and isn't really, I think, what either of you or I would want.

00:08:12   Or be good at.

00:08:13   Yeah, or be good at. It's like, I don't think I'd be a great CEO. I don't think

00:08:16   I'd be a great C-anything. I'm not really a chief. That's not really who I am. I'm

00:08:23   just a lone developer.

00:08:27   You're a loner, Dottie. A rebel.

00:08:29   Yeah. And so I think about what you're doing with Overcast. It is such a different problem

00:08:36   if the Overcast app is essentially responsible for itself. And instead of having to try and

00:08:43   manage this giant n times n problem, you end up with, instead, each app and each person

00:08:51   has their own data and it's just n. They have their data. And the way in which you

00:08:56   move that between devices is certainly complicated. And even that, I imagine the vast majority

00:09:02   of your users use Overcast on a single device. So even having something that is optimizing

00:09:10   even more so for that case is a good thing. But yeah, it's just like what you were talking

00:09:16   about. It's like, yes, you need to do this. You need to unconnect this part of what you're

00:09:21   doing. And I think, especially when I think about how the web player, it carries with

00:09:26   it, it's the symptom, not the, it's the actual, as you're saying, it's the user

00:09:31   data, not the web player necessarily. But even the web player, I think about how the

00:09:36   web player is essentially exactly the same as it was when Overcast shipped, whatever

00:09:41   it was years ago. It is clearly not a part of the app that you have any incentive or

00:09:46   desire to improve, make better, have a rich experience there. And you really honestly,

00:09:52   there's no incentive. There's no ads on the website. There's no, you can't sign

00:09:56   up for your subscription on the website. There's no reason for you to make it better because

00:10:01   it's not actually really a part of your business in that way. It's this sort of knock

00:10:05   on effect.

00:10:06   Well, I mean, I would push back on that because I can say the same thing about the Watch app.

00:10:09   There's no ads or premium subscription in the Watch app, but I make it because it's

00:10:14   an accessory to the main app. And that's how I view the website. The website is an

00:10:18   accessory to the app. It's simple as that. But it's just a far worse and less popular

00:10:23   and less used accessory than the Watch app.

00:10:25   Maybe. Yeah. But I think that's, and that difference there is it's like you could

00:10:30   imagine, I could imagine more of a connection between the Watch app and the main app in

00:10:36   terms of that becoming a thing that you have incentives to maintain in a way that I don't

00:10:41   see with the web player. But I think mostly the reality is, is I just want you to get

00:10:44   out of the user data business and have that be someone else's problem, like someone

00:10:48   else's giant database that they're managing and maintaining where, you know, there are

00:10:53   people whose job it is to be responsible for that scale in a way that is, you know, isn't

00:10:58   the kind of thing that's waking you up in the middle of the night or, you know, suddenly

00:11:01   having some database issue and then suddenly, you know, three days of your life are ruined

00:11:05   as a result. Like that is no good. And that is definitely a business I'd love to see

00:11:10   you get out of.

00:11:11   Yeah. Or at least, you know, change. Because like, you know, in this scenario, I'm still

00:11:15   running servers and I'm still crawling every podcast feed. I'm still dealing with people's,

00:11:20   you know, weird feed issues and stuff like that and, you know, availability and queues

00:11:24   and things like that. But when my servers are hosting almost entirely or entirely public

00:11:30   data, then that becomes like infinitely cashable and being able to be served through CDNs that

00:11:36   will take a lot of the load off of me and stuff like that. And so what I've been doing

00:11:40   over the last, you know, six months or a year or whatever is trying to move towards a hybrid

00:11:45   model where I have user data being served by my servers and then basically telling the

00:11:51   app, "Hey, go to this CDN URL to get the public's half of this data." So, you know,

00:11:57   the server will tell you, "Here's all your progress and deleted statuses of everything."

00:12:00   And then over there, the CDN will tell you the list of episodes and their giant HTML

00:12:04   bodies and things like that. So that's what I've been trying to move to, to try to get

00:12:08   near this ideal while still having servers hold the user data. But ultimately, that has

00:12:13   proven to be fairly complex and I've gone through a lot of different pieces like what

00:12:18   storage backend, what CDN, what serving mechanism, how do you invalidate the caches, how do you

00:12:24   make sure the CDN's up to date. And a lot of that has either failed or has proven to

00:12:32   be unreliable or has proven to be not that much of a gain after all. And so I've actually

00:12:39   spent the last couple of weeks doing a lot of optimization work just because like it

00:12:44   frustrates me because I've worked on bigger things like Instapaper, I think, had more

00:12:52   active users than Overcast did, I think. I don't remember exactly, but I think it had

00:12:57   more. Tumblr, of course, obviously had way more active users. And so when I look at the

00:13:03   number of active users Overcast has and I look at modern server resource levels and

00:13:07   things like that, like I know that I should be able to host this more easily than I am

00:13:14   hosting this. It shouldn't be this big of a deal. This is not that massive of a scale

00:13:18   that I'm operating on. It shouldn't be a huge challenge to host this information.

00:13:24   And so I've been doing optimization things just to see like, you know, is there any more

00:13:28   low-hanging fruit that I can just try to keep going on the path I was already on to try

00:13:33   to fix it and improve it and make it more sustainable and less needy? And I have found

00:13:38   some big gains, but I'm still not out of the woods yet. And so my current plan is to give

00:13:47   this a few more weeks of trying to find more gains and trying to keep what I already have

00:13:55   and stay on the path I was already on and, you know, seeing if I can do that. And if

00:14:00   I can, then maybe I'll change my mind and keep the website for a while or indefinitely.

00:14:06   If it continues to go the way it has gone for the last six months, then I'll proceed

00:14:12   with my CloudKit plan. And in the meantime, I intend to issue some overcast updates that

00:14:18   will start testing CloudKit out in my actual user base, without actually, you know, kind

00:14:22   of similar to how when Apple launched APFS, they said afterwards that like, oh, in the

00:14:28   last couple of system updates, they had actually been running tests on everyone's computers

00:14:32   without telling us. So I intend to actually, you know, send out some overcast releases

00:14:39   that have some CloudKit testing built in to test things like, you know, what percentage

00:14:44   of my user base out there is operating without being sent into an Apple ID, for instance,

00:14:49   because if you run your phone without an Apple ID, as far as I know, you can't use CloudKit

00:14:53   private data at all, because it wouldn't know where to store it. So, you know, if it turns

00:14:58   out that's like, you know, 5% of the user base, that's too much, and then I can't use

00:15:02   CloudKit, you know. Or, you know, if I like run some CloudKit test queries in the field

00:15:07   and report how often they fail, and if they end up failing a lot, or having weird throttling

00:15:12   issues, you know, then, again, then I probably can't use CloudKit. But it is promising in

00:15:18   the sense that by, I've talked to some people, especially like I talked to the developers

00:15:25   of NetNewswire, because they use CloudKit a lot, they were very helpful, I talked to

00:15:29   some other people, talked to you, talked to people who use CloudKit, and it seems like

00:15:34   the usage model I'm looking at is probably a good fit for it. And so, I think I will

00:15:40   move to that direction. And if I succeed in this, then that's, first of all, unfortunately,

00:15:46   it's going to be a lot of work to get there, and that's, again, even more time that I'm

00:15:50   not building features for my users, which I'm painfully aware of, and that's one reason

00:15:54   why I kind of hope I can make the current situation work for a longer time, so I could

00:15:59   maybe have a winter where I focus on user features. But also, if I can get to that place

00:16:04   where user data is all in CloudKit, and my server's only doing public data, that also

00:16:09   means I no longer have this like nuclear waste burden of user data, that like I don't have

00:16:15   the responsibility for things like having everyone's passwords and emails, which I've

00:16:20   tried to get out of over the years, and I still have a bunch because people still use

00:16:23   them. You know, getting out of that business, I think, could be really interesting, but

00:16:28   it's also a little scary because that is destroying value. And while it's value I'm not currently

00:16:36   really using or monetizing, that is value. And there are features in the app that are

00:16:41   based on things like number of stars people have given episodes recently, so there's things

00:16:49   like that that I would have to reconsider or rework or find some other way to do it.

00:16:54   So it's kind of a messy proposition, but if I can do it, and when I can finally do it,

00:17:00   and those are two big qualifiers, I think I would be at a point where it would be really

00:17:05   nice. But those qualifiers are so big that I might never get there.

00:17:10   Dr. Justin Marchegiani I think—because I think it's a way—just

00:17:13   something to keep in mind is I think, A, you know, you've already taken whatever hit you

00:17:18   would have taken by saying you're going to do it. And as far as I can tell, it didn't

00:17:22   seem like it was this catastrophic, like bad PR situation. And it's like, it's one less

00:17:27   thing for you to maintain. It's one less thing that you have to manage and think about. And

00:17:33   it's—it reminds me so much of so many of my apps where I—it's like, it doesn't hurt

00:17:38   anything for me to just leave this app, this old app that I don't really maintain anymore

00:17:41   in the App Store. Like, it's not really a problem, but it's some problem. And it has

00:17:48   some issues and causes some issues and some load and some anything. And there is something

00:17:53   really nice about having that be a nothing rather than it being a something. So just,

00:17:58   you know, it's an experience I've had that is relevant.

00:18:01   You make a good point, as usual.

00:18:25   You can find top talent fast with Indeed's suite of powerful hiring tools like Indeed

00:18:32   and Indeed.com.

00:18:33   And if you hate waiting, Indeed's US data shows over 80% of Indeed employers find quality

00:18:37   candidates whose resume on Indeed matches their job description the moment they sponsor

00:18:41   a job. And screenings and assessments really are great. So you can do things like select

00:18:47   for the skills that matter with Indeed assessments. You can pick from over 100 skills tests, add

00:18:52   them to your job post. That way you can find candidates with the right skills fast. And

00:18:56   these assessments help take the stress out of the interview process. Candidates get to

00:19:00   show their skills before the interview. So you can dive deeper into talking about what's

00:19:04   important to you.

00:19:06   So join more than 3 million businesses worldwide that use Indeed to hire great talent fast.

00:19:13   Indeed knows when you're growing your own business, you have to make every dollar count.

00:19:17   That's why with Indeed you only pay for quality applications that match your must-have job

00:19:21   requirements. Need to hire? You need Indeed. Visit Indeed.com/under-the-radar to start hiring

00:19:29   now. That's I-N-D-E-E-D dot com slash under the radar. Indeed dot com slash under the

00:19:36   radar. Terms and conditions apply. Our thanks to Indeed for the support of this show and

00:19:40   all of Relay FM.

00:19:42   So something that I feel like I always try and do in the show, maybe just in general,

00:19:48   is to try and find like the broad, like the broad lesson that applies from a specific

00:19:55   situation and try and make that kind of something that's useful generally, not just specifically.

00:20:00   If you happen to have an iOS podcast client that has a server component written in PHP

00:20:06   that was written several years ago that has a website component that you want to try and

00:20:10   get out of and move to CloudKit, like very specific, probably not as useful. But I think

00:20:14   there is something in this sort of discussion that has been rattling around in my head that

00:20:18   I think is useful to talk about. And I think it relates to what I was just saying where

00:20:22   in my mind I've been talking, thinking of it as almost like the principle of discontinuity,

00:20:27   where so often in life and in business and technology, there is these situations where

00:20:35   there is this sort of discontinuous, this discontinuous change in effort, outcome, result,

00:20:42   whatever it is between two things that ostensibly are relatively close to each other. And it's

00:20:48   like the easiest and probably the best place to explain this concept with is the difference

00:20:51   between something being free and something having any price at all. And it's one of

00:20:57   those just most incredibly remarkable things in development where whatever price it is,

00:21:04   if we could price our apps at a penny per download, it would still be dramatically more,

00:21:13   you get like 10 times the downloads if you make it free than if you made it a penny,

00:21:18   than if you make it 99 cents. And that's just one of those things that I think is absolutely

00:21:22   true. I just think it's been proven time and time again that there is this discontinuity

00:21:26   there, that if you imagined the demand curve for your app, the amount of downloads you

00:21:31   get at every price, if you charged $1,000 per download of Overcast, you get pretty few

00:21:37   downloads probably. If you charge $10, if you charge $1, but if you make it free, suddenly

00:21:41   it jumps up and there's this discontinuity. And I feel like that behavior, that effect

00:21:47   happens in so many different things. And it makes me think about, for example, do you

00:21:53   support multiple platforms? Well, if you do, suddenly your life just got massively more

00:22:00   complicated than if you didn't. As soon as you support the iPhone and the Apple Watch,

00:22:06   or the iPhone and the iPad, or the iPhone and the iPad and the Apple Watch and the Mac,

00:22:10   it doesn't just get slightly more complicated. It's not like, "Oh, it goes from one to two

00:22:16   to three to four." No, it goes from one to seven to 46 to 702,000. That's what's happening

00:22:25   as you add anything. And that discontinuity in this case is one of these things where

00:22:30   I was saying, there is something so transformative that I've seen time and time again, that doing

00:22:35   any of something is so different than doing nothing of something. That in this case, discontinuing

00:22:42   the website player is actually dramatically different than just leaving it there and having

00:22:47   any amount of your attention, any amount of your responsibility, any amount of something.

00:22:52   And those differences can add up. Like fair enough, maybe the website player isn't the

00:22:56   difference between zero and 5% effect. And 5% of your attention isn't huge necessarily,

00:23:04   but it's still something. But it's something that I've seen over and over again that makes

00:23:08   me very circumspect now about if I take on anything, if I want to start any of these

00:23:16   things where it adds this new aspect, this new dimension. Because so much of our work

00:23:22   is this, it's almost like I imagine it as you have this whole collection of rubber bands

00:23:27   that are just pulling us in different directions. And the number of rubber bands you have pulling

00:23:31   on you is the amount of tension that you feel when you're under. And anytime you add a rubber

00:23:37   band, it just pulls you in that slightly more direction, becomes that much more uncomfortable,

00:23:40   makes that much harder for you to, if you want to turn away from that and focus on something

00:23:44   else, even if you're not working on it, it's still in the back of your mind, just sort

00:23:47   of pulling on you. Or it's like it makes me think of how it becomes really difficult to

00:23:52   make choices down in the future. I mean, in some ways, in this case, it's like it makes

00:23:56   it harder for you now that you made this choice years ago to have a website player, whereas

00:24:01   if you hadn't had a website player in the first place, you just wouldn't be in this

00:24:03   situation and it wouldn't exist. Or I think about how in sort of more recent news where

00:24:09   one of the challenges I think Apple is facing, the way that they do ads in the App Store

00:24:14   is because they started having any ads. And as soon as you have any ads, it's really easy

00:24:19   to have more ads. That in it's like having one ad is so different than having zero. And

00:24:25   like the amount of the decisions that are just made for you by saying we don't do that,

00:24:30   like that is not something we do, is very, very different than trying to decide like

00:24:35   what degree of this thing do we do? How far do we go down this road? Those kinds of subtle

00:24:42   distinctions take a lot of energy and effort and thought in a way that is so much simpler

00:24:47   than saying we just don't do that. I don't collect any data, or I don't do that particular

00:24:51   thing, or we don't do that. And then it goes to zero and it's just kind of magic. So it

00:24:56   was a general principle that I've just seen time and time again that it makes me think

00:24:59   of in this situation. And it's like it's the general lesson of be really careful what

00:25:03   you start because starting anything can be, you know, is very different than not starting

00:25:09   anything I guess.

00:25:10   Wow. That's profound.

00:25:13   Sure, maybe.

00:25:14   Yeah, I think, you know, I've always had trouble dealing with the feedback from feature

00:25:21   removals, but I've always been happier after I did them.

00:25:25   Yes.

00:25:26   There are very few feature removals or changes that I've made that I really regretted afterwards

00:25:33   in the grand scheme of things. And this can apply even to things like when I redesigned

00:25:38   a lot of my player home screen in Overcast, like the list of podcasts, like when I redesigned

00:25:44   that screen last year, I still get feedback from people today who are saying, "I wish

00:25:51   you would change it back." But it's, you know, it's pretty small relative to the user

00:25:57   base and I'm very confident in, you know, certain changes. Honestly, I don't think

00:26:02   I'm done yet. I would love to revisit some of those decisions. But overall, like I'm

00:26:08   happy I made those changes even though it upset some people. And I think, you know,

00:26:12   the web player is similar. It's like if I didn't have it today, you know, a lot of

00:26:17   this kind of like sunk cost fallacy, it's like I would never build this today from scratch

00:26:21   if it didn't already exist. I would never do this. And so I have to decide, well, okay,

00:26:26   well, I did it and I have it. Do I keep it or do I get rid of it? And there actually

00:26:33   is a lot of value to having it to a small number of people. And I'm one of those people

00:26:38   because one of the things the website player does is help me debug problems because I can

00:26:43   quickly look up podcasts and, you know, see what's in my database for them and everything.

00:26:48   And all of that could remain. Like, because none of that depends on user data. None of

00:26:52   that depends on me knowing I am subscribed to podcast XYZ, you know. So I could maintain

00:27:00   much of that value to me. But at the same time, I think like, you know, despite everything

00:27:04   you just said, if it's not that much effort to maintain the player for everyone else,

00:27:10   I should probably still maintain it. So if I don't move user data to CloudKit, I probably

00:27:15   should still maintain the player in some form. Now, that could be limited because, you know,

00:27:20   already it doesn't support playlists. And the only reason the web player has never shown

00:27:23   playlists is because the logic to decide what is in a playlist is very complex. And I already

00:27:29   coded that in Objective-C and I didn't want to also code the exact same logic in PHP and

00:27:33   try to keep them in sync forever because that's quite a thing. And so I decided, all right,

00:27:39   that's going to be a client-side only feature and the web will only show things that the

00:27:42   web can easily show, you know. But if keeping the web player long-term is not difficult,

00:27:50   I think I'll still do it because the utility it does provide, you know, it's kind of like,

00:27:54   you know, the Mac Pro in my lineup. It's like not a lot of people use it, but for the people

00:27:59   who need certain functions, it's kind of the only option, you know. And so, I don't know,

00:28:04   I'm still torn. I'm probably going to waffle on this for months.

00:28:06   Sure. And I think that's fair for it to be difficult. And I think it's a reality of just,

00:28:12   yeah, taking things away or turning things off or feeling like you're throwing away work

00:28:17   you've done is really difficult. And I say that from someone who has had, like the challenge

00:28:23   of being the person who's launched like 60 apps is that I've had to discontinue like 57

00:28:30   of them. Like it is very difficult to do. And it's like there is something that's so hard

00:28:37   to, but at the same time, I also want to keep in the back of my mind that being creative

00:28:41   and starting new things, it's like in some ways, I think it's important to feel comfortable

00:28:47   with ending things because if you're not comfortable with ending things, it's going to be very

00:28:52   uncomfortable to start things. And it's like that tension is something that we just have

00:28:56   to wrestle with and feel comfortable with. In this case, it's like I want you to feel

00:29:01   comfortable with discontinuing the web player because I want you to feel more comfortable

00:29:05   with starting a new feature, starting something that is more actually going to move your app

00:29:12   better and your product better and your mental health and all those things potentially for

00:29:17   forward. And if that comes at the cost of discontinuing other features, like saying

00:29:21   no to that, it's like saying no to something is the same as saying yes to something else.

00:29:24   It's like saying yes to something and saying no to something else. I mean, which way you

00:29:27   want to look at it. And it's like being comfortable with that tension that you eventually, you

00:29:32   have to, you can't have it both ways is just like one of the fundamental realities of life

00:29:37   that is super frustrating, but nevertheless, very true.

00:29:40   Thanks for listening everybody. And we'll talk to you in two weeks.

00:29:44   Bye.

00:29:44   [BLANK_AUDIO]