/
RSS Feed
Show Notes
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:
Mike: In this episode of Startups For The Rest Of Us, Rob and I are going to be talking about how to respond to customer suggestions. This is Startups For The Rest Of Us episode 436.
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 questions@startupsfortherestofus.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.
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 questions@startupsfortherestofus.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.
Steve
Great Podcast. I have made every mistake mentioned in here. Well plus a few more.
We have one additional solution while working with customer requests.
I have found that if a customer wants a specific feature, and it makes sense to put it in the product, though they want it now and you see it down the road. Charge them to put it in now.
We charge it as an expedited feature release. It has helped us grow Skills DB Pro to an enterprise level offering, while getting paid along the way.
One more bootstrapping thought 🙂
Thanks,
Steve