From Concept to Creation: Mastering Product Discovery

Hey everyone, how's it going? My name is Ehan Isaacs. I'm the head of global growth for the Founder Institute. We have another exciting webinar for you today. We have the Crowdlinkr team who's graciously come back to give us their time, and they're going to educate us some more on the best practice on product management, product discovery. And today they're going to be talking about from concept to creation and mastering product discovery. We had about 300+ people sign up. We're expecting about 100-150. We're We are at about 80 people right now. So I wanna go over some quick housekeeping items and I'll introduce Aram who will introduce the rest of his team. But as you can see, this platform is called Airmeet. We have a messaging portion called the chat. Please use that to like communicate with others and communicate with us. Let us know in the chat where you're coming in from. I see Cape Town, Seattle, Costa Rica, Joburg, Vancouver, Montreal, is this me? Yeah, Miami, Peru, Portugal, Washington. Awesome. So I have a pretty international audience. So no pressure, panelists. You have a global audience here for you today just to hear your topic. The only other housekeeping item is you can see below the messaging button, there's a Q&A button. Please use that to feed us questions because towards the end, around the 40th-minute mark, I will come back up on stage and help moderate some of the questions to our panelists. So please use that to feed us questions. The last thing is you can see at the bottom of your screen, there's some emojis. Please use the emojis to give reactions to the panelists so they can also get some feedback on whether the content's good or not, right? I think last time when Aram came on, we just had hearts everywhere. So I don't know what's that about, but hey. Okay, with that being said, we are at 98 people live. Let's get things started. Aram, I'm not gonna like do a very long introduction to yourself. You've been on our webinar several times. Aram's an active Founder Institute mentor, Founder Institute global webinar panelist. I think this is the 6th or 7th time he's done this this year. You know, very gracious of him taking out the time for us and helping early-stage founders. Yeah, Aram, do you just wanna unmute yourself and just do an introduction to yourself, the team, what we're gonna be covering today? And then I'll just remove myself from this, from the stage.

Awesome, cool, thanks, Ayan. Awesome to be back here. This is one of my favorite things to do is supporting startup founders in the large ecosystem. Welcome everybody to our new webinar event. This one is around mastering the art of product discovery. For those who don't know me, I'm Aram Melkoumoff, the CEO and co-founder of Crowdlinkr. Quick little background on Crowdlinkr. We're a digital product studio based out of Toronto and Barcelona. We work with numerous disruptive companies all over the world building some of the category-leading products We've been around for about 11 years, have built over 80 digital products with companies like NBCUniversal, Shopify, Maple Leaf Sports Entertainment, FreshBooks, and many others. Well, we help them do discovery, design, and development of these impactful solutions. Today I'm joined by my awesome team. So I'm really pleased to introduce you to a few members, starting off with Fiona Haller. She's a, our Director of Product and Design. And so she's also joined by Clements Wasson, who is one of our product managers, and Sarah Hozdic, who is our delivery manager. So shout out to my team for being here with me today. So just FYI, these team members who I have on this panel today have been firsthand, you know, in the trenches, lived through, you know, discovery for many of our clients in terms of what it takes. So they're gonna be sharing a lot of that wisdom with everybody here today. As Ian was saying, just a few quick housekeeping items. So as you all know, this recording will be available afterwards, and then we have a takeaway deck which will cover a lot of the content that we're gonna be coming— covering today, which will be shared to all the audience members as well. And yeah, please use the Q&A function so that we could have some questions when we get to that. Part of the conversation. So with that intro outta the way, let's get started. All right, so the first section, we broke this up into 3 sections. So the first section is why product discovery is necessary for any successful product or company. So I'm gonna kick it off, the first question to Fiona. So maybe you could just start off by just explaining to the audience what really is product discovery for a lot of like people coming in.

Yeah, absolutely. Um, that's why we're all here. So, um, first let's start by clarifying that our use of the term discovery can encompass, um, things like product discovery, technical discovery, and even branding discovery. And today our focus is going to be on product discovery. But that being said, it's important to understand what technical discovery is, as it can come up today in our conversations and probably will. Um, and it often plays a role early on in the product discovery process. So, um, technical discovery is typically done for complicated projects. Um, if you're building a simple WordPress site, you're probably not going to need a technical discovery. Um, if you're migrating from, um, a large site from one tech stack to another, um, if you have to manage, um, and integrate multiple integrations, if you're leveraging new technologies that have a lot of unknowns and aren't tested, Maybe they don't have a lot of documentation. These are times when we would want to do a technical discovery. We've done one recently with a client working on a brand new technology, no-code, low-code, very exciting. But we really needed to do some test cases on it and explore the, the software before we could actually say to the client, yes, this is going to meet your needs today and 5 years down the road. It's going to, you know, handle your roadmap. So in addition to finding solutions for the product itself, the technical discovery is going to ensure that the solution can handle things like growth and performance and security. And so like any discovery, it reduces risk, it reduces the chances of running into unexpected technical problems when we go to build. And you can— it can even help determine what capabilities and limitations there are for a product. So it can actually define your roadmap. It can say what can be built and it'll say what can't be built. Um, so on the flip side, and where we're going to be focusing much of our conversation today, is on product discovery. Um, and this is the process of understanding and finding out what kind of product or service to create and what features it should have. Um, the goal is to uncover insights that are going to guide the development for successful and a user-centered product. And that's something that's going to come up a few times as well. Is the concept of user-centered. It is core to Agile, it's core to product delivery, product design, discovery. It is focusing on the end user and making sure that what you're building is going to meet their needs. So when we talk about product discovery, I, I can't stress this enough, is critical phase. It's where teams seek to understand the user needs, the market opportunities, and potential solutions before starting on design or development. Um, so we'll do research, we'll gather insights and validate those ideas to ensure that the product, that when it's built, whether it's a new product or if it's an existing product that is evolving and you're adding features to, um, that when it's built, it's going to meet the needs of the customers of the market. So, um, the focus for a founder is on the product concept, um, and creating a product that solves a big enough problem for a user or brings enough joy. And those are two important concepts as well. So when you develop a product, you want to make sure that either it solves a greater, a big enough problem for a user, or it's going to bring them enough happiness that they're going to want to use it and pay for it. So the other aspect of product discovery is the de-risking of a project. So by asking those right questions up front, exploring all those possibilities, we can make informed decisions then before investing significant finances and resources before building. It avoids costly mistakes, wasted effort, and ensures that the resulting product is going to be more likely to succeed. So in the past, we've had a couple of projects where our team has felt that discovery, product and technical, would have been beneficial. However, the clients were not interested. We could not sell them on the the value of discovery, even telling them that upfront that this has the potential to impact their overall costs and timelines to a project. And the result was we encountered unknowns through the project and timelines and costs were extended. So I'm going to hand it over to Clem, who has firsthand experience with a client who actually fits this perfectly. So Clem.

Yeah, so just recently we had a client who we worked on their initial apps build about 4 years ago, and they came back to us wanting to go straight into development with a new feature. And like Fiona said, they were adamant on not spending any time on technical discovery, even though it's something that we really recommended they invest the time in. And within the first 2 sprints of development, the engineering team flagged to me, and then I flagged it up to the client, that the app needed to go through a significant upgrade in order for us to be able to add this feature, and that this upgrade would take about 2 weeks to complete with 1 resource working on it. And we're like, 2 weeks, 1 resource, in the grand scheme of things, like, it's, it's quite small, right? But it actually resulted in even more unforecasted costs and timelines expansions that could have been avoided. Because while we were able to complete the upgrade at the beginning of the project, there were some of the designs and user flows that were no longer valid. We spent a lot of time on back and force, et cetera. And while our, our team showed a lot of agility in how we tackled this alongside changing requirements, it definitely changed the scope of the project timelines and costs. So if we had done at least a technical discovery before we started and before we got into the development process, the team's timelines would not have been disrupted and would've been less costly to the client.

So from, from that, from that experience, or just in general, Clem, you know, why does discovery contribute to the overall success of a product's future.

So I think I can get into that.

Yeah, go ahead.

I haven't talked yet, so I just, I'm jealous. Um, no, I wanted to touch base on, uh, the DFV framework, which I don't know if everyone here is familiar with, but that's desirability, feasibility, and viability. And these are the things that we're looking into when we do discovery to determine if the product is going to be successful and how we make it successful. So when we're looking at desirability, we want to know that your product is addressing a real need and that people want it. It might seem obvious to you when you're dealing with the problem every day that your users need this solution, but until you actually go and talk to them and have data to support it, you don't know if your product is desirable or not. So testing for this ensures that when you get to the end of your builds, there's a market that's going to support your product. Feasibility is the second piece of that, and that's whether the project's actually technically feasible. So does the technology exist today to build what you want to build? This is a huge determinant on the success of a product, because if you're in the middle of product development and all of a sudden realize you don't have the technology to finish your build, then you could be stranded with no path forward. So you don't want to be creating something that's not currently possible to create. And then the last piece of that is the viability. So this is whether or not you should do it. So it's a great idea, it's technically feasible, is it going to make you money? For what you're about to invest in, can you justify the return? Every product needs a growth strategy. When you finish developing your product, that's only the beginning of your business and not the end.

Yeah, very, very, very true. Fiona, I have a question for you in terms of like types of team members who should be involved in discovery. So like who should be conducting the discovery? What kind of skill sets do they need to have?

Okay, good question. So ideally you would have a product manager leading discovery along with a user experience researcher. So you need someone with training in product management, product design, UX principles, and design thinking. We often create what we refer to as the dream team here at Crowdlinkr, where we pair up a PM who has UX and design thinking expertise with a UX/UI product designer. And this dream team combines the analytical and creative skills needed to conduct all of the activities, and they bring different perspectives to the project. They have training to check their bias, and we'll get into confirmation bias in a bit. It's not an easy skill set to find, and they sift through data. They love to ask questions, are obsessed with customers and talking to users, and they can look at a product from a variety of perspectives and can empathize with each of the users. Including through a DEI lens, so diversity, equity, inclusion, which is something that is a cornerstone of product design and product management. So also, if there's a technical discovery component, you'll need to engage engineers. And depending on what your project is and the focus of it, you may also need to pull in other subject matter experts.

Experts.

So this could be data scientists or marketing gurus, anybody that has expertise you need that can provide the answers you need to validate the concept of the product.

Awesome. So that's a good rundown of, you know, who's involved to conduct it. But is there anyone else who should be involved in the process though? Over to you, Clem.

Yeah, I can take this one. So I would split that answer into kind of 3 buckets and 3 categories. The first one being you need a cross-section of team members who can contribute their expertise and have different perspectives of the intended user. So if you have an existing business, this can be marketing specialists, customer support, frontline workers or members, team members, marketing, sales team, etc. But from what I gather from the Founder Institute, you guys are mostly founders, right? So mostly with startups. So at this point, it's really anyone who would have expertise with your intended user and can help answer questions on their behalf. Another bucket that's really important would be executives, leadership, founders such as you guys, product owners, or basically any stakeholders that would fill this kind of higher category, for lack of a better word. And those are people that should be involved to ensure that the product direction aligns with the business strategy and vision. And that they can provide guidance and support when critical decisions need to be made. And last but not least, your customers and your end users. It's not enough to just have people who can talk on their behalf, but you need to actually talk to the people who would be your existing users or your potential customers.

Awesome. I just wanna double tap into the whole customers/users component cuz it's so important, I think, for founders, which is the majority of the audience members, I think here, like having worked with many founders early stage, like that's, that's the sweet one because you're probably already a subject matter expert in what you do or you know the industry, right? So like you need to go and talk to your customers and I've mentioned this in my last webinar as well. So a question for you here, Fiona, what, what role does the customer feedback part play in discovery and how do we effectively incorporate into the process?

Oh, good question. So I mean, customer feedback and customer involvement is king, right? This is where you're going to build your roadmap. This is where you're going to get your insights. This is going to be who tells you whether or not this product is going to work. And if it's not, for founders, oftentimes you're working with a product that you don't have any customers for. So you have to go out and seek people who is your sort of key type of customer that you're going to target and talk to those people. So customer feedback is absolutely crucial. It's the only way that you're going to validate a product or a feature concept. And without talking to potential customers, you may miss out on understanding what their pain points are, what their needs are. You need to incorporate customer feedback into the discovery process to ensure that the resulting product or the service meets their needs, enhances user satisfaction, and then aligns with the user, with the market demand. So there are many ways to talk to, um, potential customers and inquire the insights that you need. Um, and we'll get into that in a bit, but it really doesn't need to be overwhelming. Um, discovery is often skipped because of a misconception that it's difficult or expensive, and though it definitely can be, um, it can be quite an expense and quite a process, it doesn't always need to be. It can be simplified. And additionally, just to add on to all of this, you should treat customer feedback as a continuous learning opportunity. So when you go out and you launch a product, it doesn't end there. Continue to gather feedback and iterate and enhance your product's value and user experience based on that feedback.

Awesome. I'm gonna move into the second part of this webinar, which is talking about the key activities of product discovery. So Sarah, we haven't heard from you in a while. So before, before you start a discovery, you know, what do you, what do you need? What are the must-haves?

To kick off a discovery, what you need kind of depends on the stage that your business is in and what you're building. So Of course, if you're doing an MVP, it's going to have different needs than, say, a new feature request. But regardless, you should have a discovery for both of those things. At the bare minimum, you need a business idea and stakeholder alignment. As an agency, we work with businesses to create their products, but these stakeholders are really pioneering their vision. So therefore, stakeholders should be aligned on the objectives of discovery, and they should also be flexible, 'cause their ideas can, should be able to change based on whatever the results are. Of course, in saying that, we love to get as many resources as we can to kick off. So any data that's available to us, any feedback that's currently accessible, we need to know compliance considerations, ethical concerns, anything that you think will help us understand your business, getting into your headspace, and then also surpassing that when we start to dig deeper.

And so what are some of the key activities that happen for discoveries? Like, are they, is it always the same process or are there different types of discoveries? Clem, over to you.

Yeah, I can take this one. I saw a question in the Q&A coming in about this, so hopefully this answers it. So I would say that the activities that you want to do are going to differ on what stage your business or your product is at. I'll talk in threes again because I like to do that. So if you're doing a new product build, it's going to be more of a blue ocean type of discovery than if you're doing a product expansion. So you're going to want to do competitive analysis, user interviews, market validation workshops. You're going to want to create some user personas, some user flows, and some information architecture. Something I want to emphasize is that especially discovery should never be skipped, but especially for new products, it should be extensive and it should not be rushed because you can find wormholes that you're going to be going into that are worth really diving in and that can change your entire roadmap and your entire product or business. As well, for, for the new product build, like Fiona said, don't skip out on the technical discovery. I think Sarah touched on this as well. Like, you really need to figure out how how you're going to build your product and how complex it is. So for one of my current clients, actually, we built a proof of concept to ensure that we could create the algorithm that they needed to fit the user's needs. Now, so that's for a new product build. And when you're talking about a product expansion, so let's say you want to add a new feature to your product that's already out there, this means that you should already have data that can be examined. So look at your product metrics, look at your customer service metrics, Look at your metrics, marketing metrics, your sales metrics, your NPS scores, your business KPIs and your goals, as well as your technical debt. Because if you've built an MVP properly, you should have a backlog of things that you haven't addressed in your product that maybe your customer support or your operations team is doing manually. So already gauge that before adding in any new feature. I would say do a product teardown and as well make sure that if you haven't been keeping your competitive analysis updated, you go back to them. And you gauge those with that new feature that you want to add. Also, do you need a technical discovery? I'm not going to go back over what that means, but just always have that in the back of your head, right? Another type of discovery that I want to touch on would be if you're doing a pivot. So at that point, it's like building a whole new product, but you also have to go back to your initial discovery and pull out the relevant data points, right? You did all this work, you don't want to waste it. So one of my clients currently did a very long discovery with us last year, just came back at the beginning of July wanting to do a pivot. So we went back to the old discovery, spent time pulling out what was relevant and what wasn't relevant. And some of the activities that we did at the very beginning of that were very centered around alignment, both within our team and with the client on what this pivot is versus what this pivot is not. So something like workshops or writing up product charters can really help with that. Also, again, do you need a technical discovery? The last discovery that I do want to touch on is branding discovery. So slightly a little different than what we're talking about. I think we're doing another webinar with the Founder Institute on this in September. So this is a shameless plug for that. But also, I'm gonna stop blabbing about it because I don't think we need to go too deeply into it. So around— does that kind of answer your question?

Perfect. Yeah, thank you, Clem. So you spoke a lot about the key activities during discovery based on the type of, you know, builds and like, or scenarios. So maybe I have a question here for Sarah. What is the difference between the activities undertaken and their findings? And how do you distill all this information so it's digestible and actionable?

Okay. Yeah, so the activities undertaken, I don't want to get into too much of what Clem repeated, but they differ from client to client, as she was saying, the different types of clients, but also by your product stage. So although the activities might differ, the overall flow of discovery does remain relatively the same and it has kind of the same goal. Our overarching goal when we conduct discovery is to, to determine the best path forward for your product. And in order to find the path forward, we're going to go go through different activities, but hopefully we're going to get to some similar outcomes. So one of our outcomes that we're looking for, of course, is that feedback piece, which we've already mentioned, but we want to take our ideas and stress test them against feedback. So activities here range from your stakeholder interviews, your user interviews, surveys, user testing, anything that you're getting feedback from individuals that are external to your business. And when I say external, not to your business, sorry, but to the researchers who are looking into it, talking to stakeholders is also a great source of feedback because they're going to have a certain amount of knowledge about what you're building. One of the other outcomes that we're looking for, actually, we're going to look for outcomes for the whole DFE framework, which I mentioned earlier, but I just wanted to specifically talk about desirability for this one where we're looking to see Does this product already exist? And if it does already exist, is there room in the market for our product? And if the product does not already exist, why is that? Making sure there is a market there for us. For this outcome, we're looking for activities like market analysis, competitor analysis. Also with desirability, we want to identify our users. So are the people that we are trying to solve a problem for, do they actually exist? So we want to create our user personas, identify the user journey, which is kind of their emotional journey through a product that we're looking to build to understand their motivations and their pain points. But those are just kind of a few activities and what we're hoping to gain. The part about distilling down the information, we want to conduct multiple activities so that we can kind of have a holistic view of everything. To pull out trends and make recommendations. So for example, if we're doing user interviews and we hear people repeating that there is a specific need they have, we're not gonna now run and build something to meet that need. We're gonna take that need, look at our competitive analysis, see is anyone solving for this need right now? And maybe one of your competitors is already offering it and the users don't know about it. We don't expect our users to be experts in our industry, so we can't look at data solely from user interviews, and we can't look at data solely from one source. We have to apply it across all the activities. We want a greater source of truth. And then hopefully, once we have that source of truth, we can create some recommendations, recommendations, which will be our path forward for the product, which we'll hand off to our client. I think it's important to note here too that we never tell a client not to build something. Our goal when going through discovery is to determine what should be built based on our findings.

Awesome. So that was a, a really thorough answer. Thank you, Sarah. I wanna, before we get to the next section, I wanted to jump into basically what happens after product discovery. So, I mean, we've been talking a lot about product discovery, which is super important. That's the focus of this webinar, but it's like, what happens next? So I'm gonna, I'm gonna ask Clem this question because, you know, she's one of our product managers and has first and has seen through projects that go from discovery all the way to like launch and to delivery. So maybe you could quickly kind of elaborate on what happens in between these stages so that the, the audience gets a bit more familiar with this.

Yeah, so I'd say that you just need to make sure that you hand off your findings after your discovery. And so this kind of depends on like what you're doing after, kind of what you said, Rom. But first of all, it's like, who are you doing this discovery for? Who are your main stakeholders? Or, you know, for us, we do this as an agency for clients. So we need to make sure that we're handing off our findings to them. For this audience, you guys are founders. So maybe, you know, it's getting people who are doing the discovery, if you're not doing it yourself, to share that knowledge back with you. But also if you have a business partner, do they need to be updated? If you're an internal resource at a bigger company, who are your project sponsors? Who makes the go/no-go decisions, right? And then the discovery needs to be continuously handoffed— handoffed? I don't know if that's a word— to the rest of the teams as you're going through the design and the build of the project, right? So if you're going into design, then the designer who should be up to date and you should do handover sessions and workshops if needed. At Crownliker, we have the same designers that work on discovery and design, so usually that's not really considered a handoff, but always really important to do. The other one that you'll need to do is when you go into development as well. There are deliverables that you need to make sure that the development team is aligned on. The key is not to overwhelm them, but to just provide them with enough context and what they need so that they can problem solve and offer technical solutions that still make sense for the users. So what I like to take them through is at least have them go through the user personas and do a little bit of a handover session around that because then they're always keeping the user in mind as they're building. But also of course going through user flows and product requirements documentation. The one thing I want to emphasize is product discovery is not just a one and done thing. It's called continuous discovery for a reason. So you're always testing and trying to validate with each product iteration. So like you said, Aram, it's not just about doing it at the beginning, but it's also doing it during the launch, during the delivery, and during like the entire life cycle of your product, basically.

Awesome. All right. Jumping into our, I think potentially last section of the webinar, which I think is very near and dear to me. It's about why early products fail. So quick, quick stat here for everybody. So according to a Harvard Business school professor, there are over 30,000 new products introduced every year, of which 95% fail. So like crazy, like only 5% of products actually succeed, you know, after the first year. Um, so question for Sarah here is, uh, since you're, you know, on the delivery, you know, management front, I'm sure you come across this. Um, so are you able to tell us What are some of the most common pitfalls that occur during the discovery process?

For sure. But I wanna start with Aram and I don't love this topic of why early products fail, but we love educating people on why, you know, we can be successful. Um, anyways, so just to get into some of the pitfalls, cuz there is many to go through. Um, I'm just gonna name a couple. The first one, which might, Fiona actually referenced at the beginning of the presentation was confirmation bias. So when you're doing your discovery, you start with a hypothesis. This is something you're trying to prove or disprove. What you need to be careful of is that you're not knowingly or unknowingly trying to prove your hypothesis throughout. So confirmation bias is a preconceived notion about the answer to this hypothesis. And it's where a researcher is gonna look to validate what they already what you already think as opposed to gaining new and critical insights. So this can look like asking leading questions during a user interview. It can also appear in the way that data is presented to stakeholders, where you can skew things to make them look better or worse depending on what you already believe. If you're searching for a preconceived idea, then you've closed yourself off to the true answers. To be successful, you need to be flexible to change. Another common pitfall is making assumptions without validations. And this is something we see very often. People will make generalized statements, but they don't have any data to back it. If you assume you know what your users want before you speak to them, then you are likely missing out on opportunities. And you won't be able to prove that your product is serving a market until you've actually gone and talked to people about it. And I wanted to make a reference to Google Glass here, and I don't know how many of you guys are familiar with Google Glass, but Essentially, Google made these glasses that were voice motion control. It was like augmented reality glasses with like cameras, certain like app functionality. They were not successful. As you can see, not everyone is outside wearing Google Glass everywhere. And it's a pretty popular case study. And if you look at some of the reasons why they weren't successful, something that tends to be commonly mentioned is that the price was too high. And that there wasn't a need for the product in the market. Now, these are two things that we evaluate in discovery right off the board. So this tells me either Google did not go through a full discovery, or maybe they had some sort of bias that they were leaning into. If they had addressed these early on, they would've been able to make a pivot. They could have offered the product more or cheaper than they did. Maybe with less functionality, or maybe they could have found a market where there was a need for these glasses and then shifted their focus. I do want to bring up one more point before handing it back around, and that's ignoring negative feedback. This, I think, ties into ego, and people, specifically founders, become very attached to what they're building. And I understand it is hard to separate yourself from feedback. So when people receive negative feedback, they tend to take it personally, and instead of using it as a learning opportunity, they'll ignore it. Now, this is a big no-no because negative feedback is incredibly important. It tells you what you can do to improve your product. If everyone is going around saying they love your product, then maybe you have a fantastic product, but more realistically, people are probably not being honest with you and you should probably find a new sample to talk to.

Yeah, I think I'd like to just add on that a bit. Everything that Sarah said was absolutely, you know, something we experience all the time. You know, products fail early for a multitude of reasons, and it can be because you haven't listened to your users and you don't have a product that's going to meet their needs. It could be you have the greatest product in the world and you didn't market it. So there was no post-launch effort to get your product to success. But I think what happens a lot with founders, to kind of echo what Sarah was saying, is people tend to build what they think users want. And also oftentimes they build too much at once. So Sarah covered off the first part of that, but the second part is equal important. So when you go to launch a product, oftentimes people get super excited that like we can build this and this and this, and many features which should be an MVP get added on, and you end up with this massive huge product to launch. Um, this makes it very difficult to actually discern what was successful, what wasn't successful, where did users run into roadblocks. Um, it's also possible that users didn't experience the intended purpose of the product because there were too many distractions. They didn't know what to do when they landed and tried to use that product. And so this is why it's imperative to talk to users. They will tell you by listening to your pitch or walking through your prototype whether a product has the potential to succeed. And I think a really good example of this is a product launch that ESPN tried to do in the mid-2000s. This one always sort of blows me away. They had this idea to launch exclusive content and video through a phone that they would offer, and when it did finally launch, there were heaps of problems. So there was only one phone model available, and we know how well that goes with the number of, you know, different Apple versions and Android versions there are out there. So one phone. It was a flip phone, so it was kind of awkward. You know, this was when Nokia was out and Ericsson was out, and they had these sleek small little phones, and iPhone was, I think, released the year after. So it was not a great experience just from that aspect. It also came with a hefty price tag of $400 US for the phone and a monthly subscription fee of around $40. So As you all know, sports content is available from many sources. And as much as ESPN had their loyal fan base and their diehard readers and watchers, it turns out that their customers weren't interested in paying for that type of content, at least not that amount. So the result was ESPN shut down the service within a year. And that's— this was after sinking $150 million in development. So Had they tested a prototype with the users and asked the simple question of how much would you pay for this, would you pay for this, they could have adjusted the product, they could have pivoted, or, you know, sometimes the result of discovery is scrapping an idea altogether. It's just not a good idea. So I think on a final note, a fundamental aspect of user testing and discovery is also questioning to ensure that the revenue model is sound. Are people gonna pay for your product? Right? So that's the key. That's why we launch products, right? Is it's to be successful.

Yeah. Just wanted to add on that. I think the hardest thing that I've seen in the customer development process that I've participated in for some projects is founders are always afraid to ask the simple question, which is like, how much would you pay for this? How big, how big of a problem is it for you that you're willing to part ways with your, you know, hard-earned cash? Right. And it's a weird thing, you know, that founders need to overcome, but like, as a founder, you need to sell, you know, that's like every successful startup that ever built, the founder is always selling. And it's just mind-blowing for me where there's that hesitation to ask these simple questions because like, This could become your lifeline, you know, this can become the way you make money. So like, if people aren't willing to, you know, give you money for what you're doing, then really is not much there.

I just want to add something to that, Aron. I think that it comes back to, I can't remember if it was Sarah or Fiona that brought it up, it comes back to the ego, right? And being afraid that someone's going to tell you, no, I'm not going to pay for this. Isn't a big enough pain point. So it goes back to that confirmation bias and keeping your ego in check.

I also wanna add something here.

Sorry.

It's also not enough to just ask how much they're willing to pay. You gotta test them. So if you're doing some sort of paid tests where people really have to part with their money, 'cause it's one thing in an interview where someone's like, oh yeah, I'll pay. $100 for that. And then you say, okay, gimme $100. And they go, well, actually. So also important, not just a question, it's gotta be a practice.

For sure. For sure. All right, just maybe one or two more questions here. So what we talked about this already in a few different occasions, but like, you know, founders are always hesitant on doing discovery. And I think there's a question I saw, or a couple questions in the QA piece that we'll get to, but Fiona, maybe you could help me answer this one. What are some reasons why founders do not want to do discovery?

Yeah, so I think Clem and Sarah have discussed how business leaders, founders can make the assumption that they know what their users want and they don't necessarily see the value in conducting a product discovery. Ultimately though, I, I have a feeling it comes down mostly to time and money, right? Um, so with respect to time, we work with clients who want projects released quickly and without delays, and they think that this is an area that they can cut, um, to save on this measure. So they skip discovery thinking it's going to save them time. Um, on the money side, budgets are tight or they don't understand the value, and people understand the hard costs associated with design and development. They don't always necessarily understand the benefit of having a trained team come in, um, and, you know, collect and assess data on their product, um, when they feel like they could do this themselves or it's not necessary. So I think what founders should understand is that by cutting corners in the beginning, um, such as omitting discovery, the result, um, more often than not is that the cost is going to be accrued by the time the product launches. It will involve reworks, redesigns, full technical overhauls. If it's found that you may find that the product that you're trying to build is not technically feasible partway through development, so it will come up later in the project if it wasn't properly validated in the beginning. So worst case, they end up building a product that nobody wants, or perhaps wants but won't pay to use, and you're another ESPN story.

So yeah, and just to maybe conclude the section, like we talked about the importance of continuous discovery and as a founder building out your company, your product, it's something you should be doing all, all the time until you get to a point where you get to product market fit. But even then at that point, once you get to product market fit, you should still be stress testing everything that you're doing. Right. And so that just involves. You know, learning from users, speaking to them, showing, you know, what you have, getting feedback, because you could pivot and innovate very quickly as a startup. Like, as an enterprise, very hard to move, you know, into a different direction. But as a startup, you have that advantage where you could quickly, you know, you know, from an agile standpoint, change course, you know, take some, you know, new direction and kind of go, go with it until you kind of figure it out. So don't be afraid to do it as like, and we talked about discovery and, you know, the importance of it, but just like you should be doing constantly. It's a, it's a very iterative process. Okay, I wanna wrap up with a rapid fire round. I always like doing this in, in our own podcast. So I'm gonna ask a question, start off with Klem first. So what are one or two things that you want the audience to take away from today's webinar?

Yeah, I think I might have said it already, but I'll repeat it is put your ego aside, check your confirmation bias. It's something that we all need to do and all need to get better at, not just when it comes to discoveries. So I'm not going to go on a tangent on that. But yeah, just, just put your ego aside and check your confirmation bias. You're doing a discovery and you need to do discovery for a reason.

Awesome. Sarah.

Um, so mine is cutting corners at the beginning only causes problems in the long run. And as a delivery manager, this is something I struggle with all the time. Um, it's not worth it. It really is not worth it cutting that corner because you think you're going to save a couple of weeks because what was a couple of weeks can turn into months and months of rehaul. So do it right. Do it the first time and you're going to be in a much better position for it.

Awesome. And last but not least, Fiona, what's your final take you want to share wisdom-wise?

Wisdom-wise? Products succeed because they either solve a problem or they bring immense joy. I think those are two things that we need to remember all the time about a product. So build user feedback into every aspect of product development, as your users' insights are going to inevitably guide you to success.

Awesome. Cool. Well, Fiona, Sarah, Clem, thank you so much for, you know, sharing your knowledge with everybody on, on this webinar today. I'm going to jump into the Q&A portion. I'm going to share my screen quickly for a second just to offer some office hours that we have available to a lot of the startup founders that I work with. So there's a link to a Bitly link here, which goes directly to a calendar booking. We use Calendly to book our office hours, or you could just use the QR code and take a picture with your phone. So we are discovery specialists and, you know, we love working with startup founders when it comes to de-risking product builds. So if you have any questions for us, feel free to book a time with us and we could help hopefully guide you in the right direction when it comes to, you know, building what is needed. So thank you, everybody. I'm going to pass it over to, to Ayan to go through the Q&A and we'll get the, I think, the questions presented on the screen here.

Yeah, for sure. Thanks, Aram. Thanks, Fiona, Sarah, and Clem. This was really, really helpful and insightful. We have a lot of questions. Usually we have the last 10 minutes for networking, but I think let's try to burn through some. I think there's like 20 questions in here. Then folks, if you want to book time with Aram, I pinned it in the chat. Just click that link. He's very responsive and he's done a few of these, so please try to book some time because he has some sound advice. Let's set some rules in place. I'm going to show up a question. Whoever, like, I don't know if this is like bingo or Celebrity Jeopardy, whichever, but like just one of you quickly answer it and let's move on because we have quite a bit of them. And then folks, in the Q&A button you can upvote. So I'm gonna go in, uh, the questions that's been upvoted the most and, uh, and try to hit these up as much as possible.

Okay, also just add like what we don't answer here, our team will take away and we'll provide answers to those in the deck that we send out.

Okay, yeah, perfect. All right, so first question is from Altu from SLC, the US. He's like, what are some effective tools and frameworks that you use for product discovery? I think you guys already talked a little bit about this, but like, again, lightning, whatever you can.

Yeah, I'm happy to, happy to build on that one again. Um, so tools, my favorite one is FigJam, or you can use Miro, Mural, like any like whiteboarding tool where you can drop so many screenshots, add Post-it, add notes. You know, Crowlinker will work virtually, so that's our best way of collaborating. But yeah, so that's one tool that we recommend. So for example, if you're doing a competitive analysis, take screenshots of all the pages of whether it's a marketing website or product, put those in your whiteboarding tool, add your comments, collaborate with people. And that kind of stuff. Same thing for like user interviews, synthesizing, like honestly that's my favorite tool is a whiteboarding tool. Yeah, I don't know if I wanna go again over all the activities or if you wanna move on to another question.

Yeah, I could just, I could just maybe add to that. So I think starting off with anything, it's always helpful to have like some sort of like a business canvas to just put your initial kind of rough ideas down of what you wanna do. Then when you kind of get into some of like the understanding, like I always, if you have a problem that you're going after, I really like the 5 Whys exercise, where you basically ask, you start off with something and then you kind of ask why repeatedly for each response until you get to like the root of really what is the problem. So that's helpful because then, you know, when you move on to something called How Might We exercises, where you kind of like start thinking about like, okay, how might we solve this problem? It's a very like collaborative, you know, No thought or idea is bad. You know, if you guys are familiar with something called the double diamond approach, where you kind of like start wide and then you kind of go in once you kind of start narrowing down some good ideas. So it's the whole convergence-divergence kind of approach. That's very helpful when you want to kind of like just have a clean slate at the beginning and then focus in. So there's many other examples, but those are just some of the ones that I personally like.

I'd add to that, because of the type of work that we do, like we deal with startups that are, you know, trying to build something new in the crypto space to large enterprises that are established businesses and, you know, are trying to pivot or, you know, innovate. And so for us, we rely on a lot of different frameworks and we're continuously learning different frameworks. So we'll pull from IDEO's human-centered design, we'll pull from the Double Diamond, we'll pull from, you know, Lean Startup frameworks and things like that. The ultimate goal is to really get down to understanding what are the user problems and how can we solve for those.

So yeah, awesome. Thanks, Fiona. I'm just going to jump in and so we can get some other questions going. This is a similar question as before around frameworks, but this person's also asking about books. Antonio from Malaga, Spain. I know, Aram, you interviewed someone who did a product discovery book author, and Fiona, you might have some suggestions, but anyone in the audience who's looking to learn more about product discovery, what books would you recommend?

Yeah, so I'm a big fan of somebody by the name of Teresa Torres. She's a very international author who talks about continuous discovery. So she has a book called Continuous Discovery Habits. So check that one out. And then there's another one, I think it's from Radhika Dutt. Let me just get her book, one second. Her book is called—

I'm throwing that into the chat so if somebody else, whoever wants to Yeah, so sure.

So there's Radical Product Thinking, errática, dot, and then that's a good one. And then the one from Teresa Torres. Sorry, I'm just Googling at the same time here, guys. Uh, Teresa Torres, um, Continuous Discovery Habits. She's, I think, one of the leading people on continuous discovery. There's also a really good book by— it's called Cold Start. I can't remember who the other author is. Which one is it? Who is it again?

Cold Start by Andrew Chen.

Thank you.

Yeah, yeah, it's a great book.

A great book. Um, yeah, so those are just some.

Cool.

All right, I'm gonna try to keep burning through. As I'm reading these questions, these are a lot of product questions, so I don't think we can rapid-fire on them because these are existential questions. So we'll do our best. I just remembered. Okay, this is a loaded one. How do you determine if a problem has been validated and what metrics do you employ for this validation? A PM from Yerevan, Armenia, Lilith, is asking. So whoever would like to take—

fellow Armenian.

Yeah, maybe if you want to get things started and then kick over to your colleagues.

Yeah, it's a good question, loaded question, as you said. So I would say when you're starting off a discovery process, you need to kind of, you know, we have the hypothesis, but you also try to, you know, further along the process, you want to try to create what is your sweet number of people that you want to either, you know, have as pilot customers or a certain amount of interviews that you want to conduct. Like there should be also maybe a revenue target you want to try to achieve, like, you know, some paid pilots or a number of financial commitments you want to have to something being built. So those are just some. I think Sarah has one as well.

Yeah, just in regards to how do you know if a product's been validated? If a solution already exists, it's the low-hanging fruit. If there is people already solving for the problem? How are they doing it and how can you do it better? I think people miss out on that opportunity quite a bit trying to build something unique. Um, but yeah, it's definitely a good approach.

Yeah, one of the things that we do when we go through discovery, um, is a SWOT analysis. So we do a market analysis, we do a competitive analysis, and then we break down those competitors in the market that are closest, whether they're direct or indirect competitors. And we take a look at what their strengths are, their weaknesses, and things like that. So right from the beginning, we start to see opportunity in the market. And that's when we go and talk to users and validate. And typically in user testing, there's a threshold of people that you hit that when you talk to, their feedback will align. And usually it's about 7 people. It seems hard to believe, but that number is real. I've tested it many times. And so once you start to find trends among those people that, you know, support some of the research that you have done, that is when you can start to know whether or not you have been able to validate your idea. That being said, you can get stuck in this situation where you continuously try and validate, and you can do that forever. I mean, you can look at statistics and data forever. At some point, you have got to call it quits and just move on to the next phase.

Awesome, thanks. I'm just gonna quickly interject, uh, and let's keep the questions going. This is very interesting, um, is an MVP required to do an effective product discovery, or a concept media, or is a concept media or prototype good enough?

Yeah, good, good question. Um, I covered this at length in the last, uh, Founder's Studio webinar I did. I think there's many, many different ways to do an MVP. You could throw up landing pages, drive traffic ads to it, see how many people convert. That could be an MVP. Like there's been, especially now in the AI space, I've come across dozens of companies where they have an amazing landing page showcasing a cool illustration or mockup or video of what the product does, but it's all vaporware. At the end of the day, but they're just trying to really see what the interest is for that. For those who don't know, that's actually how Dropbox started off. It was kind of like a fake door tactic where there was nothing behind it. All they did was basically do a nice video showcasing how Dropbox as a solution could work, where you could move files into a finder within your computer, and then it could get synced and be in the cloud. And that technology didn't exist. They just did a nice video to show it. And that was what they used on, on their landing page to demonstrate what it is. And that's how they got like their first few thousand users. So I would say when it comes to hard tech, like where, you know, it's like something maybe in the financial space or maybe something, you know, hardware related, like you kind of have no options. You have to go and build out an MVP or a prototype of something. But when it comes to software, like I'm a big fan of just trying to like fake it till you make it, so to speak. Try to get as much interest, get people to sign up, go and obviously schedule a time with those people, understand why they signed up, what are they thinking they're gonna get out of it, what do they hope they get out of it, how much they're willing to pay for something. That's like a great mechanism, I think, to get early kind of validation very quickly.

Perfect. Thanks, folks. We are coming close to the end of the hour. I don't know who from your team can stick around, but we still have some really good questions I kind of want to go through, maybe at least 3 to 5 of them. But, you know, if anybody else on the team or anyone else in the audience needs to hop off, feel free to. This will be recorded. You will receive it within 48 hours. So, you know, you can always come back to this point in the presentation or the Q&A portion. Awesome.

A couple more.

Yeah, there's a lot more actually, but I do, I'm kind of going through this and like I think I'm trying to identify different elements here so and make sure that we don't repeat ourselves. I really like this question by Nicola from Quebec. She's asking, how do you actually gather all the relevant feedback and ideas from the team? And know what to discover and bet on later. So where are you doing all your documentation, sharing your learnings and everything?

So I could— Yeah, Clem, go ahead. I think I know.

So when you're looking at—

Sorry, sorry.

So when you're looking at your team, there's, I think, a lot of workshops and brainstorming sessions that you can do. To get everyone's kind of ideas, feedback. You can do feature board brainstorming sessions, you can do blue ocean, whether you're having prompts and kind of like workshopping your own prompts that you wanna ask your team in order to collect those ideas. And so I think we made reference to the double diamond kind of theory, but that's where you're like diverging and getting all of these ideas from everyone. And at this point you're really looking for quantity over quality. Look up ideas, rules of brainstorming to make sure that you're really driving creativity with your ideas and you're not like kind of narrowing things down just yet. When you come to a point where you have enough ideas, and I think you'll probably know when you're at that point, then comes this time to start distilling things down and prioritizing what you want to include in your product and what you want your product, product to be. So at this point, what I would recommend is aligning on your North Star. What is your product supposed to be? What What problem is it supposed to solve? What's its mission? What's its vision? And then from there you can start using prioritization frameworks. You know, there's the Eisenhower— I'm just gonna list off a couple— Eisenhower Matrix. My favorite one is the RICE prioritization method. So you're looking at reach, impact, confidence, and effort. Couple of really good articles in that. I'll try to make sure they're linked in the deck that we sent through. But basically, if you're looking at your diamond model, converging. So you're really trying to narrow things down in terms of what is going to have the impact, what's gonna be able to sell best. And this is, again, I think really where putting that ego in check comes in, cuz you may be attached to things that aren't gonna be successful. So yeah, I hope that answers your question.

Clem, that should be your new LinkedIn title.

Check your bias.

Get your ego in check. No, no, that was a great response. On that note, because you're talking about getting stuff narrow, Joy, who's a PO, is asking, when you have an idea for a product that could impact multiple personas in the start, like, is it better to focus on one ideal customer at the beginning, or like, how would you go about approaching that? Which I, and I see this coming up a lot with FI companies. It's like, hey, we have 5, 6 customers and it's like, well, okay, let's just start with one. So I would love to get somebody's, uh, so anyone on the—

I can take this one. Um, yes, I mean, ultimately most products do appeal to a lot of different personas. Um, when we start in discovery and we build out user personas, we focus generally on 2 or 3 main ones. Um, and these could be different types of customers and It could also include internal people, it could be your business stakeholders, it could be internal users of a product. So I don't like to limit to one persona. I think what you then do is perhaps build a product too narrow. You might build it on too narrow of a technology that isn't going to allow for you to expand your roadmap to reach those other personas. I think you've always got to consider them. You can narrow down those and converge those ideas at the end to focus on putting out a product specifically for one or two personas. But I think during that discovery phase, you need to consider multiple. You want to make sure that, you know, what you're going to build, how you're going to build it, is going to be sustainable for that, you know, your 3 to 5 year roadmap. You don't want to build something and have to start over and find a new technical solution because you didn't consider how the features that you wanted to launch in the near future for other personas.

Just to build on that though, I think there's also like you don't want to be building too many personas, right? Because your products at an MVP stage shouldn't be for everyone. So currently going through this with one of my clients where they'd like their product to be for everyone. It's like, okay, no, we have to narrow it down and then future, like Fiona said, um, you know, so right now we're limiting it to 2, but in the future we can have 3 or 4 personas. But right now let's focus on 2, getting something out there, validating with them, uh, with those personas, and then keep on doing discovery to validate whether or not we do want to expand those user personas as well.

Yeah, just one thing just to add, um, I'm sure everybody here is familiar with like how certain companies like Tesla started off. I really like that example. Because I think it's very related to this kind of question in the sense that when Tesla started off, they had one model of a car. It was the Tesla Roadster, very expensive, kind of rare to get, right? There was a long waiting list, but they targeted, you know, high net worth people who are interested in electric cars, so quite niche, but also had the income to justify it. So they kind of build out their initial user base catering to that market to get some more traction. And only then, once they went more mainstream, become recognized, only then did they roll out like the Model 3 and like more affordable cars for the larger mass. But like, especially when you're building out your initial MVP of a product, I would say who's really paying the most Who's the paying customer out of all your personas? Who's the one that could potentially have like the most spend or budget, right? Are they accessible? How easy it is to acquire them? You know, all these kind of things. And you know, that's why a lot of companies, you know, start off with like a whole bunch of evangelists that support it and then they start, you know, catering to other persona types.

Perfect. Um, I have a really good final question and then we'll wrap up. This I would like to get everyone's opinion on. Sinan and a few other people were asking about, there's a difference between a product discovery from a B2B to B2C perspective. What are some of the things you guys do differently? What should you be looking out for? Like, obviously the access to users are limited. Another person in the audience was asking like, hey, who should I be going after? Is it the customer, the end user? Whatever you can unpack around B2B versus B2C from a product discovery perspective. I think that would be very much insightful for the audience.

Cool. So whoever wants to start, who wants to go first?

I'll go. And I think you're gonna get different, differing responses across our team on this. I guarantee it. So we have a database. A Crowdlinker of all of the discovery activities. And so depending on the product and the type of users that we have access to, the type of data that we have, we can apply different sort of frameworks and activities to a project. And it's, it's a database. Um, I don't think there's a huge difference between how you tackle a discovery for a B2C versus a B2B. Again, you're going down to the core question, which is finding out what the user needs are, um, and how can you solve for their problems, right? So that is the core of any discovery, whether it is, as we said, product, technical, or startup, or an enterprise. Um, you will be dealing with different users. You may not have access, um, to necessarily the users that you may want on a B2B due to, you know, compliance or legal reasons, but you can always get information on those companies and on your competitors, and you can still find people who would be your ideal sort of preferred customer. So I don't think there's a huge difference between B2B and B2C. Some of the activities might differ, But really it is, it's a research, it's a research initiative to try and, you know, to find out what those market gaps are and where those opportunities are.

Yeah. So I'm just, my point of view, similar, but I wanna kind of express it. So historically as a business, we've done a lot more B2B than B2C. And one of the clear outliers, or one of the key things I've always seen is that when we work with B2B companies and we're doing discovery, a couple things might happen. It really depends on like the org and like the culture of the company. But we typically try to interview, you know, the leadership team. We try to interview the marketing team to understand what their pain points in terms of messaging is, you know, with, or what they're trying to accomplish from a presentation standpoint, content-wise. Then we try to connect with like salespeople and customer support people and obviously product, you know, as well. But where I see the interesting part with B2B is when we do discoveries, you know, with B2B companies, oftentimes we can only get access to, you know, the stakeholders within that company who think that they know everything that they need to know about their actual customers. Who could be consumers, right? Or it could be like, you know, other kind of stakeholders in other organizations. So I would say being able to actually interview the actual end users of a B2B company during discovery is very, very, very important because as Sarah was saying before, like there's that confirmation bias, you know, there's that ego component. And so a lot of B2B businesses that we work with who are maybe like, I don't know, C to Series B, they might already think that they know everything, but they're proud that the company's going through a growth spurt. And so they need to kind of keep the checks and balances to see whatever it is that they're doing is actually the right thing. And oftentimes they rely on their internal knowledge or understanding via the product managers or the people who know the customers, but they sometimes resort not to go and speak to the actual end users during this process, which is shameful. With B2C, I would say it's like we, we worked with a B2C company recently where we did discovery and we threw up a whole bunch of different types of landing pages, run paid ads to it, and we were funneling people to either some sort of like a checkout to see, to confirm how much people would pay for some sort of a health solution or health service. Which then could, can then lead into like some sort of a free webinar or whatever, a paid webinar, kind of like course offering. And I just found it's, it's hit or miss sometimes. Like you never know who you're gonna get in the public sphere. Like you could get a whole bunch of randos who come on and like, and then it's really your job then to actually validate or sanity check the quality of these people and whether or not they truly represent the sample size of your B2C target audience. So there's like different kind of things to keep in mind, but when it comes to product discovery for B2C companies, like I would say, you know, it's really easy and straightforward to go throw up a landing page, you know, and do some paid ads. It's not difficult anymore these days. Or obviously go to where your customers are. Like if it's, if you're a health wellness company, you know, try to find health and wellness forums, you know, maybe go to trade show and conferences or events around that. Go and actually speak to those actual end users who will be paying for your product. And that's like the main difference I would say between B2B and B2C, because you might not always be able to speak to the actual end users on the B2B side.

I of course agree with the points of view that Aram and Fiona shared. I think there's a lot of kind of golden nuggets in there. The one thing that I wanna talk about with B2C and B2B is that you're, user and your buyer are different. So you have to know how to appeal to both the user and the buyer. And I saw a comment in the chat about, from Eve, that says with B2B you're saving them money and human resources by automating functions and tasks. With B2C you're making their personal lives easier and more joyful. I completely agree with that to a certain extent, I think, because there's, you can bring joy into any product and you should be bringing joy into any product. If you're looking at a time tracking tool, which we're an agency, so of course we do that time tracking because we're doing billable hours. Same thing for lawyers or any type of industry that does billable hours. Time tracking is a super onerous task that frankly sucks. No one likes doing it. And so if you're building— sorry, Sarah— if you're building a product that is for time tracking that's essential to your business but doesn't bring joy to your end user, and you're not designing something that makes that easy and less onerous, then they're gonna complaining to someone like their delivery manager saying, hey, this tool sucks, I can't use it. Can we try and find something else that works better? But at the same time, you also have to be appealing to someone like the delivery manager operations that has the control of that and the buying power for that. So I would say keep on, keep on bringing joy into everything that you work on and you design, not just B2C. Of course that needs to be there, but also B2B and finding that right balance between what is useful and more like corporate, again, depends what type of company you're targeting versus bringing the joy, building something silly, right? So yeah, I love it.

Building something silly.

Awesome. I know Ahan sent it around the full table, but I honestly don't know what's left to cover here. The big, the point I was going to bring up, which Aram already mentioned, was just the quality or yeah, I guess it would be the quality of users you get to speak to differs between B2C and B2B. Personally, I don't participate in a lot of these because I'm the delivery manager, so I'm not doing the discovery, but I have sat in on some before and I find it very satisfying when we do B2B user interviews and you get to learn about some of the other opportunities that exist within businesses that maybe you didn't consider to include as your product or add to your roadmap versus I find in B2C you get a lot of different suggestions and not all of them should be taken into your product.

100%. You got to filter through tons of white noise, random thoughts, random feedback, random feature requests. Like, you got to prioritize that and see, okay, do other people think that that's relevant? Like, how many people raise their hand on this request, right? Like, you got to really filter through the noise.

Perfect. Let's wrap things up there. Crowdlinker team, thank you as always. Your presence here has been amazing. There's some people in the chat that has said you guys are awesome. You know what an impress— so Ron is saying what an impressive Team, uh, equally impressive webinar. Thank you for sharing your expertise and insights. So likewise, I'd like to extend my gratitude. Uh, we have about 120 people left. What we're going to do is we're going to stop here, we'll break for networking. So folks, you'll see a bunch of smaller virtual tables. Hopefully the Crowdlinker team can stick around and join one or two of those tables. Apart from that, you folks can network with each other, discuss what you learned today. I've certainly learned a lot about product management and discovery from the CL team. With that being said, Aram, any final words for the audience before we wrap up?

Ah, final words. Yeah, stay humble, uh, stay empathetic to your users. Try to always put yourself in their shoes, you know, um, and, uh, try to stay also niche and focused in terms of what trying to do, right? Don't deviate. Like, really try to have like a very concrete vision of what you're trying to accomplish. So yeah, perfect.

I love it. Be humble. And Clem, you want to plug your last bit of line?

Leave your ego at the door.

All right, we'll end things there, folks. We'll hopefully see you in the networking session. If not, we do these events pretty regularly, so feel free to— you'll get emails about upcoming events and all the, uh, everyone's LinkedIn URLs and the deck that they promised to send out to everyone. All right, we'll wrap up things there. Thanks everyone, enjoy the rest of your day, uh, wherever you're calling in from. Bye.

Thanks.