[00:00:01] Ferdinand Goetzen: First of all, context is super important. We get questions all the time, "Oh, so your platform just automates everything." I wish. Unfortunately, a lot of customer feedback and customer comments, the voice of the customer, whatever you want to call it, context is everything.
[00:00:18] Erin May: This is Erin May.
[00:00:20] John Henry Forster: I'm John Henry Forster and this is Awkward Silences.
[00:00:33] Erin: Hello, everybody, and welcome back to Awkward Silences. Today we're here with Ferdinand Goetzen, the co-founder and CEO of Reveall. Today we're going to be talking about how you can gather and use customer insights across all the many departments you might have in your organization, which is probably a problem and opportunity many of you can relate to. Thank you so much, Ferdinand, for being here to discuss it.
[00:00:58] Ferdinand: Thanks a lot for having me, really looking forward to it.
[00:01:00] Erin: We've got JH here too.
[00:01:02] John: Yes, I'm gonna try not to dominate with a million questions here because this is a topic I care quite a bit about.
[00:01:06] Erin: Yes, for sure.
[00:01:07] Ferdinand: I'm going to make some space for you, Erin as well, yes.
[00:01:09] Erin: Yes, definitely thinking about it a lot. So Ferdinand, let's just start from zoomed out here. We know probably everyone listening to this podcast knows that customer insight is very important to making good product decisions, good business decisions. We're all bought into that. Broadening your scope of where you're getting customer insight from, how do you collect that and how do you then prioritize it, there's a lot to unpack there. Let's start with, what's a good place to start for folks thinking about this?
[00:01:39] Ferdinand: Yes, we get this question a lot. I think it depends, first of all, how big your organization is. How, if you have a large organization with a lot of resources and a lot of teams dedicated to various customer-centric initiatives. Or if you're a small startup, starting out and wanting to learn more about your core customers. I think that definitely influences what your options are. In any case, I would say start simple. I think customer insights in the broadest sense of the term, it applies to pretty much any learnings you might be deriving from your customers.
We know from all kinds of studies that most companies talk to their customers on a daily if not weekly basis. There's already a lot of conversations happening and all of those conversations could hold valuable insights. Starting with what you're already doing, I think that's a great place to start. For example, your sales conversations, or your customer support tickets or feedback you might be getting through forms either on social media or within your product directly. There are already a lot of sources for this in pretty much any organization of any size.
[00:02:45] John: Yes, that makes sense. We've tried to do a bit of this at user interviews. The thing that we wrestled with really quickly, and I'm curious to keep perspective on is, do you try to scan all of it, try to scan all of the customer conversations and figure out what's interesting? Or do you want people to self-report and have the person flag, hey, this one's really interesting, somebody from product or research should look at this?
[00:03:05] Ferdinand: I would say both, I think the way that we structure our approach was also, the approach we're basing Reveall on is, ideally, bringing everything into one place. You can always pick and choose later what you focus on. That being said, if you have very conscious teams that are engaged in the general process of customer learning, it's great to flag things that they think are of particular interest. An example of this would be our sales team, every time they do a demo will either upload the recording to our platform, or they'll make notes in their CRM.
In that note, they'll do hashtag integration or hashtag Reveall and set it into the platform. Then they'll add maybe another hashtag to say, important or urgent. I think both is important because I'm not sure if people-- depending on what role someone is in, they might not be able to judge if something is in fact very valuable for the product team, for example.
[00:03:58] John: Yes, totally. To build on the thing you said there about important, how do you recommend or how do people go about solving, okay, we're getting a lot of feedback here of something that's a minor annoyance maybe. We're not getting as much feedback on this other thing, but it's blocking the users who bring it up from using the product at all. The severity or the importance, do you have a typical scale or a way that people should go about rating that stuff?
[00:04:23] Ferdinand: Yes, I think generally reoccurring feedback. Generally, if you see something coming up quite often, then, of course, it's probably more salient than something that only gets mentioned once. The context in which feedback is delivered is very important. Although I would say the most important thing is that all your customer feedback, one of the things that we always preach about is that your customer feedback and your product backlog need to live in the same place.
Iit always needs to tie back to your backlog, your roadmap, what you're trying to build. Obviously, this is a top-down or bottom-up approach, you're either really learning about your customers and based on that defining items for your backlog or your roadmap, your Product plans. Or you work the other way around, which is you have a pretty clear idea of what you want to build. Then you're trying to find the data, the findings, the learnings to validate that. By bringing those two things together, you also help create a little bit of direction amongst all of this feedback.
[00:05:16] Erin: Let's make this feedback a little more tangible. Let's talk about some typical departments you might find in a typical organization and the kinds of insights. I know you mentioned, sales and support. What are some different kinds of insights that might be coming in either proactively or passively from different departments and how you might think about gathering those?
[00:05:38] Ferdinand: Yes. First off, I liked that you said proactively and passively. I think one of the things that we learned very early on is people talk a lot about quantitative and qualitative data. Whereas what's really important here is the differentiation between passive and active data. Passive data being something that just flows in, if you hook up your integrations or your tools, Google Analytics is a good example. You set up Google Analytics on your website, that's going to be passive data flowing in, there's charts and graphs already for you.
Whereas active data is the stuff you need to mine for, and you have to look for and go fishing. An example would be, let's say, sales conversations. If you're doing demos, you could be recording those demos with tools like Aircall or Gong, whatever. Those recordings could be transcribed and analyzed. That's an example of a piece of feedback that actually needs quite a lot of work still, because you need to synthesize. I think that synthesizing process that requires you to have at least somebody in charge, or some resources dedicated to it.
Other forms of active data will be any kind of research that you do focus groups, interviews, surveys you send out, those things. On the passive side, it's the stuff where customers are coming to you actively and that could be on social media, comments on social media. It could be if you have feedback, forms, forms that are filling out. Roadmaps that they're commenting or uploading features on, public roadmaps, I mean. Or you have customer support requests. If you're using live chat support, or a help desk with a ticketing system.
Those are all possible sources of voice of the customer data.
[00:07:12] Erin: Yes, and I imagine across this different feedback, and these different departments through which they are coming into the organization, the user is in a different mindset. What support's hearing is mostly problems. Mostly frustrations. Maybe what sales is hearing is a combination of more top-level pinpoints the person is experiencing in their life as whatever it is that they do, versus what support's hearing. I'm just curious how those different lenses of how the user is coming to you, through this different feedback might inform how you interpret them or what you do with them.
[00:07:52] Ferdinand: Yes, this is where I probably differentiate between what I call just raw data, and then actual findings and insights. I think, very often when you take just one comment, first of all, context is super important. We get questions all the time, "Oh, so your platform just automates everything." I wish. Unfortunately, a lot of customer feedback and customer comments, voice of the customer, whatever you want to call it. Context is everything. I think that's very important. Understanding that context and also connecting the dots between different pieces of feedback, you're getting precisely from those different contexts.
Of course, customer support is hearing more negative things, sales might be hearing a mix, depending on whether they close the deal or not. There's going to be different areas. What we usually say is we push this approach where you start with centralizing your data, then you try to pull out what we call findings that's essentially your key takeaways. You might have a 10-page interview transcript, but there's probably only three or four comments that are really, really pertinent to what you're doing depending on whether it's an interview or a sales conversation.
Then those takeaways will be your findings and then we try to cluster your findings into insights. Insights is something that we-- What we're building now is to basically do things like confidence scores, so that you have clusters of findings that you can give a confidence score based exactly on what you're saying, what is the context? Does this pertain to our thinking, our strategy, our vision? Who is saying it? How often is it being said? What's countering opinions have we heard. Those sort of things.
[00:09:17] John: When you describe getting all the way down to that insight level, it's been reviewed. The context has been understood, et cetera, are you talking about getting pretty granular? I'm talking about in our own product and experience, somebody might write in to support and be, "Hey, I'm having trouble with scheduling, I wish you could do blah. Also, if incentives worked like this, it'd be much better for me." Those are actually two very distinct insights for us. We would want to store and processes differently, is that what you recommend people do? Take it down to that level?
[00:09:42] Ferdinand: No, generally, I think when there's a bug or something, we don't really pay too much attention to-- We look at it from how we-- When I talked about the product that we have, our platform and the process that we follow, they go hand in hand. We're trying to use the ideal process and build the ideal platform. Of course, things like simple, quick bug fixes, that's not something we pay too much attention to.
Generally, if there's a bug in the platform, and it's something that's relatively quick fix, it just makes it onto the bug list, then we do a bug triage, we prioritize, and we fix as we can. An example I can give here would be one of the things we do is automated transcriptions, and we started getting different feedback related to automated transcriptions. Where somebody would say, "The quality in French, the transcription quality wasn't great," or they'd say, "Oh, when I'm highlighting, I have to click on this different tab to add a tag."
We started getting different feedback but pertaining to the same feature. After a while, we started seeing all this feedback coming in and we started seeing these clear trends evolving. We clustered those into a clear insight, which was that the transcription feature as it is now is not creating the value that we would like it to. So we started taking that feedback, and actually turning that into user stories, which we then turned into a clear feature improvement plan, which we then passed on to our development team.
That's why you always need to have, of course, your product backlog and your product planning in mind when taking this feedback on board. Yes, sometimes you're going to be inspired for new things you might not have thought of, but most of the time you're looking to validate things that are already, if not on your roadmap, or on your backlog, at least in your general conscious sphere, if that makes sense.
[00:11:24] John: Yes. You have some awareness of it as a team, and you're looking for more signal or more confidence that it's something that we might actually want to go and solve and improve for users. Is that right?
[00:11:32] Ferdinand: Exactly.
[00:11:34] John: Cool. You had said something earlier about it's important to do both where have customer support, sales folks flag things that they think are interesting, but then also have the product team random sample the raw notes themselves. They might pull things out that are uniquely valuable from their point of view. Have you had any success with trying to train sales folks or customer success people to better pattern match what might be interesting to the product, or is that not a fruitful effort? They already have their own jobs, let's not put another responsibility on top of it?
[00:12:04] Ferdinand: Yes, I think it's a tough one. I guess, first of all, because customer success and salespeople have very different incentives and different activities. I think generally, my experience is that in customer success, where retention and customer experience is so fundamental to their own metrics, they're probably going to be a little bit more collaborative in that respect. I think generally, you do have people who are super involved, and you can build a culture where this is very important, and everyone.
That's what we're doing at our company. That being said, it's important to make it for anyone whose main goal isn't customer learnings, it's important to also make it easy for them. That's where integrations are really important. We knew from day one, that we're not going to get all salespeople that all marketing people, and people for all kinds of platforms to join in this process. We need to make it easy for them as well. I think it depends a little bit on your organization. Generally, I would say make it easy for them and in parallel, try to build a culture where it's encouraged.
[00:12:58] Erin: Yes, absolutely. We've been talking a bit about some of the ways that different departments can bring insight and it can be used. I know in the beginning, you said, let's start simple and start by getting all of this insight across departments into one place, or trying to at least move in that direction. I know tools can be a good way to do that. Some people might not have the budget or the maturity or need for a dedicated tool for this purpose just yet. How do you think through how to start getting these insights centralized across departments, depending on the needs of your company?
[00:13:35] Ferdinand: Yes, I think centralization is the most important step, and that is the first step. There's a lot of tools out there that allow you to do this, including Reveall, but there's many others. Generally, the price point for just centralizing information, it's not super high, so I think budget is rarely going to be the major blocker. It's usually then when you start wanting to synthesize and analyze and do all kinds of other things that the pricing starts to grow. Even then, anything from Google Drive to Miro to Confluence can be used in one way or another.
Eventually, you'll outgrow it, which is why platforms like ours exists, but getting everything into one place is really important. That starts with the process, just this idea that, hey, let's collect all of our information in one place. It really depends on your organization. You might want to get all the data into one place, and then start analyzing it. Or you might have people analyzing in real-time, and that is putting the conclusions in one place. Already just having your conclusions living in one place.
Where we see as the main problem is that companies are very often-- but how often does it happen that a feature finally gets prioritized and starts development. Then half the support team or half the success team says, "Geez, we've been saying this for ages"? It happens all the time, and I think that's the key that you're not doing repeat research, and you're not having epiphanies six months too late. That's just having that information in one place. That is the value.
The way to do that is just to tell people to, "Hey, from now on, every time there's the key customer learning, put it here. Even if you don't want to use any kind of expensive tooling just set up some automation via Slack, where with a hashtag, you just create a channel. If you have any learning, dump it on this channel and we'll push it towards an Airtable or something like that. There's so many ways you can do this.
[00:15:12] Erin: Yes, I think that's really important, to meet people where they are, especially when you're working with different departments and understand their workflows of where this insight is coming from, and what's going to work for everybody to adopt V-ONE of a system like this. I'm a huge fan of Slack Channels, for example, for just V-ONEs of things where everyone's using it already, and then you can ultimately push things from Slack to other places or things like that.
[00:15:38] John: All right. A quick, awkward interruption here. It's fun to talk about user research, but you know what's really fun, is doing user research. We want to help you with that.
[00:15:46] Erin: We want to help you so much that we have created a special place. It's called userinterviews.com/awkward, for you to get your first three participants free.
[00:15:58] John: We all know we should be talking to users more, so we went ahead and remove as many barriers as possible. It's going to be easy, it's going to be quick, you're going to love it. So get over there and check it out.
[00:16:06] Erin: Then when you're done with that, go on over to your favorite podcasting app and leave us a review, please.
[00:16:15] John: What's the best practice for product folks? Or just your opinion, I suppose, of, all this feedback is getting shared into them from different parts of the organization, different departments? How did they close the loop and let them know what's happening with that? Some of the stuff they are going to prioritize or it's going to influence what they work on, other stuff, yes, we hear it but we don't see it as a growth initiative right now. We have other business goals so we're deprioritizing it for the moment.
It's important to be transparent about what is happening with the feedback or more just to create the culture of getting it in there and good things will come from it later.
[00:16:46] Ferdinand: Yes, I think that's a really good question. It's a two-way street for sure. I think if you want to create a culture where people want to share feedback, you need to show them that it's having an impact. I think that's the problem that we saw. The reason we started Reveall was we saw that a lot of departments weren't engaged with sharing that feedback. Even in companies where you have dedicated UX researchers whose whole job is learning about the customer, they still felt like they didn't impact the roadmap.
In fact, my experience is you talk to most UX researchers, they don't feel like they're having the impact they would like to have because there's still quite a strong-- there's still a fence between the customer learnings of the actual product development and the prioritization. That's why we try to bring that into one platform. Even just in the culture, it's really important that of course, you want to encourage people to share those insights but it also needs to come back.
Then they need to know, "Hey, this is-- when you're presenting a new feature. When you're presenting the new prioritization framework you're introducing. Or if you're talking about, hey, we're now building XYZ because--" it's important to show that customer data, to show that the validation came partially from the information that they provided. I think that's really, really important.
[00:17:50] John: Yes. It sounds like the simplest way maybe for product folks or people out there to do that is just make it part of their storytelling. Like, as you are saying, like, "Hey, we're gonna work on this next, just to give the context and visibility into what went into that decision making." Is that a fair summary?
[00:18:04] Ferdinand: Yes. I think that's already as a step one, really just to say, "Hey, folks, we're building this because we got some great feedback from sales or we got some great feedback from customer support that XYZ." Same thing goes that, I guess there's already a process for this, that most companies, if they have customer success, or customer support, or a chat function, that if a customer says, "Hey, I noticed this bug," when the bug gets fixed, you relay it back to that team to inform the customer that it's been fixed.
You can use those same channels and those same approaches, just to say, "Hey, we built this because your feedback really made a difference." I think that's really useful.
[00:18:39] Erin: Yes, and also sharing it back with the users who are giving you this free insight too. You requested this. You personally, or people like you, many of you requested this, we paid attention and we built this. This is not just totally us coming up with random stuff to create, we're actually listening to your feedback. Then you'll get more of it so you create a virtuous cycle all around.
[00:19:00] Ferdinand: Two things happen. Number one is that the customer is happy because you fixed the problem, but number two, they start becoming less strict with other problems that might arise. What we find is that when you're very open with the customer, and if a customer really gets a feeling of, "Hey, I flagged this problem and it got fixed. I know within a couple of weeks or a couple of months or whatever, depending on the problem." They also cut you more slack on any potential future, be that usability problems, be that a bug.
Or be it such as that they'd like a certain feature that hasn't been released yet. They give you a lot more leeway if they feel like they're being listened to.
[00:19:35] John: Do you think that's just because they can see the vitality in the product? Like, "I know that I've shared something in the past and it's gotten fixed. So the thing I'm encountering now likely might get fixed as well in the future." Is that the loop that's happening there?
[00:19:48] Ferdinand: Yes.
[00:19:48] John: I'm just using your explanation for that.
[00:19:50] Ferdinand: Yes, exactly. If I'm using a product every day, and I flag problems and they never get addressed, then one day if there's something that's maybe more of a deal-breaker. Or something that's more likely to-- a competitor releases a feature that the current product I'm using doesn't have. You might be more willing to think, "Oh, you know what, they're never going to fix this. I'm just going to switch to that competitor now."
Whereas if you flag two or three things in the past that have all been fixed, then you're probably going to say, "Hey, you know what? My first course of action is just to let them know, hey, this is really important to me. If it's important to me and it's important to others, they're going to build it."
[00:20:24] John: Yes, totally. A bit of a change of topic here. Something that I'm curious to get your perspective on is I think this is one of those things when you talk about in the abstract, it just seems to make a ton of sense. Everyone's probably nodding their head saying, "Yes, we should do this." In my experience in reality when you actually start to go out and do this even at a smaller growing business, the volume of feedback can feel overwhelming really quickly. You start to pull in all the customer support tickets.
You start to get all the highlights from the sales calls. You start to have people share in Slack Channels. The analogy that people use often is like a fire hose. It's like, oh, man, there's like a fire hose of information coming at us. How do teams deal with that? We're fired up we're excited to do this. Then they step into it and they're like, "Whoa, there's a lot here. How do we keep up with it?"
[00:21:06] Ferdinand: I think a lot of feedback is always good, but of course it's challenging. If you have dedicated people to connect those dots, to synthesize that information, to create those insights, then it's not going to be so much of an issue because you have dedicated people. If you have so many customers that you have so much feedback that you probably have the revenue and the budgets to also hire a couple of researchers and a couple of UXs who can actually process that information. Even if it's a high amount of information.
Now there might be exceptions to that, of course. I think the key here is that a lot of companies-- I hear that quite often that companies want to jump from doing almost nothing to, "Wow. Now we've got these giant amounts of information," whereas it's you don't have to go from zero to a hundred. It's already okay to just start with, "Okay, I've got 20 items that I'm prioritizing right now with my team. Of these 20 backlog items, how many of them do I have at least five customer data points that give me any indication that I'm doing the right thing?"
You see this quite often. Every team will use their own prioritization framework, but I take something really simple like the ICE framework. You've got impact, you've got confidence. You've got ease. Well, what I'm seeing in most product teams that I've worked with, or that I've worked near has been impact is super relative and super gut-feeling driven most of the time. Ease is super under-scoped and underestimated 9 out of 10 times.
[00:22:27] Erin: Everything's easy.
[00:22:29] Ferdinand: Everything's easy. Everything's super impact. Then confidence just comes out of nowhere. It's like they just go like, "Oh yes, I'm really confident." Your personal confidence has already been reflected in the impact. The confidence in my opinion should come from customer feedback and customer data, of course. I think the process here is that for companies that say, "We've got way too much feedback," flip it around. Look at your product backlog, look at all the things you want to build in your roadmap and ask yourself, let's prioritize this.
The confidence score can only be increased if you have customer feedback points or customer data points to validate this particular idea. Then start attaching those to your roadmap items or your backlog items, and then do your prioritization again. That's a really simple way to funnel down and really focus on some pieces of feedback over others, but already having somewhat of an impact.
[00:23:20] John: Yes. I love that framing.
[00:23:22] Erin: Ferdinand, a lot of times with various tools that gather feedback across departments and are product-centric and how they get used, you'll see the insights broken up into product roadmap-centric language. I'm wondering, is there some benefit in thinking about insights in terms of user segment or user pinpoint or a more user-centric way that can be useful here in deciding how to action some of these insights?
[00:23:49] Ferdinand: Yes, I think generally every company will work with a different informational hierarchy. If you're working with general, let's take the classic, your themes, epic stories, and so on. I think at every level of information or every level of granularity, you can benefit from those customer insights. One of the things we like to do a lot is user stories. We think user stories, they play such a central part to our product development. Essentially when we're building something we almost only rely on user stories to really decide what to build.
We say, we need to build this solution. We're going to take six weeks to work on it. Let's rank or prioritize all the user stories from most important to least important. Then just cut a line where we think that six-week mark lies. Then we will use different kinds of feedback to validate not only what we're doing, but how we're doing it. I'm not sure if this answers your question directly, but if you're working with your product roadmap, that's a higher level, this is what we're trying to build.
Even within those features how you're going to build them, what kind of different user stories you want to address. All of those require or can benefit from an association with customer feedback and customer insights that can help validate shape and really give confidence in how you're designing your solutions basically.
[00:25:08] Erin: I imagine when you're doing more discovery research or perhaps your product is earlier stage, your product roadmap is very open-ended and opportunity-based. You need some container to put these insights in that might come before the roadmap exists. Like you were saying user stories or whatever, that framework can be potentially helpful there. I'm curious, what are some of the challenges you've seen working with some of your customers or in the industry generally? As folks try to implement systems like this and maybe some solutions you've seen to some of those challenges?
[00:25:45] Ferdinand: Yes, I think with smaller companies, the biggest challenge is who's in charge of this who owns this. It is a process that as important as it is, it does require some time, effort and focus. In a small company, you're rarely going to have one of the founders take the helm on this. There you really need to coordinate and assign an owner. I think that's really important. The biggest risk there always is that you have these responsibility gaps that everyone says, hey, it's a team effort, but then nobody really feels responsible for it.
They're having clear ownership. That's one of the challenges that I see with smaller companies. With the larger companies, it's making sure because this process is nothing new, I think generally talking to customers, most companies do that. Making note in some way, shape, or form of interesting things that the customer says, most companies do that. Trying to share that with other people who are working on projects that could benefit from it, companies do that with less success, but they still try to do that.
This whole process, it's nothing new. It's already happening just right now it's happening, fragmented. It's siloed. It's scattered across different departments. They're using 20 different tools. You collect your data with one tool, you centralize it with another then you do your journey maps on a different tool. Then you have your product backlog lives on this tool. Then your product roadmap lives on another tool. Then you actually, your development team is working on a fifth tool. I think that fragmentation if you look at every single other field, sales teams, they all use Salesforce or something like that now.
HR teams started using BambooHR, what do I know? Marketing teams are Marketo and HubSpot. Everyone's doing this, but I still feel that product teams very often are still fragmented between quite a lot of tools. That's very often with the larger organizations to be able to say, hey, you need to build this into your existing processes because those processes already exist. These habits already exist. Then making sure that your tool stack, your teams' activities, that your strategy is fully aligned with what they were doing or connects well with what they were doing previously.
It's a very different challenge.
[00:27:51] John: That makes a lot of sense. The thing you shared before about Hey, instead of trying to boil the ocean and process every single piece of feedback that comes in, I think people have this natural completionist streak of we're going to make sense of every single thing we have. Instead of framing it as, hey for everything we want to do that's tentatively in the backlog, let's just make sure we have five pieces of evidence or insight for it. I'm curious. Do you have a similar approach or framework for how teams maybe get into like the taxonomy or organizing insights?
That just feels like another area where I can imagine a well-intentioned, smart person paralyzing themselves before they even get started. They're like, "We have to come up with the perfect hierarchy of how we store all this stuff." Are there practical ways to step into that let teams move forward without getting bogged down?
[00:28:33] Ferdinand: Yes, I think keeping it simple is an important starting point that over-engineering or overcomplicating it is not going to help. I think that's, again, the boiling the ocean, like you say, going from 0 to 100, that's leads to here's 25,000 categories and tags that we can use. You don't want that. I think good categorization and tagging and the solid search functionality in whatever database you're using, that's going to be very helpful.
It goes back to the reason I suggested that you don't ask your sales team or your support team to filter in advance, is you want all that information to come in because what's not important today might be important tomorrow. The key is if you just use simple tags, it depends what kind of tags you want to use. For example, if you work with product themes, that can be one category on the basis of which you tag. If you have different user segments or customer segments, you're going to want to have that customer segments as a category and tag the different kinds of segments.
Then if you have feature requests versus bug fixes versus usability requests, the type of requests they're giving and the type of source. Was it a feedback form? Was it an interview and the team that collected it? Those are the categories I would always advocate. Then tags under each category that are pertinent. That doesn't have to be very complicated. The advantage is 3, 6, 9, 12 months down the line when you're working on something completely different that maybe you weren't even aware of at the point in time before.
You want to find information, you don't have to start research from scratch. You can actually first go into that database, that repository, and you can start using those texts to say, hey did we ever collect any information on this? That's really, really helpful. That's where I would say simple tagging and categorization can go a really, really long way. Even the most basic tools allow you to do that.
[00:30:20] Erin: Yes. It does feel like less is more because if you have a smaller number of tags that maybe aren't exactly what you're looking for, it's easy enough to map those to what you maybe are looking for. Versus if you went all-in with hundreds of tags out of the gate, that could be quite overwhelming.
[00:30:37] Ferdinand: Yes, for sure. Yes, it also doesn't take that long to pour over 10 pieces of data or 30 pieces of data. It doesn't take that long. If you have some simple tags already just to help narrow the scope, you'll be able to take it from there most of the time.
[00:30:52] Erin: I also imagine another benefit of having different departments add insights without a ton of filtering is you reduce some bias, right? We're all biased as we talked about, different teams have different incentives and motivations. The lens through which that raw insight is going to be filtered will vary by person and department. You can take some of that out, even if it means you have more raw data to ultimately process in the end, you're going to get the benefits of that raw data as well.
[00:31:24] Ferdinand: 100%.
[00:31:25] Erin: Ferdinand, what else should we know about gathering insights across departments?
[00:31:30] Ferdinand: To be honest, I think the key is it's not rocket science and just do it. I think it's so simple to get started. Always regurgitate the same statistic, which is I think it's something like 93% of product teams talk to customers before designing anything. That's a really, really high number. It should be that high, but that's still really, really high. Over 90% of companies talk to customers on a regular basis in some form or another. The conversations are already happening and it's just such a shame not to take advantage of them.
If you look at the statistics on how often we talk to our customers. Then you look at studies that say, what is it, a 30% of prioritization still is reliant on CEO and stakeholder pressure. Another 20% is based on gut feel. You're just sitting like, why is that happening? That you're talking to customers every day and people are still going about-- even people who are aware that they shouldn't, they're a little bit biased in their prioritization. Of course, there's always going to be some bias, but if you can at least rest on a couple of data points from customers to validate your decision, that's really valuable.
Maybe the last thing I wanted to add because I touched upon it is this is something I've seen more and more. It's the problem I underestimated in the past is how often product teams struggle with the pressures from other stakeholders. Very often, especially in a smaller company, you have the CEO pushing, "Hey, let's build this. I saw this somewhere so we should build this." It's really hard for someone who's not in a very senior position to push back against that. Even if you're in a senior position, to be honest, if the CEO at a small company's pushing you, it's hard to push back.
I find having customer insights gives you an important weapon there because when a CEO comes and says, "I want to build this," and you can come back and say, "Look, I got these three other things we could build and I've got 20 data points to prove it. I can't find a single person who says they want what you're suggesting. Do you want me to build it?" Most of the time, these days that stakeholder will back off. At least, if they don't, you've indicated in the long run of the next time they're going to think twice.
[00:33:35] John: Right, or you have a different problem in your organization.
[00:33:37] Ferdinand: Exactly.
[00:33:39] John: Maybe a different spin on the way I always think about it too is especially for me, I've been working at User Interviews for a while now. Over that time, the gut stuff comes from somewhere. To your point, right, of like you have this gut feels it's because you've had all these conversations. You've seen all these insights, you've gathered all this data over the years. It's different when you're telling people that like, "Oh, I have a strong intuition that we should do this. Trust me."
That's very different than, "I have a strong intuition that this is worth doing, here's 20 pieces of feedback that support it. Why don't you read it and see what conclusion you draw?" That's like, you're getting there in a similar way but being able to have the evidence or show your thinking that maybe is informing your gut. It just is very powerful especially as the teams get larger.
[00:34:16] John Yes. It's so much better. You could still build a culture and say, hey, you know what? Once in a while, you get to do a gut feel bet. That's fine. There's nothing wrong with saying, you know what, our gut feel has served as well in the past. It doesn't come from nowhere, like you say. Once in a while, you can just bypass all the processes and say, "We're just going to build this anyway." That shouldn't be the norm. The norm should always be we have some evidence. I think that that's simple.
[00:34:37] Erin: I think that's a great place to leave it except for one more question I would like to ask, which is what do you love about user research, Ferdinand?
[00:34:45] Ferdinand: I just love talking to customers. I love talking in general. Having an audience always helps and customers. It's just I started my career in the world of growth hacking where it's all the newest tool, the newest trend, the newest hack, the newest tactic. It drove me nuts because at the end of the day if you don't know who your customer is, all of that stuff's useless. There's just such a big difference between knowing your customer from something somebody wrote versus having talked to them yourself.
That customer empathy is just something that, it brings everything you do in a company to life. It makes your product better and more satisfying to build. It just makes everything better. I'm a big fan of talking to customers.
[00:35:22] Erin: Thanks so much for joining us, Ferdinand.
[00:35:23] Ferdinand: Thank you very much.
[00:35:24] John: Thanks again.
[00:35:27] Erin: Thanks for listening to Awkward Silences brought to you by User Interviews.
[00:35:32] John: Theme music by Fragile Gang.