# How to Read Your Customers' Minds & Develop a Best-In-Class Product – Hanne Vervaeck

Channel: Rob Walling
Video: https://www.youtube.com/watch?v=9HgoILpo1Ag
Duration: 35 min
Language: English
Words: 5772
Transcript page: https://viewrankai.com/tools/youtube-transcript/9HgoILpo1Ag

---

[0:00] [Music] [Music] my crop just said I'm gonna talk about how to read your customers minds and develop best-in-class products there are three parts in this presentation part one is why giving your customers what they ask is actually a bad idea and how it will throw you off track second part is what you should do instead including the magic wand formula and part three is how to avoid overwhelm and become a mind reader now a little bit about why talking about this so my name is Hana I'm CEO for thrive teams at thrive teams we make conversion focused plug-ins and themes we have about 10 plugins so as you can imagine we get a

[0:56] lot of feature requests we're on a three-week development cycle so every three week we release new features for these products so we have to decide what we want to put in there right and that's exactly what we're gonna go through in this presentation now let's start with part one and you probably heard this expression before and even Ali talked about this yesterday so if I would have asked what my customers wanted they would have said faster horses this is Henry Ford saying that and while Allie was using this to say that you should listen to your customers I'm gonna use this to say that you shouldn't listen to your customers

[1:38] so that's fun but actually this is only one of the four types of feature requests that you will get and I can throw you off track and when I mean of track I mean that you have this roadmap in mind and if you listen to your customers if you listen to what they want you to develop then you might get slightly off track of that roadmap and maybe it's just one degree two degrees but as we all know you can get really really far away from your actual and goal by doing that so the there are four types of feature of feature requests and I'm gonna go through them and the way

[2:18] that it's easiest to recognize that this is a feature request you should ignore - the hardest one to recognize and why you should ignore them so the very first one is the one I like to call the smash the special snowflake requests so what's the special snowflake request it's something like this so this is from our support forum we have one of our plugins which is thrive quiz builder and this is somebody asking if we can like add subcategories or something to thrive quiz builder now how to recognize whether something is a special snowflake requests well it's wood fewer than let's say 1% of your customers actually use this

[3:02] feature and very important are those people early adapters or influencers so I just want to put that in there because sometimes you can have a request that seems very niche or very little people would use it but if the people that would actually use it are the ones that are gonna advocate for your product are the ones that are gonna talk about your product then it might be worth looking at that request but if not let's be honest these type of requests you should not be bothered with them read them maybe put them somewhere in the corner of your mind let's see if you can get

[3:36] some more votes for the for the feature but probably nobody will ever ask about them again so you can simply ignore them like I said we're starting with the easiest ones to recognize right so the second one would be the sent our request so sent our mythical creature half-man half-horse and this is would look something like this so I would like to be able to send emails from thrive teams or this is probably one of my favorite ones I don't like PayPal can you please make a payment processor so first of all let me say is actually really flattering to get these type of requests because it

[4:17] means that people really really love your product they don't love somebody else's product all that marshal service and so they would prefer that you actually make this but the problem is it's not your core business and you should not be doing this so by by looking at these requests you can very easily say like yeah we built WordPress plugins we're not gonna build a payment processor right the decision is pretty easy to make now what can you do with these requests you can put them in Google Documents and save them for your next business idea if you think that it's a good one um or and

[4:53] which is a bigger opportunity for for most software entrepreneurs it's you can actually find a service to integrate with and you can solve this problem not by building it yourself you should absolutely not build it yourself but by integrating with a service that you trust and that you you know will solve your customers problems so the third one a little bit harder to recognize is the worship ich requests so this looks something like this um as a client I would like to be able to use grammarly in the text in thrive editor our physical editor and we don't get one person asking this we have like multiple

[5:33] people asking for this feature request and when somebody posts it on a blog post it gets like upvotes and and so on or this one as a user I want to reposition the Google capture on my lead generation forms now why are these worshipping requests it's actually the type of request that it would not make a difference in the buy or not buy decision for your customers so nobody would buy your product because of this and nobody would not buy your product because of this and it's it's I could have said it's like the nice-to-haves it's something that one day maybe if you have too much development resource this

[6:16] would be a perfect thing to do also if anybody has too much developing new research please come see me and let me know how you do that because usually um we have the opposite problem right so and the the other way that you can recognize this or that you can think about it is is this something that people will talk about in product reviews because you might have people like reviewing your product online and then is this the type of requests that people would actually point out and be like hey you should use this solution over the solution because they have this feature if not then it's a worship a request and

[6:54] what you can do with these requests is you can add them to your list of features and because I will show you in part 3 how you can actually prioritize those and make sure that you develop stuff that's important for your clients you will see that these will never come up first on your list on your to-do list and then we have the fourth type of request and this is the hardest one so the faster horses requests right and why is this the fast the the fastest one to recognize the hardest one to recognize is because it actually makes sense so when people request these type of things

[7:30] it's because they have a real problem and they offer a real solution so it would be something like this like Eric has a problem with his buttons and he would like to copy/paste the formatting for on the button styles or David who's asking us for this like group editing for elements and what these have in common is that you have to ask whether or not this feature request is actually solving a bigger problem for your customer and if this feature if you would implement this feature would this actually eliminate the problem now the thing is with the the special snowflake requires the center request and the

[8:17] washer Pig request you can just get away with ignoring those requests that's not the case with a faster horse request because people are pointing out that there is a real problem that they need a solution to so you want to satisfy that requests it is not necessarily the way that your customers think about it but you want to satisfy this request whereas the other three you don't necessarily have to satisfy them right so what you want to do is you want to set aside the suggested solution that your customer came up with and you want to identify what the bigger picture problem is and then you want to make sure that when you

[8:56] implement the feature it's not just solving one of those feature requests is actually solving a group of feature requests so let's look again at those two examples the bigger feature request is actually people telling us like I don't want to take the same action over and over again to style my pages and our solution is actually a bunch of feature requests which includes global colors and styles and and and we call it smart sights but this is something that nobody was asking about because they don't know that it's possible another example of this would be something like this so again we are very lucky that we have

[9:39] very vocal customers asking us a lot of things giving us a lot of feedback and here the problem is I don't want to send my subscribers away after they sign up to my email lists so I don't want them to go to a Thank You page now the things we came up with and drive leads is these posts opt-in actions so these were suggested by our customers reload the page or give as a success message okay decent solutions we gave it to them but the actual powerful solution is a switchstate solution which is something that none of our customers asked for but basically it's our it's our solution to

[10:22] this bigger problem so a switch status you can actually have an other instance of your opt-in forms which then allows to have social share buttons or a download button or anything that people want in that other state and why I'm saying this is because this solves multiple of those requests that we got and it's something that people were blown away with when we first introduced this now because I'm a nerd I made this little flow chart and it just makes it easier to decide what happens when you get one of those feature requests from your customers so there's regroups everything that I just talked about so

[11:06] it's would it be less than 1% would those people be influencers or early adopters in which case you would pay attention to this if not then it be either the center request or the washer Pig request now let's be honest sometimes there is this unicorn request that actually makes sense because some of the customers might be like you and me and actually know a product thanks through the problem come up with a better solution and in that case I said hire this customer and it's it's but basically like try to get on the phone with them and listen to what they have to say and so it might happen I'm not

[11:50] saying that all the ideas are bad but very often you will notice that it is not the case now if you can't actually trust your customers that they will tell you what they want you to develop then what do you have to do well instead you should do things that don't scale now I know this is not sexy this is not what people like to hear it's it's so much more fun to send out the survey and then to look at those pie charts and whatever but you have the advantage of being in this state in this stage of business where you can either still do this

[12:31] yourself the things that don't scale or we have somebody do this for you right so at one point we wanted to test we were working on the new visual editor and what we wanted to do was see how our customers or potential customers interacted with different visual editors so we went overboard and we created this website called get a WordPress editor and the idea was that we would ask people to test different WordPress editors and we would buy the one that they prefer now nobody knew that thrive teams was behind this experiment because we actually wanted to get a very unbiased data we didn't want to hear

[13:15] that our product was the best fairly the opposite we wanted to see what people liked and other products now it went something like this buy a domain name I know this is gonna be fun this is way too small for me to read via domain name build a landing page then by older editors test them on our websites or put them on a test website get facebook ads and then invite them for a surveyed and contact those people set up the life calls watch hours of these calls and then send an and exit request an exit survey story and then buy the one that they prefer um now you

[13:58] can ask Dave who's the one who conducted this experiment in the company he spent two weeks of his life watching these type of life calls it was not a fun thing for him to do but it was super valuable for us to really get this this information and to see what people were doing now the reason that I listed this and even like I'm forgetting so many steps but the good news is you don't have to be that crazy like you don't need two weeks full-time somebody doing this type of stuff right and we talked about it a lot which helps me because I'm not gonna go into that much depth

[14:33] because customer development calls so at this point I hope once you see saw our experiment that took two weeks that you notice that a customer development call is not impossible to do and it's not that hard so first of all I I want you to take away that you should not over complicate this and that yes it is scary but you should do it so basically six steps to organizing this first of all send an invitation to your email list on social media just get people to on the phone with you to talk to you we have this step where we have a little forum to see if people are

[15:13] qualified now if you don't get a hundred requests and you might not even need this step then send something like a calendly link where people can just book their own time so it avoids the whole timezone trouble and send follow-up emails so that's one of the things that you'll notice if you do this customer development calls that people will just not show up or forget about it so send a couple of follow-up emails and then use something like try cast which is actually a podcasting solution but it works really really well for recording my development call or I saw that Skype now also actually has the function

[15:49] embedded in the product and then what do you want to do during this customer development call and I'm so happy that Michele yesterday actually did a talk about this because this is my advice go back to her talk her advice was way better and but basically shut up and listen you don't want to guide your customers you don't you don't want to talk basically the only thing that you're allowed to say is tell me more oh really and you listen now there is one question that I do want you to ask and that's the magic wand question now like I said customers do have problems and they will give you their feature

[16:33] requests but they are not thinking about what they don't know as possible so this magic wand request which basically literally goes like this if you had a magic wand what would the solution to this problem look like and this the idea of asking them if you had a magic wand basically takes them out of thinking about what's what they know is possible and getting them to think about what they think is impossible and so at that point you can get a lot of valuable insights about what the ideal solution would look like and not just what as more as a slight improvement to the problem would look like so then what do

[17:16] you do after a customer and development call so right after write down your gut feeling like write down how how did you feel about that call this is a bit whew but I I really like it because then it can put a context to the to the call ii transcribe get it transcribed it doesn't cost anything and and it it will avoid that you have to take notes during a customer development call which you absolutely don't want to do you want to just sit there and listen and then afterwards because once you have that transcription you can actually ask somebody else to listen to it or you can

[17:55] listen to it yourself again and then you can highlight the it's where you actually got the gold from your customers so now at this point you probably or you should have a list of features um and we're gonna have a look at how you can prioritize them so in the beginning I had a way better title for this but my slide did not get updated so the boring title for this is how to prioritize new features and your roadmap at this point or your feature list looks something like this and you want to make sure that you make the right decisions because as we all agree

[18:32] on is development research you don't have infinite development resource and so you want to make sure that the features that you built first are the ones that will have the most impact and will make your customers happy so this is what our feature list looks like I try to zoom out a bit more in Excel I couldn't so this goes on for many many many many more rows um and I mean the system doesn't really matter like you might capture this in India or in Trello or what wherever you want the reason that we use an excel or a Google sheet for the beginning is because what is

[19:12] important on this sheet is this you want to have a way to quantify or to to to give an importance to the different features that is not just I like this I'm emotionally attached to this feature and in our case we have these five categories criterias that we use to evaluate a feature now for you this might be other categories there might be other criteria depending on your business so the things that we quantify our features are is will this increase our revenue yes or no how much customer value does this bring so will this our like how much customer value does this bring then how much strategic value is this and

[20:04] this basically means we are an conversion focused WordPress plugins so is this in line with the vision of the company yes or no efficiency is something that we added because there might be features that seem unimportant but it will really help our customers use our product better and so we thought it was really important to also give that a note and then is this an innovation is this a unique feature so like I said this is what we identified this might look different for you now next up the next line is basically to make it awaited decision so if you at one point if you like we want

[20:45] to do a sprint to make our product more efficient we could put instead of having all of this weighted equally we could put a higher note on efficiency and it would immediately bring up the features that have that would improve the efficiency of our product and then just give it a note from from zero to one to five this is very much a good feeling don't overthink this you know your product you know your customers on the zero to five scale how much would this work on the category that you identified and this will give you this type of of impact note so the higher that number

[21:27] the more impact it will have on your business and then of course once you filter this and you saw the features that will have the highest impact you have to see how this works with your resources right because you want to make sure that you actually have the resources to implement this um now the reason that this is actually a really really good exercise to do is because the features that you had in mind might not be the features that come up highest on this list and because often we get excited about one of those five one of those five criteria right it's like it's super innovative yes let's build it but

[22:12] then it might actually not really increase your revenue or it might not bring that much customer value or whatever I might not fit your roadmap right and and that's why having these different things will really help you to iron out and to make informed decisions and you will get something like this which I really really hope so where people are basically saying you read my mind this this latest feature that you add it's just so mind-blowing I love using your product I'm an advocate for your products and the more you use this system the more of this type of comments you'll get and people will be like hey I

[22:50] didn't even know I needed this now I do thank you are there any questions Thank You Hannah I have a question about the waiting process and specifically the the workload allocation have you found that your estimates of how long it will take match up with the reality of how long things take and if not what is your mechanism for re-evaluating that as you go so no never it's never the same but it's it's very rare so it's we go through this with our head developer or with like the the CTO and at least of course if they put like oh this is gonna take one day or one

[23:44] week like it might not be one day but it will give you that idea of will it take a lot of time or not that much time so it's very rare that they would tell you it's gonna take more than four weeks to implement this and actually it's a one-day task right so the opposite can be true but usually like when and at this point it's impossible to give real estimations because there are no spec documents there are no like that happens afterwards so it's just looking at this basic requirement it's gonna be like we'll have to change half of the code or we actually see this should be pretty

[24:19] easy to implement so it's it's it's more of comparing apples with apples so it would always be really wrong but they will show you what's easier and what's harder to implement thank you great talk wonder if you can talk a little bit about managing a public road map and sort of the implications of that you know when you you throw a candy page up and suddenly there there are 80 requests and you know you're never gonna be able to build them all how do you manage that with these sort of customer expectations so to be honest that's one of the reasons why we don't have a public road map or because

[25:03] part of it is that people will always expect it to be faster than it will be and so we only allow herself to be like yes this like where we're working on this if it's actually literally in development which means that's gonna be there three six or nine weeks later and that's the only time that we publicly tell people whether or not something is in development if not we take votes so we're like hey thank you very much for asking this API request we're counting votes on that and then it does help like especially with integrations like it really helps to have that publicly available because it shows you which

[25:45] integration is most asked for but yeah after after showing everything that I showed before like we had one person being really really really passionate about having pagination options and in our builder and it was one of those things which was like every blog post he would ask for it right and if we would have an and feature request type of page like I know that he would upload that request 150 times because that's what he did on every blog post on every YouTube video that we put out there so we have a few very passionate people and even though it's a special snowflake request so I'm I think like yeah we made the

[26:23] decision not to have a public road map exactly because we consider that our users not necessarily know the exact features that they want and we prefer capturing their problems rather than hearing their future solutions I had two questions one is they're sort of related one is like so you're at a lot of the stuff you get in from customers is going to be not the best or maybe not aligned like you said like three three or four categories of stuff how do you communicate with them or if you communicate with them about those things and like how you're either choosing not to do them or letting them

[27:05] sit and then even for things you ship like how do you what kind of communication do you do to the people who ask for those things okay so we have about 40,000 comments on our blog now so that for us is like by far the biggest way that we get feature requests and that we communicate with our audience if people ask for one of those special snowflake requests it's probably gonna be like thank you very much for your suggestion that's it every every note like every see that it's one of the faster horses requests and so it's actually something that we're working on solving if we recognize that it's the

[27:41] same problem that they are trying to solve we might say something like hey we know that is it that this is a problem we had a lot of people like pointing this out we are working on a solution and to be honest we don't like we usually don't say like oh this is gonna be in our next you know in our next cycle or in the next iteration of the product because the number of times we're done that didn't happen and people feel super entitled and then they they are disappointed because it's not in there so like I said like we only say we're working on it when we're actually

[28:17] working on developing it if not it's like thank you for your suggestion I added it to our feature suggestions and we might get there in the future and if it's something that we really are not planning on doing because we're not doing PayPal for example we just tell them like hey this is not something we're planning on doing so yeah that's do you have any idea how many feature requests you get hundreds hundreds easy our so because we have like the support forum which basically hours support agents click like this is a feature request it goes to the JIRA board that board is called ideas and

[28:59] that board has thousands of tickets in it and then yeah like I said like on the blog every blog that we put out get gets hundreds of comments and and it's especially if we have a new feature people are very used to us asking like hey do you like this and what is something that you would like to see because we do want to have that communication with our customers and yeah the moment that we launch global colors for example I think that blog post has 300 comments and it's mainly people saying like I love global colors but what would be really cool is if you

[29:35] added this this and this and that so yeah we got we got hundreds of requests any other questions we have time for one or two more thank you so much for a wonderful talk and taking all these questions I was wondering on part two of your presentation which was the base of the customer development call yeah you talked about two tools that you use to extract data from the client one is shutting up and the other is the magic wand yes but those are the only two tools and toolbox are there any others that you have found to be effective particularly for the problem of getting

[30:17] from the customer what their problems what their pains are rather than specific feature requests which is often what they're coming in the door with so we honest we like I think the questions that like Michelle went into the type of questions that you could ask one thing that and there are a couple of really really good books about this so um but one of the questions is just really being like hey you're trying to build a funnel on WordPress what are your problems with that and and I I think depending on where you are and if you're looking on a more like getting to get feedback on a specific feature or if

[30:58] it's actually a full product or if you don't know yet what you want to do or like you might ask more open questions or more closed questions if yeah it's it's literally just asking like hey what do you find complicated on with doing this one thing what have you tried before why did it work what didn't it work what did you like about it what didn't you like about it those type of questions and then being like mm-hmm tell me more about that I was just wondering if you've ever had a feature you've launched that has been you've regretted in the sense of you know customers just didn't use it or cause

[31:41] excess support requests or more problems or something like that and I guess how do you handle that and do you have any filters for preventing that from happening I wish we did have filters for preventing that I think for for support requests as many if there's a bug a feature coming out so that's what causes support requests and that is in the testing process in the development process and going back to the drawing board and me like hey why did this get out like how how on earth did this get on our master branch and this actually gets launched through our clients now because we have a wordpress plugin

[32:17] unfortunately it's very hard to know if people use certain features so that's something where I'm so jealous of everybody who has a sauce business because I would love to know when people are like using our features and if it's actually like helpful so that that makes it really really hard and the third request was regretted so the the times that we regretted putting in feature requests is actually or putting in features it's when we when we solved a smaller problem and then later on found a solution for the big old problem and now you have like this two competing things in your product so an example of this is when when we

[33:01] launched landing pages which is years ago now thrive landing pages at the time we we knew that I was super important to have a lightbox on click show and so because we wanted that in that product we had like something that was called thrive light boxes which today makes that we have something else called drive light boxes we have like try drive leads drive boxes and we and they becomes confusing for the customers and it's like well we know why we made that decision at the time that we did it today we regret and it's it was a decision made at that point that seemed like the correct one and now it's

[33:38] like ah maybe we should have waited a little while but yeah that unfortunately that happens and then sometimes you can make it as a legacy feature so you can actually like take it out of the product and it's like people were already using it still see it new users don't see it anymore that can be a solution or sometimes you just have to live with the paint I really enjoyed your scoring system for figuring out which features you should work on next I've seen similar ones where effort was actually a part of the formula why did you make the decision to sort of look at that after

[34:16] the fact rather than part of the final score because we really wanted to to get the features out there that would be most impactful for the product before starting to worry about how we were gonna build it that's the main that's the main reason like we wanted to make sure that we didn't eliminate things just because they are hard to build you

---

About this transcript
Read from YouTube's own caption track and laid out by ViewRank AI (https://viewrankai.com).
ViewRank AI finds the videos already beating a creator's own average on Instagram, TikTok and YouTube Shorts, transcribes them from the audio itself in more than 60 languages, and turns what worked into new ideas and scripts.
Free transcript tools, no account needed: https://viewrankai.com/tools
How to read any video this way: https://viewrankai.com/llms.txt