Episode 401 | Why You Shouldn’t Listen to Your Customers (And What You Should Do Instead)

Rob: In this episode of Startups For the Rest of Us, Mike and I talk about why you shouldn’t listen to your customers and what you should do instead. This is Startups For the Rest of Us episode 401.

Welcome to Startups For the Rest of Us. The podcast that helps developers, designers, and entrepreneurs be awesome in building, launching, and growing software products whether you built your product or just thinking about it. I’m Rob.

Mike: And I’m Mike.

Rob: We’re here to share our experiences to help people with the same mistakes we made. To where this week sir?

Mike: Well, I submitted the Bluetick Zapier integration to Zapier, to see about promoting it through their public availability process. I’ve already heard back from them. I’ve got a list of things they want to see changed to conform to the standards that they kind of set for everybody to maintain consistency between Zap. I got to go back, and look at those, and make some changes and then publish it but things did not seem to be too terrible.

Rob: Nice, that’s super cool man. Once that goes live, it’s nice to be able to refer customers to Zapier when they’re trying to be something in your app that you haven’t built yet—when you don’t have an integration. That was always the useful piece for us.

Mike: Yeah. Well, the thing is like the Zapier integration is already there, it’s just invite only and there’s a link inside the app where they can click on that link and go over there. The difference is it will be public so that when people are searching inside Zapier to see where there is a Bluetick Zap, they’ll be able to see it but I’ll have them to login in Bluetick first. At that point, they can add it into their account but I guess you can’t ready do anything without an API key anyways.

Rob: I remembered when Zapier promoted HitTail early on we got a bump and then Drip, I remember it was—I think it was more or less, but it definitely in the early days when you’re really scraping and clawing for every customer. I think that you get included in the email newsletter, tweeted out, I think, and every bit helps at that point. Even if you only get a couple new customers from someone hearing about it, it can move the needle for you in the early days.

Mike: Yes. I’m hoping to see that at least through the initial process in the next couple of weeks or so. I don’t know how long it has to be in their beta for before it ends up being live. I think that they said that—when I was looking through the specs—they said, “You should have at least one person using each Zap and you need to have at least 20 active Zaps,” or something like that. They’ve revised their stats page to see if you can actually see more about who’s using it, how many people are using the different Zaps that you’ve published or made available. I’m up to like 400 active or something like that, and only need 20.

Rob: Oh, yeah. That’s a lot more than we went live with it. That’s cool. segment.com will be another one. You’ll probably want to do it at some point—integrate with them. That’s another big hub to get not only the promotion but it’s just nice because people are going to want to create reports or do things with the data that you’re just not going to have the time to build and referring about to Segment, it can help there.

Mike: Yeah. Ultimately, I’ll look into that one as well. The other thing I’m in the middle of right now is kind of specking out with the public APIs going to look like. Everything in there is all used internally inside the app and then I have a specific endpoint that’s used solely for Zapier and then next step is to really kind of take that and say, “Okay, when are we going to make it public?” because there’s a couple of customers who have wanted to use a public API but I told them to kind of hold off and just use Zapier. I had a call this morning with somebody about what the specifics things they needed from a public API from us are. There’s at least one other customer that I want to talk to who I know they do a lot of extensive development work and are using Bluetick as the backend CRM for their entire company. They got several mailboxes attached and they want to be able to use that functionality inside there. I definitely want to have a conversation with them first before I start making anything publicly available.

Rob: That makes sense. For me, I am in California when this episode airs. We’re heading there for about two weeks. We’re going to see different groups of family in different areas and my sons are going to a cello and violin camp—Suzuki String Camp in San Francisco. It should be fun. It’s where I’m from. It’s nice to get back there once or twice a year to kind of see the family and all that.

Mike: Cool. Hopefully you won’t be selling the company while you’re out there.

Rob: I know. That’s the old story right? That I was signing the final docs at the cello camp a couple years ago.

Mike: Getting dirty looks.

Rob: Indeed. Dirty looks from the instructor.

I titled this episode Why You Shouldn’t Listen to Your Customers and What You Should Do Instead. Realistically, it’s about deciding which feature request to build and which not to—not even feature request, just deciding what to build in general. There’s always the popular meme of like launch soon and then your customers will tell you what to build.

I’ve seen struggles with that. Number one, often times your customers don’t know really what they’re trying to do or they’ll tell you to build things that you shouldn’t build but you should do it a different way. Or they’re just going to tell you to build your competitor. They’re going to say, “Hey, I’ve used Infusionsoft and it has these features and you don’t have them. Can you just build this, this, that, and this?” We have these all the time in the early days.

Remember, early Drip user wanted a mobile app. He wanted kind of like an iOS and an android app. He wanted these very specific reports that made sense in Mailchimp but wouldn’t have made sense for Drip to have. He’s not a software person, his idea was just to have this be Mailchimp but with a cleaner interface and that wasn’t what we wanted to build.

It’s really easy when you’re getting multiple feature request per day. I left Drip a couple of months ago, I think we get 150-200 feature requests per month. It’s a substantial line and at a certain point you have to figure out how you’re going to evaluate what to build and what not to build.

I see these like there’s three types of feature request. The first type is—I humorously named this, the crackpots—but it’s kind of odd ball request that you know that there’s no chance you’re going to build, that kind of come out of left field. Some examples of those are, people requiring you or asking you for feature that would require you to build an entirely new product. For example, “Why can’t I use your email service provider to publish blog posts on my WordPress site, or to record my podcast and publish them, or to do all of my social media marketing?” Some people would ask us to, “You do email, I want you to do Facebook, Instagram, Twitter, and do these integrations.” It’s not that we would never build those but people were asking these when we didn’t even have very basic features. In the first year or two, there were folks who were asking for these. It’s just like, “Yeah, I know. There’s no chance we’re going to build that.”

The other one is like asking you to clone your competitors. Like, “It’d be great if you could add a shopping cart, and CRM, and lead scoring.” Basically be Infusionsoft. I was like, “Nope, that’s not our goal.” Or finally, features that are the opposite of your product strengths. I remember someone saying like, “I like that your UI is so streamlined but can you add all these options to fit my rare and unique used case?” They didn’t used those phrases but that’s the kind of stuff that could come across.

Crackpot may not be the best name for them but they’re really the ones that are obvious to you that you shouldn’t build them.

Mike: I think the really nice thing about the crackpot request is that they’re usually very easy to decide what to do about it. You can just say, “No, we don’t do that.” Or, “Here’s something you can sign up for over here and they do that but we don’t.” It’s just very easy to identify them and say—you have to be polite about it—but just say, “No, that’s not something we’re going to do.” Or, “It’s on our roadmap to look at but it’s going to be probably at least six months to a year. It’s not a good fit for you especially if you need it that right now.” That’s the one nice thing or the saving grace about these types of requests because they’re easy to dismiss.

Rob: Yeah, that makes sense. The three types are the crackpot, the no-brainers—which you should build—and the in-betweens. Unfortunately, the crackpot ones are maybe, I’m guessing like 10% of feature request. It’s really a small amount but you’re right, having that certainty is a good thing.

Then, the no-brainers which are the ones where it’s almost like, “Why didn’t I think of that?” If it’s not already on your feature list but you realized, “Man, that’s a really good idea!” I remember Josh Earl, he runs Sublime Text Tips. He also works with John Sonmez at Simple Programmer. He reached out to us in some of the early days of Drip and asked if there’s a way to go back and retroactively add a tag to readers based on things they clicked on the past. It was like, “That was a really good idea.” It wasn’t a huge amount of work at that time. To me, that was like a no-brainer one that both me and Derrick it was like, “Why wouldn’t just we build it?” and we did. I think we are the only tool that does it as far as I know. If you don’t have the kind of the trigger logic and our competitors at the time they click, you cannot go around retroactively tag people. I’ve used this feature all the time. It’s one of those things where if I were to have stop using Drip, I would sorely miss because I will frequently want to go back and do it.

The crackpots are good because they’re definite nos. The no-brainers are good because they’re definite yeses. It makes it a lot easier but I would guess that in total, probably less than a third of your feature request will fit into one category or the other.

Mike: Yeah, for Bluetick, I can’t recall something off the top my head where it has been just a completely crackpot feature request. Most of them have been pretty close to what should be built or what is in kind of on the roadmap but I don’t remember the last time I had something came up that was just out of my field and we’re never going to build.

Rob: Yeah, that makes sense. Then, the third type is the in-betweens. They’re the ones that you actually have to make judgments calls. That’s really what, I think, the bulk of today’s episode is about. It’s about deciding which features to build when customers request them. There’s this whole other path like you’re going to build features that no one requested. If you’re not, then you’re really not innovating. You’re not pushing your product past other competitors. I’m not saying you have to do this but I believe—Derrick and I always had a pretty strong vision for Drip and we were definitely building things that no one was requesting. But, if people are requesting features, I have three questions that we used to ask ourselves. I think that, as a listener to the show, it’ll be helpful.

The first question is ask yourself, what is the used case for this feature request? In layman’s terms, what problem are you trying to solve? I always try to take a step back and people would say, “Hey, can you add a checkbox on this page to modify the setting?” And I would sit, think, and say, “Why do you want to do that?” and almost, in probably 80% of the cases, they didn’t actually want a checkbox there. There was some other party app that wasn’t doing what they wanted and they could go on and use a liquid tab for it. Or, we could add a report that would actually help everyone and that would require them to not need that checkbox.

Often times, there was an alternative way to accomplish this already in Drip or the optimal way to achieve it for everyone to get value—like all the customers to get value—was different than what the person has suggested. Because remember, for the most part your customers are not software people. They don’t know UX, they don’t know apps, they don’t know how to think about what to build to keep a product simple. If you just listen to your customers, you can build a monstrosity.

Mike: One thing that I find very helpful is when you get a support request or a feature request like that, ask them what it is they’re trying to do. That way you’re not guessing what it is that they’re trying to do. Your example, the checkbox, you’re trying to read between the lines to see what it is that they want or what they’re trying to achieve. Sometimes, it’s just not even related to anything that you have or it’s very situational specific inside their business. I find it blatantly asking, what is it that you’re trying to achieve or what problem are you trying to solve—that is really helpful.

Rob: The second question that I used to bring up all the time when someone requested and we start evaluating is like, will more than 5% of our user-base use this feature? More than 10%? More than 20%? As a founder, you have a pretty good feel for your customer-base especially in the early days. It’s just asking yourself, will a lot of people get a value out of it?

The number is our return, maybe your market as well. If at least 15% of people use it then it’s good. Or maybe it’s such a marketable feature that even if only 5% of your users use it but it’s an aspirational or a checkbox feature something like split testing in email marketing apps. We found out that a lot of people requested it and when we built it into campaigns, almost no one uses it. It’s like 1% adoption. But, being able to say that we can split test in campaigns and have it on the marketing side and talk about it during sales calls, it is something that’s just important. Honestly, the Visual Email Builder—I think it’s in beta in Drip now, went live after I left—I bet a lot of people won’t use it. But it is a checkbox item that when, especially larger customers, want to sign up and they’re going to sign a one year contract, they want to make sure you have this, this, that, and this because your competitors have it. At that point, sometimes you have to make a choice of like, “Well, only a fifth of the customers are going to use this thing but it’s going to get us a lot more business.”

Mike: I think a lot of times you’ll see people going if they’re evaluating different products, they’ll compare them to each other and try to say, “Okay, what features does this have and which features does that have?” And something they may not even necessarily use, the fact that it exist and they could use it if they wanted to, is a good selling point. But I have mixed feelings on that just because sometimes people will use it just to make a decision versus wanting to use it.

This is kind of where my hatred of this process comes in but I will see people deciding to implement those features. The vendors will implement that feature and the feature itself just completely sucks but the only reason they built it was so that they can create like that checkbox on their website to say, “Hey, we have this feature.”

Rob: That used to kill me, actually. We had a few competitors build really crappy versions of split testing that were actually harmful. They were not statistically significant. I was face palming because it’s like what they say, they can say they a have split testing but it was a [shit 00:14:27] implementation of it. It’s actually going to be a detrimental to their customers. I could never bring myself to do that in a product like to build something crappy. As a result, stuff for us probably took longer to build than some competitors.

There’s one other trick we used a few times as well and it was in the early days only. It was a larger customer who’s revenue would move the needle. We did build a couple of features that we basically hid in the UI except for a handful of people. Literally, like less than 1% of Drip customers would be able to see this feature and it was a feature that really we didn’t want to build. We didn’t believed it should be in a product but the revenue at that time was just something we couldn’t pass up. We didn’t do it a lot but one of the bigger reasons we didn’t want the feature in it is because it would add more checkboxes and dropdowns—just negatively impact the UX, in essence. Most people weren’t going to use it anyways and so that was a choice to just kind of—we had a feature flag and we don’t want to go into a few accounts. There’s still are a few features in Drip to this day that really only appear for a small subset of customers.

Mike: I think I have access to a couple of these features.

Rob: I bet you do.

Mike: That’s interesting. I did the same thing with Bluetick where there are certain features that you can’t even use inside the app but I have like a backend toolbox application. It allows me to either toggle them on or off or do different things inside of somebody’s account where it achieves what they want but is not something that they could actually do inside the app.

Sometimes, I’ll use that to either test it out in kind of production. For example, one of them was a Bcc field where people like, “When I send emails out, I want to Bcc this other email address.” For a long time that was, you could do it inside the app but there is no way in the UI for the user to see, that it was actually happening. They had to contact me through support and I would actually put it into a field in the database that would make it work. Now, it’s actually ruled out and everybody can use it. I use this kind of mechanism for sort of testing it out with live data to some extent.

Rob: Yeah, that’s really good way to do it. We did that. With any feature roll out that we thought was a risk at all, we would totally feature it temporarily and then slowly enable it for more and more people. Then, in this case, where I’m talking about actually building a feature and never rolling it out to everyone, that was something again, we did that in the early days when we needed to when we’re being scrappy.

I meant to say this at the beginning of the episode but this is actually, this outline is from an unpublished blog post of mine. If I ever get around to finishing that blog post, you may see this on my blog as well. I have additional examples. I can obviously go into more, more things in a 2000-word blog post than we can cover in 25 minutes here. I’ve also considered doing a talk about this. Derrick Reimer, my Drip co-founder did an attendee talk a couple of years ago in Drip on this topic. We have similar takes because we worked together on it. But I feel like we can definitely, potentially be a full 30 or 40-minute talk.

With that in mind, the third question that we used to ask ourselves a lot when we get feature request is, “Does this fit with my vision of what the product should be?” Going back to an earlier example, since Drip was a competitor especially in the early days, it was compared a lot to Infusionsoft. We would get a lot of request to add shopping cart and landing pages and affiliate management—really, things that we didn’t want to build on the product because we didn’t view Drip as, we want to integrate with best in class solutions rather than try to be everything to everyone. We felt like the bloated software just wasn’t, we couldn’t see an example of it in a space where adding all these features has helped anyone. It always makes it a crappy experience.

The fact is when you’re bootstrapping, there’s an opportunity cost. Every hour you spend building features, that’s an hour that you don’t spend becoming the best at what you’re doing. That was where we decided to focus on integration. What’s nice is the integrations were platforms that people were already using like Unbounce, and Shopify, and Stripe, and Gumroad, Leadpages, and PayPal and on and on. We had 35 integrations within probably the first year of being live. It was a nice lift for us in terms of actually getting new customers because all those integrations are—they’re promotional avenues if you can get folks to promote you. But they just make the product more sticky.

This whole ties in the question coming back to it is, “Does this fit my vision of what the product should be?” We always had a pretty strong vision. We want to be a best in class email marketing or marketing automation tool. Therefore, a lot of the request that came through is like, “Huh, yeah, that doesn’t fit with where we want to take the product. We’re just going to have to say no.”

Mike: The part about this, knowing what vision you have for the product is one of those things where it’s a little bit more abstract. You kind of have to step back from the product itself, away from the features and away from the dirty details of how things are implemented and say, “What is the type of person that you want to use this? What is it that you want to empower them to be able to achieve?” Because otherwise, you may have this vision for your product but people come in with feature request and I say, “Oh, this is why I want to do x.”

If it’s one of those in-between things, it could change or alter that vision a little bit and shift it in one direction or another. Sometimes those shifts in direction will isolate or exclude certain types of people as well. It’s something to be a little careful of because your vision can change over time based on the feedback and the feature request you’re getting in. You can easily end up going down the road where you’re tracking the wrong types of people—you’re tracking more of them—but it’s the wrong type of people. They’re having a bad experience because they’re not using your tool correctly or in the way you envisioned and you’re not catering to them anyways. It’s a very slippery slope you can end up on if you’re not very careful about how you’re making those decisions.

Rob: Yeah, that’s a good point. Your vision will likely change over time. In the early days of Drip, my vision was completely different than what Drip became. That was okay but you can hear it was a painful process to make that decision and kind of switch the vision. You can hear it and if you go to startupstoriespodcast.com, there is a 90-minute audio Derrick and I recorder over, I think about nine months. I edited 10 hours of audio down to 90 minutes and you can hear the agonies we’re going through of like, “What should we be building? What actually are we building?” early on. It was one thing then it became essentially an ESP with automation. Decision process is what makes startups hard. We were just trying to find product market fit and therefore our vision had to follow something that was valuable to people.

In the early days, it wasn’t valuable enough. People were willing to pay us but they were not willing to pay us the $49 a month that I want to beat the minimum price point. We had to follow that. Then, once you get past that though, once you start scaling up and growing and you have product market fit, I think it becomes so, so much easier to know what you have, what you’re building, what you should build. It really does get easier. It’s that first year or 18 months that’s really hard to figure out when you don’t have a large customer base and you don’t just have that gut feeling of what you should build based on all your experience.

Mike: Yeah, I totally agree with that. If you’re in a position where you don’t have, I’ll say, a critical mass of users yet, then take a lot of this advice with a grain of salt. Definitely take the feature request with the grain of salt because the decisions that you make now are going to change things in the future and draw or repel certain types of users. That will influence, ultimately, how the product is received in the market and what other features you end up developing.

Rob: I think the thing to remember is you’re always going to get way, way more feature request than you can possibly build. Even when you have 10 users, people are going to be requesting things. As a bootstrapper, time is your most valuable resource. You’re just never going to be able to build anything you want. If you could build everything you want, I don’t know. I questioned if the product would get bloated too fast. It might actually be a benefit that you are time-constrained because I think in the early days, you’re going to want to build anything everyone requests. If you’re able to do that, I think you can potentially build a really crappy, bloated, product.

Mike: Yeah. Definitely the danger in building this many feature is you like is the fact that it makes the interface much more difficult to work with. You have to do a lot more design work with where different things are in the app. A lot of times, as you add features, you have to restructure or re-architect either the different parts of the application itself or the UX which forces underlying changes as well. You’re basically bolting things on after the fact. I think that’s why a lot of people, specially newer developers, tend to say, “Oh, I’d like to rewrite this app from scratch because now we know what we want to build based on the features that we have.” But it’s really tough to do that unless you’re in a situation where you can completely rebuild the app.

I think that David, DHH from Basecamp has talked about this a couple of times where they’ve rebuilt Basecamp from the ground up. As much as I disagree with that decision, I would disagree with it for me and in our situation that kind of makes sense because they can essentially abandon the previous version and say, “Everyone who’s using this, you’re still going to get to use it but anyone new is going to sign up and they’re going to use this newer version and they get to work on new stuff.” But not everyone is in the position where you can basically halt all development on your current app and still be making millions of dollars a year from your current customer bases.

Rob: Yeah. That’s rewriting app—that would be a whole nother episode. I think Basecamp is such an anomaly and such an edge case that very, very few companies will achieve using them as an example is tough just for that reason, because they got in so early and grew so fast. But you’re right. Rewriting an app. I’ve seen several startups do that and I always cringe pretty hard when they talk about doing that because it’s not going to solve all your problems the way you think it will. It’s going to keep you just frozen for six months while you try to rebuild everything.

Mike: Yeah. I think the fallacy there is that you understand how the different pieces fit together so you can reengineer all the stuff to solve your current problems but even after you’ve done that, let’s say, that you can do that in a hour and everything’s completely restructured. Yes, it only cost you an hour but you’re still going to end up getting more feature request that you’re still going to have to bolt on to the application afterwards. At that point, you’re retroactively architecting new features into the architecture and how the UI and UX is all laid out. It just will not solve every single problem that you have. There’s certain problems you’re just going to have to live with.

I think that about wraps it up for today. If you have a question for us, you can call in into our voice mail number at 1-888-801-9690 or you can email it to us at questions@startupsfortherestofus.com.

Our theme music is an excerpt from We’re Outta Control, it’s by MoOt used under Creative Commons. Subscribe to us in iTunes by searching for Startups For the Rest of Us and startupsfortherestofus.com for the full transcript in each episode. Thanks for listening. We’ll see you next time.