Under the Radar

5: Managing Feedback


00:00:00   Welcome to Under the Radar, a show about independent iOS development.

00:00:03   I'm Marco Arment.

00:00:04   And I'm David Smith.

00:00:06   Under the Radar is never longer than 30 minutes, so let's get started.

00:00:10   So today, what we wanted to talk about is the way in which we manage and deal with getting

00:00:16   feedback on our products, on our apps, both in terms of from customers.

00:00:21   But I think one of the things that I really wanted to unpack a little bit is the way that

00:00:26   We handle feedback when products are in their earlier stages.

00:00:30   So things like beta testing or early interactions

00:00:33   with customers.

00:00:35   Because something that I find really complicated

00:00:38   when I'm developing an app or developing a major update

00:00:41   is I will have in my mind a vision for what

00:00:44   I want that update to do, what I want the app to do.

00:00:48   And I kind of am working towards that.

00:00:50   I'm working towards that.

00:00:51   But in this early sort of embryonic state,

00:00:54   It's only in my head and in the little prototypes

00:00:58   and the little bits of code that I'm building.

00:01:00   And something significant, though,

00:01:02   happens the first time you ever show it to someone else,

00:01:05   even beyond just telling someone the idea.

00:01:07   But when you actually show them something

00:01:09   and you give them something to react to,

00:01:12   the way that you think about the app

00:01:14   seems to change for myself.

00:01:15   Because suddenly, it has their feedback, their suggestions,

00:01:19   their ideas start to be kind of mixed in and muddled along

00:01:22   with mine.

00:01:23   And so something that I've learned is that I have to be really, really careful about

00:01:28   how I get that feedback, at what point I get that feedback, and the way in which I sort

00:01:34   of manage it.

00:01:35   Because what I don't want to do is take too much feedback too quickly and kind of lose

00:01:39   that vision for what I want to do, where I want the app to be, or what I want the update

00:01:45   to be.

00:01:46   And so it's something that I, it's a weird discipline that I think you kind of have to

00:01:49   learn.

00:01:50   And I was curious though, if you've had a similar set of experiences, how do you go

00:01:53   about kind of pulling in that feedback?

00:01:55   >>Trevor

00:01:55   during early development I will usually ask close friends for input on certain basic decisions

00:02:02   about it, basic feature decisions, how things might be structured, what features might need

00:02:05   to be necessary or unnecessary. And then I've recently, in recent years, gotten really a

00:02:11   big fan of medium-sized private betas. For me, the private beta is extremely useful,

00:02:18   and I've done a number of sizes of betas. I first, in the early days of Overcast, I

00:02:24   was doing a beta of like, I think like 20 people. I've also since then done betas with

00:02:29   800 people because TestFlight allowed you to do a thousand, now it's actually 2,000.

00:02:33   But so I did like 800 people on a beta that was like, I basically had a public sign up

00:02:38   form and just would let almost anybody in. More recently I've done much smaller betas

00:02:42   going back to that original size of like 20 to 40 people again. And what I found is that

00:02:47   the quality of the feedback doesn't actually seem to change significantly with the size

00:02:53   of the beta, which is kind of intuitive, but it seems like you can show the app to a relatively

00:03:00   small number of people and you'll pretty much get all the feedback you need from a

00:03:06   small group. And maybe not a small group of like two, but 10 or 20 people, if they're

00:03:13   actually going to use it and give you feedback, which is a separate point, but if they're

00:03:16   actually going to use it and give you feedback, you don't need that many people involved

00:03:20   in the group. Now the feedback you get tends to be really focused or really heavily weighted

00:03:26   towards upfront feedback, right the very first time somebody uses a beta. Because, and I

00:03:32   don't know if other people do this, but I do this where if somebody gives me a beta,

00:03:36   I will usually take a lot of time going through the app that very first time and giving pretty

00:03:41   detailed feedback to them. But after that first time as more updates come in, I very

00:03:47   rarely ever take that amount of time again, unless I spot an obvious bug then I can screenshot

00:03:51   it, send it to them, whatever. But general feedback about a beta or about an app, it's

00:03:56   usually front loaded. And I found that to be the case with most of my testers as well.

00:04:00   So what I will usually do is, if I can, I will have a few new testers in every group.

00:04:08   And TestFlight allows you to see who among the group didn't install the latest few versions.

00:04:13   it'll tell you the last version of each person installed.

00:04:16   So if I see some of my testers losing interest,

00:04:19   you know, like if they just don't install the updates,

00:04:22   or if the last update they installed

00:04:23   was like five builds ago,

00:04:25   I'll just quietly remove them from the list,

00:04:27   and it's no hard feelings, you know,

00:04:29   'cause I do that all the time,

00:04:29   I always fall out of beta all the time,

00:04:31   because I lose interest, or I don't have time

00:04:33   in that month or whatever,

00:04:35   so I usually will cut people who kinda aren't using it,

00:04:38   and you know, no hard feelings,

00:04:39   a lot of times they're my friends,

00:04:41   I don't even, you know, doesn't matter, no hard feelings.

00:04:44   And then I will add a few new people every time

00:04:47   because it allows me to get that initial impression,

00:04:50   like somebody's first impression of this app,

00:04:52   it allows me to have that ongoing throughout the process

00:04:56   rather than showing it all to the same people

00:04:58   right up front and never bring any new people in

00:05:01   along the way.

00:05:02   - So I've only recently started doing beta testing

00:05:06   properly at all, I would say.

00:05:07   Like the most recent update I did for Perimeter++

00:05:10   the first time I'd ever done a big update or big beta test before I launched something

00:05:16   big.

00:05:17   And before that, it had only really been I would have it running on my own phone, maybe

00:05:23   my wife's, maybe a few, like one or two other people, and honestly, then on a lot of testing

00:05:30   devices.

00:05:31   But I'd never had that experience of having this big kind of like wide, like I did a similar

00:05:35   kind of thing.

00:05:36   Like I just said, anybody who wants to beta test, pedometer plus plus, let me know.

00:05:40   and I went to TestFlight and I put them all in.

00:05:42   And I had an interesting thing that was sort of like similar to your experience where you

00:05:45   get this big wave of comments and this big wave of feedback early on, and then it sort

00:05:51   of dies down.

00:05:52   And then actually what I found is you ended up with another wave like a week later with

00:05:55   sort of like the, "Huh, now that I've been using it for a while, here's some other thoughts."

00:06:00   And I would say that I had a very similar kind of experience to you in so far as there's

00:06:04   only a certain number, amount of feedback was actually helpful.

00:06:08   And beyond that, you start to get a lot more repeats, you start to get a lot more tangential

00:06:14   things.

00:06:15   But at its core, what I found helpful in the beta test was validating, A, that the app

00:06:21   works and is functional in the way that I need it to be, and then, 2, it's validating

00:06:25   that it's a good idea.

00:06:29   I'm not getting to, "What?

00:06:30   This doesn't make any sense."

00:06:32   Or people who've used the app before and going to this version are like, "You're totally

00:06:35   breaking the thing that made the app good before.

00:06:38   Because I think those are the things that I find that I struggle with as myself, because

00:06:43   I have been working on an update for several months.

00:06:46   My experience with the app at that point becomes almost exclusively the new version of the

00:06:52   app and not what the existing version in the App Store is.

00:06:57   And I can tend to lose sight of the distance that I'm creating between those two things,

00:07:01   because I never go back to, other than for like my final acceptance testing, like I won't

00:07:05   go back to the app store, download the version, and run that for a few days.

00:07:09   That's just not typically the way I do it, because obviously I'm constantly running development

00:07:13   builds on my own machine.

00:07:15   And the feedback that I got that was most helpful is when I have someone who's like,

00:07:18   "So I used the old version yesterday, and I used the new version today, and this felt

00:07:23   weird by going from there to there."

00:07:25   Those types of feedback are things that are really hard for me to do, because like I said,

00:07:29   I have this whole new vision for the app.

00:07:31   I've imagined and built features around this whole new thing, and that's what I'm used

00:07:36   to months later.

00:07:37   Sometimes the weirdest one is when you go back to the App Store version, you're like,

00:07:40   "What is this?

00:07:41   I can't believe this shipped."

00:07:42   But like, "Whoa, this is different.

00:07:47   This functions in a different way.

00:07:48   This has lots of other issues."

00:07:51   And so that was something that I learned from this feedback.

00:07:55   I was like, "Huh, this was weird coming from that."

00:07:59   And that's helpful both in terms of from a development perspective, but then also from

00:08:02   in terms of what questions are my beta testers going to have about the app?

00:08:08   What's weird to them?

00:08:09   What's new to them?

00:08:10   And then when I take that feedback, I can structure my documentation or my release notes

00:08:15   or things to be like, if you're coming from the old version to the new version, you might

00:08:19   find this weird.

00:08:21   If you find this weird, this is the answer to your question.

00:08:24   But that's something that I was never able to do before I was able to find TestFlight.

00:08:28   I have a broader audience, and something that I definitely now I think will use going forward,

00:08:33   whereas before I always viewed TestLite as like, "Oh, it's beta testing."

00:08:35   It's just like making sure that there's no crashers.

00:08:37   It's making sure there's not a lot of things.

00:08:39   But understanding customer perspective changes from the old to the new was really helpful.

00:08:44   >> Steve

00:08:52   incredibly, because when you're developing an app,

00:08:56   when you're only using it yourself,

00:08:57   like you mentioned, I do the same thing,

00:08:58   where I'll use it myself for months,

00:09:00   and as soon as I can get it running on my phone,

00:09:04   I will use it myself full time.

00:09:06   And when you're developing the app yourself,

00:09:09   you know how to use it, and you know what you did.

00:09:12   So everything makes sense to you.

00:09:14   And when you first show it to beta testers,

00:09:16   especially for a 1.0, where they are not familiar

00:09:19   with the app before,

00:09:21   The most valuable perspective I got was,

00:09:24   what doesn't make sense?

00:09:26   Or what is being misunderstood from what I intended?

00:09:29   And I made tons of interface improvements

00:09:32   and tons of changes during that initial test.

00:09:35   I thought that a beta test would just be like,

00:09:37   oh, just let me know if anything crashes or breaks,

00:09:39   and then I'll ship it in a few weeks.

00:09:42   And it turned out to be months long

00:09:44   because everybody gave really good feedback about,

00:09:48   this doesn't really make sense,

00:09:49   or I don't understand what this is,

00:09:51   And the app, I dramatically improved the app.

00:09:53   It was almost like shipping at version 2.0,

00:09:56   you know, rather than shipping 1.0

00:09:58   because I had such great feedback just by asking people.

00:10:01   And again, this was only a group of like 20 people.

00:10:04   It doesn't need to be a big group.

00:10:05   It just needs to be people who aren't you

00:10:07   because you get everything you did

00:10:10   because you did it and you designed it.

00:10:12   And as soon as you show anybody else,

00:10:15   you immediately will see the flaws in what you did

00:10:18   because you will see them either struggling

00:10:21   to understand what you did or misinterpreting things

00:10:26   or missing entire big features

00:10:28   'cause they just don't see them

00:10:30   or they don't see why they would need them or something.

00:10:33   And it's great.

00:10:34   Like my effects panel in Overcast looked totally different

00:10:38   when I shipped the 1.0 beta, the very first beta.

00:10:41   Voice Boost didn't even exist by that name.

00:10:44   It was actually a Boost slider

00:10:47   and it had four different modes,

00:10:49   and smart speed was there,

00:10:52   but everything was kind of rearranged differently,

00:10:54   and over time, and the wording,

00:10:56   the labels were all different,

00:10:58   and over that beta I was able to really refine that panel,

00:11:01   reduce voice boost down to either an on or an off,

00:11:04   which was actually, it was its strongest setting.

00:11:06   I just, I realized halfway through development,

00:11:08   you know, actually, I always just leave it

00:11:11   at the strongest setting because that's the best.

00:11:13   So I'll just eliminate the other ones

00:11:15   just make it the strongest setting. Stuff like that would reduce user confusion in the

00:11:19   beta. I rearranged major parts of the interface during the beta. The directory was dramatically

00:11:25   changed and added to during the beta. I mean, so many things in the interface, so many changes,

00:11:30   so many wording of microcopy in the interface and everything, so much of that was improved

00:11:35   simply by asking people like, "Hey, what do you think of this?" and watching what

00:11:41   they said and seeing what they got and what they didn't get and what they misunderstood.

00:11:45   Under the Radar this week is sponsored by Imageix.

00:11:48   I-M-G-I-X dot com slash U-T-R.

00:11:51   Imageix is basically hosted image processing and image resizing.

00:11:55   So you kind of give them like a back end source of images.

00:11:59   Whether it's your web server, an S3 bucket, or even just arbitrary URLs that you sign and have them process.

00:12:05   Then you can just serve their URLs for those images in your apps, on your websites,

00:12:10   anywhere that you need an image served over HTTP.

00:12:13   and you can do real-time processing on that image

00:12:16   just by URL parameters to their service.

00:12:18   So I use ImageX, I used it for a while

00:12:22   for overcast thumbnails.

00:12:23   It is a fantastic service for just basic things

00:12:26   like resizing, you know, like all I need to do

00:12:27   with overcast thumbnails most of the time is resize them

00:12:30   and serve them over a fast CDN.

00:12:32   And it does that flawlessly.

00:12:34   I have no complaints about that at all.

00:12:36   But also what it does is a little more fancy stuff,

00:12:38   like for instance, you can serve, you know,

00:12:40   automatically serve different DPI to different screens.

00:12:43   So like if you have a device that has a retina screen

00:12:46   versus one that doesn't, it can automatically serve

00:12:48   the right DPI to that to not waste bandwidth

00:12:50   or to not look bad.

00:12:51   You could automatically serve things like the WebP format

00:12:55   to devices that support WebP, things like that.

00:12:57   There's all sorts of great stuff you can do automatically.

00:13:00   And then also you can actually adjust the images

00:13:02   by using those URL parameters.

00:13:03   So you can do things like change the colors,

00:13:06   crop them in different ways, rotate them, add annotations.

00:13:10   I mean there's so much you can do with this.

00:13:12   Pretty much any kind of like image filtering task

00:13:14   that you can do, so much editing technique you can do here,

00:13:17   just by changing URL parameters.

00:13:19   And it all runs on their proprietary system

00:13:22   that is all like GPU accelerated.

00:13:24   It is so fast, I've never seen an image processing CDN

00:13:27   that works this quickly and that's why I use them.

00:13:29   ImageX's API is very easy to use.

00:13:32   I just wrote my own thing myself to do it

00:13:33   in like one function.

00:13:34   But if you want any other kind of library support,

00:13:36   they have tons of libraries for different languages,

00:13:39   including one for Swift from the developers over at Hodinkee.

00:13:42   So check this out, imageix.com, that's I-M-G-I-X.com/UTR

00:13:47   for Under the Radar.

00:13:48   Thank you very much to Imageix for sponsoring our show.

00:13:51   - Once you're out of this beta phase,

00:13:53   like you've gotten all this good feedback from your beta,

00:13:55   then you have the interesting thing

00:13:57   of how do you transition to feedback

00:13:59   from customers more generally?

00:14:01   So you're kind of, you're past this point where,

00:14:04   fair enough, you've gotten all this great feedback

00:14:05   from a small group of people.

00:14:07   You open something up, you put it out

00:14:08   a broader update to lots of people.

00:14:12   And then things get really interesting, or at least complicated, because suddenly you

00:14:16   have lots and lots of customers who all have different visions for your app, all have different

00:14:22   goals for your app, and just by the volume of the virtue of having so many numbers, hopefully

00:14:27   your app is going to have thousands, tens of thousands, hundreds of thousands, millions.

00:14:33   You're going to have such a wide and varied user base at a certain point that the feedback

00:14:38   you get and the way you collect and manage that becomes like an engineering problem in

00:14:42   and of itself. It's something that I've over time had to kind of wrap, maybe become more

00:14:48   comfortable with the understanding that I'm never, A, I'm never going to make everybody

00:14:53   happy. Like that's just a given. Like right off the bat, if you ever are kind of trying

00:14:57   to build an application catering to everybody, you're going to end up building like a terrible

00:15:02   application because you just can't do it. You're never going to make something that

00:15:07   everybody happy, but you still are going to get a lot of feedback. And that's a good thing.

00:15:11   When you get feedback from a customer, they send you an email and say, "Hey, I love the app. I wish

00:15:16   it did X." That's a good sign. That means they like the app enough to open up their email client,

00:15:22   then write down something thoughtful, and it's a big enough part of their life that they see it as

00:15:27   something that could be better, could more fully meet their needs, and that's a good thing.

00:15:33   But I've definitely gone down the rabbit hole many times where I'd look at that feedback

00:15:38   and be like, "Oh yeah, I should do that, I should do that, I should do that."

00:15:41   And you can end up with a product if you kept saying yes to every bit of that feedback.

00:15:46   Like by version two or three or several updates down the road, your app is going to look nothing

00:15:51   like what it really was.

00:15:53   Especially for a smaller shop, what makes my app good, typically, is their simplicity

00:16:01   and the design around being really accessible, because I can't build big, monolithic, massive

00:16:07   structures because I'm just one guy. I have to always be fighting that tension. And so

00:16:12   typically what I'll end up doing is I'll say, "Hey, thank you for the feedback. I appreciate

00:16:16   it. It helps inform my future decisions." But I never say, or very rarely will say,

00:16:22   "Yes, absolutely. That's a great idea. I will definitely do that. It'll be in the next update."

00:16:26   it's something of course that I'm already working on, but being able to say no to people

00:16:31   was something that I definitely had to learn. It was something that I really struggled with

00:16:35   early on. How do you deal with feedback from the more general public to your apps?

00:16:41   You have to consider when you get feedback. When somebody is asking for a feature or asking

00:16:46   for a change, it's easy to look at that and say, "Oh, well, if I can add this feature

00:16:51   or if I can change the app to work in this way, then I will get X number of people that

00:16:58   will be happier with the app or that might buy it who wouldn't buy it before. If you

00:17:02   keep following the trackpad, like you said, it's very easy to basically have the Microsoft

00:17:06   Office 97 toolbar of app features, you know, to have this giant wall of features, really

00:17:12   massive settings areas and tons of just complexity and burden in the app. And that can very easily

00:17:20   overwhelmed not just an independent developer but also the users who have to see all those

00:17:24   options and don't understand them or might configure them wrong and not understand how

00:17:27   they got there. And so what you have to consider when you have people saying, "Oh, if only

00:17:32   it had this feature, I would be happier," there are many people who are already happy

00:17:36   with the app the way it is. And if you add things to it or if you change the way things

00:17:41   work, they might become less happy with the app. And so that's always been a very tricky

00:17:46   balance for me with Overcast because when I made Overcast it was in part in response

00:17:51   to what I was seeing from so many podcast apps at the time which was just so much complexity

00:17:56   in the interface and the settings and everything and I wanted to make something simpler. A

00:18:02   lot of people use Overcast because it was simpler at the time. And now there's a lot

00:18:07   of great podcast apps now, many of which are that simple. But at the time that was a unique

00:18:12   selling point for Overcast and I never want to ruin that. And not only for myself and

00:18:19   for my customers but also just for the quality of the app. If I add too many features the

00:18:24   app gets worse because it's harder to navigate, it's more complex, there's more edge cases

00:18:27   that I might not be able to test as reliably as I test the core functionality. It's a

00:18:31   very tricky balance. In 2.0 I added streaming and I thought it would be amazing if you could

00:18:38   just tap any episode and before tapping an episode would just download it if you didn't

00:18:43   already have it downloaded and you'd have to wait for it to download before it would

00:18:45   play and in 2.0, well now I have a streaming engine so if you tap on an episode now, I'm

00:18:52   just going to start playing the episode, just start streaming it and that'll be amazing

00:18:56   and to me it was amazing but the number one feedback I've gotten for 2.0 has been how

00:19:03   do I turn that off and just go back to the old way of doing it because I want to just

00:19:06   is go download a bunch of stuff.

00:19:08   I don't want to start playback immediately.

00:19:10   Now downloading things requires two steps.

00:19:12   You have to tap the info button and tap download.

00:19:14   Now I've made the way that people used to do it

00:19:17   a little bit harder because I thought

00:19:18   the new way was better, but not everybody thinks so.

00:19:21   And so now I have to weigh this decision of like,

00:19:23   well, do I add another option for that?

00:19:26   Do I change the interface to be more like

00:19:28   kind of like the way when you tap a tweet in Tweetbot,

00:19:31   rather than going directly to something,

00:19:33   it expands a little button panel below it.

00:19:35   I've thought about maybe doing something like that.

00:19:38   Now I have this problem I need to solve.

00:19:40   And no matter how I solve it,

00:19:42   if I leave it the same as it is now,

00:19:44   or if I add a setting to just toggle

00:19:46   the old behavior back on,

00:19:47   which I think is kind of the worst way of doing things,

00:19:49   or leave it the way it is now,

00:19:50   in which case somebody's angry or the app is slightly worse,

00:19:53   or I can do the Tweetbot button row thing

00:19:56   when you tap an episode cell,

00:19:57   which will anger the people

00:19:59   who like the streaming immediately approach,

00:20:01   'cause now I'm making that two taps for them instead of one.

00:20:04   So none of these are perfect.

00:20:06   And that's the thing, when you're facing

00:20:09   app design decisions like this,

00:20:11   and when you're dealing with people's feedback,

00:20:12   nothing you do will be perfect.

00:20:14   Nothing you do will satisfy everybody.

00:20:16   And so you basically just have to fit,

00:20:18   you kinda have to develop a sense yourself,

00:20:20   and you can see the results too,

00:20:22   but you kinda have to develop a sense yourself

00:20:24   of what will probably please the most people

00:20:28   and result in the best app.

00:20:29   I feel like it's relatively counterproductive

00:20:33   to think too much about what were people accustomed to before because all your new customers just

00:20:39   see the new app. And the app as a thing, the app as a concept is what it is today, not

00:20:46   what it was two years ago. And so even as you're bringing your customer base forward

00:20:51   through updates, I always think it's way more important to have a better app today

00:20:56   and a better app for tomorrow than it is to please everybody who wanted everything done

00:21:02   done the old way. So as I'm weighing this feedback about overcast streaming versus downloading

00:21:06   when you tap on the thing, I'm not really considering, you know, do I give that option

00:21:11   to people to just toggle it back the way it was before? Because that to me is like losing

00:21:16   the quality fight because that is just adding another option that new people will go into

00:21:20   the app not knowing or caring what that does. If they accidentally turn it on, the app will

00:21:24   start behaving differently and they'll think it's weird if they don't remember how to turn

00:21:27   it on. So I'm not really considering that option. I'm more considering like probably

00:21:32   doing the Tweetbot button row thing instead,

00:21:34   because I think overall, if I was starting from scratch,

00:21:37   now that I have many different things you can do

00:21:40   on an episode, rather than just tapping it to download it,

00:21:42   that is probably the best approach,

00:21:44   so that's probably what I'm gonna do,

00:21:45   because I'm thinking about what will make the best app

00:21:48   if somebody looks at it for the very first time,

00:21:50   not how do I please everybody throughout history,

00:21:53   because not only is that not good for app quality,

00:21:57   but it's impossible.

00:21:58   - And I think it also speaks a little bit

00:22:01   one of the other traps that I know I've run into a lot with feedback is the trap that

00:22:07   it's very easy to overweight the feedback you get proportional to the size of your user

00:22:14   base.

00:22:15   So the only people you hear from are the people who are typically very upset or very happy.

00:22:23   And the entire middle of your user base, which is probably in many ways the more important

00:22:28   group of your user base, you hear nothing from.

00:22:33   I've definitely fallen into the trap several times where I'll get a feature request once

00:22:38   a week for six weeks from six different people.

00:22:45   And because it's happening at this sort of interval, in my mind it's like, "Oh, wow,

00:22:49   people areā€”can keep asking for this.

00:22:51   This must be really important."

00:22:53   But then you take a step back.

00:22:54   It's like six people have asked for this feature.

00:22:59   The app has 1.4 million users and six people have asked for it.

00:23:04   It's very hard to not conflate those things and make it feel like, "Wow, this is really

00:23:09   important," because the only people you hear from, there's this self-selection for people

00:23:15   who want things changed, whereas all the people who want status quo, or at least who are happy

00:23:21   with what it is, you never hear from.

00:23:24   And that's a really funny dynamic that you then have to balance with and get comfortable

00:23:28   with to say, "Okay, is this..."

00:23:32   What actually is a lot of feedback?

00:23:36   Has like 10% of my user base reached out to me to ask me for a feature?

00:23:42   If they do, that's probably worth paying attention to.

00:23:44   I've probably never gotten feedback beyond every now and then where you'll accidentally

00:23:49   ship a horrible crashing bug, in which case, fair enough, you hear from a lot of people

00:23:53   saying "fix the crashing bug" and that's good feedback I will definitely fix.

00:23:58   But in general, you just kind of have to go with it.

00:24:02   And I think where to wind this down is to focus on, in order to build software, I think

00:24:07   you have to be able to have a vision for what you want the app to do.

00:24:13   You're trying to build this vision, it's a bit abstract, but you want to have someone

00:24:19   to know it's yours, they know what the app is, it has a personality.

00:24:23   that's the right way to say it. You're trying to create this persona that your app has,

00:24:28   and doing things that ultimately will be counter to that persona are probably going to be counterproductive.

00:24:34   When you get feedback that are people who are like, "I like your app, but I want it

00:24:38   to be something else," they really want your app to be a different person, to have

00:24:41   a different personality. And you have to then build the confidence even to say, "No, this

00:24:49   app is about this. It's about simplicity and focus and ease of use. Or it's about, maybe

00:24:56   it is a really strong, complicated, advanced thing, in which case it's like, yeah, every

00:25:01   feature I can think of, all the settings, all the options, the more the better. But

00:25:06   you need as a developer to have that confidence to be able to say, this is what my app is,

00:25:10   this is the way it should work, and to then just be able to go with that and make that

00:25:14   work.

00:25:15   Sounds good. Alright, I think that's it for this week. Thank you very much for listening.

00:25:19   Please rate us in overcast, or please recommend us in overcast, and tell your friends about our show, help us grow.

00:25:24   And we'll talk to you next week. Bye.