Wonderful. Ok, let's kick off. Um So welcome to making a case for product discovery. Thank you for spending your time with me. We'll just jump right in. So who am I? My name is Ivan. A, I'm a practice director of product at leading product development firm Connected.Um And at Connected, we work on software products that are loved by millions of customers around the world. We're deeply passionate about building products and we believe that the best products are built by cross functional teams that practice both product discovery and product delivery.

So I'm glad that some of you are in these areas uh right now and I'm sure you'll be adding to the discussion. Um So what are product discovery and delivery? We can think of discovery as the process of deciding what to build and delivery as the process of building it? Of course, it's a little bit more complicated than that. And there are many different techniques and tactics used in both of these. Um But one of the biggest obstacles to building the great products I heard Spotify on the chat um is that we jump right into delivery without practicing discovery or without practicing discovery on an ongoing basis. I'd love to get to know all of you. So if you have it already dropped in the chat where you're from, uh what your current role is and maybe a product that you really like that continues to delight you. Uh You're probably here because you're curious about discovery or you understand the value, but you probably work with a few people who don't feel the same way that you do. Uh You might be here also because you're not able to get buy in for the discovery work that you need to do either from your team or from, from your leadership.

For example, think of the last time you wanted to speak to some of your customers or run a usability test and you were just told flat out. No, we'll talk about that. Uh So let's talk quickly about the agenda. I'll go into why we want to do discovery in the first place. We'll talk with three of the main reasons that I've seen why people say no to discovery. Uh And these are from direct experience. So we'll get into a fun scenario. Uh We'll talk about when we don't actually want to engage in discovery and then we'll, we'll recap and I'd love to hear any conversation afterwards as well. Um So think of a product that makes you just as excited as these two look to be using it. Um Anything uh a product that has continued to evolve to stay relevant, but it's also been profitable for the company that built it in my time and connected. I've worked on amazing products that make a difference in people's lives. Um whether it was to help them stay fit or whether it was to help them connect with their loved ones in new and immersive ways. But just because you have a great product, a strong theme and deep empathy for your customers doesn't mean that it will always stay this way, doesn't mean that it will be smooth to continue to evolve.

The markets will change, organizations will change and not everyone will agree on how to approach that problem or will agree on the solution. Let's get into the case study about a year into a year into joining a new client. I was still wondering what exactly the product was supposed to be. Uh Let me tell you how exactly we got there. Let's pretend that our client was building an app called Plant Love that helps users learn how to garden using machine learning. It will consider various data about which plants you have in your garden, the real time climate to rain your goals and it will give you advice on when to take certain actions. For example, watering your plants as a future or fertilizing your plants as the future. Um One feature might address pests and disease. Of course, you can, you can imagine there's a lot of data coming in. Uh and in real time too, and there are many possible features we could build based off of that data. So our client realized that it would quickly become too hard to manage with the limited teams that they had available. So they wanted a standardized way to build and maintain all of these new app features. Uh And my team that connected was tasked with building that platform product.

It would save the client time money and be the foundation for numerous of their new app features. Uh In turn, those features would continue to drive the light, they would drive loyalty and provide superior customer service to all of the users. Let me introduce you to the CEO whose name is Joe. Joe was really excited about plant lab and even more about uh more excited about enabling his team to build faster and that's why we were out to build a platform. So for the sake of simplicity, let's just call it the awesome platform or A P. After we established our product vision and mission, we ran a workshop with the team and we identified a few different areas that we wanted to explore for the platform. But just as we were starting to put together the the discovery plan, the client Joe said this is a great backlog. We're agile, right? So I can't wait to see what you're you're gonna build next week. It's not that simple, right? So in the aftermath of the workshop. I spent a lot longer than I want to admit at convincing Joe of the value of discovery. And it was often unsuccessful. What I'm gonna share with you next are some of the lessons I've learned and how you can avoid falling into those same traps when you're trying to convince somebody to sponsor your discovery efforts.

Let's just back up a little bit and ask ourselves why we want to engage in discovery in the first place. I've listed a few reasons. Uh And to summarize, they would be to first better understand the problem we want to solve. So, if we are in the insurance industry, for example, what are the problems that folks are finding common? Uh What are, who are our users to begin with and what do they find difficult? What could they uh use help with next? We want to derisk the product that we're building. So how do we validate that it's desirable, viable, feasible and usable? How do we validate that? It's ethical to build something that folks have not considered in the past? Um Also we want to maybe we're building something completely new and it has no common patterns to follow. So we're trying to get information, it could be a technical discovery as well. Uh And last, we just simply love the discovery process. Um This is the case for me. All of the above are really the case for me, but our client wasn't convinced why won't discovery is messy. Sometimes you invalidate a direction you're really excited about and that gets people disappointed. Um You'll have to pivot sometimes frequently and your team might be confused and they're just impatient to build uh much like Joe, not every team enjoys this discovery process or living on the edge and constantly pivoting, but there are ways to help them along.

So let me share how I could have done better so that instead you can spend your time making your product awesome. Instead of spinning your wheels like I did at least initially. So reason number one, we have an existing backlog. The product that we were working on a platform had a phenomenal engineering team lead from one of the future teams, which was the plant watering feature. Um The team lead, Jenny had been on the team for about two years and Jenny knew the team's work flows inside and out. Maybe that sounds familiar to some people. Um And Joe believed that Jenny already had enough experience working on one feature so that Jenny's experience would be transferable to building a platform. And because we were unable to convince Joe to invest in discovery at this point, we followed Jenny's gut and Jenny's backlog and we started building. So did anyone have this experience? What uh what can happen? Um When this is the case, I'll tell you what happened in our case. Yeah. Nice. I'm glad I'm glad this resonates. And so Jenny wasn't exactly the user we were building for no surprise there.

Um Jenny was so experienced that the MVP we built failed to be easy and intuitive for our target users um on other teams simply because they were not as experienced. So instead of simplifying the work they were doing, we just made it a little bit different. The other challenge that we had here was that Jenny was hyper focused on her own experience without considering some of the key opportunities to engage other teams um that work at the beginning or at the end of that process. So, of course, what happened later was we had to refactor our product because we were unaware of some of the really important key features that we needed to implement. Let's talk about how if you're faced with the scenario, how you can come out of it um or at least do a little bit better than I did. So, first and foremost, you always wanna come back to your business objectives and your product objectives zoom out. It doesn't have to be a large zoom out. Uh But show how a a particular goal can be achieved in different ways, even if you aren't or if your team isn't willing to invest time on a long discovery process. There are still quick ways to demonstrate value. Uh For example, a full design sprint takes only five days. Um So even if you don't have five days of your whole team's time to spare, you can always find time to explore a few different concepts that you can demonstrate rather than jumping in fully to solution.

Um So in my case, here's what we could have done and later on did do to engage the team a little bit differently. Now, we could have worked with the whole team to really focus on our objectives. So if one of those is we want to save time for our users who are ultimately going to build these new features, how do we want to quantify that? And can we validate it easily without building the product first? So it turns out that we can, we later had that opportunity to engage with our users and within a few interview questions, a few really short interview questions, we found out which features that we were proposing addressed their pain points and which didn't. Unfortunately, this happened after the fact. So we could have saved a lot of time just by talking to those users upfront. I'm sure this is familiar to a lot of you. The other thing that we could have done differently was we could have spoken to teams within the org that have similar processes and work on the borders of our product. And they could have helped us understand the big picture and that would have shown us what happens before what happens after users come to our platform. It could have broadened that initial backlog to allow us to really truly solve the problem that our users were facing.

Let's get into the second excuse if you will that we've heard. Um And that is misaligned incentives. What you'll often hear and face is that the team is simply not incentivized to engage in the kind of discovery work that we want to do. Um And it makes a lot of sense when you create something, build something, it's really rewarding. Um We thrive off of that, we want to build products that we want to deliver to our customers. But sometimes the discovery process will actually tell you what not to build and it's extremely valuable. You don't want to waste time, you want to focus on the important features. But at the end of that process, you won't have anything to show to your users. So there's a lot of pressure to measure productivity by way of how many features you've delivered. And in our cases, our Ceo Joe was faced with the decision to have one or two tangible features. Let's pretend the landing page for new feature creation or to run some user research and learn about the features that really matter to all of the teams who would ultimately be our user. But because user research takes time and it may not provide a clear direction right away.

Joe uh chose to build, here's what we can do in this case. Um It's actually quite common in output focused teams. And I'm sure many of you have had that experience before. It is a cultural challenge though. And it doesn't have an easy solve what you can do in this situation is focus on defining and ensuring that everyone understands what your OKRS are and then link them to the current incentives. So for example, in the case of plant love, we could have defined success as building something that improves a particular features, time to market by 10% rather than delivering any future regardless of the value. Um So it would have then made sense to invest in learning what would help us achieve that goal, what would help us uh improve that time to market? And there are times when you'll just have to deliver without the where, where you'll just have to jump into delivery right away without that discovery process. And that's ok sometimes. But over time as your leadership gains confidence and your team gains confidence in your delivery capabilities, it will be easier to align to those incentives to allow for more discovery work. Let's jump into the last reason why we hear no often. Um we need working code.

Um It's kind of similar to our previous discussion about incentives. When we started working on a platform, there was still a lot of unknowns. Even as we continue to build, there are new technologies being introduced at the company and Joe just wanted to show working code. So we focused on a particular feature team that was ready for the product, even though the technology they used would ultimately be decommissioned. And although we delivered a solution that helped them work faster and more reliably, that portion of our product actually quickly got deprecated and ultimately stopped delivering value because discovery helped us understand the context in which we're building, we can avoid wasting resources like we did on A P.

So how do we address this? Just build mindset one way instead of giving the our leadership this beautiful bouquet that can be overwhelming, lots of different scents, lots of different colors. We can start small and engage in continuous discovery, but similar to the idea of um very small amounts of discovery rather than a Multiweek customer discovery phase. Um This can be hard when there's a lot to learn, but just being mindful of how you frame your vocabulary can actually help you build credibility. Um So instead of telling Joe, we wanna run discovery for six weeks, we could add some expert and stakeholder interviews as part of our planning process. Um Instead of running separate usability tests, we can integrate them with user acceptance or Q A. Um So it can often be little overwhelming if you don't have discovery experience, but narrowing it down to start small and using language that everyone can relate to will help your users and your leadership understand how discovery will ultimately help them. Just build um One quick note around when we probably don't want to engage in discovery. Um And that is when you're not really sure what you want to achieve.

Um Right, there are many tactics and techniques so you want to make sure you're using the right ones depending on what you want to learn. So first understand the why. Um also, so when you're more focused on the process, which is fun, but what you really want to focus on are business and product goals. And then last, uh when you're operating within a very rigid technical regulatory or organizational constraints, focus only on those areas that are very flexible. Um So just to sum it up, um what we've learned through our adventures with plant lab, we want to start small um and integrate continuous discovery. We wanna take our teams along for the ride, continue to drill down on what is most important for the business and the team and give them options instead of saying discovery or no discovery, give them options to do a little bit and then see what it's like. It's really, really hard to build good products. It's really messy. But I hope that these lessons will inspire you and your team to practice more discovery so that you can build products. Your customers love that also work for your business.

I wanna quickly thank you for joining me, uh and invite you to connect. I'd love to talk about the product thinking playbook from connected and I'd love to talk to you about both discovery and delivery. Thank you so much. Everyone. I'll be around in the chat.