In this episode of Startups For The Rest Of Us, Rob and Mike talk about how to respond to customer suggestions. The topic was inspired by a Tweet by Ken Wallace, the guys give six approaches they use to tackle this issue as well as some additional thoughts.
Items mentioned in this episode:
Welcome to Startups For The Rest Of Us, the podcast that helps developers, designers and entrepreneurs be awesome at building, launching, and growing software products. Whether you’ve built your first product, or you’re just thinking about it. I’m Mike.
Rob: And I’m Rob.
Mike: And we’re here to share our experiences to help you avoid the same mistakes we’ve made. What’s the word this week Rob?
Rob: Things are going good. We’re in the midst of interviewing and talking with founders who have applied to be part of TinySeed. As I mentioned before, there’s quite a few applicants to go through, and we’re having a lot of conversations and we’re coming up on our mental deadline of when we want to get everybody on board. We have started making offers to founders as things come together and as it becomes obvious that we’re a mutual fit for each other. That’s the thing, it’s not just do they have the chops or do they have the traction to get in, but are we going to be able to help them? Are they fit for us? I think that I’m trying to do as much evaluation of them as I’m trying to do of us.
We’ve had some folks apply who have traction but it’s like, “I just don’t know that we can help you.” It’s businesses that are perhaps outside of our expertise, outside of our mentor’s expertise. All that said, we have had five companies accept offers which feels really good, just to start making our way towards that. MicroConf is coming up here real soon. It’s about a week-and-a-half away from when we’re recording. I’m actually out in London the following week with the family. It just feels like there’s a lot going on right now.
Mike: Yeah, for sure. It’s interesting that you are evaluating whether or not you can help them, not just whether or not they have traction. It’s interesting seeing some of the questions, for example, that come in to people asking about whether MicroConf is a good fit for them as well. There are certain people who are just evaluating, for example, the station at the conference, like, “You really shouldn’t be going there because it’s not applicable to you or you’re not going to get the benefit out of it that you’re looking for.” I talk some of them out of it or talk them into the right direction. Some people is just not a good fit for it. Same thing with sponsorships as well. Some people will say, “I’m interested in sponsoring,” and I have to talk them out of it because it’s not going to do them any good, and I really don’t think that it’s good for us to accept sponsors where it’s not a good fit for the audience either.
Rob: Exactly. Are you in this for the long term or are you in it for a quick buck, so to speak. We could accept people into TinySeed that have, “Oh, you have tens of thousands of dollars of MRR,” but we’re not going to be able to help you that much. In the short term, that might be the right choice, but in the long term, they’re not going to get out of it what they deserve and what they should get out of it.
You’re just ding your reputation. Same thing with sponsors. You could sell a $5000 or $10,000 sponsorship, but if they don’t like it and they don’t get the value out of it, then you’ve caused yourself a problem to your reputation. Same thing running a SaaS app. Their customers will come to you and they could be your biggest customer. In the early days, a $500 a month deal is game changing for you when you’re doing a couple grand a month.
In the short term, that might be the right fit. But in the long term, if it’s not, it’s a real problem. I think that’s the thing. You and I have played long ball on so many fronts. Not only with the podcast doing 436 episodes, but with MicroConf talking attendees or talking sponsors out of it, with our apps, with Micropreneur Academy, with FounderCafe. I mean, we have turned away a lot of people. I actually think it’s a good policy to have.
Now, it means that the growth-at-all-cost mindset were not growing at all cost, because we’re not going to do it at the cost of our long-term relationships. I think that if you’re in this for decades, that it’s the right call to be smart about this, and to evaluate from both sides of the aisle so to speak.
Mike: I couldn’t agree with you more.
Rob: How about you? What’s going on?
Mike: Well, I have a upcoming webinar that I wanted to actually share with the audience. Remember probably three or four weeks ago, I had mentioned that there were some publications and stuff that I was going to be hopefully getting into, but I wanted to hold off on that. One of them that I want to share with the listeners is on April 29th at one o’clock. I’m going to be doing a webinar called Personal Email Strategies to Drive Traffic, Engage Leads, Close Deals, and More. That is going to be through hr.com.
I’ll link that up in the show notes, but I’ll work with them to put that on the calendar for them. I’d say it’s a big win just because of the size of their audience, but also working with anybody who’s got a 2-letter domain name. That’s interesting in and of itself.
Rob: Yeah. It’s just a URL that you’re doing your webinar at, it’s web.hr.com/u9vo.
Mike: Yeah, that’s just a short code, I’m sure.
Rob: We’ll link it up in the show notes if you want to do it.
Mike: Yeah, maybe we should. People have to remember that. Do you say U9VO or do we something special. I don’t know. Various conversations.
Rob: I mentioned that me and the family are going for my kids’ spring break, I believe, that we are headed to London for about a week after MicroConf. Sharon and I were thinking about putting together just an informal London bootstrapper’s meet up probably two hours on an evening. If you’re in London, I will be in London between April 1st and the 6th, head to robwalling.com/london and I have just a simple three-question Google form there that’s like, “What nights can’t you make it? What’s your name if you have one? What’s your email address?” That’ll be fun. We’ll put it together if it makes sense. If only one person responds, then maybe we won’t go to the effort of it.
I’m looking forward to it. I’ve been to London at least once. Trying to think if I’ve been twice, but our kids really wanted to go, because just of all the stuff these days. They read about Sherlock Holmes. They are fans of Harry Potter. Even Shakespeare, they have that familiarity. One of them was in a play with that. There’s just so much cool stuff there and we really haven’t taken the kids there or taken them to a lot of European cities. It feels like a good time to get out and go.
Mike: Cool. I almost went to London about probably four or five months ago, I think. I almost went there and then I realized I was in the wrong line and I would have gone out of the airport and into London itself instead of getting on my connecting flight.
Rob: Nice. That would’ve been fun if you missed your flight and then hung out in London. Saw the Eye and the Shakespeare Theater and all that.
Mike: Yeah. I’m sure that my connecting flight would have been thrilled with that.
Rob: It would have been a blast. What are we talking about today?
Mike: Today, we’re going to be talking about how to respond to customer suggestions. I say suggestions because it also incorporates feature requests as well. This can broadly apply across different types of businesses whether you have a SaaS app, or a downloadable app, or productized service, or something like that. We’ve talked about how to solicit feedback from your customers back in Episode 119, but it’s been awhile since we had a dedicated podcast episode about this. We’ll link up Episode 119 in the show notes.
The idea for this episode comes from a tweet stream that Ken Wallace had put out. Ken Wallace runs MastermindJam which you can find over at mastermindjam.com. I’m going to summarize a lot of what he said because he had hit a stream of 18 tweets. I’m going to summarize that a little bit and condense it. His basic thought process was questioning how to respond to customer suggestions. He said that for his business, customers tend to be entrepreneurs and transparency is big. It tends to lead naturally into, “Let’s dig into that.” For context, MastermindJam is a service that connects entrepreneurs with other entrepreneurs who are in similar types of businesses and lets them find other people who they wouldn’t otherwise normally find in order to form a mastermind group.
The question starts out where he’s offered a suggestion by a customer and he starts explaining why he does it in a particular way, what he’s tried in the past, and what he intends to do in the future. This approach worries him because there are times when he persuades the customer to agree with him and that’s where he thinks there’s a missed opportunity because he essentially talked the customer out of a particular way of doing something when they came to him with a suggestion.
Understand that there’s a lot of reasons why the customer might concede that point. They might be tired of debating the topic with him or they may leave the can they’re so entrenched in whatever the particular suggestion is. The person thinks, “Oh, I’m not going to convince him to change, so I’m just not going to bother,” or they don’t have the time and they just think, “Oh, this isn’t worth arguing over.” Its fundamental problem boils down to how do you know why it is that they agreed with you.
Rob: They may also agree because they actually agree and because he truly convinced them that it’s a better way. That’s another option.
Mike: Right but the lack of clarity there is what concerns him because if people fall into any of those previous camps where they didn’t necessarily actually agree with you, but they just say, “Agreed,” to move on the conversation or end it because they’ve got other things to do, then how does he know that? What are some recommended approaches to responding to that type of information?
What Ken wants to know is when a customer gives you a feedback or a suggestion like this, what should happen next in the conversation? What’s your response be and how should the conversation go from there? His belief is that if you just say something like, “Thanks for the suggestion I’ll take that in consideration. Where can I follow up with you?” it seems very patronizing. I think you chimed in and you talked about drilling into the five whys a little bit. I want to back up a little bit and take a look at a much broader approach to this.
Rob: Yeah, I would agree. He basically said, “Should I drive into the five whys?” The thing is, I actually started writing a response and it was more of a full-blown out like how I would handle it. I hate Twitter because it’s 280 characters. I eventually just stopped and gave in and said, “I’m not going to do that,” because we are going to talk about this for 30 to 40 minutes today and I bet we will cover it well but not even cover everything. To try to respond in a series of 10, 20, 30 tweets or whatever to truly summarize the nuance of this question, I felt like wasn’t going to going to do it. I just boiled it down to, “Yes, ask more questions. Thank them.” I tended to not commit to anything on the phone, but we’ll dig into more of that because you have a whole approach outlined here like a six-step process that I think is pretty worthwhile.
Mike: Let’s start going through these six steps. I think the first thing to do here is to mentally prioritize their suggestion and feedback. Categorize it and say, does it sound like (a) a problem they need a solution to, (b) an additional nice to have but not critical, or (c) this is a better way to do it. Essentially, an optimization of some kind. Really what you’re looking for is trying to figure out, is this something that is part of the experience or is it a new feature that they’re asking for? Are they trying to improve something that already exists or could exist in a different way or a better way, versus are they asking for something that’s fundamentally new. You have to drill into that and figure that out.
Rob: I agree. I think at a certain point, it can become kind of a gut feel. If you’ve talked to 50 customers, 100 customers, you do start to see repeating questions, repeating suggestions, repeating information. There’s a way to bucket them in your head of like, “Yeah, we know that. We’ll prioritize it,” or “Yeah, we thought of that,” and I would often say, “Here’s why we’re not going to do that,” but I guess that comes back to Ken’s point of, is that the wrong thing to do?
I think in my head it’s like, if you’re always trying to talk suggestions a customer that have suggestions, that’s a problem. I do think that there are going to be quite a few suggestions that come up that you’re not going to build and are not a good idea to build. Those are the ones where it’s not as much a debate but it’s a, “This is my vision for the product,” or “I’m not going to copy competitor features that doesn’t make sense,” or you’re going to have some good reasons that people who are not working day-to-day in your app or in your business, they’re not going to have because they’re not thinking about it all the time.
Anyways, I’ve skipped ahead in the thing. I think that for this first step, taking in the suggestion and trying to mentally bucket it early on can be helpful. Especially if you’re doing 5-10 calls a week, you’re having a lot of these conversations. It does help you to get some clarity as to how you talk about these things.
Mike: Right. I said that you should mentally prioritize, but I really meant categorize, or bucket like you had said, so just to clarify that particular piece of it.
The second piece of this is to start asking them questions and make sure that you understand their context and their point of view. They’re going to have different experiences based on their own life and their own business, versus the things that you do and see, because you have a viewpoint from inside the business whereas theirs comes from outside of it.
You also have to differentiate between the type of person they are where they are in your sales funnel. If they’re a prospect, is it a feature request? If it sounds something along those lines, you can ask them, “Is that something you need?” When you’re very early on in your business, what you’ll find is people will ask questions and they don’t necessarily care about whether or not you have a particular feature or not, but they just want to know. They’re curious as to whether or not that functionality or that piece of it exists.
A lot of times, what you’ll find is by asking that question, “Is that something you need?” they’ll just say, “No, I was just curious.” I found in cases where I’ve asked that question, it was for something that I knew was probably going to take 3-6 months to put together and they’re like, “No, I was just curious.” But had I gone down the rabbit hole and said, “Yes, we can do that,” and started trying to implement it, I suddenly pushed everything back by 3-6 months. You have to be very, very careful about whether or not it’s something that they absolutely need, versus is it nice to have?
One of the ways that I like to phrase this is to say something along the lines of, “Tell me more about that,” and as a follow up to that you can say, “What makes you say that?” When they give you a suggestion or they say, “You should do it in this particular way.” “Really? What is it that makes you say that?” It allows you to take that conversation and make it much more interactive.
Rob: Yeah. I love this idea of asking questions to dig in further to make sure you understand their context and their point of view. As you’ve said, digging into their context can show you that they were just curious. Digging into their context might show you that they are not a fit for you, that they should not, to our point earlier, they are not a good fit for your company, your conference, your SaaS app, your service, whatever.
I think having disqualifying questions that you could even come before this is a huge win in determining if someone is alternately a fit, as well as determining if someone is the perfect fit and that they might be suggesting something that you’ve never thought of before. That’s always a cool realization when you know that someone should get a ton of value out of what you’re offering and it’s almost like an epiphany. That’s why I said five whys when I responded to the tweet because to me, it’s not technically asking why, why, why, why, but it is asking a bunch of questions to be like, “What are you trying to accomplish with that? What does that mean? Where are you coming from with this? Blah-blah-blah,” just to try to dig in to really understand their true needs.
Sometimes you’ll find out it’s like, “Well, I know that my current tool, MailChimp, does that. I was just thinking if I ever wanted to use it, do you have it as well?” We got stuff like that back in the day with Drip and it’s like, “Cool. You have context of a competitor, you don’t use the feature today, is it a deal breaker?” “Well no, it’s not.” “Okay, but you would like it in the future?” “Yes, it’s on a roadmap.” It’s just digging into these things and not taking the face value is pretty important.
Mike: And a lot of that just gives you context for the feature data points that you can say, “I heard this from one customer. I heard this from 5, or 10, or 50,” and once you start hearing things over and over, it goes back to if you ask the question to begin with. If you didn’t ask, then it’s very easy to not get that information. You have to start drilling in as part of the second step to ask questions and make sure you understand where they’re coming from, why they’re asking those questions, and how they feel about it. How would they prioritize their particular suggestion.
If it’s critical to them, then you have to take it more seriously and give it a little bit more thought, versus something where they’re just like, “You should have this phrasing instead of that phrasing,” or “I don’t understand why this is on this particular menu in your app versus this other menu.” Those are the types of things which a lot of times they can go either way, but then there are certain things where they really have to be done in a particular way and you know the best way to do it because you had that context and thought about it, and it really happened.
Rob: Yeah. I think the third step for this approach is to compare their context to yours. Coming back to what I said earlier, is this something that they saw a competitor doing and is that a road you want to go down with this particular competitor or this particular feature? Do they have personal experience with that competitor or with this feature? What’s the frustration level with the fact that this doesn’t exist? Low, medium, high, or are they angry and belligerent? Have they considered the implications of what they’re asking? Do they have any idea about the amount of work involved? Do they know it’s going to take 3-6 months versus 1-2 weeks? They probably don’t. Any idea about the timeframe? Is this something only they would use? They’re probably not going to know that, but you should have a gut feel. This was always something that when we would get a feature request with Drip, I would try to get in the mental mindset of all our customers. It’s hard to do. You can’t do it 100%, but I would frequently say things like, “I think if we build this about 10% of our users will use it. They’re going to get a ton of value out of it and they’ll stick around forever,” or “I think about half our users will use this,” or “I think 2% will use it, but it’s the power users,” or whatever.
Again, those are guesses but that’s part of being an entrepreneur is making decisions with limited information. You don’t have all the information in a roadmap sense that you can just walk from here to X-marks-the-spot of victory and profit. Making decisions with incomplete information is a huge part of it and developing that, I’ll call it “gut feel,” but really what it is, is it’s years of experience working with your customer base, on your product, and in your space, that can help give you that context for it. I think the last thing to think about when you’re comparing contexts is, have you previously considered the suggestion or is it on your roadmap already?
Mike: Yeah. I think that last piece makes a big difference. If your response is off-the-cuff and just say, “Oh, we have thought about this before and this is how we’re going to do it,” versus something that you’ve put it on your roadmap already because you’ve heard it a lot, or you put it into a document based on things you’ve heard from people who’ve asked about that particular thing enough that it warranted having a, I don’t want to call it a stock response, but an answer that you can share with your team as to ‘this is why we are or are not going to be going in this particular direction.’
That lends itself to you have considered the implications of that. A lot of times what you’ll find is that the customers don’t necessarily consider all the implications. Part of that is just because they don’t see all the same things that you do. You’ve got all these priorities that you’re working on, maybe things at your bug tracker, or features, or particular customers that are high value that you want to be able to serve better, or a particular direction you want to take the product in. You have visibility to those and the customers or your prospects do not.
Rob: Yeah. As you go on, if you’re two, three, four years into it and you have 1000, 2000, 3000 customers, a steady influx of prospects, you’re going to get to the point where you’ve heard 90%+ of all the request that come in. You’ve heard them before. Maybe 95%. It’s crazy how much these things are just clustered. You can put them into these buckets of absolutely not going to build that because we’ve evaluated it and you can come up with 10 different reasons of why you wouldn’t build, but you just know that right now, you’re not going to build that, absolutely are going to build it, and it’s “on your roadmap.”
Now, in the early days we were super agile with Drip. Our roadmap was literally 2-3 weeks out, but we had a mental roadmap of where we’re going to go beyond that, but it was certainly in flux. A third bucket is, you don’t know yet, it depends on how stuff unfolds with what you’re currently building. Then there’s this fourth bucket that was the pleasant surprise of, “Wow, no one has ever suggested that and that’s a really good idea.” The issue is that is so rare. I mean it’s probably 1 in a 100, 1 in 200 feature requests if that as you get to scale. At least from my experience with the apps that I’ve built.
It becomes less and less frequent as it goes on. If I got one of those and I was on a call, I don’t know, that would blow me away and it would be a fun thing to dig into with that customer because if you haven’t heard it, you haven’t thought through the context of how it would be used and where they got the idea. I mean, I would really dig into that. Again, I do think that’s an edge case and not something that you’re going to have to deal with everyday.
Mike: I don’t think we specifically mentioned it, but part of comparing their context to yours is where they are in the sales funnel. Are they already a customer? Had they been a customer for a long time? Did they just sign up? Are they just evaluating your products to see if it’s a good fit? All of those things are going to make a difference when you start evaluating what your response is going to be.
Now, when it gets to response, this is step four in the approaches, you’re essentially inserting a massive if statement and a matrix here that indicates how you’re going to respond, because it’s going to depend on a comparison of how critical it is to them, how quickly it can be done, whether it aligns with what you want your product or service to do in the short term versus the long term, what the current state of your business is.
If you are very early on and either you’re pre-revenue or you just started selling it, you have a little bit but you’re not full time on it, all of those things are going to make an impact on whether or not you’re going to decide to move forward with that and implement it, versus you’re going to push off of it. One of the biggest pieces of this is whether or not you believe that you have a better solution to this suggestion or feature request than they have offered.
Sometimes, you just have a workaround. Sometimes you know that you can do it, but it’s not going to be a timeframe that they need. You can say, “Well, here’s a workaround, we can do this for now, and we’ll implement this in a month, or three months, or six months, just because it’s so much work in order to do that.”
That leads directly into step five which is to make sure that your response establishes a common context for the two of you. You want to make sure that you’re on the same page. You don’t want them to walk away from the conversation thinking, “Oh, he didn’t listen to me,” or “She didn’t take my suggestion seriously.” You have to make sure that they understand what it is that you are doing and why. You can go into the, “This is what we’ve tried to do in the past. This is what we’re doing now. This is what we’re going to do in the future,” but it’s extremely important that you make sure that they understand what you’re going to be doing in the future and why you have come to that decision.
They may not agree with you but ultimately, it’s your business. You’re the one who has to make that call. You can’t let the customers decide every single thing that’s going to happen inside of your business. Quite frankly, if you just sat there, respond to customer requests all day, and try to implement everything that they wanted you to do, you would never have time to do anything else. There’s lots of stuff in my business that I would love to do and I just don’t have the time to get to them.
You’re never going to have a to-do list that gets shorter and shorter over time. It will always get longer and you have to pick and choose which things you do and don’t implement. Sometimes you’re going to have to tell a customer, “No,” or “We can’t do that and here’s why,” or “This doesn’t align with our vision and here’s why.”
Rob: Yeah. I actually think that’s where the concept of customer development and listening to your customers does. Especially early product people, it doesn’t mean disservice. I haven’t read every book on the in-depth machinations of customer development, but I know the concept, how it’s used, the definitions and all that. It feels to me like people, whether it’s used correctly or they misuse it, they think that you ask your customers what they want and then you build those. That’s not going to work.
There’s such an issue when your customers are using some type of competitor. This is the major issue, if they’re using a competitor, they’re pretty much just going to ask you to duplicate all of that competitor’s features that they use. That is the non-product person’s initial reaction to everything. That tends to be a pretty bad choice and it’s going to come back to bite you later on.
I think the idea that it’s ultimately your business, points to having a vision for your product that you hold on to but are also willing to adapt. You know when to change it. In the early days of Drip it’s like, “Alright, we’re going to build this little add-on. Okay, now we’re going to change the vision to build an ESP. Okay, now we’re going to change it to add automation.” This division had a through line to it. We never veered off and built shopping carts software which was requested all the time. We didn’t build affiliate management which was requested all the time. There were other things that were just off. It was just like, “No. We’re going to integrate out for those,” but this through line of ESP add-on to marketing automation, we allowed the vision to adapt and adjust. We didn’t hold onto it so tightly that it was like, “No, we’re only going to be an add-on for an ESP.”
We would have still had some success, but we would never have had the success that Drip had. We also didn’t just go around building everything everyone asks. I think that’s a real problem. When you get into an app or someone has done that, you can tell. There’s settings everywhere. I unfortunately see this in a lot of older open source projects. Where people just come in and just bolted on this checkbox, that checkbox, this switch here and there, because they had some unique use case.
Frankly, if you’re building a SaaS app for the long term, thinking about how not to clutter your UX, clutter your app with these features that just make everything more complicated but almost no one uses or these edge cases, is something you really need to think about, because you can make a choice today that will just come back to bite you for years to come.
Mike: And running at the end of this approach is that you should always thank them for looking out for you. Find out if they have any more questions. Make sure that they understand what the responses that you’ve given them and why you have come to the conclusion that you have. Again, it’s not saying that they’re going to agree with you. You just want to make sure that they understand why it is that you made that decision. Part of this is just about making sure that they walk away having a good feeling as if you listened to them, and you truly understood what it is that they were asking for and made the decision, “Hey, that’s not right for this business and it’s not going to be right for you.”
I’ve heard from people who I’ve said, “Hey, this is not going to happen at any time frame that is close to what you’re looking for, you should probably find something else,” and then 6-9 months later, I’ve had them come back and say, “Okay, we tried a bunch of other things and those things didn’t work. We would like to come back and revisit this with you.” People appreciate you being candid with them and giving it to them straight. They don’t want to be jerked around. They don’t want to be told lies. They hate it when a sales rep will make promises, then suddenly they get in, they’ve spent all this time and effort trying to integrate their systems in with yours, only to find out you can’t deliver, or you haven’t delivered on exactly what it was that they wanted because you didn’t understand and you guys weren’t on the same page. Make sure that they know what they’re walking away from and make sure they understood what you’ve told them.
Rob: I think some additional thoughts we can run through is, sometimes taking a request that’s fast and simple, and something you can build in an hour or two, buys a lot of goodwill, even if it’s not a current priority for you but it’s something that you know you want to build long term, or if it’s a good suggestion. I loved doing this in the early days of both Drip, HitTail. There were other, Wedding Toolbox. There were other apps that it was the best.
I get this email and say, “Hey, how come I can’t blah, blah, blah, or can I?” and you would literally go write the code, ship the code, and then respond back within an hour and be like, “Hey yeah, that’s available now. We just implemented it for you.” It is the best feeling to be able to do that. It’s something you can do less and less as you scale, but I just love that idea. Again, only if it’s something you’re going to build. You don’t just want to add cruft because it’s quick. That’s also a mistake early product people make.
Mike: Another huge thing is that the communication medium that you’re using is extremely important because what you say and how you say it is going to be a lot different based on whether it’s a chat message, or an email, or Skype, or Zoom Call, or video call, or something along those lines. It’s a lot easier to determine if they really agree with you on a voice call than any other medium.
If you are having conversations in that particular communication medium, it’s so much easier, and so much more effective. The downside is that you don’t necessarily have as much time to think, so you have to make sure that if it is not something that you have thought of in the past, that you write it down and take notes, and give yourself an opportunity to say, “Look, I haven’t really thought about this. Let me think about it some more and I will get back to you.”
There’s a lot of times where just having time to think about it more is going to give you a lot more clarity on whether or not that suggestion is a good fit. You can always just say, “Hey, I really appreciate you looking out for us and I have written down a bunch of notes. I’m going to think about it and I’ll get back to you in three days, or five days, or what have you, with an answer about what it is that we’re going to do about this.” That way, you can take it offline into an email instead. Make sure that you follow through on those commitments because if you don’t, that’s going to reflect poorly on your business overall.
Rob: To come back to an earlier thought, you can’t possibly do everything that people request. You can’t possibly do everything you want to build. You have to pick and choose. You have to prioritize. You have to say no to a lot of good ideas. What separates a decent product person from a great product person is their ability to choose the right things to build because no way you can build all the good ideas that everyone has. A lot of things sound like good ideas and they might ultimately be, but it’s part of being a founder, or being a product person and deciding, “What is my vision for this? Which gets the most bang for the buck? Which will delight the most customers in the deepest way?” and that’s where you have to take a look in the mirror and just say, “We’re going in on this.”
I hope that was a helpful discussion and that wraps us up for today. If you have a question for us, call our voice mail number at 888-801-9690 or email us at email@example.com. Our theme music is an excerpt from We’re Outta Control by MoOt used under Creative Commons. Subscribe to us in iTunes by searching for Startups, and visit startupsfortherestofus.com for a full transcript of each episode. Thanks for listening. We’ll see you next time.
In this episode of Startups For The Rest Of Us, Rob and Mike talk about why you shouldn’t listen to your customers. Not all requests are created equal. The guys breakdown customer feature requests into three categories and give tips on how to get the most out of them.
Items mentioned in this episode:
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 firstname.lastname@example.org.
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.