Transforming Customer Input Into Killer Features – Derrick Reimer – MicroConf Growth 2017

0:00[Music] [Music]

0:14hello everyone my name is Derrick and I'm the co-founder of drip alongside Rob walling who I'm sure most of you know and part of my job at drip is to figure out what we should build next into the product and I think we can all agree that it is wise to include customers in this process and not retreat into a cave and build features in isolation but the problem is deciding which ones to actually build if you're anything like us at drip I we receive hundreds of feature requests a month and you know if we were to build everything our customers asked for our product would

0:51end up looking something like this where it just devolves into a junk drawer of useless features so what I want to talk to talk about today is the framework we've developed and it's not something we've formalized until I sat down to to write this talk and kind of distilled it down into four different steps that we take so let's dive in so the first step is to parse the feature requests and customers love to to tell you their problems in the form of a proposed solution so you'll often hear like hey can you add this button to this page that allow me to do this thing or

1:27enhance this feature in a certain way and really what you should do first is try to distill that down you know wipe away the solution they're proposing and try to get to the core the problem and oftentimes just shooting back an email and saying hey what are you actually trying to accomplish with this will go a long way and to give you an example from drips history we often get the feature requests for for a feature that is present in a lot of marketing automation products out there today and it's a feature that allows you to send an arbitrary HTTP POST to an endpoint at a certain point in a

1:59workflow and usually when we when we actually ask the customer what are you trying to accomplish they tell us well I want to integrate with a certain plugin and send data at a certain time so really the best solution for us would be to actually build a first-class integration where rather than giving them a way to like manually wire it up and so at this stage what you're really looking for is consensus you're looking for has more than one person actually expressed the same pain and if the answer is no then it may not be time to actually build that feature but if you're starting to see a pattern and

2:32that's really key here is looking for you know patterns among among pain points being expressed then it may be time to you to dive in alright so step two is to synthesize this is where you take the bucket of feature requests that have been expressed in the pain points that you've distilled down and actually try to envision what the best solution is to the problem and this is where the creative process comes in for us it often means sitting down in front of a whiteboard throwing out crazy ideas usually the best ideas start with this is going to sound stupid but and then out comes the genesis for a really good

3:12idea so I lost my train of thought sorry about that so at this point you want to look for you want to look for patterns and and try to come up with with a good solution so moving on to the third step if you've as soon as you've envisioned a good potential solution to the problem your next step is to prioritize that feature and we usually ask ourselves two central questions at this point first we ask ourselves is this going to help us gain new customers or two is it going to help us retain existing customers so it's a growth or a tension question and if the answer is yes to both then you

4:05know it's probably something that's worth building in the near term if the answer is no then and it's not necessarily something that you don't want to build but you know it may not be something that's worth building in the near term we try not to look too far out into the future we usually plan about 60 to 90 days out into the future but that those are the two central questions we ask ourselves when when trying to prioritize what to build we also consider what's the development cost do we have the resources on the team right now to to actually build the feature and and so these are all the things we consider

4:48finally the fourth step is to actually build the feature and it's it's probably conventional wisdom these days that you want to try to build the smallest hammer down the scope to as small as possible and get it in front of customers as early as you can so the recent example of this is customers asking for a feature to merge two subscribers together in drip and you know this we kind of procrastinated on building this feature for a long time because it's it's a potentially large undertaking to take all this data from two subscribers and merge it together but we finally decided to instead just hammer it down

5:29to only merging together tags and custom fields and we were able to knock this out in about six weeks wasn't too big of an effort and we could get it in front of customers early on and start getting feedback and if it proved to solve you know 80% of the problems people are having then it's probably good enough to stop there but if customers you know we're telling us that they needed more functionality then we can circle back and add more to it so those are the four steps just to just to reiterate first step is to parse feature requests and try to get to the root of the problem

6:08and if you determined that that it's actually a pain point where it's worth solving then step two is to synthesize that and actually envision the right solution for the problem step three is to prioritize based on whether it's actually going to move the needle on growth or retention and finally build the smallest iteration possible thank you very much [Applause] [Music] you