Under the Radar

191: Self-Imposed Constraints


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 today we're going to start talking about constraints, and sort of especially self-imposed

00:00:16   constraints. And in some ways this is just like the follow-on to what I just said, where

00:00:20   it's like never longer than 30 minutes, so let's get started. And it's kind of coming

00:00:24   from a place where I've been—so this last week, John Gruber and Ben Thompson launched

00:00:29   a podcast called Dithering, which is limited to 15 minutes, sort of no more, no less. And

00:00:35   it reminded me, obviously, of our show, of Under the Radar, and in many ways even moreover of

00:00:42   my previous show, To Under the Radar, which was called Developing Perspective, which is a show

00:00:46   I did for about four years before Under the Radar. And it was never longer than 15 minutes,

00:00:51   so let's get started. And it's one of those things that I've found that limit. Every podcast

00:01:00   I've ever done, other than a few one-off interview shows or things like that, there's always been a

00:01:06   limit. And I'm just used to it now. In my mind, when I'm podcasting, there's always a hard limit.

00:01:10   But it is certainly abnormal in some ways for podcasts, and it is not something that is typical.

00:01:17   But I think the reason why I got started with Developing Perspective with a 15-minute limit,

00:01:21   I think, is instructive just in general for creative endeavors and things that you want

00:01:27   to start and things that you want to make. Because what I've found—and this applies just generally—is

00:01:32   that having constraints of any kind usually increases the quality of the output that you

00:01:39   end up with. And obviously you can constrain for many different things, but in the case of

00:01:45   podcasts, some of the easiest things to do is to constrain the length and to say, "I'm going to

00:01:49   limit myself to Developing Perspective is 15 minutes, Under the Radar is 30 minutes." And it

00:01:56   gives you this tremendous focusing tool and this ability to... There's this hard thing that you

00:02:04   have in your mind that you have to work around. And the process of working around it and getting

00:02:08   good at working around it makes you better. It makes you a better podcast, a better app maker,

00:02:14   better artist, whatever it might be, because that constraint is a useful thing. But I'm curious,

00:02:20   before I get into that too much, Marc, because you were actually—I've never listened to Developing

00:02:23   Perspective as a listener, but I know you did. And I'm curious if you remember your first experience

00:02:29   with that limit and what that meant to you or how that resonated with you when you first came across

00:02:40   that style. I think you hooked me pretty fast. I realized this show is interesting and I want more

00:02:44   of it. But before a listener reaches that point, before you've hooked somebody, before they've

00:02:50   decided they like you and they want to listen to more of you, having a constraint like that,

00:02:55   I think, helps people get in the door more. Because as a podcast listener for a very long

00:03:00   time, way before I made my own app, I had the same problems that many people have, which is

00:03:06   most podcast enthusiasts have more podcasts to listen to than they have time to listen to them.

00:03:13   And many tech shows, especially—because tech shows are what I know, so this is kind of the

00:03:18   role I know—many tech shows are done in kind of a loose conversational manner. That's how

00:03:24   almost everything I do is done. And what that does usually is expand to fill lots of time,

00:03:30   because we're having casual, unscripted conversations with people who are passionate

00:03:34   about stuff and want to talk a lot. And so a typical episode of ATP is about two hours long.

00:03:39   And many tech shows have one to two hours as their typical length.

00:03:46   So when presented with, "Here's a new podcast that I might want to subscribe to,"

00:03:52   if it's going to be an hour and a half or two hours a week, I know that realistically I'm

00:03:57   probably not going to get to that. Because I already have so many long shows I listen to,

00:04:02   I'm probably not going to have enough podcast listening time to add another hour and a half

00:04:06   long show. And that's a very common sentiment among podcast listeners. When something new is

00:04:09   presented to them, it's like, "Well, do I really want to add another hour commitment a week,

00:04:13   basically, of listening? Do I have enough time for that?" And so when you say right up front,

00:04:18   in the definition of the show, it's only going to be short. And people know, like,

00:04:24   "15 minutes is short." Even 30 minutes is fairly short, but 15 is obviously even more so, right?

00:04:30   And so when you say, like, "This is only a 15-minute show every episode," that really,

00:04:36   I think, encourages people that, "You know what? No, you probably do have time for this.

00:04:41   You can take this one on. This is a small commitment, so you can take a risk on this.

00:04:45   Like, if you don't know us already and we're saying our show's only 15 minutes long,

00:04:49   you can take a risk on us because you know that it's not that big of a time commitment for you."

00:04:55   And a second part of this as a podcast is, like, people often fall behind on podcasts. They might

00:05:01   accumulate multiple episodes that they haven't had time to get to, given, you know, maybe they're on,

00:05:07   maybe it's like winter vacation and they're home all day or they're stuck in their houses during a

00:05:11   month-long quarantine and they don't have a community anymore. Episodes build up for shows

00:05:15   in various times for people. And when each of those episodes that's built up is an hour and a

00:05:21   half long, you're just going to start deleting them. Or you're going to say you're going to get

00:05:25   to them someday and you never will and you'll feel bad and you'll have this podcast debt that you

00:05:30   feel guilty about that you're not getting to. If each of those episodes that has stacked up is only

00:05:35   15 or 30 minutes long, you know you can plow through them a lot faster. And so you're more

00:05:39   likely then to not feel bad about it and to be able to get through all of them on a long walk or,

00:05:44   you know, while doing your dishes or something, you can plow through a couple here and there.

00:05:49   And that's another thing, short episodes enable people to listen to a complete episode in more

00:05:55   contexts. So like, you know, if you only have 10 minutes, 15 minutes, whatever, if you have like

00:06:02   a short commute or if you have a short task you're doing, you can get through an entire one of those

00:06:06   episodes probably. Whereas you can get through maybe like half of a topic on a tech show, right?

00:06:13   - Sure. - So in a lot of contexts,

00:06:15   that also is something you want where like you don't wanna like be constantly chopping up what

00:06:19   you're listening to. You wanna like have a complete thing and then be done with it and then you can

00:06:23   move on to, you know, your next thing. And so having a shorter show improves all of those things.

00:06:28   And it isn't what everybody wants. A lot of people, you know, you leave them wanting more and they

00:06:33   want more. Maybe they have time. Maybe they listen to podcasts all day as they work and they burn

00:06:38   through lots of them. But that's probably not most of the audience. Most of the audience has a time

00:06:42   constraint of how much they can listen to per week. And if you're not adding much to that,

00:06:46   that'll help get way more people into the door and it'll help you retain people over time.

00:06:51   - Yeah, and I can say from my experience, like as a maker of only time-constrained podcasts,

00:06:57   like I hear, this is something that I hear very often on the audience side is that, yeah,

00:07:03   like there's something helpful. And I think in some ways there's a sense of it is sort of

00:07:10   intrinsically trying to be respectful of the listener. And I think that as a listener often

00:07:15   you get the feeling that they feel that. That it's the intention of the show becomes about being,

00:07:22   you know, sort of respectful of their time and sort of constraining it such that not that

00:07:27   necessarily like a two-hour tech show has a lot of filler, like, but it has less focus and less

00:07:33   sort of deliverance in it or deliverance is not a word, but deliberation, I guess. It's less

00:07:38   deliberate in this potentially in what it does, or it has maybe it has more banter or it has more

00:07:43   silly sidetracks and sort of little digressions down the side, which are lovely and are part of

00:07:48   what makes the show the show, but are in some ways are less, you know, that they're a trickier thing

00:07:55   in terms of what that actually means for the audience. That if the audience is, if you try,

00:07:58   if you have an idea you want to communicate and you want to communicate it clearly and you have

00:08:03   a time constraint, that will help you to be respectful of your audience's time and really help

00:08:08   sort of communicate that in a sort of a concise, like intentional way that is perhaps rather than

00:08:15   more rather than the kind of more meandering one or approach where you may like you have the benefit

00:08:20   of getting all of the individual's thinking and you might hear them like, you know, give a couple

00:08:25   of different versions of their idea and that helps you increase the richness of that communication,

00:08:31   perhaps, but it's different if you only have 15 minutes to say it, like you really got to

00:08:35   think about it and speak more clearly and help it kind of this is helpful thing. And I think as an

00:08:40   audience person, like that was something that I always would hear is that like they liked that,

00:08:45   that, you know, developing respect for under the radar. There's a sort of, there's this very,

00:08:49   it's respectful of the audience in a way that just honors their time and isn't assuming that I am,

00:08:54   I've, I haven't necessarily, I haven't earned more than 15 minutes of your time, or I haven't earned

00:08:59   more than 30 minutes of your time. And it's easier for me to kind of make my, make sure that I'm

00:09:03   worth it. If all I'm asking for is 15 or 20 minutes rather than, you know, two hours. Yeah,

00:09:09   the quality has to be so much higher for that, I think in some ways too.

00:09:12   Oh yeah. And like, you know, my mode of speaking, the way I talk on this show is totally different

00:09:18   than the way I talk on ATP. That because I'm, I'm always aware of the time. I'm always looking,

00:09:23   I'm always keeping an eye on, on that clock in the corner of my screen to see like, all right,

00:09:26   how far are we? And, and I know roughly where we are in the show. I know that right now we're

00:09:32   at about nine and a half minutes. And so, you know, we're going to do the sponsor break somewhere

00:09:35   around 15 minutes. So right now, kind of like two thirds of the way through like the, the initial

00:09:40   pre-sponsor break topic. And I know I have to keep a certain pace to get out my thoughts. And then I

00:09:45   also am very conscious about what I'm talking a lot, making sure I leave enough time for you

00:09:50   to get your thoughts in. So I have to like pull back and stop at a certain point so that I leave

00:09:55   enough time for you. And all of this is totally different than how I do ATP. It's, there's,

00:10:00   there's none of that in ATP because there's no, there's no time constraint on ATP. I can just,

00:10:04   I can talk forever and then John can talk forever and then Casey can talk forever and it's fine.

00:10:08   Yeah. And it's just different. It's a different format and it's, it's a,

00:10:12   and it's not to say necessarily that I'm saying that like, this is the best way to do podcasts

00:10:15   and everyone should do it. It's, but it's, I think there is a powerful thing in it. When you put this

00:10:19   constraint on you. And I think too, so that's like on the audience side, but I will say too,

00:10:23   on the creator side, like it is a powerful tool to constrain the length or constrain the content

00:10:29   or the format or whatever you're going to kind of, you constrain a lot of different things.

00:10:32   I think the most powerfully, what that means is that it helps you to start and to feel confident

00:10:39   about actually starting the project. Like developing perspective was 15 minutes because

00:10:45   I wanted to have a podcast. Like at the time I was this big, like I listened to podcasts

00:10:48   constantly. Like I love podcasts, but I never had one. And I was like, I don't know what to do. Do

00:10:52   I have enough to speak about, you know, am I well spoken enough? Whatever, all these,

00:10:56   the sort of the negative, like self doubt things that I had in my mind. And what I ended up on was,

00:11:02   it's like, well, if it's only 15 minutes, like I can say, like, I can speak for 15 minutes about

00:11:07   a topic and I don't feel like I'm going to be waffling. I don't feel like I'm going to be

00:11:12   kind of, I don't have time for digressions or for sort of issues like that. And it was something

00:11:18   that I felt like from a time commitment perspective, I could do that. I wasn't like taking

00:11:22   on two hours a week of work. I was taking on 15 minutes of work a week, which is way less,

00:11:28   way easier. And I mean, the same thing when you and I sort of took on Under the Radar. It's like,

00:11:32   okay, this is twice as long, but it's still only half an hour of recording. It's much less of a

00:11:38   commitment of time and energy and effort. And I think it really helps to both to get started.

00:11:42   And then probably moreover is once the kind of initial excitement phase of starting a new

00:11:48   project kind of wears off, it's like, how likely are you to continue it and sustain it going

00:11:54   forward? And by making it constrained in format or length, it's much easier for us to keep doing this

00:11:59   because it's not a huge investment of our time. And when life gets complicated or our projects

00:12:04   get complicated or whatever is happening in our life, it might be tricky if we were trying to find

00:12:10   two hours to record together, that can get complicated. But if we're just trying to find

00:12:13   half an hour, I can always find half an hour in my schedule. And so it's much easier to do that.

00:12:20   And so from a creator perspective, I think having those constraints to the length of a show has been

00:12:25   really helpful there. And I will say too, it don't feel like too if you ever were starting something

00:12:30   that has a length constraint, that you are forever bound by it in a way that is completely immovable.

00:12:35   It is important to be respectful of the format and give people what they want. But

00:12:41   in the developing perspective days, I had a couple episodes that were interviews,

00:12:45   and those didn't have the time constraint. And if we ever did an interview on this show,

00:12:49   I know Craig Federici just did a great interview with Federico Vittucci on App Stories. And it's

00:12:56   like, whoever got one of those, if we ever get a call from Apple and they say, "Hey, we want to do

00:13:00   an interview on your show," it might not be 30 minutes long. And the feedback I always got was

00:13:05   like, "That's fine." As long as you respect the core, that's a different show. The people who are

00:13:11   interested in your actual show, your normal show, are probably going to be interested in that. So

00:13:15   don't feel like you are forever bound by those rules. But having those rules is so helpful for

00:13:20   getting started and then for keeping it going and focusing your mind as you're going.

00:13:25   Matthew Feeney I like how you pointed out that you can change

00:13:29   if you need to, or if it's best for the show. My wife does a podcast called Somehow I Manage,

00:13:34   which is a podcast about the TV show The Office. And initially, it's a rewatch show, so one episode

00:13:41   per episode of The Office. And initially, they wanted to keep the podcast the same length or

00:13:47   shorter as the episodes, which are like 22 minutes long. And it turns out 22 minutes is really tight

00:13:53   for two people discussing the ins and outs of a TV episode. And so they tried it as a constraint,

00:13:59   but it just wasn't good for the format. It wasn't good for the content. And so they expanded it a

00:14:03   little bit. They went to like 30 or 35 or 45 minutes, and it's fine. So like the constraints,

00:14:08   you don't have to stick with them forever if they don't work. It's like my whole thing with the

00:14:12   magazine not having a setting screen. I'm not going to have a setting screen. And it turns out

00:14:15   that was a terrible idea, and I needed one, and it was better. So you can start with constraints,

00:14:20   and you can change your mind later if you need to. We are brought to you this week by Linode.

00:14:24   Whether you're working on a personal project or managing your enterprise's infrastructure,

00:14:28   Linode has the pricing, support, and scale you need to take your project to the next

00:14:32   level. They have 11 data centers worldwide so far, including their newest one in Sydney, Australia.

00:14:38   And with their enterprise-grade hardware, their new S3-compatible storage option,

00:14:42   and next-generation network, Linode delivers the performance you expect at a surprisingly good

00:14:47   price. You can get started on Linode today with a $20 credit with listeners of our show,

00:14:53   and you get access to their entire infrastructure. They have, of course, native SSD storage for very

00:14:59   fast performance, a 40-gigabit network behind it all, industry-leading processors. Their cloud

00:15:04   manager has been recently revamped. It's now built on an open-source single-page app, and it's built

00:15:08   on their awesome API. You can use their API if you need to to automate things. You can use a CLI tool

00:15:14   to create instances, all sorts of wonderful stuff. Or you can stay out of the API and just use a nice

00:15:18   graphical interface, and it's wonderful. Their plan started just $5 a month, and they have lots

00:15:23   of options to go up and above and beyond that for various needs you might have, including specialty

00:15:27   needs like dedicated CPU plans, GPU compute plans, high memory plans, and more. I use Linode myself.

00:15:34   I host all my stuff there, and I'm very, very happy there. I've hosted it there since way before

00:15:38   they were a sponsor for almost 10 years now, and I'm just very happy at Linode. I run something like

00:15:43   30 servers there now, and it's just wonderful. So go to linode.com/radar, and to get that $20

00:15:50   credit towards your next project, use promo code UNDERTHERADAR2020 when creating a new Linode

00:15:55   account. So once again, linode.com/radar, promo code UNDERTHERADAR2020 for a $20 credit.

00:16:02   Our thanks to Linode for their support of this show and all of Relay FM.

00:16:05   Michael: So I think what you just said, though, about the magazine is a really useful kind of

00:16:11   like transition point for us, though. Like talking so right, moving on a little bit from talking

00:16:15   about podcasts and to turning this into a bit more about apps. Like there are so many things that you

00:16:20   can do in the creation of an app that are constraints that you can put on yourself.

00:16:24   And I think many of them have the same benefits that constraining the length of a podcast

00:16:29   has. And like your example there of constraining yourself to say that you're not going to have a

00:16:35   setting screen. Like while ultimately, like down the road, that ended up not being necessarily the

00:16:40   right thing for the app, I imagine in the creation of it, it's a very useful tool because it means

00:16:47   that you forced yourself to think like, "How can I structure this so that it doesn't need one?

00:16:51   So that how can I anticipate what choices my user would want and design around that?" Or prevent you

00:16:58   potentially from going down lots of rabbit holes and giving all these kind of like these bifurcations

00:17:03   you can have in your design where it's like, "Well, what if the user wants it to be this way

00:17:07   and this way?" Then you end up building both. Like by saying to yourself, "I'm only going to

00:17:13   sort of build, I'm going to build the app such that it doesn't need a setting screen."

00:17:16   You force yourself to make a bunch of choices that maybe aren't in the long term what you want,

00:17:22   you know, the best thing for the longevity of the app, but almost certainly for the creation of it.

00:17:27   Like I suspect the magazine app as it was, was better for not having a setting screen to start

00:17:33   with. Like I feel like that's the kind of thing where these constraints that you put on yourself

00:17:37   can just be these really helpful tools for focusing your mind and kind of giving you something.

00:17:42   Like in some ways I almost kind of think about it like it's hard to push something if you're not on

00:17:50   a solid, like if you don't have something to push against. Like if you just push on one thing but

00:17:55   you have nothing on the other side of you, like you really can't move it nearly as much as you

00:17:59   can if you can push on both sides. Like you need this anchoring to kind of be working against and

00:18:05   that really helps you to move things in real life. But in some ways, if you don't have any

00:18:10   constraints, if you are just like this free and open thing, then you're up in space and you're

00:18:15   trying to push something. Like that doesn't really work. You have nothing to push against. If you

00:18:18   imagine an astronaut floating in space and he's trying to push something away from him, sort of,

00:18:23   but it doesn't work as well. Like you really need to have something behind you that's a limit that

00:18:28   is like, "Okay, this is somewhere that I'm stuck against and I'm working against and I have this

00:18:34   constraint." And whatever that is, in some ways we have a whole list of things we can talk about, but

00:18:40   you need to have something. You need to have some kind of constraint that you're putting on yourself,

00:18:43   otherwise you're just going to be spinning around in space and that sounds awful.

00:18:47   But also, the constraint often represents a goal. If you kind of step up a level,

00:18:54   like my thing with the magazine, I didn't want a setting screen. Why? Step up a level. I didn't

00:18:58   want a setting screen because I didn't want it to be too complicated. So even after I gave in on the

00:19:03   setting screen thing, I can still try to achieve the goal, the idea of, "Well, don't make it

00:19:11   complicated." So, okay, I needed to have a setting screen after all. It ended up being more complicated

00:19:16   to try not to have one. But the idea of not making it complicated still guided me in the design of

00:19:23   what I had to do to break that constraint and I still kept it very simple and tried to have

00:19:27   very few options, keep everything very clear, keep it mostly not having options, mostly not

00:19:34   having settings, and just have the bare minimum I can get away with. And the similar thing,

00:19:38   like we were saying with podcasts, if you're constraining your length, what you're really

00:19:41   saying is, "I want to make a tight show. I want it to be concise and fast-paced and dense and

00:19:47   respectful of people's time." You can still do that as your guiding principle, even if you have

00:19:53   to change or break your stated time constraint or your time goal. And so the same thing with apps.

00:19:58   Like, if you constrain yourself and you say, "Okay, this is not going to be an app that I slowly work

00:20:05   on as a labor of love that I'm going to pour my entire soul into for six years before anybody

00:20:10   sees it. Instead, I'm going to make a small, simple app. I'm going to do it fairly quickly.

00:20:17   I'm not going to tackle any big, hairy features. I'm just going to make it small and tight and

00:20:23   not a big commitment, not a big investment." That is a very useful guiding goal, and that applies

00:20:29   to so many things. That can apply mostly to your timeline. If you say, "I want to make an app in

00:20:35   the next month. One month from now, I want it to be in the store." So what does that mean? So,

00:20:40   "This week I have to do this. This week I have to be here. This week I have to have reached this goal,"

00:20:45   et cetera. And even that can be a very useful constraint, even if it's a little bit broad or

00:20:50   a little bit squishy. Having any kind of constraint can really help a lot.

00:20:55   Jonathon

00:20:57   I think timeline is probably the most powerful constraint for a new project. Having a deadline

00:21:03   focuses the mind and helps you be ruthless in a good way of deciding, "Should I do this feature?

00:21:10   Should I not do this feature?" Especially, I will say, as an independent developer,

00:21:16   it's the hardest thing, deciding and holding yourself accountable to a deadline.

00:21:21   Because there is no one outside of me, there's no external force who's telling me that you have to

00:21:26   ship by this day. That's why in all of my apps, I tend to have this point where I literally will

00:21:32   take a big piece of paper and I write, "No more new features," and then I draw a really terrible

00:21:37   crude picture of a ship, and I stick it to my iMac and I say, "I'm done." I've had to do this with

00:21:44   Calzones, I did this with WatchSmith, and I'll stick it to my computer, and then from that point

00:21:49   on, I'm done. I've hit my time limit, and all I can do is work on screenshots and description and

00:21:57   last bit of testing and stuff like that, but I'm done with features. But I have to impose that on

00:22:02   myself. I have to give myself the constraint and then hold myself accountable to it, because

00:22:07   otherwise it's so natural and easy to be like, "Oh, the app would be better if I did this. Oh,

00:22:11   the app would be better if I did that." But not having any constraint there, you'll just keep

00:22:16   meandering around forever and you'll never actually get anywhere. You very quickly hit a

00:22:21   point that you're getting diminishing returns on the viability of the app, or you're inventing the

00:22:28   features that you think people will want, but in reality, people might not want at all. They might

00:22:33   want something completely different, and you're building this app for this imaginary person who

00:22:36   doesn't exist. Some of the things, though, that you can also think of with constraints. I was trying

00:22:41   to think of what are some of the timeline. So timeline is the biggest one that I can think of.

00:22:46   The next biggest constraint is probably platform. What are you building this for?

00:22:50   And so maybe this is to start with, the app only is on the iPhone or is only on the iPad or the Mac

00:22:57   or the watch or whatever it is. You can constrain the number of platforms that you go to, because

00:23:04   in the modern world of Apple development, there are a lot of platforms that you can

00:23:09   now address with, in theory, the same code. And that's a very, the same code has the biggest

00:23:16   quotes around it you could imagine. There's a couple asterisks and daggers on that.

00:23:20   There's a lot of asterisk footnotes, those double daggers. There's tremendous caveats around that,

00:23:26   because in theory, you could address the Mac, the iPhone, iPad, tvOS, and the watch, all with

00:23:37   the same Swift UI code, probably, or at least mostly the same. But that's not true.

00:23:41   And what you're doing, and while ultimately that might be the case, constraining the number of

00:23:46   platforms you address at the beginning is probably a useful, helpful thing. Because if you launch on

00:23:53   one platform and it's successful, there's almost certainly going to be a desire for it to go to

00:23:58   those other platforms. And then there's a reason for it to go to those other platforms, because

00:24:01   other people have asked for it and your customers want it, rather than just doing this work without

00:24:06   necessarily even knowing that it's going to get there. And another thing you can constrain is the

00:24:10   feature set. You can just say, "These are the features I'm going to start with," which is very

00:24:15   loosely related to timeline. Those two things tend to work in opposition to each other. But

00:24:20   for some people, I could imagine that just the features, thinking of something as a feature

00:24:24   rather than as time, or probably moreover, if your time is not something that you have

00:24:29   as much control over, like if this is a nights and weekend project, and the time it takes to get

00:24:34   it done is very variable based on your day job and your life more generally, but saying, "I'm only

00:24:40   going to ship with this set of features," that could be a useful constraint you put on yourself.

00:24:45   You could constrain the audience for an application. Many apps can have many different

00:24:53   uses. You can sometimes even just as simple as you could say, "Is this for a professional use,

00:24:59   or is this for a more casual use?" Like when I made a calendar app, you could make that focused

00:25:05   on one or the other, and the features and the direction you take will be different. And if you

00:25:10   try and do both, it's going to be difficult, both from a time perspective and a design perspective.

00:25:16   You could also constrain the languages and the locales that you support. So this is like,

00:25:20   "Do you support localization? How much are you testing right-to-left languages?" and all these

00:25:25   things, which may or may not be important for you and your app, and based on the audience question

00:25:29   you just answered for yourself, but that's something that you have to keep in mind.

00:25:33   And then the last one that came to mind to me was you can constrain the design approach you're

00:25:39   taking to an application. Are you trying to just ship something that looks like native iOS or

00:25:46   native watchOS or whatever that platform might be, or are you trying to do something completely

00:25:51   custom and totally new? They both have value, and they're both useful in different ways,

00:25:57   but if you can constrain that and you say, "I'm not going to subclass UI button in this app,"

00:26:05   that's a powerful constraint that would dramatically change the number of ways that

00:26:09   you would build things. Or you're never going to subclass UI table view cell, or whatever it is.

00:26:14   You can give yourself a constraint that might be useful to say that you're going to keep it as

00:26:19   simple as possible, to start with at least. Yeah, that kind of thing. The design and UI stuff,

00:26:26   that can be such a rabbit hole. What's the term out of rabbit hole, right? What's the

00:26:32   massive cost sink? Anyway, whatever the term is that everyone else who's listening is screaming

00:26:40   at me that I can't remember right now. There is so much potential for massive time loss and

00:26:48   just infinite possible investment in UI customization. And also, you mentioned earlier,

00:26:53   a feature set. A lot of it gets down to, do you want your app to have settings or not? Do you want

00:26:58   it to be opinionated and say, "I'm going to make a podcast app that appeals only to people who want

00:27:05   to stream full-time, and only to people who want to listen and organize in this way, and who only

00:27:11   need this feature X, Y, and Z," stuff like that. You can have that kind of constraint. Or you can

00:27:15   say more broadly, "Do I want my app to be broad appeal or narrow appeal? If I'm making a to-do

00:27:21   app, do I want to make it super customizable and powerful so that everybody with their

00:27:27   needs for to-do apps can potentially configure my app to satisfy their needs? Or do I want to

00:27:33   make something that does something one way and appeal to the people who want it done exactly

00:27:37   that way and possibly nobody else?" Certainly, it's a little bit different with apps versus

00:27:42   podcasts and stuff like that, because apps have updates. So one thing you can do that's a useful

00:27:47   thing is start. Get your version one out there, your minimum viable product, whatever you want

00:27:52   to call it. Get your version one out there that is significantly constrained, and then use the

00:27:57   feedback and economics that result from that to decide what to do next. But certainly,

00:28:02   a lot of these constraints are significantly more valuable for that 1.0.

00:28:06   Yeah. I think, too, the underlining lesson that I think hopefully I'm trying to communicate this

00:28:13   episode is the sense that you just need to be thoughtful upfront about what constraints you

00:28:19   have, honest about them, choose which ones make sense for you. And I think being intentional and

00:28:25   conscious about that is where so much of the value comes. It isn't that a 15-minute podcast or an app

00:28:31   without a feature setting screen is intrinsically better. But if it's the thing that you want to

00:28:36   build and you've made a conscious choice that that's what you're going to build and that's what

00:28:40   you're aiming at, that's where the power comes from. That's where you get this extra speed boost

00:28:47   that lets you be more effective, make a better product, make a better show. Whatever it might be

00:28:52   is because it was a choice that you had and that you're holding yourself to and it guides you along

00:28:57   when you inevitably bump into the things on the side of the path that is always going to happen

00:29:02   when you start something, whether that be an app or a show or any creative endeavor.

00:29:06   Yeah, and it also helps you avoid the things that you might do speculatively, thinking that you will

00:29:12   need to do them. A lot of them you don't need to, right? And so by not even doing a lot of them at

00:29:18   first and just kind of testing the waters without doing a lot of the optional stuff, you'll find out

00:29:23   just from feedback and stuff, you'll find out like which of those should I actually do and which of

00:29:27   them is nobody asking for. Sure. So thanks for listening everybody and we'll talk to you in two

00:29:33   weeks. Bye!