How to make customer feedback accessible
Summary:
Are you overwhelmed with customer feedback? Do you want to know how to structure user research and distill the right insights?
Today’s guest is Ferdinand Goetzen, Co-Founder and CEO of Reveall, an all-in-one customer insights platform. Ferdinand guides listeners through his framework for gathering data, structuring and interpreting it, distilling and validating the right solutions, as well as prioritization and development.
Ferdinand is passionate about solving one particular problem—if you want to build a successful business, you really need to understand your customers.
Episode Highlights/Topics:
- Reveall: How and why Ferdinand got into product-led growth, customer-centric mindset
- Customer Feedback Challenges: Digital transformation, growth of product management
- Customer-centric Mindset: Understanding not only your product but your customers
- Too many tools? Most product teams need/want one system of record for data/learnings
- Practice What You Preach: Speaking to customers is fundamental to everything
- Who should talk to customers? Everyone—from founders, developers to finance, legal
- Why record data/learnings? Digestible feedback helps validate and make right decisions
- Interpretation: Not every great innovation was invented by the customer
- Product Development: Utilize user stories to understand need and then build solution
- Prioritization: How to know which initiatives/features to start and will be most impactful
- Who should use Reveall? Any product team that wants to bring customer learnings closer to product prioritization
Resources/Links:
The Customer Centricity Playbook by Peter Fader
Read the transcript:
Victor [00:05]: Are you overwhelmed with customer feedback? Do you wanna know how to structure user research and distill the right insights? Today’s guest is Fair De Not Goodson, founder of Reveal an All in One Customer Insights platform. He will guide us through his framework of gathering data, structuring and interpreting it, distilling and validating the right solutions. We’ll also go over the prioritization and moving on to development.
Ferdinand [00:24]: Welcome back to the Product Stories podcast, hosted by Victor Nik. This podcast helps founders like yourself to find leaner ways to build successful SAS products.
Victor [00:38]: You are welcome to the show.
Ferdinand [00:39]: Thanks for having me.
Victor [00:41]: Yeah, my pleasure. Up. Looking forward to this one because you really work with this stuff. But first off, how, how did you get into, uh, Running Reveal? What’s your, what’s your history?
Ferdinand [00:51]: Yeah. Uh, I started my career in marketing. I started marketing agencies and then I moved to Amsterdam, Yeah, years ago, to, to really get into kind of fast growing startups and, uh, starting in kind of a marketing function and getting more and more involved in product led growth. So I got more involved with these different disciplines through, yeah, product led growth, product marketing, and various other disciplines. And that really got me, uh, into the, the, the customer centric mindset into understanding product organizations, the importance of prioritizing your roadmap. And then, uh, after a few years and a couple of exits and the companies I worked for, I decided to start my own business. And I was really passionate about solving one particular problem, which is if you want to build a successful business, you really need to understand your customers. And, uh, I always found that there’s a big gap between companies desire to be customer centric, which is unprecedented, but their ability to really put that into practice. So that’s something that, um, I’ve been passionate about and that’s why, uh, I wanted to start Reveal.
Victor [01:50]: Awesome. And what’s so hard about getting customer feedback? What, what’s the challenge here that most people face?
Ferdinand [01:56]: There’s a lot of different challenges at, at play here. I think fundamentally what it’s all about is over the last years, I mean about 10 years ago, you started seeing, or even more, but especially last 10 years, you saw a lot of digital transformation within older businesses, newer businesses establishing themselves, uh, digitally from day one. And what you’ve see in the last year is, is a similar process happening in kind of the productization, kind of the, the growth of product management as a function has just been exponential. And now the same way that bigger corporations used to, uh, have entire projects and departments dedicated to digitalization. You have the same process happening in terms of product management emerging as a key function within these businesses. And with this growth of product management as an important function within businesses, from startups to corporates, you’ve seen this growth of customer-centric mindsets.
[02:46]: It’s really gone hand in high hand as, as product has become really important. Understanding your customers has become really important. The big challenge is that currently when you look at most teams, if you look at sales teams or marketing teams or development teams, of course there’s a lot of different tooling in each industry. There’s a lot of different niches and point solutions for each function. But you see that the most successful teams seem, tend to rally around kind of that one system of record. So for development teams, oftentimes that Jira for marketing teams, it’s often HubSpot or Marketo for sales teams at Salesforce. And you usually see this, you see these point solutions emerge and then they kind of consolidate into platforms. And I think the need for platforms comes from a need to collaborate and centralize your data and your learnings. And that’s something that currently doesn’t happen in product departments as much because when you look at a product team, very often they’re using half a dozen tools.
[03:45]: They have a tool for gathering their UX research, They have a tool for creating UX research repository. They have a tool for customer journey mapping. They have a tool for product prioritization. And what happens with this crazy fragmentation is that information just kind of gets lost. You, you just end up with, every time you’re switching from one tool to another, you’re losing insights, you’re losing collaboration, you’re losing data. And this is both a cause and a symptom of the fact that product teams tend to have quite fragmented processes. You know, you at the end of the day, ahead of product decides, very often it’s product leaders decide that a UX research team is necessary or that a UX researcher is necessary. But the processes of the product team and the UX team and the journey mapping teams, if there are teams dedicated to that, they they’re very split apart.
[04:33]: And, uh, we really believe that that needs to be unified into one process. We believe that needs to be a clean flow. That’s also what Reveal aims to do is bring, to be that solution of record to bring all of this into one place. So I think a siloing and fragmentation of process is the biggest challenge. On the one hand, we’re talking to customers every single day. Most companies are talking to customers in sales, in customer success, in doing, they’re doing their market research, they’re doing their user interviews. But somehow from that moment of contact until the actual prioritization of the roadmap or the backlog, most of that information just kind of gets lost. That’s the biggest challenge right now.
Victor [05:07]: I think that’s right. So, um, I guess when you’re talking with customers, right, there can be customer support, as you said, they have their own tool designers or UX researchers even, even if they talk to clients, they might even put that information into Figma, right? Because that’s their tool of choice. Like I’ve seen things like that either Miro or, or even even that research in Figma sometimes. And uh, then obviously the product team in, in Jira and, and then nobody’s really talking to each other apart from the water cooler situation. So that’s really, really good point. Do you see a big difference in that? That just came to my mind when you said that older companies are changing versus new ones are obviously emerging in new patterns are emerging. Do you see different challenges in, you know, obviously validating a completely new startup that needs to be customer focused to even understand whether they’re building the right thing versus a super old company, well super old, whatever, could be 10 years old or or 50 years old that that understands they need to change their pattern. Is there, is there something different here?
Ferdinand [06:14]: I think the big difference, I tend to find, of course, bigger, bigger traditional organizations, they’re a bit clunkier. They have slower processes, they have more decision makers. Uh, they also have a lot more resources. But, uh, of course it’s not always smooth sailing. What I have found though is that the bigger organizations tend to be quite humble about it. You know, they’re coming in usually with a mindset of, Hey, we’ve been around for years, we wanna do something differently and we are really keen to learn and we have the resources. We might not do it fast, but we have the resources to actually make this transformation. Whereas smaller companies, I think you have a little bit more, the startups, they often have a bit more of that misconception when you ask them how important is knowing the customers, You know, they’ll give it, if you ask them to, I dunno, grade the importance of understanding your customers to your strategy, they’ll probably give you a 10, outta 10 average, or nine outta 10 average.
[07:05]: But then when you ask them, do you, do you really understand your customers that there’s a big gap there? And then if you really were to test them on how well they know their customers, it’s usually quite poor. And I think that’s true of most companies don’t know their customers as well as they want to. But I think very often I find that larger organizations tend to be a little bit more honest about it. It’s a gross generalization of course, but, uh, I generally find that in startups, you know, you’re building a plane whilst it’s taking it off, whilst it’s taking off. You have a thousand things to worry about. So sometimes understanding your customer can almost feel like a luxury. So I think, yeah, the, the, the younger companies, the startups, they really know it’s important, but they struggle to prioritize it. And again, it’s part of the fact that this process is so fragmented. So it feels like a lot of effort building a product that is all about being customer led. Uh, at Reveal we try to practice what we preach from day one. So speaking to customers is so fundamental to how we do everything that we’ve, we’ve really implemented it from the start, but it’s not easy for every company to do that. And yeah, you learn fast, you fail fast, that’s really important. But, uh, it, it can also be painful at times.
Victor [08:11]: Is it that, that startups are poor at being customers centric or have worse insight in their customer base because they simply don’t have the customer base as opposed to big organization that might have thousands of customers they could potentially tap into?
Ferdinand [08:26]: Yeah, I mean, let me be clear. There are definitely, when I said talked about the organizations that are quite the old organizations, the big organizations that are quite humble and really keen to learn, that’s not all of them. There are definitely companies out there that have been around for 50 years and they say, what we do has worked for 50 years. We don’t need to change. A lot of companies like that, the ones that really do want to change and digitalize and modernize and become customer centric, of course they can tap into a huge database of data. Usually they, they have access to the insights they need relatively quickly if they want them. So definitely it’s a challenge. Uh, I think when you’re talking to pre-product market fit startups, so super, super early stage, like really new baby startups, they definitely talk to the customers all the time cuz it’s become such a fundamental process.
[09:06]: Anyone who does kind of the lean startup methodology is get people to use it, get the feedback, iterate feedback, iterate, feedback, iterate. And you know, as long as you’re not getting traction and selling, you have no other choice than to talk to people and learn, talk to people and learn. It’s usually once you they get that product market fit, they start getting their traction up to kind of the scale up phase, that’s where the gap happens. And I think it’s partially because they don’t have access to the data, but I also think it’s partially due to the, just the chaotic nature of startup life. There’s so many things you could be doing and uh, sometimes, you know, customer research fuels contradictory to this, uh, this, you know, move fast and break things mentality that a lot of companies like to pursue, which is, you know, should we talk to 10 customers or should we just build it and see if it works?
[09:52]:But I always say that, you know, product teams have, they, it’s very simple what product teams want to do. They wanna build the right things in the right way at the right time. Because if you build the right things at the right way at the right time, you can go to market faster, you can outpace your competition, you can create value for your customers faster, you can drive revenue, acquisition, retention, that’s what it’s all about. Build the right thing in the right way at the right time. And I think, uh, that’s something that is harder to do when you’re a startup because you just wanna build things and see if they work. But building things, things that don’t work don’t necessarily mean you’re not building the right thing. You might be building the right thing in the wrong way, for example. That’s where these complexities kind of arise. I think a lot of companies are very customer centric and operate in quite a customer-centric way. I I just think that it could be so much easier for so many companies if the processes were integrated, if user stories and understanding the customer were a fundamental part of their day to day working.
Victor [10:46]: And I think that’s exactly it. When you say, you know, we’re, we’re building the right thing, but in the wrong way, right? That sometimes the, the lack of, of data might be made up for by, by the vision or, or the intuition of of the founder. I think that’s what happens in very early stage companies a lot. And then either he’s right or he or she’s right or, or is not. But once there are people you can speak to or ideally even before you build anything, you, you might have a user base, um, who should Rudy speak to customers versus how should that be gathered? Because you have uh, obviously the UX role, you have customer success, you have product management, at least UX and product management, both are trying to figure out our be building the right thing. How, how would one structure that?
Ferdinand [11:38]: Yeah, I think that’s a good one. I mean if you say who should in an ideal world, I think everyone should talk to the customers, including developers, including finance teams and including legal teams. I think everyone should fundamentally understand. Cuz I think there’s a big difference between customer knowledge, which is something you can get from a report or a document and customer empathy, which is something you develop for your interaction and engagement. And uh, I think everyone in a company should have that. Of course, realistically speaking, that’s not so easy even in a company like ours where we try to make it fundamental. Not everyone talks to customers every day, but we try to talk to customers as much as we can. I think the, who is a difficult one, I think when you’re a very early stage company, whoever is doing it should be doing it, if that makes sense.
[12:19]: If you have someone in sales, then the key is not necessarily getting more people to talk to the customer, but the first step is whoever is already talking to the customer, make sure that you’re getting those learnings. So if you have sales calls, are you recording them with something like Gong or air call or whatever And are you then getting those recordings, transcribing them, highlighting the key takeaways and understanding, hey, this is what we learned, right? I think, uh, very often people, people reduce understanding customers to, hey, I’m gonna send this survey or this feedback form. But there was a very artificially created forms of feedback. I think when you’re trying to sell someone your product in a demo and then they tell you, Sorry, we chose someone else because of X, Y, z. That’s some of the most painful, but the most valuable learnings you can get.
[13:06]: And this is where I kind of take, uh, issue with most of the tooling out there, and not necessarily to name names, but you have a lot of product management tools that claim to be insight driven or customer driven and then they have like an integration. And those integrations, they, they, they kind of work, but they only work when somebody’s telling you exactly something. Giving you a very digestible soundbite. I’ll give you an example. If somebody sends you an email saying, I wish feature X had functionality b whatever, if someone sends you that email, you can pull that into your product management tool through, through an integration. You can stick that onto your roadmap or stick that onto your task, your issue, your epic, whatever you wanna call it. And then you have the validation there. But when you have a 30 minute sales call or an hour long user interview, that’s a lot of talking for probably three to four key takeaways that actually matter for your decision making.
[13:55]: And that’s what most project management tools don’t do. Most project and product management tools don’t have that data synthesis and analysis part. And most data synthesizing and analyzing tools from transcription software, UX research repositories don’t have that decision making part and bringing those together. I mean, of course, you know, if I’m gonna be super biased and do a shameless plug, I say you should do it with Reveal. But even if you’re not doing it, even if you’re using a combination of Confluence, Jira, and Miro, you should be integrating this process, bringing it together. The question of who depends on where you are, what stage you are in the organization, I think very often you will find that UX people own it. But we generally see, I love, uh, there’s, there’s this great market research report by, uh, or industry report by user interviews, which is kind of the state of user research.
[14:40]: They recently released the 2022 version, really good read. And they like to differentiate between two kinds of people, which is researchers and they’re what they call p pwd r people who do research. So a UX researcher spends all their day doing research, whereas a product designer probably spends 10, 20% of their time doing research. Their main goal isn’t research, but they do research in order to facilitate their main goal, which is validating i i ideas or designs and concepts. And then you have kind of product leaders, product managers who are more about the decision making, the bigger strategy and the actual, uh, execution of that. So first, in a small organization, make sure you’re centralizing the insights for anyone who is talking to customers in a bigger organization. Assign people to own it. And that can be a product marketing manager that can be a growth marketer, it can be uh, a sales operations person, it can be a UX researcher, it can be anyone you want.
[15:29]: I think, I think the key is someone should own it and everyone should try to contribute to it. And the key of using the right tools is also making sure that you make it easy, right? Because someone in cus in sales, it’s a salesperson’s first instinct, isn’t to send their insights over to the product team. It’s not so you need to make it easy for them of course. And that’s, that’s kind of the hard thing. I do think product teams or UX teams should own it just cuz they get the most immediate value out of it.
Victor [15:56]: Hiring a perfect team isn’t a piece of cake, is it? To find a good candidate, you need to post a job on multiple job boards, review like a hundred cvs, conduct at least a dozen initial interviews to make sure there’s at least a single specialist you would like to hire. But with superb hire by trustor, you can forget about all of the hiring headache. Find, meet and hire skilled and dedicated assistance ready to take over marketed sales, administrative customer support, data entry or other task contribute to your business growth and help you reach your goals. Superb hire takes care of the entire recruitment process. You just have to show up for the final interview, visit superb hire.com and book a free no commitment call to learn more. It’s superb hire.com.
Victor [16:41]: There’s obviously multiple ways to get that feedback. One is I’m just gathering as, as part of my daily job, right? The salesperson or the customer support person, they just interact with clients anyway and they then gather that and should probably distill some takeaways from it versus if I’m a UX person or a product manager or the CEOs trying to figure out what to do, how, how should I go about going out to my customers and, uh, doing that research.
Ferdinand [17:12]: One of the previous companies I worked at 3D Hubs now known as hubs that we, we used to just say, get out the building, just go talk to them. There’s events and meetups and it’s, it’s not that hard. I think it’s, I think the starting point is to just get the conversations going. I think a lot of people, and this is not just true of user research, I think very often people think about a very sophisticated way of doing something before they’ve even started doing it. Like, you know, learning to run before you’ve learned to crawl. And I think if you’re not talking to your customers, so as a founder, I think you should be talking to your customers every week, at least as a ceo that should be your goal. Talk to customers every week. And if you can’t do that, start with every month and later you can start thinking about what are the right processes?
[17:55]: Am I asking the right questions? Am I avoiding leading questions? Do I have the right research methodology? Am I, you know, managing my research insights the right way? I think all of those things, they should come secondary to just doing it right. It’s not that hard to get your customer success or customer support or you, yourself as a ceo, if you email five of your most active customers and say, Hey, I’d love to get on a 15 minute call just to ask you one question or two questions, that’s a great starting point and that takes you 15 minutes so you can’t say that you don’t have time for it. And then that just gets the conversation going. And I think that’s really the starting point. And then once you have a sy uh, kind of a a a a set where people are talking to the customers, you can think about how to make that systematic and how to make that more efficient, how to make that less biased. I think those are secondary concerns to actually just doing it.
Victor [18:47]: That makes a lot of sense. So, so crawling basically is just, you know, speak to your clients and then running might be either customer interviews in a structured way or even user testing from, with, with um, anonymous users that have never seen your product or something like that. And then, then you gather all of that and try to interpret it. Which really leads me to the next question because I think a lot of people also struggled with interpreting this, right? There’s, there’s that, that challenge if when people tell me what they want, what should I then build, right? There’s that Henry Ford quote being passed around, which I, I, I think, I think illustrates that, right? With the faster horses and obviously there’s something in there, but it’s, it’s, it’s not quite what, what people said they wanted, right?
Ferdinand [19:39]: Yeah. I I think there’s uh, of course, you know, there’s customer feedback and there’s customer voice of the customer, let’s call it, and customer insights. And then there’s also your vision and you know, not every great innovation was invented by the customer, right? Sometimes you come up with something new and people didn’t even know they want it. I think there’s this Steve Jobs quote of, you know, build things before people even know they want it. And I think that’s, uh, that’s very true. And then the, the Henry Ford quote with the faster horses, I mean, aside from the fact that he never actually said that, and also that not too long afterwards, I think Ford struggled heavily when a more customer-centric, uh, model with uh, uh, GM came into the market. Cuz Ford also said, you know, I don’t care what color it is as long as it’s black.
[20:19]: I think there’s also a big downside to that mentality, cuz very often people you like to use the Ford quote to say, you shouldn’t be customer-centric or you shouldn’t listen to your customers. And I think that’s a, that’s a big pitfall. You should definitely listen to your customers. But I think the key is if a customer asks you for faster horses, well what are they actually saying? They’re saying they want to get faster from A to B, right? So of course you can’t take everything every customer says at face value, and there’s going to be customers who really get what you’re doing and customers who don’t really get what you’re doing. And of course you should favor the feedback from the customers who really get what you’re doing, who are most aligned with your vision, who are most aligned with what you’re building. That’s why you need to know your ideal customers.
[20:58]: You know, there’s a great book by, uh, Peter Faber, Favor, Favor, yeah, Peter Faber, I believe called Customer Centricity, where he basically says, you know, Apple is not a customer-centric company, but Tecos, the supermarket chain in the UK is super customer-centric, right? Because if you’re using an Apple computer, you have a dongle. I don’t think anyone asks for a dongle and it’s not necessary. So, but apple’s at such a stage where they have such a strong product and brand, they can do whatever they want and the rest of the world will follow. If you flip that around in the faster horses question, it’s, I wanna move faster. So whether you build cars, rocket ships, hover boards, it doesn’t really matter. You’re, you’re solving the fundamental problem. And I think that’s what it’s always about. I think that’s one of the mistakes that I see companies make a lot is they’ll get on a sales call and they’ll lose a deal because of feature X and then the whole company kind of rallies to build future X.
[21:47]: But it’s is that what a really good salesperson does is understand why do they need feature X and can we solve that differently? If you can solve that differently, then you gotta build feature X, but if you can solve it differently, find a different way to solve it first. And I think it’s about understanding their problems and their needs. And for me it really boils down what, what plays a really central part in our own product development process at Reveal is user stories. It’s all about the user stories. If you understand your user stories, you can build the best product in the world. And of course really understanding them is a challenge. And then really making that a reality is a challenge. But that’s what it’s all about. What are your users trying to do? What are they trying to achieve? What are their needs? Then you, your role is to come up with the most innovative, the best, the most effective, the most cost effective solution. That’s then your role as a product person is to meet that need. But I do think understanding that need is fundamental and that’s really what I take away from the faster horse’s ideas. What is the need? And then you build a solution.
Victor [22:45]: That’s a really good point because a lot of times when people are asked for feedback or, or generally asked about their needs, they will first name a solution that’s in their mind, not their need. It’s like automatic. You’re being asked for your need and you come up with a solution as the answer, but you don’t answer the actual question. You don’t answer what your need or your problem is, which is actually quite funny. But I guess that’s because people in their head, they try to solve their own problems in, in whatever way they can from, from whatever position they’re in. And I think that’s the faster horses mentality if you wanna even stay with, with that quote because people are answering the question from their point of view. And so I guess you should, as you said, understand their need that’s behind that. But probably take the suggested solution with a grain salt and understand if you at your, you know, with your product head on, if you can solve that even better with everything that you know and your, your innovation. So the process really, so far we’ve talked to people in some way. We, we took notes or whatever research material we have, we distilled key points from that. We, we managed that in, in some sort of solution. We put that, we centralize that so that the entire team knows about it. What should I do with that data next? Should I map that somehow? Should I, should I try from there to create new features, new solutions? What’s a great process here?
Ferdinand [24:21]: I think you, you really illustrated these different steps very well and very clearly. I think maybe there was one jump there, which is everyone has access to that. I think there is a, that is its step in itself is making sure that everyone is aware of this stuff. So you get a lot of companies, they do great research, great insights, super centralized, really accessible and then nobody reads it. Basically anyone who’s ever used Confluence or notion is it’s you know, 90% writing and 10% reading. And that’s kind of the problem is it needs to be super digestible. So whether that’s reports, whether that’s video snippets, whether that’s having uh, all hands and sharing stories in company meetings, it’s really important that everyone is aware of this information first. That’s why companies like to go for some kind of tagable kind of solution where they could easily find their information.
[25:04]: Maybe one note on what we were just talking about before, people, we live in this kind of polarized world where everyone seems to tend, tend to think that you’re either one thing or the other thing. And I’m religiously customer centric, but at the same time, you know, that doesn’t mean that everything is only about taking everything at face value. So when it comes to your decision making, what are you gonna do with this data? It really depends on where are you as a business and what are you trying to achieve. So from a product perspective, I would say you probably have a backlog, you probably have ideas on what you wanna build. The first step is to see are all of the insights we’re currently gathering, which ones of these relate to what’s currently in our backlog on our roadmap, whatever backlog is a little bit more nitty gritty.
[25:48]: And so obviously your bug fixes and all this kind of stuff that goes straight to Jira. You gotta fix your bugs, you gotta make the user experience manageable, you gotta fix your usability issues. But fundamentally every company has like the next three, four big initiatives they wanna work on. How do you know which one of these is the right one to start with? Which one of these is gonna be the most impactful at a really long debate with my uh, co-founders about the use of prioritization? So we’re currently building a feature which allows you to create actions based on your data and then send them into your product management tools. And it has prioritization built in and we were debating which framework should we use and how do these frameworks work? And we were just looking at it and we were talking about the ICE framework, you know, impact, confidence, effort or whatever variation of that.
[26:30]: And what I generally find is very often companies they’ll do the impact, it’ll be kind of, you know, I kind of think it’s gonna be really impactful. Um, the effort without any scoping that just go like it’s a three outta five and then the confidence is like a complete gut feeling exercise. I feel like they just go like, oh I’m pretty confident this will work. But the confidence, that’s what needs to come from your customer data and of course your impact as well. Your impact and confidence depend on the customer insights you’ve gathered. So there’s two ways of working. You could talk to your customers, gather learnings and based on those learnings, come up with ideas for what to build next. But you can also flip it around and say I wanna build this, this, this and this. Here are four things we might wanna build.
[27:09]: Let’s go back and find the data to validate that and not some kind like shorty poor validation where you find one person who agrees with you and you go like, great, let’s go, let’s build this. Cuz that’s super tempting. Of course if you’re a product designer and you design something, you have a beautiful concept for something or a great prototype, the fir you just wanna get to designing. You don’t wanna spend the next two weeks trying to validate that. But you need to get real insight into, hey, I wanna build X, what are the user stories that I expect behind X? And do I actually have any form of validation that these user stories are in fact correct, that the solution is in fact addresses these user stories and in fact something that companies or customers or users or people want to use. And I think that’s really where what you do next with your data is you factor it in your prioritization.
[27:54]: You should be prioritizing your roadmap and you should be using this data in your prioritization. And that doesn’t mean you have to only do that. Sometimes you wanna take a bet, right? Sometimes somebody comes along and says, you know what, I have no data, no evidence and I’m gonna build this anyway. Sure. Sometimes the best features get billed that way. Sometimes you also waste a lot of time and money that way. But you know, you can still decide as a company that you want to go with one or two bets per sprint or per cycle, whatever you’re using. But fundamentally you should be prioritizing your ideas and your customer insights should be playing a role in that. And if you don’t have the customer insights, you should go out and get them. And that’s where there’s a lot of things you can do from asking your sales people to mention new features during demos to building an online community.
[28:40]: You can ask questions to, to posting things on LinkedIn to who knows what else. We, we, we now use, uh, in Mark a lot of marketing teams and sales teams, they use kind of like, uh, these kinda automated outreach on LinkedIn. Use that for research, reach out to 50 people who fit your target audience and ask them to do a 10 minute, uh, interview or you know, do a 10 minute, you know, user test, people do it. Um, for us it’s easy because our target users or UX and product people, so it’s very meta and they understand the importance of it, but you’ll find in most industries that people are wanting to do it. So user insights define your next, define your pro your product ideas or work the other way around. Just make sure you’re prioritizing with data. That’s the key.
Victor [29:18]: Absolutely. And uh, you’ve, you’ve touched on the super important point, the prioritization, the frameworks, especially the ICE framework. For people out there who have not heard of it, you’ve, you’ve mentioned that it, there’s, there’s a few key elements that make up the ICE framework, but could you explain how, how it works? How does someone take a list of features and understand which is the most important one or which one is the next one to build?
Ferdinand [29:44]: Yeah, so fundamentally for each idea you have, you have a set of factors. So in ice, your factors are threefold, it’s your impact, your confidence, and uh, the effort, the impact, meaning how impactful is it gonna be, The confidence being how confident are you that it’s gonna be successful or how confident are you in the impact? And then you have your ease or efforts. The thing is, there is no one way you should do this. You just need to have the factors by which you want to determine, and you can make this up yourself and come up with your own factors, that’s completely fine. And then usually you grade them one to five, one being the least good and five being the best. So five means super impactful, five means super confident. Effort is always a difficult one because people go like, does five effort mean really high effort or highly low effort? It’s up to you how you calculated, but generally you, you, you, you grade each one and then you multiply those greats together to get an end result.
Victor [30:35]: And obviously if, if the lowest effort is best, then that’s where you divide in the end. But uh, that then gives you the score. But that’s also tricky because, um, the best score usually means there’s a low hanging fruit, right? Highest impact, lowest effort, totally we should build that. But probably if you only do that, you, you miss some larger strategic points that could give you even more impact. So again, probably not the easiest to, or you probably not something to follow in, in, in a dumb way, but I, this really gives a lot of insight and probably would save a lot of people from building kind of the worst case features, low impact, huge effort. I think it, when you look at that prioritization, you really realize what you definitely shouldn’t build.
Ferdinand [31:21]: The reason you need this is because no matter what company you’re in, big or small, whatever, you will have a stakeholder, usually someone like the ceo. So someone like in my role who comes in with that gut feel idea and who will bully, almost bully the team into building it and prioritizing it. <laugh>. And very often sometimes those ideas are genius, right? Those ideas can be genius, you know, no one if luckily no one told Elon Musk not to build a Tesla, but you know, like at the end of the day people will come with these ideas and you need to have a clear framework where you can at least say, okay look, you came up with this idea, it ranks out of our list of 20 ideas, it ranks 17th based on our impact, confidence and effort. It’s super difficult to do, we don’t know how impactful it’s gonna be and we have zero data to back up the confidence and I can’t find a single customer to say that they want this, do you still wanna do this?
[32:11]: And suddenly it puts a stakeholder in a very, very different position because trying something and it doesn’t work, that’s one thing. But suggesting something, having tons of evidence that it won’t work and then forcing it through and it doesn’t work, that makes you look really bad and it makes people que uh, second guess it. The other thing is I think none of the frameworks are like really, really good and like flawless, you will always have issues with these frameworks, but the key with the ice one for example, I think the main problem is that the confidence is not based on real data. If the confidence is based on real data, your ice framework becomes way, way more stable and way more reliable and you could always use ice and rice and pies and who knows what else. There’s so many different frameworks out there, you just gotta find what works for your business. Cause some business effort is not an issue because you have tons of resources and unused capacity. So you also have to adapt to what matters to your business.
Victor [33:02]: That makes a lot of sense and we’ll certainly link up, uh, a few resources on what frameworks are there. So you can, you can take a look. I’m not sure, maybe you even have some resources. I actually don’t know, do you guys have a blog or anything about that? Yeah,
Ferdinand [33:16]: We have a blog. We also have guides. If you go onto our website you can see uh, our guides and we have a guide on product prioritization for example. But we are now building a lot more content around this. So we’re gonna be sharing our opinion pretty strongly in the, in the coming weeks and months.
Victor [33:29]: That’s awesome. So I encourage everyone to check that out. Um, now we’ve gone through, you know, gathering, understanding what features to build, validating them, prioritizing them and that’s the moment when they should be pushed onto the development roadmap and then backlog. How does that work, uh, specifically with you guys at Reveal? How big is your product team? How do you guys work in implementation?
Ferdinand [33:55]: Yeah, so including developers, we have a product team of about seven, eight people. It’s a bit different here because our customer success and customer support are inside product because we want to keep that connection between product and our customer very, very short. So customer success is part of the product team, part of the prioritization part of everything that said developers, product designers and such. You’ve got about six, seven people working on it, um, full time and uh, I think this is really a good example that there’s a lot of great models out there and we just kind of try to pick the things we like best. For example, if you look at ShapeUp, which is base camp’s kind of approach, I’m a big fan of some of the ideas behind ShapeUp. The idea that you have six weeks cycles, you spent a certain part of those cycles discovering and scoping your ideas.
[34:38]: What I like most about ShapeUp though is this idea of appetite that basically before you build something you kind of say, what is the problem we’re trying to solve? And then you basically say straight away, how much time am I willing to invest in solving it? So let’s say I’m willing to spend four weeks solving this, then you need to scope a solution that you can build within four weeks. Of course you’re not gonna do that, you know, a hundred percent every time. But I think this idea of thinking about appetite is really valuable cuz we’ve all had this situation where you launch a feature, it’s supposed to take six weeks to build and then after six weeks you still got a few things missing and then you’ve got your testing and then it takes nine or 10 weeks. And then in hindsight you go, if I’d known this would take 10 weeks, I probably would’ve prioritized differently.
[35:16]: Uh, this comes back to the problem of prioritization frameworks, which is that effort is constantly underestimated with companies and you need to really be strict on that and you need to scope ahead of time. That’s another thing I like about ShapeUp you scope before you prioritize. I think that’s really, really valuable. But I don’t like six week cycles. So we work with one week sprints, uh, not even two weeks. So one week we basically map out everything we wanna work on and at the end of the week we present what we’ve done. And I think, uh, every Friday we have a thing called Friday Wind Sharing and it’s essentially everyone in the company shares what they’re working on. But it started off with just the developers showing progress on what they’re building. The reason we do this is cuz we think there’s just a huge value at the end of every week.
[35:57]: A developer needs to think in practical terms, this is the user story I need to deliver. This is what I, I wanna demo this user story in action at the end of this week. I think that’s just, or these user stories and that’s just super valuable, having those really short feedback loops and there’s really short information cycles or communication cycles cuz then everyone knows where we stand, everyone knows what we’re building and what goes into it. So that’s how we do it. We do one week cycles or one week sprints, try to scope as much as we can ahead of time, prioritize clearly, and then try to work with appetite to really think about how many, So really simple, when we build a feature, we make, we scope it with all of the user stories and then based on the appetite, we prioritize our user stories from must have to nice to have in line with the KNO model.
[36:38]: So your base threshold features your excitement, features your delight, your performance features, your excitement features. So based on the KNO model, we prioritize our user stories and then we basically just draw a line and say, Okay, we expect each user story to take this and this much time based on the scoping, we’re willing to spend eight weeks, bam. And then we just cut a line in that user, in that user story list and say, All right, this is version two, everything below this line that’s v2. And then when V2 comes along, we draw that line again. Okay, everything below this line, that’s V3 and that’s how we tend to develop.
Victor [37:08]: That’s super cool and I love these one week cycles and, but what I especially find interesting is the, the concept of appetite that you mentioned and explained, right? Because let’s say you want to improve, let’s do something complex. Let’s say you have a very complex, um, eCommerce store or eCommerce solution and you really wanna improve the search, right? It now improving the search is a very loose term, right? It can mean a lot of things, uh, from auto suggestion to even two AI solutions that try to understand what someone wants to buy when they type in a certain thing, right? And without telling people how much time or resources you’re willing to spend on a solution, people naturally want to come up with the best solution they can possibly think of. And that usually creates just super huge concepts. But saying from the start, we have, we have four weeks to improve the search gives people a very clear boundary and we’re like, Okay, okay. I I think, I think this is what we can do in four weeks. This is really gives us the biggest bang for our buck and uh, let’s do that, but let’s not, you know, train our own AI models. Something like that.
Ferdinand [38:19]: Yeah. And the other thing that happens, and this is where I don’t like this is why I like the, every, the weekly kind of demos is that sometimes people go down rabbit holes and they might not, a given developer might not understand or realize that they’re over complicating or overengineering a solution, but with weekly demos, cuz people then go like, Yeah, but this takes eight weeks to build. What am I supposed to show after week one? And we say, I literally don’t care if you’ve in the development environment just added the item to the main nav. Just something clear that is part of a user story. So sometimes we just make the page, like the outline page. You have, we, we call basically with the, the the main page. Then you have the detail page, and then you have the interactions, and then you connect the API end points.
[39:01]: That’s like four phases, that’s four weeks or six weeks or whatever. But every week you just show even the most basic thing to show that you’re on the right track. And then you always have your user stories and then you have your, let’s say your technical backend logic that you need to kind of implement. I’m ML developer as you can hear by the, the terms I’m using. But uh, you need to be able to present something every week of what you’re working on. I think that’s really valuable. And then like you say, scoping it and sometimes you will say, I wanna improve search in four weeks. And sometimes the re the answer is, there is no meaningful way to improve search in four weeks. That could also be the solution, right? If your search is already an 8 out of 10 and you’re talking about bringing it to a 10 out of 10, maybe four weeks is not enough to really make that difference. But then you need to question whether it’s a priority or not.
Victor [39:44]: All right. Awesome. I think that was super valuable. I thank you so much for, for that conversation. I think we all learned a lot about this entire process. Now given that we know the process, who should use Reveal?
Ferdinand [39:59]: Honestly, any product team that wants to bring their customer learnings closer to their product prioritization, we’re about to launch our actions feature, which is gonna really help you build your product kind of backlog or your, your your, your, your, your list of product ideas in reveal connected directly to your user research, to your customer journey maps, your user UX repository. So everything from importing data to transcribing interviews, to mapping your customer journey, to tracking the customer experience in real time, to actually defining those next actions that you will push into your product roadmap. You could do that all in one place. So I would say any team that wants to build customer led process from the ground up or make their process more customer led.
Victor [40:39]: Perfect. And where can we try reveal and learn more about you?
Ferdinand [40:43]: If you go to reveal.co reveal with two ls.co, you can find the product, get a free trial, ask for a demo. Uh, we have a live chat we always answer really quickly. And uh, yeah, we, we like to involve our customers in building the platform. So if you’re passionate about building stuff, customer centric, you get kind of a two for one deal. You get the product and you get to kind of be part of helping shape the product. And that’s, uh, kind of, uh, what we’re all about. And then I’m on LinkedIn if anyone wants to find me. I’m not hard to find
Victor [41:09]: <laugh>. Perfect. Awesome. Thank you so much for being on the show. That was super valuable.
Ferdinand [41:14]: Thank you. I really appreciate it.
