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:
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.
Episode 341 | How to Deal With Toxic Customers
/
Show Notes
In this episode of Startups For The Rest Of Us, Rob and Mike talk about how to deal with toxic customers. They give you some warning signs to help predict if a customer is turning toxic as well as some strategies to help deal with them if they do.
Items mentioned in this episode:
- Spark
- Laravel Spark
- Delicious Brains post
- Future Hosting Post
- Rob’s “How to Detect a Toxic Customer” Post
Transcript
Rob: In this episode of Startups For the Rest of Us, Mike and I talk about how to identify and deal with toxic customers. This is Startups For the Rest of Us episode 341.
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 Rob.
Mike: I’m Mike.
Rob: We’re here to share our experiences to help you avoid the same mistakes we’ve made. What’s the word this week, Mike?
Mike: A couple of things. I’ve just pushed a major UI release for Bluetick to address some usability questions and stuff that kept coming up for people. It’s a massive improvement but it took forever to get it done. It was like a week and a half to get everything finalized, tested, and pushed out the door. It’s over and done with so I can move on from that side of things at this point.
Rob: Congratulations. That’s a big deal. It’s over and done with for three to six months until more usability stuff comes up.
Mike: It’s done for like three days. That’s what it really boils down to.
Rob: That’s a big deal. Congratulations. I know that this kind of stuff, it nags at you because you know it has to get done but it doesn’t exactly move things forward. It’s better than like doing taxes in terms of moving things forward for customers but it’s also not a new feature. It’s that balance of I got to push this.
Mike: Right. I think the part that made this piece so difficult was the fact that this was one of the areas that I knew needed to be rewritten for the past six months, to be perfectly honest, and I just didn’t get into it because I knew that it was going to be a hornet’s nest and didn’t want to deal with it at the time. But with that said, it’s like, I went through it, got most of the things cleared away, got all the code organized and commented properly.
Everything’s much more tested now more than it ever was before. It’s just so much easier to work with. I can go in and make changes now whereas before, I was afraid to touch anything because it might fall over and break.
Rob: That’s good. It’s nice to refactor as well. It sounds like it was a UI improvement as well as a code refactor. That’s two wins.
Mike: Now that that’s out of the way, now I can move onto more important things like the website and getting the signup process working.
Rob: Cool. For me, the only thing I have this week is we got a nice email from Victor Perolnick. He had listened to our previous episode where someone asked a question about resources for the engineering side of launching a SaaS. We had given a couple but it was mostly blog post and such. We did specifically say, “I know there’s going to be some out there for specific languages like if you want to do it in Rails, you’re going to find stuff. If you want to do it in PHP.
Victor called out Spark which is from Laravel which is a PHP framework for building a SaaS app. It’s spark.laravel.com. He also talked about Laracasts has a bunch of Spark screencasts if you want to see something really quick. And then link to a couple of blog posts that talk about it.
It gives you a head start if you’re going to build a SaaS app in PHP. Anyways, I wanted to call it out. We’ll link those up in the show notes. If you happen to be building in PHP, that’s probably where I would start.
Mike: I looked through some of those links that he had sent over and we’ll link them up in the show notes. The Spark system looked really nice for getting a SaaS app up and running and not having to deal with a lot of the fundamental plumbing that you would typically have to work with, the billing accounts, subscriptions, impersonation, and things like that. It looked like it was all kind of cookie cutter which is really nice.
Rob: This week we’re going to be talking about how to identify and deal with toxic customers. I wrote a blog post back in 2010, looks like December 2010 that we’ll link up. It was called How to Detect a Toxic Customer. It actually got a lot of traction on I think it was Hacker News at the time. It has like 72 comments or something on it.
I basically walked through a case study of what I had experienced with an invoice and a customer who is quite demanding and was just really combative. I talked about how to identify them and what to do. I find that this type of thing, it comes up every 6 to 12 months. If you’re running a SaaS app, if you’re selling software, it can be a challenge. You talk to anyone who’s been selling software for any length of time and they’ve run into something like this.
We’ve talked a little bit about this in the past on the podcast but I just want to walk through these steps of how to identify really early on, because one of the keys is being able to see it ahead of the actual person getting in and starting to use your app. Because once they’re using it, it actually becomes harder to force them to switch. It’s a really tough decision to do that. Maybe not at the same level of firing an employee that you mis-hired but it is in that spectrum of like, “Man, if someone gets in and they’re really using it and being a pain in the butt, it’s hard to make them switch.”
That’s where we want to start, early signs if you’re in conversation with someone that they may not be a good fit for you even before they ever get into your app. I have a big list here, mostly culled from this blog post.
You know what the first sign is that they view their “vendors” or they view you as like, it’s this weird attitude that you’re like somehow a servant or a slave to them. They’re extremely demanding. They treat everyone they speak with as if they’re an idiot. They talk down to your support people. They talk down to you whether you’re the founder or the salesperson, just this very demeaning tone. It’s like they expect everyone to bend at their will. It’s like they’re doing you a big favor for being their customer.
Mike: I think there’s a few different pieces to this part of it. Most of the time, you can identify this type of thing in the language that they use or how they reference the types of problems that they’re running into. Whether they say, “Oh, this is a massive problem in your app.” Or “Why doesn’t this work?” They get very angry and frustrated very, very quickly and things just escalate fast to the point that they see even just little, minute problems or UI glitches and things like that as a massive problem that calls into question everything that’s underneath the cover.
Most of the time, that’s just not the case. There might be a color that’s off or something is mislabelled or the documentation isn’t quite up to date and they’ll just blow things out of proportion and what you’ll find is that the language or the tone that they take with either the support emails that they send in or the calls that they make or even just the way that they get in touch with you.
If they send you an email and then five minutes later send you another one, that’s a classic sign of a toxic customer. The way that they communicate to you is heavily indicative of how they’re going to be to work with long term.
Rob: Yeah. I have that as a warning set number four in this article. This was an actual sequence of emails that I got from someone again with .NET invoice years ago. Warning set number four is unrealistic expectations. I got an email in support. It says, “Is your software localized for Australia?” And then literally, 10 minutes later, “I wanted to make sure you received my previous email. Is your software localized?” And then 30 minutes after that, “Hello, is anyone there? I haven’t heard back.”
It’s been 40 minutes since you emailed. This is insane. And then 20 minutes later, it was like an all caps thing of like, “Why aren’t you answering?” It’s like I have a feeling maybe I shouldn’t answer this one. If I answer the question and they spend the $300, how much more of a pain are they going to be later on? It’s unrealistic expectation, expecting everything to be answered or done yesterday.
Mike: I wonder if there’s a way like Brennan Dunn as you know is working on RightMessage.io, I wonder if you could somehow flag them and just jack up the price by like 10x to account for that kind of thing.
Rob: Yeah, that’s awesome. I think you make a good point about little things. You’ll have thousands of customers using an app and no one complains about a bunch of stuff and then one person will just have this such an issue and like, “This is a major issue.” Like you’re saying, it’s like all caps subject lines. Everything’s a bug instead of a feature request. It’s like, that’s actually the way you think it should work but everyone else is fine with the way it works. Or it’s like this fixed rigid mindset of you should do it this way because the only way to do it or that’s the way my old system did it.
It’s a bug since you don’t match the way my old system did it but it’s like that is a point of view but your point of view isn’t necessarily the right one. Again, telling back to toxic customers tends to think that way, the language they use early on and maybe the expectations that they have.
Another thing that I’ve seen and it was funny because I used to man support with .NET invoice and so I would answer a response and then I would get this threat to escalate like, “Can I talk to your support supervisor?” “Can I talk to the founder?” “Can I talk to the CEO?” Or “I demand to talk to the CEO is another one.” It’s like, “That happens to be me. How can I help you?” That would be my response but there’s always like really? We’re going to do this because there’s one misspelling or whatever it is. Like you said, the button caller doesn’t agree with how you want it to be.
To threaten to escalate, again, not always and each of these on its own isn’t the end of the world but it’s when you start seeing multiple of these go on over the course of a few interactions, your red flag should be going off.
Mike: I think the other interesting thing about these is that sometimes, it is just one thing that you can see and say, “This person is going to be a toxic customer.” And then there are other times where it needs to aggregate. You need to have several different data points.
If your first interaction is why doesn’t this work and it’s all in caps, it’s kind of a giant red flag but then, there’s other more subtle things that you get into and they add up over time. Sometimes, you don’t see them until much further down the road. As you said earlier, that’s when things become a problem because then they’re probably already in your app, or already using it, or have already paid for it. It becomes much more difficult to cut them off as a toxic customer.
Rob: Another potential sign of a toxic customer is that they provide way too much feedback. Every interaction with them is just a stream of consciousness of how they feel things should be different. We had people tell us like, “This word doesn’t make sense. You should rename that everywhere in your app to be this other thing. It should just say emails up there instead of broadcast or something like that.”
It’s like, “Okay, thanks for the feedback. We have four years of history of this being broadcast everywhere and that’s what all our documentation says. That’s what all of the marketing says.” It’s like everything calls it broadcast just because right now, you don’t understand that yet. In a week, you’ll know what that means and changing it to emails is actually more confusing.
I guess what I’m saying is it’s fine to get feature requests and it’s fine to get some feedback from someone but if every phone call you’re walking away with 10 different things that someone is asking for, there’s a potential there that that person may take their opinion a little, too seriously is not the right word, but it’s like they value it over your own or over the opinion of your company or your product.
Mike: The specific example that you just brought up about the name of a particular field, or a drop down menu, or just something that is presumably really just a label in the app, it brings up an interesting sideline about the fact that some people would go and say, “What can I implement and put in as a technical solution to this thing that keeps coming up where people wants to use different terminology?”
The thing I have seen a lot of apps do is allow you to rename things throughout the apps. So that instead of calling something emails for example, they’ll call it broadcast. If a customer comes in and says, “Hey, this should be called x.” You can go in and you could presumably change that inside of their user account, they would just propagate it throughout the entire app. But then, it makes it more confusing. It’s a little bit harder to support because all your documentation is probably not going to line up directly with that.
I think that you have to be a little bit careful about whether or not you put technical solutions in place for problems that are actually warning signs of problematic customers.
Rob: Totally, it’s like if everyone request that, then that might make sense but that’s a heck of a lot of work to do for one customer. If literally you have thousands of customers, no one ever complained about the naming thing and one customer gives you 10 things and a bunch of them are naming things, it’s like, “Really? Are you going to change that?
Everyone has an opinion and you’re building for the masses and a single customer coming in doesn’t understand the context, and they don’t understand that you do have thousands of other customers. I think that’s another kind of mindset thing with the hard customers that you deal with is they don’t have any context for the thousands or tens of thousands of other people who are already using it. I think that comes back to that fixed mindset thing I talked about earlier. That there’s only one way to do it and it’s the way that I think it should be done.
Another thing that I’ve seen is someone raising the same issues over and over. I guess it comes back to that email that I kept getting about the Australian dollar. They’ll just email back with the same issue everyday or every week even if you say like, “We’re working on it.” It’s like they feel somehow this anxiety or this sense of urgency and they need to, I don’t know, continue to force it on you.
I’ve also seen multiple contacts with the same issue through multiple channels. They email you. They call you on the phone and they chat. You’re like, “You’re actually making this harder on everyone because that mixes things up. Please don’t submit the same questions.” Something about urgency and expectations. It’s expectation of turn around.
If you’re a consulting firm, then maybe they’re paying you $50,000 or $100,000 and you have someone dedicated to them. If you’re a SaaS app and you have 10,000, 20,000 customers, even big customers, they likely will not be getting that level of turnaround time on their feature request. Again, if they were a consulting firm, then yes, they’re going to build what you say. If you’re a SaaS app, you’re not necessarily going to build everything everyone suggests.
Some folks have a hard time understanding that. Those tend to be the ones with misaligned expectations that turn into toxic customers.
Mike: The other thing that sometimes you’ll see is that they will, after a very short time period with your app, they will have several pages of “suggestions” for you to change. It’s partly just a lack of education on their part because they haven’t taken the time to learn how your app works and how it compares to things that they have used or done in the past, but they feel like they know better than you do about how this particular app should be built.
There are certainly exceptions to the rule here but generally speaking, you probably know the market way better than they do especially if you’ve been doing this, running an app, for any length of time and it’s a profitable app. They’re going to come in and they’re going to base all of their thoughts and ideas around their previous experiences.
A lot of times, you’ve designed around those because they weren’t good experiences or those other apps that you were competing against weren’t doing things in a way that made sense for most of the customers and really you’ve just been pushing yourself in a position to put in bad features because of their request. Those are the customers that you’re trying to avoid.
Rob: That’s a really good point. It’s a trip to see if you’re competing against apps and some of them will make what you see as poor design choices. Over time, you’re like, “Man, that’s pretty hacky.” Customers coming from those apps think that as the “right way” to do it even though it’s not. It tends to be a bad user experience for new customers but since they’ve been using something, they expect that to be the way, that’s the way things should be named, or that’s how it should work.
We see this with Infusionsoft to be honest. There’s just a lot of I would say questionable UX and design decisions but if you do it different than them, even in a what I would consider more modern or better way to do it, that’s much more efficient, it can confuse people who are used to thinking in the Infusionsoft mindset.
I think the last one for perhaps identifying toxic customers early is that they can expect a lot of special treatment. They’ll ask for extra services get thrown in and they’ll ask for almost always a big price break like they’re doing you a favor for being their customer. They get a price break that no one else asked for without giving a reason. There are just a lot of special favors that they can call in.
Again, if this is the only thing a customer does early on, alright that’s fine but if it’s coupled with these other things, it’s something to really be aware of and watch out for.
Mike: The big one here for like a SaaS app would be phone support or direct access to the founder which is justifiable especially in the early days when you’re the only one who is running everything or maybe you have somebody who’s doing some part time support. But it becomes a problem over time that can get bigger if you leave it unchecked. You have to cut those things off early if you can possibly help it but the people who have that expectation going in, that’s where you start running into the problems.
Rob: Now, we’re going to switch gears a little bit and talk about potentially how to handle this. Whether you detect it early or you get down the road a bit some strategies on what to do as this type of thing unfolds. I think I’ll start by saying that hard customers, toxic customers, they will by nature just absorb and suck away an enormous amount of your time. There’s someone out there who calls them time vampires.
I’ve seen folks that will literally just demand dozens of hours a week of your time based on the number of request and the number of the hand holding and the phone calls and all the stuff. It can really be chaotic especially if you’re running SaaS. If you’re selling downloadable software, I’ll tell you something we had to do with .NET Invoice a few times. It wasn’t often but it was maybe once a year, we would refund them. Tell them to keep the software, we refunded them and we basically ran away.
We told them, “Look, for $300, one time, we cannot provide this level of support.” And then let them be on their own. But with SaaS, it’s harder because if they’re already using you platform and you didn’t turn them away in advance, you have to force them to leave, to migrate away, which is a bit harder to do. We’ve only done it a very, very few times in the life of Drip. It really sucks, to be honest.
Like I was saying earlier, it’s close to but it’s not nearly as bad as hiring the wrong person but it can be a real drag which is why you’ll want to learn to identify these folks in advance, to see the signs early on in the sales conversation and try to cut them early because you have to ask yourself, is this going to be worth it in the long run? Trust your gut. If you see a bunch of these signs, it’s easy to talk yourself into, “We can work with it.” Or “We can manage expectations.” It’s likely going to get more complicated than that.
Mike: I think there’s an important distinction to be made here between the customers who are taking up a lot of your time because they have legitimate issues versus the ones who are being difficult. I’m in a situation now where there are certain issues that are taking up a ton of my time and there are some customers who are coming to me and saying, “Hey, can you do this?” Or “Can you do that?” I don’t want to say constantly but I’m getting fairly regular emails from them.
If you go through this list, you can say, “These people are problematic customers.” At the stage that I’m at, that’s actually not the case. It’s the opposite. I’m actually appreciative that I’m getting this feedback and these people are saying, “Hey, could you do this?” Or “Could you do that?” Because it gives me ideas and yes, I’m spending a lot of time on it but it’s also pointing me in the right directions. I need that right now.
If I were 100x where I’m at right now, that might be different but I’m not, so there’s a very big distinction between where your business is at in terms of how much time you’re probably going to be spending with the customers and whether or not they are problematic customer.
I don’t have any of those right now but you could certainly potentially mistakenly view some of those customers as all of these are problematic when the reality is your app is just not quite there yet and it still needs more work and there’s still a lot of effort that you need to put into it on the front end in order to be able to cut those issues off on the back end.
Rob: Totally. I am glad you called that out because especially in the early days, getting a lot of feature request feedback input, especially, there’s a tone element to it, if it’s not demanding. If it’s like, “Hey, have you thought about this?” Or “Hey, this would really help me out or this would be a great feature to build.” You’ll get emails like, “How have you not built this yet? I am shocked and appalled at the catastrophic way that your app does not do x, y, z. yet.”
It’s like it’s being shocked that it doesn’t, versus suggesting it as an improvement and realizing the software, especially SaaS, is an ever evolving thing, that everything is not perfect all the time, going to work exactly the way everyone wants 100% of the time. There’s a difference in tone. I agree with you. We’ve had a ton of people who give us a lot of really good feature suggestions.
You look at Brennan Dunn, he does it publicly. He does it via email. He gives us a ton of feature request, suggestions, ideas, and they’re damn good. These are things that really have leveled up Drip over the course of years. But he’s never been on that other side where he’s like, “I can’t believe Drip doesn’t do this.” I never heard the out of his mouth. It’s just this difference in attitude and tone.
Mike: A tell tale sign that they’re trying to be helpful is that if they apologize for sending feedback over. I’ve gotten that from several people where, “Oh, I’m sorry to keep bothering you with this stuff but it’d be great if you could do this or can this be done?” If they’re apologetic about writing into you for email support or anything like that, that totally puts them in a different category. They’re certainly not a problematic or toxic customer at that point. They’re the opposite.
But as Rob just said, it’s the tone of voice. You can tell from that whether or not that’s the case.
Rob: The thing to remember here, if you do have a really hard customer who’s demanding, is you have to keep your cool, you have to be kind, you need to be honest with them, and you need to be firm. The more you give in to irrational demands, irrational feature requests, there are actually things that makes sense, and you say, “Look, we are going to build that. That’s a great idea. Let’s do it.” And the person backs off, then you’re cool. You fixed the thing.
If they continue to still email everyday or every week like, “Why isn’t this done?” Then you know, maybe you’re tipping in that other direction of it being hard. If it’s rational stuff and you’re building it, then keep going. If it’s not rational stuff, if it’s stuff that you know is incorrect, bad for the product, bad for other customers, you’ve already tried it, it doesn’t work for whatever reason, that’s where you do have to be firm and you have to separate your emotions from the conversation.
If you can’t do it, you need to have someone like a support person or customer success person who can do that. Someone who is exceptionally good at this is Anna on my team. She would handle angry customers. She would handle toxic customers. Those two are different.
Mike: She’s talked to me a bunch of times.
Rob: Yeah, nice. Well done, Mike. But you know, you’ll have angry customers who are just angry about one thing. They get frustrated. You can smooth that over. Toxic is when they’re angry all the time. It’s the way I would put it. But Anna is really good at it. If you remember, I interviewed her, it may have been on ZenFounder actually, it was maybe 6 to 12 months ago, but we talked about dealing with negative emotions and how she was able to separate herself from the emotions coming from customers who are frustrated.
Like I said, this is by far the hardest thing to do especially if someone is making sweeping insults about you, your team, your intelligence, your application, but this is where you have to be kind, be honest, be firm, and not lose your cool, this is going to be the hardest thing to remember, and not let it derail you. Once you know that a customer is being particularly difficult, don’t let it derail your day, or your week, or your month because it’s so easy to do that.
In the best case scenario, someone who is difficult upfront winds up not actually being a toxic customer. Maybe they were just frustrated and they had several issues that you’re able to work with them, you’re able to fix them and they’re able to move on because there’s often this on ramping period where let’s say the first 30 days of using a new app, you’re confused by a lot of things.
Most of us go with it. We figure out how to use it. We don’t ask the app to change everything but some people are of that more fixed mindset. But if you handle a few of their issues and they like everything else, then it’s like you can move on and they really won’t be long term, won’t be that toxic customer.
I guess what I’m saying is often issues are clustered when someone first starts using your software. After that, they’ll calm down and people can understand how it works. That is the best case. I would say it’s not the norm but in the best case, if you do handle them with kindness, and honesty, and firmness, again, that’s the best case of coming out of this.
Mike: Something else to keep in mind with this is that dealing with customers is a learned skill. You might not be very good at it at first but you will get better at it over time. In addition to that, there are some people who just have a knack for this. Like you said, Anna seems to have a knack for it. She’s capable of separating herself from the problems and from the app itself and empathize with the customer.
Some people are better at that than others. Even if you train yourself and go through a lot of doing this type of support, and dealing with a lot of these types of people, it doesn’t mean that you’re going to be better than the next person at it or worse than them. Some people just have a knack for it and some people don’t. But with that said, if you don’t have a knack for it, you can get better at it. You can learn to separate yourself. It just takes time and practice.
Rob: To wrap things up, we talked about the best case which is working with them early on and then being able to transition them into a productive, happy customer. The worst case of course is that you find yourself and your team just living through ongoing stress for weeks on end. There are a couple of ways to approach this.
Firing a customer is not unheard of especially with larger SaaS apps. It depends on how you want to handle this. Sometimes, I’ve seen folks just plain ignore and just say, “Look, even if this customer sends 10 emails a day, we’re going to respond once a day or once every two days to all of them.” That is one way to handle it.
Or you can fire them. If they start being abusive to you or your staff, that’s not cool. You have to protect your people and your loyalty to your people in my opinion is going to go so much further than loyalty to one demanding customer. This is a hard decision because it’s not always black and white. You can have a toxic customer that’s not abusive. You can ask your support team, are they abusive? No, they’re just a little demanding and it’s like okay, then maybe it’s not time to fire them.
But if people are really shaking up, and you feel like things are rattling around, you have to evaluate at what point you let this single person have so much control over your team. Again, this is a hard decision. It’s always going to result in people being pissed off but if you find that you’re at that point, and you feel like you’ve done everything you can over the long run, frankly, firing someone who you think could cause this level of headache for you, for months or years on end, it’s the right decision.
Again, it’s like making a bad hire. It’s not as bad as making a bad hire but once you’ve made a bad hire and you know you need to fire someone, it’s a hard decision but over the long run, you always think to yourself, “Why didn’t I do that sooner?”
Mike: I was thinking about this and trying to figure out whether or not there’s a specific turning point or a hard benchmark that you can look at to determine whether or not you should just turn the tables and cut a customer loose because. Early on, you really don’t have any history with the person so you’re not entirely sure whether or not they’re going to stick around to begin with but you probably have an idea of what your lifetime value is for that customer.
If you’re looking at that and trying to track it back to how much time and effort you’re spending with the support, that’s not the whole picture. The whole picture is actually the impact to the rest of your day. I think that that’s not something that any of us would really be measuring. You might only take 15 or 20 minutes to answer a support request but if you spend the next couple of hours with that stuff turning at the back of your brain and it’s distracting you from doing other things, the time for that to cost you weren’t 15 minutes, it was 2 hours.
These things can be exponentially more damaging than you initially realized and in some cases, you have to be able to identify those people as early as possible just because you don’t want it to get to that point where it is causing you 5x, 10x, or 50x what it is that they’re paying you or would even potentially pay you if they were to stick around for 10, 20, 30 months.
Rob: To circle back, we’ve talked about some signs to look out for. We’ve talked about what to do. Hopefully, you’ve heard that the best case is that you can actually work with someone and help turn them around. I guess that would be hopefully something you can shoot for if you do find yourself amidst “toxic customer.”
Mike: With that, we’re going to wrap up for today. If you have a question for us, you can call in our voicemail number 1-888-801-9690 or you can email it to us at questions@startupsfortherestofus.com.
Our theme music is an excerpt from We’re Outta Control 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 and we’ll see you next time.
Episode 295 | How to Get Your First 10 SaaS Customers
/
Show Notes
In this episode of Startups For The Rest Of Us, Rob and Mike talk about how to get your first 10 SaaS customers. They reference a ParseHub blog post about the beginning stages of their startup. Rob and Mike walk you through the steps of this article and how you might be able to replicate their success.
Items mentioned in this episode:
Transcript
Rob [00:00]: In this episode of ‘Startups for the Rest of Us,’ Mike and I talk about how to get your first 10 SaaS customers. This is ‘Startups for the Rest of Us’, episode 295.
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 are just thinking about it. I’m Rob.
Mike [00:29]: And I’m Mike.
Rob [00:30]: And we’re here to share our experiences to help you avoid the same mistakes we’ve made. So, what’s the word this week, Sir?
Mike [00:34]: Do you want to hear a joke about tacos?
Rob [00:36]: Always.
Mike [00:37]: Are you sure?
Rob [00:37]: Uh-huh.
Mike [00:37]: It’s kind of corny.
Rob [00:39]: Well, you know. It comes with territory, right?
Mike [00:41]: Get it, corny? Tacos?
Rob [00:45]: I was waiting for something funny.
Mike [00:47]: I know. I don’t know what you were expecting from me.
Rob [00:49]: Ah, man. Yeah that was pretty bad. I wouldn’t even tell that one at MicroConf. That’s how bad that joke is. Yeah, we were talking offline before this podcast and it’s like we don’t have so much going – we have a lot going on, but none of it this week is that interesting to do in this update upfront. It’s like there’s behind the scene stuff. You said you’d talked to a potential customer about early access stuff. I’ve been plugging away having meetings, charging ahead. But I really couldn’t think of anything in the last week that was that interesting to tell the listeners about. Some weeks it’s like that.
Mike [01:21]: Yeah. It’s not that there’s not stuff going on. It’s just that it’s not really interesting to hear about at this point.
Rob [01:26]: Yeah, well so maybe today we just dive right in to the topic of the day. We’re talking about how to get your first 10 SaaS customers. And, specifically, we’re going to be referencing this blog post on the ParseHub blog called ‘How We Got Our First 10 Paying SaaS customers.’ And ParseHub is a SaaS app. They’re a visual web scraping tool. So, they have tag lines like ‘Extract Data from Any Site,’ or ‘Turn Any Dynamic Website into an API.’ And so, obviously, you sign up for them. You can go and it does screen scraping, in essence. And then you can pull data out. I’m assuming you hit some ParseHub endpoint and then you can pull data through there.
But they published a post – this is over a year old at this point. They had launched in September of 2014 and they published a post in 2015 about how they went through and – basically from a standing stop. As far as I know, they didn’t reference having a list, or they didn’t reference having an audience, or any of that stuff. And so that’s where I found it interesting – is that these folks have done it recently, relatively. They walk through – what is it, 5 or 6 steps that they took to do this. And we won’t cover in detail everything that they talk about. We’ll obviously link it up in the show notes. But we did want to kind of walk through some steps of how you might be able to kind of replicate what they’ve done to also get your first 10 SaaS customers.
And so the first thing they talk about is don’t rush. And the post mentions there’s a lot of pressure to launch early and grow from day one. But premature growth can be detrimental to a small team that’s not equipped to handle a large number of sign-ups. And, back to my voice here, not only can it be detrimental if you can’t handle the support and can’t handle the onboarding, but it can be detrimental if you have a product that nobody wants yet, and you launch and people try it, and then they don’t give you a second chance later on. Whether your product is just plain bad, if it’s not built well. Or if you haven’t built something people want yet it’s going to be really hard to get the benefit of the doubt and get another try out of folks six to twelve months down the line once you actually have built your killer tool.
And so ParseHub – in the posts – talk about how they didn’t launch publicly right away, that they focused on finding a pay-in point. They solved one problem for one type of customer very well. And this is where having this early access – I called it the “slow launch”. I mean, DRIP launched over the course of six months, in essence. We got customer number zero and then customer number one and we figured out “How do we built it until they get value?” And then customer number two. And we built up one at a time. And ParseHub, in essence, did a similar thing where they really took they’re time to focus on finding a real pay-in point and solving it for one target customer type.
Mike [03:53]: And I think in most cases that’s probably the way to go if you don’t have traction yet, and you’re not really sure if what you’re launching is really what people need. I mean, so there’s a difference between what your vision for the product is and what you’re able to deliver on day one. And there’s a lot of people who are going to be willing to put up with the early access bugs and the lack of features and functionality that you just aren’t going to be able to have on day one. And then there’s going be this large category of other people who are not willing to wait, and they don’t want to because they’ve got a problem right this second that they need solved and they need to have either you solve it or somebody else. And if you can’t solve it right then and there for them, they’re not going to be willing to wait.
So, I think that this point kind of drives home the idea that there’s this certain classification of customers, or prospects, that you have to have early on that are going to be willing to work through whatever those issues are over whatever that timeframe happens to be for you to get to a point where you can deliver not just everything that they need, but go above and beyond it, to the point that you’re able to attract and retain these other types of customers.
Rob [04:52]: Another reason that they’ve said don’t rush is that they’ve spent a ton of time up front solving this problem well. They said there are dozens of competitors that can extract data from simple, well-structured sites. But nobody could tackle the edge cases. ParseHub essentially spent a year – they said they grabbed a random sample of 30 scraping jobs from oDesk and they told themselves they wouldn’t launch publicly until they could handle at least 20 of them, and it took almost a year of development before they hit it. By that time, they’d built something really unique, really special. But what is they’re value proposition then? We can scrape sites that no other tool can. Like we are, quite literally, the best. We know that no one else can do that. So, they had a value prop that they’d developed through working with real customers over a longer period of time then most start-ups would be comfortable with. And – I haven’t done research into ParseHub – but I’m guessing by the fact that they took that much time that they were bootstrapping. Because if they had a big chunk of funding they probably would have been pushed to hire faster and get bigger faster. But instead they were really trying to build – in this case a better product – and seeking that product market fit in essence of building something people wanted. And it took them a long time. And it will very likely take that long when you’re doing it as well.
So, the second tip they offer is to perform extensive user testing with potential customers. They said they did more than 50 hours of user tests. And they said almost every change to their product was hinted at by what users did during an interview. They had friends, co-workers and friends of friends use the product while they watched. They found potential customers on marketplaces like Elance and oDesk and PeoplePerHour. They interviewed early adopters. They tested usability. They did all that stuff and they asked questions. Here’s a few sample questions they asked: “What web scraping techniques and tools did you try? What did you like or dislike about them? What kind of websites do you want to get data from? What do you need the data for? Is that data essential for your business?” And so, they said they focused on solving the customer’s problems. And they spent a ton of time doing it. So again, this is part of the don’t rush. It’s like, do it well. Don’t try to short-circuit this part of the process. We’re all in a hurry, and we’re all impatient and we want to get there, but realize that investing the time now will yield dividends if you really nail it in this early stage.
Mike [06:55]: And I think the point of what they’re trying to get at here is, specifically, that if you know what the customer wants before you try and build it then you can design towards the customer expectations, not what you think that they want, and then try to match it up later. At which point you’re going to have to go back and adjust for whatever that gap is between what you thought they wanted and what they actually were looking for. And that’s going to hold true regardless of whether or not you’re using the tool. And I think that if you are using like whatever the type of tool is that you’re building, if you’re in that target market, then you’re probably more prone to maybe make some assumptions about what the customer really wants. And that can be very difficult to adjust for the gap between where you ended up versus what they were really looking for, what they really needed.
Rob [07:39]: And the third tip they lend is to build something people will pay for. So, very much like building something people want. And I think the way they phrase it is they say, “Provide value that customers are willing to pay for.” In their post they say, “Finding a problem is great, but is it a problem that your customers are willing to part with their hard earned cash to solve?” They said before they had a product they would go on oDesk every day and apply for web scraping jobs. They asked people to commit to $150 a month for a tool they could use themselves. And once they got a few commitments, then they were sure there was a need to actually build software. And they point out that customers will pay you if you help them make money. We’ve said this many times on the podcast. Help them make money, help them save money, help them save time. And they found a product that, in essence, does all three.
Mike [08:24]: I think it’s very easy to kind of skip this particular piece of it and think that you’ve got this problem that needs to be solved, and it needs to be solved so people are going to be willing to pay for it. And it’s really a matter of whether or not they’re going to be willing to pay you for it. And the other side of it is whether you’re going to be able to find additional people who are also willing to pay for that. Back in late fall, when I started the process on Blue Tick, there was actually another idea that I was looking at and I really thought that that was the one that I was going to be able find traction with and get customers for, and it turned out that it wasn’t. It was an interesting problem. I think that there was a lot of money to be made there, but I don’t know if I would have been able to actually make that work, because I couldn’t find enough people that were – essentially a critical mass – that would have been able to develop into a customer channel. So I think that you have to have those conversations with people and find enough of them early on. And if you can’t go through the process and find even just 10 or 20 people who are willing to pay you for it, then what’s going to make you think that you’re going to get 100 or 500 or 1,000? So, if you try to think to yourself, “Oh, well, that’s a lot a work. I don’t want to do that.” Well, you’re not going to really be able to build a business if you don’t do that to begin with. So, you have to take a little bit of a step back and at least just take a baby step in that direction. Try and find the core group of users that you’re going to target. And if you can’t find them, you’re probably not going to be able to scale that into a viable business.
Rob [09:44]: They’re fourth tip is to leverage marketplaces and communities. And, with ParseHub, these guys focused on Elance and oDesk, but they specifically have a couple questions you should ask yourself. Number one: Where does my customer spend his or her time online? Two: Where does he or she look to find a solution for the problem I am trying to solve? And they give a couple of good examples. They say, “If you’re running a business that can help jewelry designers sell more product, reach out to them on Etsy?” If you want to solve a pain point in the real estate market, you can try kijijirealtor.com and other industry-specific communities. If you’re developing a solution for teachers, you can find them on Udemy or Skillshare.com. The idea here is that if you can find a community or a marketplace you’re not looking to scale it up to a bazillion users at this point. What you’re trying to do is get early feedback. And it gives you a little bit of exposure to people who are experiencing a pain point pretty dramatically, and if you’re solving that you are going to get some interest from folks. And that’s the point, you’re looking five, 10, 15 people at this point. Which the reason the title of this episode is ‘How to get your first 10 SaaS customers,’ so you’re doing stuff that doesn’t scale very well at all. But that’s the point. You’re just trying to hone in on their needs at this point so that you can solve them, and then you look to scale it later, and you look to replicate that out and expand it.
Mike [10:57]: One of the things that I really like, that they kind of eluded to in this particular articl,e which was they went out places like Elance and oDesk and looked specifically for job postings to solve this particular problem. They used those to help build their software, because it was evident from those job postings that people wanted that particular problem solved and they were willing to pay the money right this second for it. So, I think it’s worth going out there and taking a look at those different types of sites to find out if there are active job postings to solve the problem that it is that you’re trying to solve. That might also be a good place to just leverage to find ideas as well. I mean, if there’s enough people that are paying for a particular job over and over and over again, or particular problem they need solved, then you could, in theory, build software that is going to solve that problem for them. And – maybe you’re not going to be able to sell it to them because they need the solution right this second – but down the road if they need that problem solved again, or if there are other people who also come across that particular problem you can get them into a sales funnel and solve it later for them.
Rob [11:58]: Yeah, I agree. It’s a hack I don’t know that I’ve heard about it before, but it totally makes sense. These aren’t going to be easy things to solve. Imagine going onto oDesk and getting the list of all the people who want something extracted and then looking at those sites. I bet a bunch of them are really nasty, because I bet they had already tried all the solutions available on the market. And so you’re going to have to do some hard work here. You’re going to have to solve a hard problem. But that’s the nice part, is that you’re going to be able to charge for that if you are in fact able to solve it. I get the feeling so many of us as engineers, or of the engineering mind-set, or even just the entrepreneurial mind-set, once you have a problem you really want to tear into it. But it’s just finding that problem that people are willing to pay for. Even if it’s hard and you’re willing to spend six months of nights and weekends, or as these guys spent a year of customer development time. Finding the problem and vetting it is perhaps as challenging or more so than solving it itself.
The fifth tip from ParseHub is to engage on Q and A sites like Kora and Stack Overflow. And they talk about how they answer questions on Kora and Stack Overflow about web scraping and that this had a measureable impact on their revenues, especially in the early days. They also talk about launching on Hacker News Reddit and [Product Time?], which I think these days most people would probably try to do and they talk a little bit about. But I like the Kora approach which they reference – there’s a Kora how-to guide by Kissmetrics. And they talk about how there’s 40 underrated niche sites where you can post about your start-up and you can engage about that. This is – I’ll say it’s a somewhat common approach – it’s not completely novel or new. But if you can get on Kora or Stack Overflow and you do provide value and you can answer questions, because by this time you’re such an expert in your topic that probably off the top of your head you have more knowledge than 99+% of the people on the site. And so you actually can, off the top of your head, answer stuff with really in-depth numbers or thoughts or metrics because it’s just something you’re living and breathing. I have seen this with my products. Whether it’s DRIP today, or HitTail previously. I have seen getting customers from these types of things, because what’s interesting is that these aren’t just forums off in the corners of the internet. These are big sites with a lot of traffic, and the people who search for these questions are desperately seeking an answer. And so if you can provide a good answer to it – it doesn’t even need to be that the answer is “Oh, use my product.” The answer can often just be here’s some insight, here’s some metrics, by the way I learned this as the founder of this product. And it lends you that credibility. I like this approach.
Mike [14:20]: The other thing that nice about that is, as you said, these sites have lots and lots of traffic. And it’s not just the immediate traffic from the people who are asking the questions. It’s more the long-term traffic over the course of a year, or two years, or five years, because those answers that you left several months or years ago will continue to be searched and indexed, and people are going to look for those. Because the same questions on forums tend to come up over again. So, even on Kora you’ll find that the same types of questions keep getting asked and they keep getting answered. And even on Stack Overflow, to some extent, there’s a lot of times where there will be one canonical answer. And that’s really what the community there strives to try and do. But a lot of times there’s variations of a particular answer, and you can go in and you can answer them. And as Rob said, you just drop some notes, “Hey, I learned this as the founder of X.” And people will go through those and they’ll take a look at it and if they still need the problem solved, or if they still have questions, they’ll click through and they will end up at your site, and hopefully that will lend itself towards another marketing channel. But I do know people who’ve been using Kora to some degree of success to try and help push their sales funnel further.
Rob [15:26]: Yeah, and you might that that Kora doesn’t scale – and it’s not going to scale infinitely – but you see entire brands built just on answering Kora questions. Like with Jason Lemkin and [SaaStr?]. He says that’s how he built, pretty much, the core of the SaaStr brand. And he’s answered thousand’s, I’m assuming – I’m sure you’re going to look and see how many he’s answered – but thousands of Kora questions. And he’s become kind of the defacto guy to be talking about B2B SaaS, and how to grow that because of that. So, while you may not have the time to do that, if you’re able to answer questions up front and then later on you can use the approach that Steli does at close.io where he says they’ll often put out a blog post. And then he basically records a video and then they turn it into both a video, audio and a blog post. And then the kind of editor – the guy who’s helping him do the content production – reads the post and gets the ideas out of it and goes onto Kora and figures out are there questions that pieces of this post answer? And then will answer it, whether it’s posting it all on Kora, or linking back. I’m not exactly sure how they do it. But There can be value that is a somewhat scalable thing, because it’s not using Steli’s time anymore, and you’re not using someone else to continue offering a lot of value to the audience and answering questions that they want answers to. And, in effect, getting some of that value back by the handful of people who are going to click back and potentially check out your product.
The sixth and final tip from ParseHub about how to get your first 10 SaaS customers is to use Twitter. And, specifically, they say that Twitter works magic, and so do your first few loyal fans. They talk about how they had a few users give them positive shout-outs on Twitter. And that after their initial launch, someone noticed them and reached out to write about them. And, to quote, the author says he wrote an honest comparison between ParseHub and Komodo Labs and he included the pros and cons of the first version of ParseHub. I agree. I have this love-hate – mostly hate – relationship with Twitter and Facebook for that matter. You need to use your head when you’re doing this. You can’t be on Twitter all the time, in my opinion. You need to be running your business. But, he’s right that monitoring Twitter and engaging with folks, especially in the early days, will earn you fans. It can earn you press. I’d say it’s more important in this early stage, as you’re starting, to get momentum. And he indicates that the opinion of your first few users matters more than gold. Reach out to them. Ask for their feedback. Engage them in your story, because then they become advocates of yours. And if they like you and they like what you’re doing, they’re the ones who are going to help spread the word. And so, engaging with them on Twitter is one way of doing that. Email is another. The nice part about Twitter, of course, is that it’s public and if folks are asking you questions or high-fiving you essentially, virtually through Twitter that’s a nice way to engage and kind of I guess broaden your reach so to speak.
Mike [18:05]: That’s also a double-edged sword because if they’re experience was a negative one then, of course, it’s out there publicly for the entire world to see throughout all of human history at this point.
Rob [18:13]: But most people, like if you really are working with them and they have a negative experience, they tend to do it via email.
Mike [18:18]: Right.
Rob [18:19]: Especially in the early days when you’re really hands on. I would hope that you could handle that one on one and –
Mike [18:23]: Sure.
Rob [18:23]: – help them move along. But you’re right. It is a danger.
Mike [18:25]: Right. I mean, I won’t say I take issue with this so much as it really like – I don’t think that Twitter is a silver bullet for every single business. I think it’s great that it worked for them and it’s great that they were able to land an honest review between them and somebody else. But that’s certainly not going to happen to everybody. In some ways it was a lucky coincidence, but in other ways if you are really working hand-in-hand with a lot of customers over the course of a year to build your product, then that’s going to happen naturally on its own, regardless of whether it’s Twitter or some other place.
Rob [18:55]: Yeah. I would agree with that. That’s a good point to raise. There is absolutely some serendipity in this. I think there are ways to tip that serendipity in your favor by providing amazing support and hand-holding experience up front. I think, if possible, working with influencers – whether you’re handpicking them or whether you’re just lucking into them – that’s always a big one. Because then you want to know that email list or a big Twitter following, they tend to want to create content to send to that list and, if you really knock their socks off, it often gives people an excuse to talk about you. It’s not a sure fire thing, for sure. And you’re going to spend a lot of time that’s never going to yield anything. But at least ParseHub, in their early days, said that they used it to great effect, or at least to get them to that 10 customer mark. And I think if you did all of their other things and didn’t use Twitter, I think you’d be just fine. I think Twitter is more or an icing on the cake if you’re already there and you know your audience is there as well and that that is going to be a viable channel, then I think it’s something to think about. But I wouldn’t prioritize it as high as any of the other points we’ve spoken about.
Mike [19:53]: Right. But I think that’s more because it’s so dependent upon those other things. I think that your comment about icing on the cake – I think that that’s very true just because of the fact that if you do all of the other things then Twitter will work well, or Facebook, or showing off your stuff publicly is going to work well because you’ve already worked with customers a lot. You’ve seen exactly what they’re looking for and what they’re willing to pay for, and you’ve done all of those other things. And it eventually leads you down the road of being more public about your stuff, and being more public about your interactions and the success that your customers are having, which then leads to these other things and these other success marks like the unbiased reviews and things like that that you can then highlight. So it becomes something of a snowball effect at that point, whereas if you were to start out with Twitter, for example, it just wouldn’t work because there’s nothing to base it on. You don’t even know if you have a viable product yet, or you’re solving a real problem that people have. So I feel like this is not just the last on the list because it just happened to fall there, but because it naturally falls there. It has to, because all of the other things have to be in place in order for that to really work well for you.
Rob [20:57]: So, again, we’ll link up the full blog post in the show notes. And, hopefully you’ve enjoyed this look today into how to get your first 10 paying SaaS customers.
Mike [21:05]: I think that about wraps us up for the day. If you have a question for us, you can call it into our voicemail number at 1-888-801-9690. Or you can email it to us at questions@startupsfortherestofus.com. Our theme music is an excerpt from “We’re Outta Control” by MoOt used under Creative Comments. Subscribe to us in iTunes by search for Startups and visit startupsfortherestofus.com for a full transcript of each episode. Thanks for listening and we’ll see you next time.
Episode 257 | Mistakes Founders Make in Getting Traction
/
Show Notes
In this episode of Startups For The Rest Of Us, Mike interviews Gabriel Weinberg, founder of DuckDuckGo, about the mistakes founders make in getting traction. They also discuss Gabriel’s new book “Traction: How Any Startup Can Achieve Exposlive Customer Growth”.
Items mentioned in this episode:
Transcript
Mike [00:00]: In this episode of Startups For the Rest of Us, I’m going to be talking with Gabriel Weinberg about the mistakes founders make in getting traction. This is Starups For the Rest of Us, Episode 257.
Mike [00:17]: Welcome to Startups For the Rest of Us, the podcast that helps developers, designers, and entrepreneurs be awesome at launching software products. Whether you built your first product or you’re just thinking about it. I’m Mike.
Gabriel [00:25]: Hey, I’m Gabriel.
Mike [00:26]: And we’re here to share our experiences to help you avoid the same mistakes we’ve made. How you doing this week, Gabriel?
Gabriel [00:30]: Great. Thank you for having me come back.
Mike [00:33]: Yeah, no problem. So to give the audience a little bit of preview here, we’re going to be talking to Gabriel Weinberg about the mistakes that founders make in getting traction. We talked to Gabriel back in Episode 199 about a year ago, and for those of you who don’t remember or didn’t listen to that episode, Gabriel was the co-founder and CEO of Opobox which sold for ten million dollars back in 2006. In 2008, he started DuckDuckGo which is an internet search engine that emphasizes protecting searchers’ privacy and avoiding the filter bubble that is offered by personalized search that you would be most familiar with from Google. So you’ve co-wrote the book ‘Traction’ with Justin Mares and people can find that at either tractionbook.com or Amazon or Barnes and Noble. The new version comes out today. In that book you talk mostly about the bullseye framework that people can apply to help them get traction. Because the second edition of the book is hitting shelves today, can you give us a little bit of a refresher for those people who didn’t catch that episode about the bullseye framework and what the book itself is about?
Gabriel [01:32]: Yeah, sure. I actually started working on this book a long time ago, back in 2009, when DuckDuckGo was just starting to get traction itself. I was trying to figure out how do I get more traction, which is obviously what almost every business sets out to do once they launch their product. How do I get this thing traction? I found out that there was no great framework for getting traction. There was nothing like a procedure you could do to really think about how to pick the best marketing channel for your business at the time. So I went out just to investigate that myself. Then after interviewing lots and lots of people, really hit upon this framework, and extracted it from their successes and called it the bullseye framework because of all the channels that you can use, and we identify 19 in the book, you’re really trying to hit that bullseye, the right channel for you to grow your startup and meet your traction goal. So once I had the framework, I realized there’s really a need in the market for this book just so that startups can use this. That’s when I got my co-author, Justin Mares, to help really flesh out the book. From then, I thought I was 70 percent done, but I was really 20 percent done and I had to really write the book, edit it, and put it out last year. People started using it right off the get go and it starting working really well for people. We sold 35,000 copies, sold out our three printings. Then I started talking to people, doing events, and all sorts of things and really understood where people were getting it wrong and where people were getting it right. From that, I wanted to do a re-write that more crisply helped people get traction and that is what this second edition is. In that context, the bullseye framework in the first edition was a five step process and we simplified it in the second to a three step process. That three step process is simpler and it is the following: the first step is to go through all the 19 channels, these are all the different ways you can get traction, SEO, search engine marketing, trade shows, etc., there’s 19 of them, and really brainstorm a test in each channel where you could possibly get traction from that channel. Then the second step, and we’re talking about this, but the visualization of this framework is a bullseye, like a target, with three rings. So that outer ring is these 19 channels. Then the middle ring is you pick three that seem the most promising tests to run then you run those tests. Those tests are meant to be very small, simple tests, take less than a month and $1,000 to figure out how many customers you can really get through that channel, how much it would cost to acquire the customers, and are those the right customers you need right now to achieve your traction goal. So you run those tests in the middle ring. Then hopefully we assume one of those middle tests look really promising. One of those channels seems like it could be the channel to move the needle for your business. Then you go down to the inner ring, the bullseye, and you double down on that channel and focus on it and try to achieve your traction goal through it by running additional sets of tests within the channel to discover the best strategies to do that. So that’s why it’s called the bullseye framework is because you’re trying to hit that bullseye and find that one channel of the 19 that is going to make you hit your traction goal.
Mike [04:49]: When you went about this new edition of the Traction book, what areas were you seeing where people were making mistakes in implementing it? Was it a result of the fact that it was a five step process and it needed to be cut down to the three step process or were they just kind of misinterpreting different things? Is it the difference between optimization or understanding?
Gabriel [05:07]: The three step process really simplified it and people were a little confused by some of the steps that we had cut out. They were things that you needed to do, like ranking the channels and prioritizing them; really we combined into just one step. There was a little confusion around that, but the bigger issue was in each of these now three steps there are ways that people routinely messed them up. We tried to reorganize those parts to really make it clear to not mess it up in those ways. They’re non-intuitive ways and I can go through each of those. Besides, that’s all in the intro, the first five chapters. Then the last 19 chapters are a chapter for each of the channels. For those, we updated them and we really tried to edit down the parts that were kind of too fluffy. We just did better editing. We ended cutting out about 50 pages of the book even though we added two additional sections, a preface which explains kind of my history of getting traction and some of the mistakes I made, and then a testing addendum at the end which is one of the things people really wanted and were messing up of how to do cheap tests in each of the channels. We have a list of all the channels and we give you a way to do cheap tests in each of them.
Mike [06:20]: I think those extra tests are extremely helpful just because it may not necessarily be clear for some people, for example, offline ads or viral marketing and things like that. You kind of have a conceptual idea of what it is, but you don’t necessarily know how to go about doing it because you’ve never done it before or you’ve never considered it before. I think the addition of those things can certainly help a lot of people. What are some of the broad non-intuitive mistakes that you were seeing people make over the last year of talking to people that are pretty common?
Gabriel [06:52]: Right. There’s four of them. Three of them relate to each step in the new process. The first one is over-arching before that and it’s not starting traction early enough. People think that they need to, and we did say this in the book, but you know now it’s says a lot more crisply, people think that you really need to launch a product before you start going to get traction. The reason is the ‘Leaky bucket’ metaphor. We reuse that in the book and try to use that to explain it. The ‘Leaky bucket’ metaphor is when you start your product it has a lot of holes in it, right? It’s essentially a leaky bucket and if you pour customers on the top, and you can think of customers as money because it costs to acquire customers, then that money is leaking out. So the intuitive answer is I should not spend money on traction efforts until my bucket holds water. The problem with that is that what people do instead is they get beta customers and they get these beta panels and they iterate on the product just off these beta customers. Those beta customers, they’re too close to you. Not only do you become friends with them and you kind of know them, but they are not getting first impressions of your product at any time. They are seeing this evolution of the product and they are primed with what they previously know whereas if you have a steady stream of cold customers coming through, through some traction efforts then you’re constantly seeing real market feedback and whether your product is really going to resonate in the market. You want that so you can really figure out where the holes in your bucket are or else what happens is, this is what usually happens, you then launch your product, start to get traction, try to get traction, and realize, “Oh, I thought my bucket wasn’t leaky from my beta customers but it really is still leaky.” So you really want to start that traction effort right away, right at the beginning of product development. We try to argue strongly in the book that you should spend 50 percent of your time on it. Just to make it even more clear of why you should do this is you think that you might be getting a lot of this information from your product development methodology from your beta customers, but what you’re getting in addition to finding the holes is when you’re testing these traction efforts, you don’t have to spend a lot of money on it just to get a few customers coming through cold, you’re figuring out what messaging is best. You’re figuring out what niche to focus on when you launch. So when you do launch you can figure out the right channel to launch with, the messaging, the niche to focus on, and you can really hit the ground running with a real useful product launch.
Mike [09:27]: Yeah, as you were talking, and I’m not sure this is a good analogy to make, but the whole leaky bucket, I think that people have this whole conceptual idea of like all the holes are exactly the same size and I just need to put a patch over each of them, but the reality is that depending on your product those holes can be different sizes. They can be different shapes and the solution to patching each of those holes can be completely different. You need the customers going through that bucket in order to get the information you need to figure out what the patch is for that. So whether it’s a new feature or whether it’s a new marketing message, every single patch is going to be different. You can’t just take a blanket approach of, “Oh, let me create this product and implement all these features because I think that’s what people want.” Those customers coming through and leaking out of the bucket is where you’re going to get the information you need in order to patch those holes. You can’t do it in advance. If you try to, your patch is not probably going to be the right size or shape and you’re going to end up doing too much work or not enough work. In either case you’ve either wasted effort or not done the things that need to be done and you’re still going to be leaking things out the bottom.
Gabriel [10:31]: That’s exactly right. I think the real known intuitive piece is that you have a false sense of security with beta customers. That’s been the product development methodology for a long time and it’s a good one. You should have beta customers, but it’s just not enough.
Mike [10:46]: What are some of the mistakes that people make in terms of the different channels? Because obviously there’s 19 different channels that you can choose from but there’s going to be certain ones that people are much more familiar with. Shouldn’t people be focusing on those?
Gabriel [11:00]: Right. That’s the number one mistake in the first step. When you’re brainstorming all these channels, people navigate towards the ones they’re already familiar with. That’s just availability bias. We saw more and more that people just wanted to ask us and say, “Okay, which of the channels are great for my type of business. Which are good for SaaS businesses, which are good for this offline retail business. That’s the wrong question to ask because you almost want to ask the opposite question. This is the non-intuitive piece of which are the most underutilized channels for my industry or business. Often those are the ones that are greenfield that you can have huge traction opportunities in. Unfortunately, the piece that people mess up is they often ignore these underutilized channels because they’re not familiar with them because they’re from that industry. Say everyone in that industry is using search engine marketing so therefore they need to use search engine marketing. That’s usually a bad idea because that channel is very competitive because all your competitors are using it. If you could find something better to do, even offline, that would be a good choice. A good example of this is WP Engine, the Word Press and hosting company which we profile in the book. They are an online hosting company for word press. A very competitive industry. They ended up going for two very underutilized channels through different parts of their growth. One was offline ads. So they ended up a lot in magazines which no one else was really doing. Then two, they built a side product, a speed tester for word press which we call as a channel engineer and as marketing where you build this other tool that’s completely free on another website that’s complementary to your product. Then everyone started using their speed tester and then they could capture their e-mail and upsell them on the hosting product. If they had just focused on the regular channels, search engine marketing is what people mainly use and SEO, they would have had a much harder time growing.
Mike [12:53]: Now isn’t the risk of doing that also that you are choosing channels that your existing competitors have tried to make work and were unsuccessful doing? That would be my natural inclination. My fear would be, “Oh well, I’m not sure about doing offline ads because there must be a reason that my competitors aren’t doing it.” Is that a fear that people should be concerned about? Is that a real fear or is that more imagined than anything else?
Gabriel [13:19]: I think that’s a fear that people really have. It’s an imagined fear in the sense that almost everyone has the same availability bias and so, quite honestly, no one is really testing these under utilized channels for the most part. But, you make a really good point which is it’s almost the highest leverage tactic you can do. Go talk to other founders, not currently competitors, but failed competitors in your space who are very willing to talk to people usually. They’ll go tell you about all the things they tried and why they failed. It may be the case that they did try something five years ago that didn’t work for x, y, or z reason that may work now or you may discover they tried a bunch of things that for good reason won’t work now. This is kind of the other broad area where people fail in this first step of brainstorming is that they don’t really brainstorm deep enough. You really want to have a good sense of your competitive landscape, whatever you think, marketing channels everyone’s tried, go talk to people of things they haven’t tried, go talk to complementary industries to see what they’re trying. There may be some overlap there. Really spend a lot of time thinking about each channel and how it could be used whereas what mostly happens is people say, “Oh, I don’t know much about that. I guess maybe I could use that for something,” and they give it maybe a minute of thought. The problem with that is that underutilized, overlooked channel may be the one that could just jump you to success.
Mike [14:46]: But I guess how would you know? That kind of comes back to the question of how to test these different things. If you’re looking at a particular channel and you’re not entirely sure how to go about testing that channel, there’s, I think, this bias towards not spending a heck of a lot of money or time doing it because you don’t know what you’re doing. How do you come and get past that? How do you scope the tests that you’re doing such that you’re not wasting time and money, but you’re still doing what would essentially be a definitive test to find out whether or not that channel is going to work for you?
Gabriel [15:18]: Right. That’s exactly why in the second edition we added this testing addendum where we’re giving you suggestions of how to test these channels. In the scope of these tests, you’re trying to answer three things again. You’re trying to answer how many customers could I get through this channel and how scalable it is; how cost effective it is, how much does it cost to acquire customers through the channel; and are these the right type of customers that I want right now because each channel can bring in slightly different demographics and types of customers. You’re measuring those against your traction goal which is also a hard number, which in the beginning is often how much traction do I need to get to profitability or financing. Say I need 1000 customers and I run a test and this channel we only think it’s going to give 100 then that’s probably not going to be a good one to focus on whereas one of these that say, “Oh, it seems like I can get 10,000 if I really blew this out.” That might be a good one to focus on. So what you’re doing in that first step is really identifying tests you can run in each of these channels and then you look at them and you say, “Okay, based on my guesstimates of these tests, I think these three tests are the most promising to run.” Then you literally run them in the second step. The part that people mess up in that second step is trying to optimize too early, premature optimization there, and if Facebook ads are the channel you’re going to test, you run 40 ads. You really shouldn’t be doing that. You should be running four ads and what we say in the book now is don’t run a test longer than a month or more than $1000 except in extenuating circumstances. Then from those tests you can have data to dump to the next step. So to really answer your question is you need a good way to run a cheap test in these channels and if it’s cheap and short then it’s really easy to test these underutilized channels because you have a good sense of what you can do that doesn’t take a lot of time or money to really bear out whether that’s going to work or not.
Mike [17:12]: Now are there any guiding principles around that $1000 versus the month of time? Is that just an arbitrary cap or is that something that is helpful for a founder who is trying to boost up a company and they have much more time than money versus somebody who says, “Hey, I really need to find this out fast, let me just blow $1000 in a week to try to test out say paid advertising or something like that.” Are there guiding principles around striking that balance or is it more just kind of what resources are available to the founder?
Gabriel [17:42]: Well we look at all, we try to come up with good cheap tests for all the channels. We looked at them and we said, “Okay, that cutoff seemed appropriate and it encompassed all these test ideas.” Then where we saw people messing up was they were spending either too much money or too much time on these tests and not cutting them off sooner when they had the information they needed. So, yeah, it is a guiding principle. I think that particularly is guiding for early founders trying to initially find their traction channel. The caveat there is like DuckDuckGo or I Am Now, we’re running tests of much greater magnitude because our traction goal is so much higher and we want to get the error bars down on our estimates so much lower. So we’ll run bigger tests that take longer and take more money. When you’re first starting out or just going into a channel for the first time, I think you should keep it really small, even if you had a lot more money and time. There’s no more reason because you reach diminishing returns very quickly on these tests.
Mike [18:43]: Got it. So the purpose of those principles of $1000 or no more than one month of time are really for newer businesses that are just going into a channel and those limits can fluctuate between the different types of channels that you’re going into. So when you’re targeting blogs, for example, you wouldn’t probably be spending $1000 but it might take you several weeks of back and forth with the relevant blog owners in order to get your product mentioned on their site or to kind of get through their process of doing guest posts versus something like paid advertising where you may very well spend up to $1000 and you can do it within a couple of days, but those bounds are really to encompass all of the different channels that you might try.
Gabriel [19:27]: That’s right. Exactly. A lot of the tests will be free. Some of them you can do very quickly. Yeah, they’re more like guidelines of limits. If you see yourself going over these limits early on, you might be doing something wrong.
Mike [19:39]: Right. That totally makes sense. I just wanted to make sure that we clarified it for the listeners. So are there any other mistakes that people are making when they’re going into specific channels? If you’re testing a specific channel, what sorts of things should you be focused on? Obviously there’s also the potential to focus on multiple channels. Why wouldn’t you try to do more than one at a time?
Gabriel [20:00]: Right. So in the testing phase, the things that people really messed up are the premature optimization, going too deep while you’re just trying to get error bars around these numbers, and the second is not really doing it quantitatively which we really haven’t mentioned. You have these three questions you’re trying to answer and you really should be trying to get hard numbers against them and then compare those numbers to another hard number which is your traction goal. Once you identify the right channel that is really promising that seems like it might actually work in the sense that the numbers look good, and if it looks like you started to optimize it and scale it, it would reach your traction goal, then you’re doubling down. This is the other area people mess up. This is the inner circle now. You hit the bullseye and you’re working on that channel not getting rid of the other channels. It’s really non-intuitive because say you have three promising tests in channels. Say you did a little PR and you did some social ads on Twitter and you did some offline meet ups. All three, they were promising. They had a little bit of success, but the Twitter ads were just well and above the rest. The right thing to do in our framework is to double down the Twitter ads and really focus on that. What people often do is they still focus a bit of their time on the PR and the meet ups because they know they are going to get some results out of them. The problem with that is their marginal benefit of focusing on the Twitter is much higher and when you really focus on it, what you’re really doing then is now focusing your testing effort on that one channel so now you’re uncovering the underutilized strategies and tactics within that channel. The only way to do that is to really focus. The time you’re spending on these other channels that yeah, they get you a little traction, but that’s time taken away from uncovering the best tactics you could use on the main channel. That’s the other area that people messed up when they’re focusing is not really doubling down on the one channel and getting rid of the other tests they were running.
Mike [22:03]: It almost seems like by focusing on the one channel you’re getting exponential results versus some of these other channels where you’re getting incremental or multiplicative results which are not comparable if you go far enough into that one channel that you’ve dug into or that you’ve identified as the one that’s going to give you the most traction. Is that an accurate way to portray that?
Gabriel [22:22]: Yeah. Not everyone can get the exponential growth, but that’s what you would hope. To do that, what you’re doing or advocating is you are becoming a worldwide expert at that channel. If you’re really focusing on say social ads via Twitter and Facebook, you’re really digging into all the case studies, all the forums, what people are on the platform cutting edge, what they’re saying about their own platform. For example, so right now Facebook video ads are kind of outperforming everything because Facebook is really focused on competing there. That may not be the case a month for now, but you want to be first to those tactics because when you’re first to those new tactics, those are where that exponential stuff really happens, the really high click-through rates and things like that. You want to be on the cutting edge of those. This just goes more into saying that going to underutilized places in the world gives you great conversion rates both channels and then tactics within channels. The only way to really do that is to really be in optimization mode and that requires a lot of effort and all that other effort is distracting you from getting there.
Mike [23:30]: Now one of the things that you talked about earlier was that you have to be in each of these channels and before you even do that you go and you define what your traction goal is going to be so that you have some sort of basis for measurement. Now how do you define that traction goal? What should that look like? Are there some ideas that you can share about how to define what that is or is that more specific to the type of product that you have?
Gabriel [23:54]: Yeah, I totally agree. That’s basically step zero. The other thing we added to the book was a preface about a little more of my history. That’s something I messed up early on. To give you a good example, I set out early on to get traction via SEO because that’s what I knew from my last business. But it turns out that I was pretty successful at that and spent a lot of time doing it and so I ranked really highly for the term new search engine to get to duckduckgo.com. I got number one on it, but it was just not enough people to really move the needle for what my traction goal really needed to be which ultimately was like 100,000 searches a day, not 10,000 which is where that ended up getting me. If I had sat down initially and realized my traction goal should be 100,000 searches a day, then I would have looked at SEO and either changed my SEO strategy completely or not done SEO to begin with. So it really is important to take a step back initially and figure out what your traction goal is. What I think that should be is a hard number that really moves the needle for your business and achieves some kind of significant inflection point of your business. That could be a number of things depending on what your situation is. The number itself, of course, will vary depending on your business, but for most people starting out that number is often one of three things. It’s how much traction do I need to get profitability, how much traction do I need to get financing, or what do I need to prove that I have product market fit. Those are usually specific numbers like I can look in the market and see which companies are getting financed and see how much traction they have in terms of growth or revenue or whatever the metric is in your industry and say, okay that’s what I need to hit. Then you can back out from that from your pricing about how many customers I kind of need and that’s the number you should be evaluating against these tests. You should definitely start identifying what that goal is. It goes right back to what kind of business you’re running too because if you’re not concerned with high growth or financing and you’re really concerned with paying your bills at a certain level of profitability, then that should be your goal. You should say I need to take home x amount a month and from that I can back out how many customers I need to do that then that should be your traction goal.
Mike [26:10]: Yeah. So those traction goals can either be the revenue that you’re specifically looking at or could be tied to a piece of functionality in your product. For example, a search engine, number of users is much more important, or not even users but like searches per month is important versus if you’re in a situation where you need to be able to pay the bills, you need to have that revenue coming in and you need to be able to tie those marketing efforts directly back to those revenue goals. You can tweak the numbers in terms of the price and the number of people coming in and just do some multiplication there to figure out is this really working for me, is this going to be a channel I can leverage or do I need to go someplace else? Depending on which of those situations you’re in and which of those metrics is important to you, you can then find what your traction goal is.
Gabriel [26:57]: That’s right. That exercise, that’s basically saying what is your business model and trying to clarify that initially, which is really an exercise everyone should do because, like you said, you can think about the pricing of your product. There’s a good post, I’m forgetting who wrote it, about the ‘hunting’ metaphor, but like hunting deer and elephants and different things, but it’s basically saying how much it’s going to take to get to a million dollar business which is what most people’s goal is initially based on what your price point is average revenue per customer. There’s wide ranges of businesses that get $0.10 a customer to $10,000 a customer and knowing where you are on that scale really influences what your goals are in terms of how many customers you need, which then changes everything about how you’re going to get traction.
Mike [27:44]: That article that you just mentioned was from Kristoff Jans and he wrote the blog article on ‘Five Ways to Build a One Hundred Million Dollar Business’. It’s kind of a graph of the size of your customer and how much money they’re paying you versus the number of customers you have. Obviously there’s this graph that goes along with it. I think the two extremes that he uses are one thousand enterprise customers each paying you $100,000 a year or, on the other end of the spectrum, you’ve got 10 million active people who you’re monetizing at $10 a year by selling ads for example. The metaphor is essentially you’re hunting elephants or hunting mice and how many of them do you want to go after and what’s your business model look like? I think it’s an interesting metaphor he used.
Gabriel [28:26] Yeah. He’s got a follow up too. He adds three more things there and he goes down to hunting flies because people wrote him back and they are like what about some of these other businesses? So he has an addendum article. It’s even a wider range. It’s really interesting because each of those categories are very different businesses, but has very direct implications for how many customers you need and how much traction you need and what your traction efforts are. So it’s really good to think about that ahead of time and think about really which type of business am I in? Which category am I on the scale?
Mike [29:00]: I think that leads back to another interesting point about if you start bringing that type of model in and start looking at, for example, a SaaS business versus a services business. Services businesses fit into this model where you’re probably charging them a heck of a lot more because you have to, because you’re interacting with them. You have to sell them on an engagement and it might be five weeks, it might be five years, but the reality is you’re charging them a heck of a lot more and those are kind of your elephants versus a SaaS model where, I guess, traditionally you want to charge as many customers as you can smaller amounts of money. But the problem is that it takes much longer to get that mass of customers. That kind of leads back to the analogy that Gayle Goodman from Constant Contact called the ‘Long, Slow SaaS Ramp of Death’. Getting that mass of customers that you need takes a long time. You can get there faster if you can charge fewer customers more money, which lends itself more toward the services model, but a lot of people are trying to get away from that if they’re trying to build product. There’s this balance that kind of needs to be struck and, as you said, it depends a lot on the model that you have behind your business. I think it’s interesting how that should be what is the piece that’s influencing what your traction goals are. I think that sometimes it’s a little confusing because the type of business that you want does not necessarily match up to the type of business that you’re going to end up with.
Gabriel [30:23]: Yeah. Right. What you’re getting at is people end up going through this and not doing this early and then they meet with kind of that harsh reality a little later on. That’s why I think it’s good to do this early and really think about hard numbers, what your goals are, because that will inform everything. Maybe you want to change what you’re doing initially.
Mike [30:44]: I think that’s a super important point to make just because going through this process you may very well find out, hey this isn’t the business that I thought it was, maybe I should go do something else. So what startups have impressed you with their ability to gain traction and why? What is it that has made them so successful?
Gabriel [31:00]: So we profile a bunch of ones in the book and each kind of has an interesting story that they did something really cool with traction. This concept, I was talking earlier with WP Engine and this engineer and his marketing I really liked because we literally had to name that channel because no one else really had named it. HubSpot and RJmetrics are two other companies that have really embraced that channel and does it pretty well. Moz would be another one. They’re all making complementary tools and sites and they’re using some of their engineering resources. The reason why it’s so cool is it’s non-intuitive that engineer resources are so sacred in a company that everyone thinks they should always use their product, but this is taking a little of those resources and using them for marketing. Developing this other tool that then drives the whole business. So HubSpot recently IPO’d, did that with their site called Marketing Greater where you could go type in your domain name and it would tell you all about how you’re doing in online marketing which basically every business who goes online needs. So they got millions of businesses through there and then from that they had a great lead channel to do inside sales and sell them on their main product. Moz has done the same thing and RJmetric which is a kind of cohort analysis company in data analytics, has done it with a bunch of different sites where a lot of their target audience is in house data development and teams who independently need to do database queries and things like that. So they made all these database kind of tools for these developers and then on there they educate them about RJmetrics. So I really love businesses go after these kind of underutilized channels. Another good example of another under utilized channel is publicity stunts which most people completely shy away from because it seems like they would be unscalable and repetitive. To some extent that’s true. There’s been a lot of ones that happen just at launch. A great example, an old example, but I like it also because I’m in Philly, for example is half.com, Josh Kopelman who currently runs First Round Capital. When they first launched half.com they had a city in Oregon renamed to half.com, Oregon, which was Half, Oregon, and they gave two jobs to the of the people there. The whole thing cost maybe $100,000. Got them national TV across the board, 40 million impressions before there were any social media. So back in 1999 and immediately vaulted them up. Six months later that company was sold for 300 million dollar plus. Then another company who does publicity stunts, Grasshopper, they really have invested in this over time and they have two employees completely dedicated to thinking up these publicity stunts and things they can do, run contests and things like that. Half of them fail, but they’ve gotten most of their traction through this effort because when they do take off it’s such a great press story. They get so much press it makes up for everything.
Mike [34:05]: Now at what point do you start taking into account the ROI on some of these channels because some of the things that you just used such as HubSpot, they have these different website marketing graders and things like that, but their price point is also substantially higher than I think your average run of the mill SaaS application. I think that their pricing starts at $200 a month and if you kind of extrapolate and say, “Ballpark it, I don’t know what these numbers actually are.” If an average customer sticks around for two years with them, that’s $4800. So for them it makes sense to fill that pipeline with as many people as they can because each of those customers is going to net them $4800. It becomes this awkward situation, especially for the people who are running really small businesses where the look at that and say, “Well that sounds great, but I can’t really afford to have an inside sales team calling these people even if that is going to be successful because I just simply can’t afford it.” How do you take those types of considerations into account?
Gabriel [35:01]: This is where the testing really comes into play. When you’re running these tests you’re trying to assess those three numbers, what the scaleability of it is, how many customers, how much it’s going to cost to acquire the customer, and is it the right customer? The second one, how much does it cost to acquire the customer, is the key one here. In this scenario, say the engineer and his marketing, they don’t need to have an inside sales team necessarily. It could be an off the shelf product that you sign up for in some kind of signup flow and that’s the test that you’re running. Will people convert from this and sign up and then how much would it cost to get them? How much contact would I need to have with them. You’re absolutely right. If you’re a small SaaS company you can’t afford any kind of personal contact like that. It costs too much money. So you need to be testing whether it will just work for your regular signup flow. I think that all comes out in the testing. That relates back to your traction goal and kind of knowing how much you can spend to acquire a customer.
Mike [35:57]: I think that’s a pretty good place to wrap it up. This book comes out, I believe, today you said, correct?
Gabriel [36:02]: That’s right. Today. October 6th.
Mike [36:04]: So if anyone’s interested in buying that, they can go over to tractionbook.com. We’ll link it up in the show notes. They can also get it on Amazon or Barnes and Noble, correct?
Gabriel [36:13]: That’s right. We have a couple other retailer links like IndieBound. They’re all at tractionbook.com.
Mike [36:18]: Great. If anyone wants to follow up with you, where would they do that?
Gabriel [36:21]: Twitter is best. My handle is @yegg. Y-E-G-G.
Mike [36:25]: Awesome. Well thanks for coming on the show Gabriel.
Gabriel [36:27]: My pleasure.
Mike [36:28]: If you have a question for us, you can call it into our voicemail number at 1-888-801-9690 or e-mail it to us at questions@startupsfortherestofus.com. Our theme music is an excerpt from We’re Out of Control by Moot used under creative comments. Subscribe to us on iTunes by searching for startups and visit startupsfortherestofus.com for a full transcript of each episode. Thanks for listening and we’ll see you next time.
Episode 232 | How to Design a Killer Client Demo
/
Show Notes
In this episode of Startups For The Rest Of Us, Rob and Mike talk about how to design a killer client demo. They put together a basic four part outline that will help you take your customers to the next step.
Items mentioned in this episode:
Transcript
Mike [00:23]: In this episode of Startups For the Rest of Us, Rob and I are going to talk about how to design a killer client demo. This is Startups For the Rest of Us, episode two hundred and thirty-two.
Welcome to Startups For the Rest of Us, the podcast that helps developers, designers, and entrepreneurs be awesome at launching software products. Whether you’ve built your first product or you’re just thinking about it. I’m Mike.
Rob [00:24]: And I’m Rob.
Mike [00:25]: And we’re here to share our experiences to help you avoid the same mistakes we’ve made. What’s going on this week, Rob?
Rob [00:28]: A couple weeks ago I mentioned I was going to be hiring an executive assistant, super part-time, remote, to help with my email volume, and to go through and do some filtering. And I’ve been thinking about doing this for a couple of years, and really couldn’t see a way that someone could actually help and save me time. But with my schedule going from having four hour tasks, that I do during a day, to basically hundreds of five minute tasks, which is essentially what I do now, I really did see that I probably needed to do it.
So I hired an executive assistant. Found her on oDesk. She’s based here in the U.S., and it’s actually working our pretty well. She’s basically just filtering my inbox into two separate labels. She’s either putting them in one of the two labels or she’s deleting them. And I just gave her instructions, and walked her through the screencast, and then if she has questions she asks me. So the two labels I’m using are ” _today” and “_this week”, and it really translates into “urgent” versus “you can do this whenever.” And underscores there, of course, to keep them at the top of the list. But I’ve been shocked at how much time it’s saving me. It’s not hours a day, for sure, but it’s probably maybe twenty to thirty minutes a day. Just getting all that sorting gone, there’s TrueTwit validations that come through from people on Twitter and she’s handling those and one by one I’m figuring out these little things she can do to save me two minutes here and two minutes there, and it’s cool. It’s cool just to open up Gmail and never look at the inbox. That’s been the hardest thing, either on my phone or on Gmail, is to only look at Today tab essentially and see what she’s putting in there.
Mike [02:00]: Yeah, that’s interesting, because I find the same thing. If I try to avoid doing my email throughout the day, or just try to batch it up, the most difficult thing is not going in there and looking at it just out of habit, sheerly our of habit. I grab my phone and it’s like “Oh, do I have any messages?” It’s obviously a bad habit, but hard to break, too.
Rob [02:16]: Yeah. I do the same thing. And I have peeked in the inbox, especially on weekends. She doesn’t work, so on the weekends I do have to check on my inbox if I want to see stuff that’s coming in. But overall, I’ve been pleased with it so far, and I’m hoping that overtime I can give her more and more little things to do as she learns my work flow.
Mike [02:32]: Very cool. So we got a lot of positive reviews from the “Being Married to a Founder,” episode a couple weeks ago, when we basically outsourced the podcast to our wives. Jay Adams said, “This is one of the best episodes yet. It’s great to hear insights from other founder’s spouses, and how it relates to our own situations.” And Richard says, “Well done. That must have been quite scary to do. I’d love to hear some more advice you could give to founders on how they can make it easier on their spouses.
Rob [02:55]: Very cool. Yeah, I thought that was a neat fifth anniversary episode, right? We could get off the mic and put some other voices that I think have a lot of interesting things to say. And Richard, if you’re looking for other advice on working with your spouse and communicating, that kind of stuff, I have a podcast with Sherry, my wife, and it’s called Zen Founder at Zenfounder.com. Every week or two we’re addressing that kind of stuff. It’s keeping your family and yourself sane while you’re starting up.
Mike [03:20]: And I’ll vouch for it as it’s a good podcast. I listen to it.
Rob [03:23]: Cool. So I have some bad news. I hired a part-time marketing assistant, essentially. He had a full-time job during the day, and he was doing stuff on the side for me. And I had a thirty day trial. We were trying to figure out if we could work together, if he could do the work and stuff, and he quit about three weeks in and he just said, “It turns out I don’t have as much free time in a week as I thought I did.” He said, “I feel bad that I can’t put in as much time as you need, so I’m just going to bow out now before it becomes an issue.” So that was a bit of a bummer. It’s a bit of a bummer to try and get down to someone and hire them, and then have them not be able to do it. But the good news is through some crazy circumstances I stumbled across a candidate who could not only fill that gap of online marketing, but she also has customer success experience, giving demos. She has a unique skill set, I’ll put it this way. Because, normally, you can find someone who can do onboarding, and be a customer liaison or account executive, but they don’t have internet marketing experience. And she happens to have both of them. So I made her an offer this week and it looks like things are going to move forward with that. So very good ending to what was otherwise some bad news that I received last week.
Mike [04:30]: It’s always rough to have to end one of those things in the middle of it, especially when it’s not your decision. But in some ways it’s better to have those decisions forced on you, early, especially, then to have to make the hard decision later on and say “This isn’t working out and I have to end it.” Because then it’s more of a mental weight that you’re going to carry around for probably at least a couple of weeks, if not a month or two, before you pull the trigger and say “This has to end now, because it just can’t go on any further.”
Rob [04:53]: Exactly. And I really appreciated him just coming out and saying. I have no ill feelings at all. I appreciated his honestly, and the fact that he didn’t want to waste either of our time. He didn’t just fade away like a lot of contractors do, and not get back in touch, because that’s, like you said, a real bummer because it drags on for weeks and weeks.
Mike [05:10]: Yeah. I might have mentioned this before. I was interviewing somebody for a developer position, and my typical process is go through, talk to them for a little while on a phone call and explain to them what the position is, and then ask if they’re still interested. And I actually had somebody tell me, “Yeah, I’m not interested.” I was shocked. I was just like “Oh. Okay.”
Rob [05:28]: That’s good to know now.
Mike [05:329: “That’s good to know now. Thanks.”
Rob [05:32]: So before we dive into the meat of this episode, we got an email from Wilson Peng and he says, “I’m a self taught Rails guy, but self-teaching myself through all the sites you mentioned didn’t work.” And he’s referencing our episode, it was three or four episodes ago where we talked about whether a non-technical founder should learn to code or not, if they’re going to start a SaaS app. And we threw out some different sites like One Month Rails and Udemy and other things and he says, “After I started working for Iron.io I was pretty much able to code anything, mainly because we worked out of a co-working space, which is where all the [Dev?] tool startups work, and it was beyond easy asking for help when I ran into problems.”
What I thought was interesting is, one thing we didn’t mention on the “Should I learn to code episode,” is that in my opinion, the best way to learn to code, by far, is to get a forty hour a week job coding and have a mentor. Have someone you are either an apprentice to, or they’re just an informal mentorship relationship, where you can go and they can show you how to architect and they can show you the stumbling blocks and how to get around them. The reason we didn’t mention that on the episode is that the person asking the question already has a full-time consulting business going and he’s thinking about launching a SaaS app on the side. So he doesn’t really have the leeway to go and work forty hours a week salary for someone to learn to code. But in my opinion, it’s far, far better to get a full-time gig in coding, if in fact you do want to learn to code. So what are we talking about today?
Mike [06:59]: Well, we have a question that came in from Guy Lewis, and Guy wrote to us and he said, “Hi, guys. It almost goes without saying how valuable your podcasts are, so firstly, thanks so much for sharing your hard-earned experience. My question is can you do a podcast on how to set up an online demo? What tools and equipment are necessary, and what have you learned about managing consistency across a team? Thanks again, gents. Guy Lewis.”
Well, Guy, I think in terms of the tech itself, the tech can be fairly straightforward, especially if you’re doing an online demo. For our podcasts we just use Skype. I use Pamela on my machine because it’s Windows, and Rob uses –
Rob [07:29]: Call Recorder.
Mike [07:30]: – Call Recorder because it’s on a Mac. You probably don’t need those particular features, and you probably wouldn’t be using Skype to run a demo. I would recommend either GoToMeeting or WebEx. If you go with GoToMeeting, I will warn you in advance that the recording does not work very well. So if you’re anticipating recording the demo, I’ve always had problems with it, and when you do get the recording it always goes into this unique GoToMeeting format that you have to use their player for. So just keep those things in mind when you’re using it. But otherwise, in terms of the tech, in terms of the headset and microphone, I would use a headset. Don’t use a stand alone microphone. Use something that is going to sit on your head. You don’t really want to be using a phone if you don’t have to. If you are going to use a phone, make sure you’re using a headset that goes with it, so that as you turn your head or look at different screens your voice isn’t fluctuating for the customer. You want a very uniform experience when you’re doing that.
As I said, the tech stuff itself is very easy. I think that when you’re looking at a client demo, what you really want to concentrate on is, what is the customer looking for? What is it they want to learn? How do you present it to them? And how do you go through that process of conveying the information to the customer in a way that is going to essentially lead them from that call to whatever the next step is.
So what we’ve done is we’ve put together an outline of the four basic steps of how to design a killer client demo that is going to help you take that customer from where they are today to the next step, whether that next step is them giving you a credit card right then and there or another call or a trial or et cetera.
Rob [08:57]: Yeah, to jump in and actually touch back to the tech stuff. When you get your headset make sure it’s a USB headset to avoid the hum. I often find that gaming USB headsets are pretty good. The other service that I’ve used for giving demos is Join.me, and it’s a free service, but obviously that comes at a price. Free like a puppy. I have used Skype for a bunch of demos, and it’s not the most professional thing, just because you have to add them as a Skype user, as a contact, and then share the screen and stuff. It works fine, but moving forward, if I were actually to start scaling this up, like you said, Mike, Skype is not the way to do it.
Mike [09:30]: Yeah, both GoToMeeting and WebEx have free tiers. So I think that you get up to two or three users, or something like that, and it’s completely free. So as long as you’re not running a large scale demo for five or six people in different locations, you’re good.
Rob [09:44]: Cool, let’s dive in.
Mike [9:56]: So the first step in designing a client demo is your open. And in the opening, basically what you want to do is you want to let the other person talk. You don’t want to go into what it is that you do, or how you do it. What you want the customer to do is you want them to describe their problem in their own words. And if more than one person is on the call, you want them to ask them to reiterate their current challenges and allow other people who are also on the call to chime in. That does a couple of different things. First one is it level sets everyone’s expectations, so that everyone on the call knows exactly why they are there and why they are talking to you. The second thing it does is it allows them to provide you with the information that you need further on in the call.
Now you can leverage things that they’ve said later on, but you can’t do that unless you’ve asked them. So if they say, “Well we’ve had a problem getting our servers connected to X, Y, and Z services.” Later on in your call you can create a hypothetical scenario and you talk specifically to that and you say, “Well, and so and so had this problem where they were trying to get these servers connected to X, Y, and Z services,” and basically reiterate exactly what their problem was, and the fact that you’ve been able to solve it. But again, if you don’t ask those questions, you don’t know the information, so you can’t relate it to them later on.
Rob [10:57]: Yeah, I like this open. I think this combines maybe the first two questions of what I consider a really good sales call outline. And this was presented by Harry Hollander two years ago in his attendee talk at MicroConf. His first two questions of the three question outline are, number one, “What are you doing now for X?” So for me it would be “What are you doing now for email marketing?” [Auto Shark] might be, “What you are doing now to access your server’s security risk.” And the second question is, “What about that isn’t working for you?” And I think that those two combined, kind of gets at this opening, right? You’re basically saying “”What’s your situation today, and what’s the problem with that? Why are we even on this call? Why are you looking at this as an opportunity?”
Mike [11:38]: So, also as part of the open, once the stage has been set, that’s about the time when you start talking about who you are, what the product you have is, what the history of the product is. Some people don’t like to do this. Other people prefer to do it. If you’re talking to large enterprises it’s almost expected of you that you’re going to talk to these things because they want to know that whatever it is that you’re pitching to them has a history behind it, that they’re going to be able to rely on. So the larger the customer, the more you’re probably going to have to put this type of thing in here. But at the same time, there are situations where the person’s done their research. You probably don’t even have to talk about it. I’ve actually gone into demos where I walked in and I asked the questions and then I put up a slide and said, “This is our history.” It’s really not important. Nobody cares. And just clicked to the next one. And people laugh about it but they remember it, too. They realize that what you’re doing is you’re getting to the heart of the matter, the things that matter to them, because you don’t care about you, you care about them and care about solving their problems. And in some ways it’s just psychology. It’s just explaining without telling them that you care about them, and you’re not there to just talk about yourself.
Rob [12:41]: Sure. Yeah, what I’ve found is – I haven’t done many cold demos, they all have quite a bit of interest by the time we get on a call – and so I tend to give a little bit of info about Drip when I get on the call, but it’s like you said, you don’t want to talk about yourself here. You’re really trying to get at what the customer is trying to achieve. So I think building a little bit of credibility up front is helpful. You can say, “We’ve been in business this long,” or “We have this many thousands of customers,” or just position yourself like “We’re the lightweight marketing automation that doesn’t suck. That’s really who we are,” just to get even one or two sentences in there of setting the stage of the call. And you can always go into this later. The person’s going to have quite a few questions for you – at least they should – and you can answer those toward the end once you’ve gotten this early stuff out of the way.
Mike [13:28]: Yeah, you bring up a really, really good point there, which is you have to know what the stage looks like before you even get on the call. The last thing you want to do is get onto a call and think that you know who you’re talking to, or the type of customer that you’re talking to, and get it wrong. Because you can very well end up showing them the wrong presentation. And we’ll talk a little bit about that later on, but just to give you a very brief example, one of the people that I was talking to in the past couple of weeks, I thought I was talking to a very small IT company that did security assessments, and I went in and I gave my sales pitch, and I was talking to them and I was like “Oh, yeah, we work in this general vicinity and people who we are interested are between the two hundred and five hundred node range.” Which that’s going to depend on who you’re talking to. You don’t want to sell somebody who’s working with extremely large environments that you deal in the small range. Well, it turns out that that was actually what it was. He’s like “Yeah, we wanted this for a thirteen thousand node environment,” and I’m like “Oops! Just shot myself in the foot there.” So you really want to know what the stage is before you even get on that call. So if you have a way to ask questions before you even get to the point where you have the demo, that’s the ideal scenario, because then you can tweak your presentation specifically to them. And usually it’s worth doing that if you’re going into these direct one-to-one sales environments.
Rob [14:37]: Yeah, and I’ve found it helpful to have a lot of flexibility during this whole process. I know we’re still on step one, which is the open, but I haven’t prepared slides for these sales demos. I typically will get on the line, have a conversation, get a little more detail about what they’re looking for, and then I will demo the part of the app that they want to see and I will do a live demo. I realize that won’t work in all cases. If you were demoing to five people or something, you probably want a few slides to give them whatever credibility and give them some ideas of common questions or something, but I feel like having a lot of flexibility and really making it a conversation, rather than a presentation, has worked out better for me.
Mike [15:14]: Yeah, and I think that just depends a lot on the size of the customers you’re working with and what their expectations are.
And that goes into your second part of your demo which is, essentially, the lead in. And I think that, Rob, you probably handle these things a little bit differently than I do, but I like to gather as much information about the target customer as I can before I get in there so that the demo itself is tailored explicitly to them. So it almost looks like they’re the ones who are part of the demo. And the way I do that is I essentially start out by telling a story, and the story is about a hypothetical client of mine. It’s best if you can use a real one, but I try to include a photo, a job title, et cetera, and explain who the person is that has the problem. And this problem that they’re having should very closely mirror the problems of the person you’re talking to. And the only way you’re going to be able to do that is if you’ve talked to them on the phone, or via email, before you even get on the call. So, especially if you’re talking to groups of people, then you can talk to one person, get a feel from them about what the problems are that they’re facing, and then incorporate those in the demo. And then when you get into the demo itself, you’ve got two, three, four, five people on the call, and you’re relaying exactly what their situation is to them, and to the rest of the person – except for that one who you had previously talked to – the demo that you’re presenting is exactly describing the situation that they’re in. So at that point it really looks like you are on the ball, you are doing exactly what it is that they need you to do.
Rob [16:33]: That’s a pretty nice hack. Yeah, I’ve definitely never done this. I always just take the questions, find out their situation, and answer them and do a demo. But if you actually have prep work that you’ve done in advance, I think that would come off quite professional.
Mike [16:44]: Yeah, like I said, it depends on how much time you have to prepare, and what the dollar amounts are. If you have a twenty-five dollar product it’s not worth doing this every single time. But if you’re selling for thousands of dollars, it makes a big difference. Especially in their perception, and the number of people you’re doing these demos for. Because at the end of the day it’s all a numbers game.
Rob [17:01]: Right, and I think you raise a good point that we should probably touch on here, is when should you do these demos? Because, obviously, if you have a ten dollar a month SaaS product then doing a demo for every new prospect isn’t feasible. It’s just not economically viable. Now I do think that early on in your product’s lifespan – basically when you’re doing a lot of things that don’t scale – I do think that even with a ten dollar or twenty dollar a month product, that I would be willing to do these demos, because the information you’re going to get out of them is so valuable to you. But once you’ve hit the point where you have built something people want, and you’re getting people to sign up for your trials, then I tend to only do these demos for people who are going to spend more than X dollars a month, or per year. And for me that number is right around a hundred and fifty, two hundred dollars a month. It will depend on your business. Like you said, Mike, if you’re selling something that’s thousands of dollars – let’s say you have a fifty thousand dollar contract, or fifty thousand dollar project that you’re going to be selling – than obviously it’s worth doing something like this. I don’t know if you have a specific number in mind of how low it goes before you won’t give a demo?
Mike [18:01]: It’s got to average out to at least a couple hundred dollars a month, is really what it comes down to. So if I’m selling something for five thousand dollars I’ll do a demo. But if it’s for a thousand I might or might not.
Rob [18:11]: Right, a thousand a year.
Mike [18:12]: Yeah. Those are excellent points. You have to know what those numbers look like, and what’s worth it for you to do the legwork before you go down this road.
Rob [18:18]: And I actually think that number goes up over time, at least in my experience with the product, because early on you’re just scraping to do everything you can to get sales. You start giving to most everybody and then it’s like “All right. Only people who are going to pay us fifty bucks a month, then we’ll do it.” And then you get a few months more down the line and that doesn’t move your needle anymore, so you need to jump up to a hundred bucks or a hundred fifty bucks. And I think overtime with any good product that is growing, that’s naturally going to happen, and that dollar amount is going to go higher.
Now there is an in-between here where you can record, certainly not a personable demo, but if someone requests a demo and they are only a thirty or forty dollar a month client, you can send them a pre-recorded screencast that isn’t highly produced, and looks almost as if you could have recorded it just for them. I’ve known a couple guys who do this, and I’ve started doing it as well. It will still give them a nice demo, and as long as you have a few markets that you’re focusing on and you can record one for each, that’s pretty applicable to this person’s question, that’s a nice in-between. So you don’t have to just tell them “No,” but you can say “Sure, here’s this screencast demo that we’ve recorded,” and send it to them, and not have to do all the scheduling and the manual in-person thing.
Mike [19:22] Yeah, those are great ideas. Jumping back to the lead in, another thing that I like to incorporate in the lead-in is part of this hypothetical story about a hypothetical client, talk about the things that that client tried, what didn’t work, and why those things didn’t work. And these are things that you can extract from the initial person that you set up the call with. Before you had said that Harry basically starts out the conversation with those things. I don’t know if it makes a material difference. Maybe it does, maybe it doesn’t. I haven’t tested it. But again, having those things in there so that the customer knows that you know what you’re talking about and you have addressed these types of issues before and if those things mirror their experiences, then again, you’re speaking their language. They know that you’ve gone down this road before, and that level of trust just goes up with you.
Rob [20:05]: Yeah, and the cool part is that, assuming you’ve vetted your customer well and you have the information before the call, you can tailor that story, like you said, to mirror their journey. And the customer will essentially be nodding their head the entire time, because they know what this path looks like. And like I said before, it comes of really professional when it looks as if you’ve really catered everything to them and it really connects with their use case.
Mike [20:27]: Yeah, and in some ways you can almost relate this entire presentation back to something that you would find on a long form sales page, because the long form sales page it intended to walk them through the journey, talk about all the different pain points, and hit on all the different things that that person who’s reading it, all the challenges they’re likely having with whatever the situation is that they’re in, and you lead them down the path. Well, you’re doing the exact same thing in this particular demo. You list out all the different challenges, what the customer ultimately did about them, and all of those things should lead down the path to your product.
And that leads up to step three of the demo, which is the middle. And in the middle you’re going to talk about how you went about solving the challenges for this customer. And again, going back to step one, you relate it back to that opening so that your product and your company history converge with this hypothetical customer who mirrors your prospect. And again, you’re basically aligning the starts. You’re putting everything all in the right places so that the only natural conclusion that the person can come to, that is listening to the demo, is that your product sounds like it’s going to be a great fit.
So once you’ve aligned all these things, one of the other things you want to do is you want to touch on all of the different challenges, but don’t necessarily talk too much in detail about them, because you want to allow the customer to come back and provide you with additional input because, obviously, they’ve tried different things and they’re going to have different perspectives. They’re going to have some bad experiences that they’ve gone through, with maybe some competitive products or manually doing things. You always want your product to be the natural conclusion but you want to essentially allow them to speak to you to say “Hey, by the way, we did try that and it didn’t work and here’s why.” Or if they have any objections. You want them to be able to bring those things up so you have an opportunity to talk to them about it. And if you’ve done your homework in terms of doing sales demos, at the same time, anytime a customer asks you a question on a call you should also be keeping a separate document some place that it lists your customer objections, because those are the things that people are going to want to know and you want to be able to have a concrete answer for any time the customer says something. For example, “Oh, that price point is too high.” It’s like, “I understand that you say that but,” and then you list out five reasons why your price isn’t too high. And if you have those things all thought out in advance, because you have taken the time to set those things off to the side when a customer asked about it, and then you think through exactly what the answer is, when another customer comes to you and says “Hey, I have this particular problem,” you tell them the price, they say that’s too expensive, then you have a concrete answer that you don’t have to think about. You don’t have to come up with it on the spot, because if you come up with it on the spot it’s going to be different every time. And it really helps to have that concrete answer. And as you give the answer, if somebody pushes back with it you make a note of that objection, you work it out on the spot, and then you go back to your objections list and say, I tried this, they said “What about this other thing,” so you have to come up with something else to respond to that objection as well.
Rob [23:19]: I think the important thing to keep in mind here is if someone’s objecting to your product they can either be just throwing up roadblocks, as some people do, and they just want to see if you have answers, or they could genuinely be concerned that the product isn’t a fit. And the idea of these demos, just as with all sales, it’s not to convince someone to use a product that isn’t a good fit for them. And I’ve been on calls and demos like this before, where I realize halfway through that the product isn’t a good fit for them, and that they should go use, either a more expensive competitor, or maybe it’s a less expensive competitor. They just don’t need the features that I’m offering. And at that point I’m not trying to convince them to put on this shoe that isn’t going to fit their foot. So that’s something to keep in mind is that try not to just think about objections and the counterpoints to those. Then you will come off as perhaps being pushy or something. Keep in mind that you really want to listen to what a customer says and try to get at the deeper meaning of that.
At the same time, I think there are a lot of objections that are thrown up. Price is one. That’s a lame objection. If the product is a really good fit for them, and it’s going to make them a ton of money, or save them a bunch of money, or save them time, then the price is not super relevant, within reason. It’s some twenty, thirty percent difference between a competitor, it just doesn’t make sense. So that is a lame objection. It is something that I would push back on pretty hard, but I would always do it very courteously with a “Yeah, I totally understand.” Kind of have to lead it in that way, right? I make it a conversation. It’s not like an argument. I want it to be much more conversational than argumentative.
It probably goes without saying but I think it’s something that you want to keep in mind is that sales, in my opinion, is not about convincing someone to use a product. It’s just assessing their needs, and trying to figure out if you’re a good fit. And if it is, showing them that it’s a good fit. And that’s what I think these four steps that we’re laying out here are doing.
Mike [25:00]: Rob, you bring up an excellent point, is that if your product is not going to be a good fit you have to be honest with them and tell them flat out and say “Look, I don’t think that this is going to be a good fit, and here are the reasons why I don’t. You’re looking for this, I don’t have that. You’re looking for this other thing over here, we don’t have that either. And the way you need to do this over here is not going to work with your systems,” et cetera. You can essentially throw the objections up yourself. And sometimes people are just looking for a way to get off the phone. They already have their own agenda, or something like that. There are going to be people out there who have their own agenda when you get on a call and you’re just not going to know about it. And it sucks to be in those situations because sometimes a vendor’s brought in for the sole purpose of being compared to somebody else. And it’s not that you ever had a real chance to begin with, it’s just that you might have been brought in to help lowball a price or something along those lines, and you don’t know it. But that being said, you do have to know when you’re in over your head, and if your product’s not going to be a good fit, tell people. And if they push back at that point and say “No, no. We really want to try it,” handle them with kid gloves a little bit because you don’t necessarily know what you’re getting into.
Rob [25:58]: Right. Especially with SaaS, where they can cancel at any time, right? It’s not like you get some big one hundred thousand dollar signature and you’re really trying to push this through. If you convince someone to try your product out, you’re going to spend a lot of time onboarding them, and then if they cancel in thirty days you have actually wasted more time and you’re out more money than is worth it.
Mike [26:15]: So near the end of the middle section is really when you want to get into how your product works. You want to show them. So it’s not enough to lead them through this hypothetical scenario, where you’ve talked about their problems and how this hypothetical customer solved their problems with your product, that it mirrors their situation, and then leave them hanging. You want to prove it. And I actually have a slide in my presentations that basically says “Prove it,” because I’ve said all these things, but you have to show them that you mean what you just said. And so I’ll walk them through whatever the presentation is, and specifically focus on the things that they’ve said are important. So if they want to know about discovery I show them that. If they want to know about recording I show them that. You really have to get a sense of specifics, what are important to them before you get to that point. And, obviously, when you’re demoing a product itself you can go anywhere you want. There’s no real script to that. But the outline itself of how the demo will go, essentially leads you to this part where then you’re showing them the product and how it works and how it solves their problems.
Rob [27:12]: So we’ve covered the open, the lead in, the middle. Let’s talk about the close.
Mike [27:18]: In the close you essentially want to talk about what the next steps are with the prospect. And you want to formally agree to some sort of a timeline, whatever that timeline happens to be. So if, for example, you’re talking with an organization that, let’s say that they’re very informal, they only meet once a month or once every two months, you’re next call with them might not be for six weeks. Obviously you don’t want to be selling to those types of people, but if you are you have to know what that timeline is. And it’s not just about setting expectations for them, it’s about setting expectations for yourself, because you don’t want to be thinking, “I’ve got to get ready for this sales demo, and I’m expecting this sale to come in”, only to realize it’s not going to come in for at least eight weeks, because the customer isn’t even going to talk to all the people that are involved for another four or five weeks. So those are the types of things that you need to keep in mind, but the timeline itself, ask them directly about what their timeline is, do they need any other people to be involved? It goes back to the BANT acronym. Do they have budget? Who has the authority to make the decision? What are the next steps? All these different things that factor into it, you need to know what those things are and figure out what those are on the call. Just ask them flat out. What’s your budget? Whose got the authority? Do you actually have a need for this, which you’ve clearly established that. And what’s your timeline? So that’s what the BANT, B-A-N-T stands for.
Rob [28:36]: Yeah, timeline’s a big one, because otherwise these things can drag on and people won’t make the decision. And you can bring this up very casually. I will typically say “All right, so do you have any other questions?” And they’ll say, “No, I think that wraps it up.” And so then I’ll say, “Okay, so would you like to sign up for a trial? What’s your timeline? I can get you set up with a trial.” It can be something easy like that, and it doesn’t feel forced and they can feel free to say “No, I’m not ready,” or “Yes, I’d like to get started right away.” It can be brought up pretty casually. That’s in the less complex scenario, right, where there’s only one or two people involved, but I think your BANT applies when it’s selling into the enterprise and there are multiple stakeholders that you have to get on board.
Mike [29:09]: That’s another good point, is that all these different steps, I think that they naturally lead you through the process, but the specifics of how you address the questions or how you deal with asking what the next steps are, whether it’s very informally or having a focused discussion on it. Maybe you even take that discussion offline with a manager who has the authority to actually sign the check, because he doesn’t necessarily want all his techs in the room talking about the actual budget for it, or pricing. Maybe those are things that aren’t necessary for them to know, and a lot of people just don’t want their techs involved in those discussions. But all of this goes back to the idea that, ideally, you should know what you want out of the call and out of the demo before it even starts. Do you want them to go to a trial? Do you want them to make a purchase? Do you want to get to another call? Do you want to talk to somebody who’s in charge of budgeting? What is the next step? And that depends a lot on what your type of product is and what the logical next step is. And your entire presentation, or your demo, should revolve around what that next step is going to be. It should lead to it.
Rob [30:07]: Right and I often ask, before a call, as we’re emailing to set it up, “What would you like to get out of the demo?” Right? So finding out what the customer, or I guess it’s a prospect at this point, wants is also super valuable to make sure that you can provide that during t demo.
Mike [30:21]: I think the only other thing I’d mention is if you’re dealing with higher end products, what you don’t want to do is if somebody emails you or calls and says “Could you send us over a pricing sheet,” the last thing you want to do is send it to them. It sounds counterintuitive because they’ve asked for it, but you want to have a demo and a discussion about what their needs are first. Because, otherwise, it’s the fastest way to walk yourself out of a deal.
It’s funny because I’ve done this in the past. I’ve never responded to a pricing request with pricing information and then later landed the sale. Every single time I’ve sent pricing to someone who asked for it, without doing a demo and having a discussion with them first, every single time I’ve regretted it and it’s never worked out. And it’s not to say that it can’t in some situations, but if you have higher price points I don’t think that it works.
Rob [31:04]: If you have other thoughts for us or questions regarding this killer client demo outline you can call our voicemail number at 888.801.9690 or you can email us at questions@startupsfortherestofus.com. Our theme music is an excerpt from “We’re Out of 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.
