Erin - 00:00:35: Hello, everybody, and welcome back to Awkward Silences. Today, we're here with Prayag Narula, the Co-Founder and CEO of HeyMarvin. Today, we're going to be talking about building a customer-centric product culture, which, of course, we are very much big fans of here at User Interviews. Thank you so much for joining us.

Prayag - 00:00:55: Thank you for having me.

Erin - 00:00:56: We've got Carol here too.

Carol - 00:00:57: Hello, excited for this conversation. As a product person, always looking for ways to be more customer centric, so excited to dig in.

Erin - 00:01:03: Awesome. So Prayag, I know that Marvin, HeyMarvin, was not built by accident, it sort of came out of a need you were seeing as you were doing your own work. So maybe you could tell us a little bit about where the company came from?

Prayag - 00:01:19: That's a great question to start with. I really like to tell this story. So I'm a researcher by training. I'm in California, we're based out of the Bay Area, and I actually came to the US to study and then teach research, design research specifically. Before that, I was working at the University of Helsinki with a research group. So I have basically been steeped in research since the beginning of my career. But as I was building my previous company, as we were doing a lot of customer research, I was really frustrated with the tooling that was available. As I was teaching, I was getting really frustrated with the tooling that was available. I felt like, even in academia, we had these really old and clunky tools that helped with qualitative research and helped with research analysis, but at least we had something. And I felt like none of the advancement had reached the industry. I was doing the same research again and again, because people kind of kept forgetting that we have that research. My team kept doing the same research, we were not really referencing that research beyond a project. The tooling, as I said, was clunky. So it was a big frustration. When I got a chance to start my second company, that was the idea basically that I wanted to pursue, and I was right in thinking that it wasn't just us, there were a lot of people who were facing the same problem. So I'm really happy and truly blessed to be working in the research and design community again. I'm really thankful for that opportunity. So again, thank you for having me.

Erin - 00:02:53: Awesome. Awesome. It reminds me a little bit of our founding story. I don't know if you know, but our founders had started another company, a long story short, not a success. Let's give it another go before we throw in the towel and they decided to do some user research the second time around. And long story short in their process, they discovered that recruiting participants was pretty challenging. And as you said, it was actually challenging for a lot of other people too. And here we are.
Prayag - 00:03:19: That was going to be my other idea if I’d pursued it, but I felt like User Interviews was doing a great job, which was my core competition, which is the research analysis piece. But there has been a lot of advancement in research tooling lately and that has been really good. I feel the world, I know in tech we are used to making these sweeping statements, but I think the world is truly better off when people are building more customer-centric, user-centric technology. I think it's part of a broader trend, and I'm very happy about that.

Erin - 00:03:52: Awesome. Alright. So everyone wants to be customer centric. This is not going to be a podcast about how you should really start thinking about being customer centric. That's, I think, well established. That's important and most people want to do that. So today we're going to talk more about how you actually do that and some high level and getting more into some tactical details as well. So curious to hear from your perspective, what are some of your recommendations to really build a culture around customer centricity?

Prayag - 00:04:21: So one of the things I've learned in my career, both as Founder CEO, but also working with Fortune 500 companies, very large companies, small startups, is that culture change is hard. And it is a lot easier to build a customer centric culture than to change into a customer centric culture. Not that it's impossible, it's just hard. So the best time to build a customer centric culture is when you're establishing a team or a department or establishing a company, if you're a startup. So that's the best time to do it. And the most customer centric teams that I have seen, it comes a lot from the top. It's a lot more of a top-down. It's a lot easier to do when the design leaders and the team leaders and the company leaders and product leaders are obsessed with customer feedback. It's a lot easier to do than to build it from the bottom up. That's been kind of the two major lessons for me. If there are team leaders, product leaders, company leaders, CEOs, founders listening, my message to them is start early. Start from day one. It's a lot easier to do it from day one. And then as leaders, obsess about it. Obsess about it on a daily basis. If you obsess about it, your team is going to obsess about it. Your team is going to want to include customer centricity every conversation that they have. And I've seen this in very large public companies. We're like, oh, these are really customer centric companies. But then it turns out that their CEOs and all the way back to their founding, they were obsessed about customer centricity from day one. But if you want to change your company into a more customer centric company, if you are trying to do this bottoms up, what needs to happen is the research team needs to act as champions for their customers, and keep repeating the customer centricity and keep bringing all the conversations back to the voice of the customer. And really showcase as close to the customer's own voice as possible, down to we are really big fans of using like video clips. So keep repeating and keep bringing the true voice of the customer into the conversation and truly become a champion. Whether you're a researcher, whether you are a designer, whether you are a product manager, whether you're a market researcher, whatever role you have, if you want to change the organizational culture, repetition and bringing as much voice of the customer and socializing the voice of the customer, that's what leads to cultural change. I have yet to meet a leader or a CEO who says, don't share what our customers are telling us about us, I don't want to hear it. I've never heard that. In spite of this being kind of a popular meme, CEOs, most leaders, most team members want to hear from the customers. If you can become the conduit to do that, that is going to drive an organizational culture change.

Carol - 00:07:20: Got it. So a piece of this is if you're in a leadership position, Founder, etc., you can start by establishing the culture by obsessing about it. And there's a piece around what individuals can do. I'd love to hear more about what it means to obsess about it? Like, what does that look like on the day to day? How are those leaders interacting with the teams? How are they bringing up the customer questions? All that.

Prayag - 00:07:38: It works in two different ways. Like, one is being proactive in asking whoever is in their organization, whether that's the research team, design team, market research team, strategy team, pricing team, proactively asking as leaders, so what do our customers say? Like, what have you heard? Is there something new that you have heard? One of the best examples I saw is, again, another publicly traded, very large technology company, and what the CEO's mandate was, especially when they were doing this new initiative, the CEO wanted, every week, to get an email with here is what we have learned and here it is in customers' exact words. So the research team was sending them these video clips or these playlists on a weekly basis so that they can proactively hear what their customers are saying. So tactically, if you can just ask those questions over and over, that will not only change the team's outlook, you'd always learn something new. The other part of this is more strategically using that feedback in decision making. And it doesn't need to be just product decision making, it needs to be all decision making. So, hey, we're making this decision about this product strategy, what are our customers saying? I think HubSpot had this great example where they had this persona in the room. So they would have an empty seat in their conference room that represented the customer. That was really good. But it doesn't need to be that extreme, and you don't need to leave a chair empty in a conference room. But keep asking the question of what do our customers think when you're making decisions is really important. And again, this doesn't need to be just product or it doesn't need to be just strategy, even pricing. In every major strategic discussion, ask yourself and ask the team around you, what are our customers saying about this? That would also change the mindset. And again, it'll give you another parameter to look at while you make these organization wide decisions. A couple of practical ways to do this are both being pre-active and proactive and then thinking about customers’ feedback when you're making these decisions.

Erin - 00:09:43: Because I do think bringing data to the conversation, quant data analytics is so deeply ingrained at this point. And obviously some organizations do it better than others. But the idea that if you're going to make a decision, build a product, launch a campaign, whatever, you better have some data you're basing that on. Where I think organizations are at different levels of maturity, of course, but having that same habit of how did we make this decision with customer insight? What customer insight did we bring to bear? And then how did we use it? And many organizations still have some room to grow and it's a great place to start, just asking that simple question like you said.

Prayag - 00:10:22: Yeah, and most organizations, in my experience, over-rotate on quant data. They over-rely on quant data and don't ask qual questions enough. There is this famous NASA saying, in data with God we trust, everyone else needs to bring data, right? And it's a great saying and it's been used over and over again as like, oh no, every decision needs to come from data. In their mind, first of all, data is quantity. I mean, I say people who keep talking about this, right? First of all, qual data is data. Yes, I think what NASA means is all data, not just quant data, but also qual data, but people immediately forget qual data because it’s harder. And the other thing is, if you all rely on quant data, most companies don't have the right kind of quant data. And even if you do have the right quant data, it's harder to capture context there. So my message to all CEOs, all leaders, all product leaders is that quant data is great and you should definitely use it, but don't over-rotate on it. Definitely ask, you know, what is the market saying? What are our customers saying? That needs to be as important in your decision-making framework as like the A-B testing.

Carol - 00:11:32: So we talked about the leadership role both. It sounds like, I think there are two pieces that I heard you say. One is sort of set a habit, this CEO trying to get feedback every week, sort of more of a habit. And one is more just making sure that in the key decisions we're making, we're bringing in the customer. So that's sort of the leader setting the example there. Then what do you think about, again, sort of these individual research teams? What are some of the things they can do? Or I'm a PM at a company, maybe I don't have a researcher, right? How do I make sure that the customer is top of mind?

Prayag - 00:11:57: Research to me is a team sport and it's not just a researcher with a capital R's job to do research. And not everyone has a research team or has access to a research team. Product managers or strategy people are actually in a very unique place where they have the mandate to go and engage with the customer. So do that, make sure that you make that active effort. Look, you don't need a researcher to do research for you. You don't need tools to do research for you. You can just call your customer on the phone and just ask them a few questions. That's better than nothing. I hope you have research and I hope you have a lot of resources, I hope you have a lot of time, even a lot of software. Even if you have none of it, it's easy to get in front if you are willing to make an effort. So first of all, my message is go do that. It doesn't need to be perfect, it needs to be done. And then the second part of this, I think I've alluded to in some of the previous questions, is this idea to socialize it, socializing your research, socializing what you're learning in the form of, here is a customer quote that I thought was really cool. Here is an audio clip that we recorded in one of these conversations. So when you socialize and you share directly what your customers are saying, your teammates will sit up and take notice. But make it easy. Don't have them go through an hour of Zoom calls to go through that one key quote. Just make it easy for people to engage with what you have learned, bring it back to the voice of the customer, and you'll start to see how quickly you, as an individual in an organization, would gain a reputation as the champion of the user and person that you can go to ask what the customers are thinking. So once you start to do that, then you're off to the races and people would want to give you more resources. So repetition and bringing it back to the actual qual data, actual quotes, actual down to video recordings or audio recordings, I think that will be a game changer. And you'll be surprised how few people do that.

Erin - 00:14:06: There's a lot of, don't overthink it, in what you're saying, which I love, right? Don't let perfect be the enemy of good. And there's a lot of verbs here. Just like do it early, do it often. That's better than having this full arsenal of expensive tools and a full research team. Talk to your customers and then share the insights and do something with the insights if they're actionable, right? So I want to get into that balance of “doing research” and then “using research.” And how do you think about where to spend the time? Do we need to do new research all the time? Is that in itself important? Or is the point to use insights we already have? How do you think about balancing the kind of doing of new research, the using of existing insights, toward this goal of being customer centric?

Prayag - 00:14:53: Great question. Here's what I'll say and this is from my experience and this personal experience. A lot of teams do research when they don't have to, or they would definitely start behind in their research project or research initiative when they don't have to. In my experience, anywhere between, unless you're completely starting down a completely different product roadmap or a completely different strategy, a lot of research questions that need to be asked, like 20 to sometimes 40, 50%, somebody has already done it, and somebody has already asked those questions. You have some insight into what your market is, what your users are thinking. It's a matter of finding it. Right. So, I mean, that's honestly, one of the biggest value propositions of our product, right, is to be able to discover some of the research that your team has done previously. So, relying on research that your team has done is really, really important and I think that will save people a lot of heartache, a lot of trouble, a lot of time. But at the same time, you know, a lot of times that you have to do new research. And then I want to differentiate between when I say research, that is sometimes you have to do research with a capital R, where it requires a proper process, a proper planning, you would want trained researchers involved, or at least you want to get some training as a researcher, even if you're not a capital R researcher, to do that right. There are times where you would need that research with the capital R, and there are times where, as I said, anybody could be a researcher with a small r. So finding those differences and having thoughts and opinions when you need capital R research versus small r research, but making that differentiation. Do I need the research? Number one, do I need proper process oriented research? Can I kind of do guerrilla research? Answering those three questions can answer when you need to do new research. Now using research, that's a whole different ball game. Ideally, every decision-making process needs to go back to some research that's being done. It's easier said than done. Like, oh, well, how do we? Researchers don't know what research has been done. They keep doing the same research. I'm not a researcher trying to make a decision, how do I go back? So that's more of a tooling question. That's more of a repository question. I think there is a lot of progress that's being made that can be easier. But using research, yes, everybody, every decision should use some customer research or a lot of customer research. People think it's all product or people think it's all market, but strategy, pricing, there are whole lots of places where teams and companies should be using research where they're not today. And that's why I'm a huge fan of CEOs where they ask questions like, what do our customers say about this? But every decision needs to start with research.

Carol - 00:17:45: You mentioned capital R versus lowercase r research. You know, I want to get into that. We at User Interviews use a similar name. We say researchers and then we say people who do research. We call them PWDR, it's an acronym. But yeah, I would love to hear about when you think it makes sense to use a researcher, someone with official research training, versus just someone who does research.?

Prayag - 00:18:05: Great question. So I think of a researcher's job as multi-fold. First job that I think researchers with a capital R, or researcher, not people who do research. I love that acronym, by the way. So a researcher's job is number one, to socialize both research, research as in the results of the research, and the job of doing research itself, and make sure that people in the organization have visibility into the importance of both of those. They are at their core, people who want to promote customer-centered thinking. As part of that, also another job that they have is training people, training PWDRs, training people who do research in terms of, hey, what are the best practices? I, as a researcher, can't be everywhere. How do we make sure that the research, the lowercase research that everybody is doing, gets done in the best way possible? So training, making sure people are following the right processes, standardizing those processes, providing them the right tools if you have available is a big part of that process. So I feel that's the primary job of research teams today. Another primary job is building out what we call a researcher roadmap. Essentially, figuring out what are the places where you need research involvement or research teams involved, and what are big strategic decisions that are being made in the organization that will require us to go and run a proper large-scale research project. That requires talking to your product team, and talking to your design team, and talking to your strategy team, staying ahead of what's coming down the pipeline. And then getting involved in that research project, and getting started in that research project is one of the best things that a research team can do. And then when you are doing those projects, actively involving your other stakeholders, and making sure that they see how research is done, that's a way to train them, that’s a way to showcase the best practices, I think it’s a really good way to build that muscle out in the organization.

Erin - 00:20:49: I've heard a few folks suggest that capital R researchers are especially adept at big, long-term, expensive strategic research. And then on the other end of the spectrum, a PM, a designer, a not trained researcher, a PWDR is maybe better suited to a usability test. Not that a researcher can't do them, but that a person that isn't a trained researcher could oversee something like that, more of an evaluative test. Do you find that a distinction like that checks out or is it not so much about methods and more, as you were saying, researchers are really advocating for the craft and doing training and then from there a PWDR could do any kind of research? How do you think that breaks down in terms of the types of research different folks are doing?

Prayag - 00:21:35: I don't think it's black and white, or you need evaluative research, go to a researcher. There are absolutely places where you won't want a research team to be doing usability testing, for example, right? Like absolutely places for that. It's about, and again, I'm not saying researchers need to spend all their time just training people to do more research. I’m saying, spend your time training people so that they can do more, let's call them low impact projects, right? And that could be evaluative, that could be generative, that could be either, but a more localized project. Let the team do those themselves, and then find where you would make the most impact. And there's usually large scale initiatives, and people usually know those large scale initiatives. And then trying to kind of make sure that you are being part of those initiatives, and trying to insert yourself and adding value to those initiatives. I think that's a lot more kind of distinction that I would make. Give your team of PWDRs freedom to do more localized research and free up your time to do more strategic research and get more strategic projects as well. And that's honestly, that's kind of something that we have seen as we've been working with a lot of very large companies. Even in large companies, the research teams are somewhat small. So a lot of our customers are coming to us saying, hey, I would like to bring out standardizations and tooling so that my team can do research while we are more strategic. And I think that's been a great change that we've seen in the last few years.

Erin - 00:23:12: So you'd say that a researcher is supporting big research that supports the strategy of the entire organization. Whereas a person who does research, regardless of method, is doing research to support their area, you know, within their sphere of influence.
Prayag - 00:23:28: I would say impact more than because sometimes you might have just one project, one product, but the company's riding on it. So in that case, you might want to get more.
Carol - 00:23:39: We sometimes hear from researchers who feel like they're being maybe late in the game and pulled in at a lower level than they think they should be involved in. So I'm just wondering if you have any recommendations for researchers who want to get more involved in the more strategic conversations where maybe their job description or the understanding of others puts them at a lower level.

Prayag - 00:23:59: That's a great question because I've heard that too. Well, I'm doing evaluative tests every day. I think about seeking out partnerships, and I asked the same question to other research leaders in my podcast, in my webinar. I think the answer I got from this research design leader, Vanessa from Twilio, and what she mentioned was this idea of trying to up-level both your team and yourself in actually going and seeking out and having conversations with product leaders, product managers, and kind of telling them and educating them and say, hey, by the way, have you thought about the risk factors of ABC? Have you thought about the risk factors, because, you know, from my experience, this could be a risk factor, have you thought about it? Oh, you haven’t? Why don't I go and do some research and come back? Maybe we'll need more research on this, right? So having those conversations with other members outside of your research team and seeking out those conversations is a really, really big part of that. But to do that, you need to also be able to say, oh, I'm not needed on this one evaluative project and I can hand that out to someone else. So it requires a lot of things to come together and it requires you to have good relationships and you to have socialized the value of research in other parts of the organization that might not be as close to your day-to-day as your immediate team is.

Erin - 00:25:28: Maybe we could talk a little bit about how you practice customer centricity at HeyMarvin. What does that look like? And it's always fun to try to dog food and experiment and practice what we preach and figure out what we want to preach by trying things out. So, yeah, how's it worked there?
Prayag - 00:25:45: One of the things that we like to do, and this thing I invented in my previous company also, is that all customer interactions get centralized. Whether that's research calls that's being done as part of capital R research projects, or research calls that's done by PWDRs, or check-in calls that might be done even by customer success, or maybe your market research is doing some research, they're running large scale surveys. So anything that we do in Marvin gets in one Marvin repository. And we go to the other extreme, we do, sales calls get centralized, customer success calls get centralized, any survey, any NPS survey, email. If our PMs are getting an email from a customer asking for features or making recommendations, that needs to go into the repository. That's a really, really good step one or step zero. And that's something that we do. The culture that we built is kind of steeped into that. So if a sales team gets on a call, a customer success team gets on a call with a customer, and they're giving some good product feedback, they'll nudge. They'll say, hey, go look at this, by the way, research team or product team, or go look at this call that I did with a customer. It's some really good feedback. So the product team makes it a point to go back to those calls. And it doesn't take much because everything is centralized, all you have to do is just take a look at this call. And then everybody in our team, engineers, product managers, designers, sales team, customers, everyone has access to this repository. So both in terms of adding data and in terms of reading data. So for us, every customer interaction is an opportunity to get feedback. And then when you make decisions, so our PRD, for example, our product requirement documents, all product requirement documents have customer feedback as a major point. In fact, down to we have videos from customers embedded in those product requirement documents and say, this is why we are building this. Every Jira epic gets connected to a product requirement document. So what that means is, down to every ticket that people are doing, unless it's bug fixing, and even if it’s bug fixing, it can actually be tracked all the way back to why we are doing this, what customers have asked for. And I think that has built, at least in my opinion, a very, very customer centric organization. Every time I read a review of HeyMarvin, I hear what great customer service we have, and how we are willing to listen to our customers. The reason for that is we are willing to hear from our customers because we're looking at that as an opportunity to get more customer feedback.

Carol - 00:28:29: So earlier, you were talking about how to make sure that customer feedback is included in decision making. And I was actually wondering really tactically what that looks like. It sounds like one thing is you have it as a part of your PRD. It's required that we get some customer input. Are there other things like that, where just either socially or sort of as a part of the process, you have to make sure customer feedback is a part of it?

Prayag - 00:28:48: So in our all-hands, we always bring in both our NPS scores. It's a requirement to report on an NPS score. And as part of that, we also have like, what have we learned from our customers that might come from ideally, there are video clips in there, but at least some quotes from the customers are included in every all-hands that we do. And this is, we have a separate product and engineering all-hand that's all about this, but the all-company all-hand needs to have a section dedicated to what our customers are saying about it. I have seen that to be one of the best ways. And then we also take it beyond product. So if we talk about pricing, if we talk about strategy, if we talk about market, we always bring it back to what our customers are saying. Do we have any customers that we have spoken to? Maybe we're breaking into a new market. Do we have any customers in that market? What have they said to us about it? Can we access those conversations? Let's go talk to a few people. This has nothing to do with if we should build this product. It's about should we go into this market? Most people are like, well, that's a separate part. No, it all comes back from the customer research and talking to your customers, talking to your market.

Erin - 00:30:03: You can imagine the scale in any organization by simply asking the question of sort of, what are all of our rituals, our meetings, are the things that we do, and how might we make customer insight more a part of those things? And it might not be an obvious way to do that across everything, but that'll probably get you some good ideas, right? If you're feeling like, we should really probably socialize this more and make this more a part of our day to day. I imagine many organizations could find some ways just by asking that question, using some of your ideas as inspiration.

Prayag - 00:30:39: I love that word rituals because ritualizing, coming back to your customers, I don't think we actively started out doing that. I mean, it's all bread and butter, so we have to do it. But I think it has become part of the company’s ritual in which I've seen a lot more customer centricity. So, ritualization of customer centricity in every meeting, every decision you make. I love that idea, that’s a fantastic way to put it.

Carol - 00:31:06: You mentioned bringing the customer feedback into strategy and pricing questions and all that? Is there anything that you've done at the leadership level or the level, you know, the level that people are having those conversations to bring the customer forward? I feel like sometimes the leadership level is furthest from the customer, so it's almost hardest to bring the customer in there.

Prayag - 00:31:27: That's a great point, which is I think I've tried to actively stay engaged with the customer. Honestly, as I said, most CEOs, most founders, most even VPs are like, they are probably spending a significant amount of time outward facing. And when I say outward facing, I mean engaging, I'm not saying like, oh, they're all talking to customers, they're all making sales calls, but maybe you're talking to other teams that are involved in the same field. Maybe you're talking to other companies, maybe you're talking to other company leaders. Whatever you learn, if your job is outward facing, bringing in those learnings to your team and documenting those learnings in your repository, I think that's a really, really critical way that organizations and organization leaders can make sure that they are actively contributing to the knowledge base of an organization. Yes, you might be farthest away from the customer, but you're getting feedback from the market on a daily basis. You're getting feedback from other outward facing people and organizations. Make sure you share that learning. Make sure you document it. Make sure you bring it back and add it to your company knowledge and add it to your repository. That's the best thing you can do. So that's where the leadership, a lot of leaders, can do a better job at that is bringing that back and sharing it with their team.

Carol - 00:32:55: So there's this piece of just you're saying that the customer success team, the product managers, the researchers are all contributing to the repository, but there's also a lot of insight that could be coming from leadership team, especially the CEO and customer facing folks, that they can bring in. Yeah, I love that. One more question on the repository before we move on. I think sometimes the repository can feel like there's a lot of insight being dropped into it, but maybe it could feel like a black box, that it becomes a database, but how do we make sure it feels active and alive and used? I wonder if there are any practices that you have, in addition to using it in decisions, to feel like that data that's getting added every day is immediately visible to the company.

Prayag - 00:33:36: I think the stuff that you're talking about, the fact that it can become a black box is valid. I think that's a limitation of tooling rather than a limitation of the companies themselves or the teams themselves. I think that's where AI can do a lot and can actually help you do a lot in surfacing some of those insights. So there are two parts to this. One is a process and having your team kind of make sure that they build out, not a repository as a way to just go back to their research, but also a way to socialize the research and as a way to help other members of their team or other teams be able to showcase their research or be able to discover their research. So teams can do a much better job of setting up their repository as more of a discovery tool. That's one piece, I think. But I think there is also tooling that can do a better job at surfacing some of these insights that are in there. So again, I don't want to toot my own horn too much, but HeyMarvin has this new feature where you can ask questions, like a natural language question and say, what have our customers said about this product in the last one month, last two months? And then AI can actually answer that question for you and then get to you some really good insight that can be a real start of a discovery journey. It can do a better job at helping you build that journey and follow that discovery journey as someone who's not a researcher, someone who's kind of outside. I think AI has a really important role to play. We're just catching the surface there. I think there's so much more that we could do there. So I think partly it's the team's responsibility that's setting up this repository, but also it's the tooling's responsibility. And I think that AI can play a big role there. I've seen some amazing results.

Erin - 00:35:24: On the repository, we have people listening who are senior in their careers, junior in their careers, people who do research, full-time researchers, large companies, small companies, right? Have repositories, don't yet have repositories. Built their own air table or using a custom solution, everything in between. How do you recommend folks, like how far should you go in sort of nailing down your tagging and IA system for your repository out of the gate versus get it in there and centralize it and deal with that later, how much is AI going to negate the need to do that if it can just, I don't know, figure it all out for you? Because I think, right, you want to be setting yourself up to not feel like, oh my God, we have an embarrassment of riches. We just have too much insight. We can't possibly find the signal, right? I think that's maybe a concern some folks might have, especially as you get larger. So I guess my question is, how do you balance that organization of all this insight, depending on where you are in your life cycle?

Prayag - 00:36:24: It's a balance of how much freedom do we give and how much do we control the reins, take the reins, and not let people run amok. It's between how much constraints we put in while also encouraging people to have that or add that data. I like to err on the side of giving them more freedom, as in your team, more freedom to bring in that data. The problem that I've seen with a lot of teams is that researchers would be the only one bringing in a lot of that, or maybe even, a lot of times researchers are also not bringing in, maybe they're bringing in the final reports, but not the actual data, right? If you kind of don't encourage people to add the data, if you don't make it easy for them to add the data, you are always going to end up in a place where all of your insights are coming from a small, small data set, rather than a large enough data set. So I would say as you start, like start from a place of doing, making it easy for people to put more data in. And as you see the data start to balloon, that's when you can go in and start to massage the data and massage your process a little bit. And ideally, your tool should be able to help you with all of that. Our focus a lot is making it easy for people to add data and making it easy for people to tag data as they're adding the data. So that is a better way. And as I said, with AI, you can actually start to do a lot more even with unorganized data. So I'll give you an example. One of the new tools we've launched is this idea of you can put in a large survey, thousands of survey responses. And now people are like, well, if I had the thousands, let's say it has like, you know, 10,000 open-ended responses, like, what am I going to do with it? I'm not going to be able to go and tap that data. This was a problem on Marvin, until like four months ago. But now we have technology to actually go and synthesize that data automatically for you. Now, if you had added that data six months ago, you could actually now use the new technology to actually analyze that data and synthesize that data. So technology will catch up. So giving people more freedom is something that I always err on the side of when you're building out, especially in the early days. And especially collaborating with people outside of research, market research, pricing research, strategy research, bringing all of that in, I think that's what my recommendation is. Don't shut the gate as you're building out the castle.

Erin - 00:39:07: Well, I guess as we get to wrapping up here, this is something you've thought about a ton. Obviously we could talk about customer centrism for a very long time, but what are some parting thoughts that you would like to leave our listeners with when it comes to some of your best kind of learnings and building Marvin and life as a researcher before Marvin?

Prayag - 00:39:26: Talk to your customers, talk to your users, talk to your market. It doesn't need to be a big process. Get on a Zoom call, start a Google form, just get in front of your customers. Really, you don't need to do a lot. Start somewhere and then see where that takes you. A lot of companies, a lot of teams end up in this analysis for analysis place. I'm yet to meet a team which says, we just do too much research. I'm sure they're out there. We just talk to our customers too much. I haven't heard that. However, on the other hand, I have heard a lot of companies and a lot of products and a lot of teams failing because they didn't emphasize customer centricity. To just start is my big, big lesson and everything else will come together.

Erin - 00:40:20: Yeah, and there's no excuse not to with tools like yours and ours and hop on a Zoom call and you're done, right? So it's easier than ever. Absolutely. Well, this has been really fun. Thank you so much for joining us.

Prayag - 00:40:33: Thank you. This has been a really riveting conversation, it’s given me a lot to think about. I hope your listeners have enjoyed it too.