Under the Radar

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.