For a vast majority of the product and user research teams we’ve spoken with, time is the limiting factor that stops them from speaking to their users. Speaking to your users takes too long.
Ray Villanueva-Aswani is the Product Design Lead at Butternut Box, the UK's home for fresh dog food delivery. She tells us about the process and challenges behind moving towards a continuous user research and discovery motion, and how rapid research tools like Ribbon support them on their research journey.
Axel (00:01): Hi there, everyone. Axel here from Ribbon. Ribbon is a user research platform that makes it super easy for product and user research teams to do in-product and continuous user of research with their actual customers. Joining us today is Ray from Butternut Box, and I'll let Ray talk more about what Butternut Box do and what her team focuses on. So, Ray, would you like to quickly introduce yourself? And then we can dive straight into a conversation understanding more about how Butternut Box goes about research and discovery and all things like that.
Ray (00:30): Nice. Sounds good. Hey, all, I'm Ray. I'm the Product Design Lead here at Butternut Box. The aim of Butternut Box is to deliver health and happiness to our dogs and humans all over the world, we believe that dogs deserve better, and we do this in the form of our food. We deliver fresh meals to them, directly to their door, to deliver that health and happiness that all our dogs love. I've been at Butternut now for one and a half years, and I look after four designers across our digital product and I oversee design initiatives that goes through our web and app experiences.
Axel (01:04): Awesome. Super excited to chat with you. Could you, to kick us off, maybe tell us a bit more at a high level about the role that research and discovery plays at Butternut Box and what the typical process for that looks like in your setup?
Ray (01:16): Yeah, sure. I would say we're actually a really customer-centric business, so it's not really hard to conduct research within Butternut. It's ingrained in part of our processes and it's actually part of our purpose and beliefs that I mentioned earlier, so it's not just a product engineering culture, it's a business culture in itself, which I'll touch on later in the details of that. But fundamentally, research is part of our processes, as it not only tells us behavior or sentiment of what exists today, but how we can make it better tomorrow for our customers. So, it actually is the root of all our prioritizations and decision making within the business, and we find it incredibly valuable just knowing that also we can challenge back if there's not enough confidence or not enough research has been conducted, so we do it to develop that confidence and making sure that we are solving the right problems for our customers.
Axel (02:09): That's super, super interesting. Has that always been the case? That journey looked like? How did you get to where you're today in terms of the state of research?
Ray (02:18): To be honest, when I joined it was already often one of the questions, is, "Has this been validated?" Or, "Have you done user research on this?" How we go about doing that has changed since I joined. Obviously, we have to be quite creative with how to do research, so, often the team would email directly customers, ask them to join a Zoom or a Meet call and get them to speak through their thoughts of some designs, et cetera. But since then, we've just been using more tools and trialing out unmoderated testing to see whether that gives us more valuable insights while we get on with other things as well. So, it's also proven quite successful for us in allowing us to dedicate other time while that research is happening in the background as well.
Axel (03:08): Interesting. Who typically is involved in executing and taking part of the research process?
Ray (03:16): Specifically in the digital product team, or as different departments around the business?
Axel (03:20): I think both would be interesting to understand a bit more about.
Ray (03:24): Cool. I was going to say, it's not an exaggeration, but I would say almost all departments conduct their own form of research. Marketing have their insights manager who collect research from a customer sentiment point of view, NPS, segmentation, all of that and informs almost the wider business initiatives and prioritization. We also have an NEPD team. In case you don't have that, it's a New and Existing Product Development team, and they have a pool of customers which they call tastemakers, and they're the ones that they get in touch with to trial out products before they're released, like recipes, snacks, et cetera, and giving us feedback on how to improve those.
(04:07): And then I would say in the digital product team, product managers and product designers conduct their research. I can elaborate further later, but basically, the product managers' main focuses on the research is understanding what problem to solve, and then the product designers' role in the research is making sure we solve it in the right way, and obviously we conduct our own forms of research to validate or understand the problem in those spaces.
Axel (04:37): That's super interesting. So, everyone's involved to some extent. How does the research that product managers get involved with differ from the one that designers get involved with, for example, in terms of methodologies, but also in terms of other parts and how they go about answering these two search questions?
Ray (04:56): Yeah, good question. I think it's pretty well known now that we use a Double Diamond framework. I feel like quite a few industries use this. We really utilize that framework, and it may not be referenced much, but we definitely follow the process, where there's an exploratory stage, or what we call a continuous discovery stage, where that's more the product managers' lead. But I highly encourage product designers to get involved to understand what customers are saying in that space. But that's often what is used to understand the problems of the customer. And this is where we use Ribbon or social media, or our pool of tastemakers or pet parents to understand or sense-check those opportunities, and they usually form the basis of our hypothesis on what projects we then prioritize with our teams.
So, that's the first part that the product managers lead. And then the secondary part the product designers lead is the validation side of things, so this is solving for those problems. Depending on the project or the problem we're solving for or how big of an unknown it is, you can do this in different ways. If it's prototype testing, then we conduct usability tests on either Ribbon, calling out customers, and we just take them through and understand if they can complete the tasks we give them. So, that's the main differences between the two.
Axel (06:34): That makes sense. You mentioned continuous discovery research there. Are there specific frameworks that you adhere to and talk about a lot at the company?
Ray (06:44): I would say everyone's obsessed with Teresa Torres. Not necessarily a specific framework there, but just more her teachings on how best to conduct surveys, how best to do interviews, having non-leading questions and stuff like that. I would say the team pretty much reference her every time we do a study, but yeah, not specific frameworks in the continuous discovery phase, but just making sure that we gather those insights when we speak to customers in a non-biased way as possible.
Axel (07:18): That makes complete sense. Given that both PMs and product designers as well are involved in actually executing on the research, what's the journey been like for making sure that this is done in a good way? I know Teresa Torres speaks a lot about active listening and really executing on interviews in a way that means that the answers you get are true and representative. What does that look like for you?
Ray (07:39): That's a good question. Actually, it's just been more recently done, because sometimes people's scripts can be leading or sometimes people don't know or have the skillset to ask or conduct certain forms of research. Actually, if anything, there's two things we focused in on in that area. One is process and the other one is playbooks. We've created, alongside our insights manager, almost best practices, like a list to make sure that you've checked off that you're doing in your research depending what research it is, and process as well to ensure that it does get done. Again, depending on the project. We're not asking every team to follow strictly the process, but just more if you're not confident in the solution or the problem, to increase that, make sure you do X research or Y research.
And often, if the challenge back is, "There's no time," we then challenge back, "What can we do to make the time?" As in not to necessarily increase the timeline, but what can we do quickly to get that insight that we need to increase that confidence? And we also have two forums, we have a digital product team forum and a design review where we share these learnings, and often this is the valuable bit that the team sees or learns from to encourage them to do more of the research, because it does make it easier to make decisions and prioritize initiatives or opportunities once research is done. Otherwise, it's like a finger in the air or a gut feel of things.
Axel (09:21): Yeah, no, absolutely. I think those forums sound interesting. Are those the main way you've gone about making sure that this gets implemented? I know often, if someone's short on time and there's a lot of research to do, it can be easy to sometimes skip it over it and sometimes execute it to a poor standard. Have there been any particularly useful things, for example, these forums, that have meant that the research gets done to a better standard?
Ray (09:45): Yeah, a hundred percent. I think often it stems from either not necessarily a fear, but either the product manager or product designer, not everyone is as well-versed to research as the others, so some are more higher skillset in it than others or more experienced in it. So, often it's just an educational bit. If they say there's no time or they don't know how to do it, then we just sit down with them and say, "Okay, what do you want to find out? What are the questions you need answered?" And often the case or not, it doesn't take more than a less than 30-minute chat with a customer to understand the problem or if the solution works for them.
Often, they have in their mind like, "Oh, research is going to take a long time, it's going to take a week or it's going to take two weeks to do," but actually it's just something you can do in your day while you get on with other things as well. So, it's just reassuring the team that it can be done quickly. It doesn't have to be a massive prep for it or anything, it's just to make sure that we are on the right path and have the right confidence with things.
Axel (10:51): Yeah, absolutely. In terms of getting that buy-in then to make sure, I can imagine it's a journey, people are getting more involved in both doing the research, but also of course understanding the research is something that's really useful to execute on. What's that looked like? Have there been specific blockers, specific things that have made it easy to have these conversations?
Ray (11:11): Yeah, actually I'm quite lucky to be working alongside a product manager lead, and also our digital product director, are both very customer centric. So, often we as a pair or as a trio held certain educational sessions with the digital product team to really work that muscle and making sure that they internally vocalize the questions that we're asking them. Every time this comes up as a difficulty or there's no time or there's no money, just to be creative with these things, because often it does pay back and they do see the feedback, but we try to encourage them to do it themselves.
We don't tell them, "You have to do X, Y, Z," but it's more like, "These are the questions you should ask yourself, and if you are unable to answer them, research is always the answer, in a way, to give you the confidence or the answer that you need," because our team is very curious naturally, which we're quite lucky in. So, that's why it doesn't really take that much buy-in a way. It's like it's almost feeding their curiosity and giving them the answers that they need if they can't get it in data or insights.
Axel (12:36): How do you go about sharing the insights? Once you have run, you've executed some interviews, maybe you've run some surveys, how do you go to make sure that across the business the people who are interested and involved actually get those insights?
Ray (12:49): There are a couple of ways we do this, like our insights manager does it via email. She emails wider company reports on the survey she's done, because it is more wider reaching, so it'll influence digital products, NEPD, marketing, et cetera. But for us within digital product, we have Notions, which we call them PRDs. I can't for the life for me remember what that acronym is for, but it's essentially a document that outlines the goals of the project, the scope, the non-goals, why we're doing this, and that's where we also put in our direction in terms of how we solve for it. And as part of our design direction, we would note down or link to research that justifies those decisions or stats that have suggested that this is the right problem to tackle for now and these are the solutions and this is why.
So, we circulate those PRDs to our stakeholders, and they would then comment directly on the Notion whether they'd agree or disagree, or if they themselves have seen other data points or insights that can help justify for or against a particular initiative. So if anything, I think the team are quite responsive to feedbacking or listening to the insights that we've gathered.
Axel (14:19): That's awesome. That's good to hear. Are there any specific pieces of advice or interesting learnings that you've found in going through this journey where you would like to pass on to either earlier stage teams that are just starting to think about this, or even bigger companies where they're actually shifting more towards this continuous type of research?
Ray (14:38): Yeah, I couldn't decide between two, so I'm going to cheekily give you two advice. If you are ever joining a startup or a smaller-scale company, like I have, I would say persevere improving the value of the research, because it will pay off. You may be lucky like me, that I've joined a customer-centric company, but that's not always going to be the case. So, sometimes you just need to be quite creative in getting the research as part of your process, whether that's asking friends and family, your internal team, emailing customers directly, giving them incentives. If you don't have the time or budget, sometimes you just need to be creative in getting that in. I try to not let, "We don't have enough money," stop me from doing research.
And the second advice I'd give is to do a triangulation of research. So, making sure you just don't get it from one source, make sure it's from a couple of sources, like data insights, user testing, user research, competitor or any other secondary research that you come across, just to ensure that you don't have any biases. Because sometimes what you look for in your research can be something you just want to prove or disprove yourself, but may not actually be the case. So, I definitely recommend doing more than one form of research, and it doesn't have to be speaking to customers directly, but just making sure it's validated in other touchpoints.
Axel (16:02): Super interesting. You touched on this bit at the start of the call I think, but are there specific methodologies where, when you do this triangulation, that you seem to over-index on or rely on the most? Is it user interviews, is it survey data? I think you mentioned some reviews as well.
Ray (16:17): Yeah, often actually it leads with data, because this is the majority. So, if something comes through in the data, then we are really quick to jump on it, and if we don't understand what the data's suggesting, sometimes they can track behavior but not the sentiment, and that's when we conduct those interviews to understand why they're doing these behaviors. So yeah, we try to make sure that we have both, because sometimes you lack confidence in just the data alone.
Axel (16:50): Yeah, absolutely. Finally, looking ahead, are there specific challenges or things that you're thinking about in terms of how do you continue to step up your research practice and the testing that you're doing?
Ray (17:02): I think one of the challenges I'm facing right now, and the digital product director is also in agreement with me, is having a dedicated research team. We do do it ourselves, but sometimes we don't have the time to do them properly, so we do it to our needs and what we need it for to get us moving quickly and understanding the space, but I feel like a dedicated research team can help dig in a bit deeper into the problems we're only touching at a surface level.
Axel (17:35): Yeah, absolutely. I think that tension or coworking between actual trend researchers, where often they have to go more in depth and do the really complicated stuff, and obviously being small and scrappy can often be quite an interesting challenge. So, definitely hear you on that. That's interesting.
Ray (17:51): Yeah.
Axel (17:52): Awesome. Well, thank you so much for joining us and just sharing your experience. Really interesting to hear about how you guys have it set up at Butternut Box, and thank you for sharing your thoughts and experience.
Ray (18:01): No worries. Thank you so much. It's been fun.