 Well hello product managers and welcome to this presentation on more cooks in the kitchen getting engineering involved in discovery. My name is Tim Sims. I'm a director of engineering at full story. And you might be asking yourself, how can I learn more about product management from an engineering guy. I get it. I promise you stick with me. We're going to have a lot of fun together unpacking this topic that is really near and dear to my heart. Because I do see a huge opportunity that's not being realized when it comes to getting engineers more involved in the discovery process. So we're going to unpack that talk about how it plays out why it's valuable and some tips for how you might be able to instrument this in your own organizations. And speaking of which, I do need to point out as a disclaimer that I recognize different teams have different modes or different ways of operating. That's fine. Maybe some of this content isn't applicable. Maybe you're already doing many of these things. That's great. So my encouragement would just simply be take the nuggets that are beneficial. Take the nuggets that are helpful. And hopefully you can use that in order to build better teams that build better products. So at the end of the day, that's what it's all about. All right, let's go ahead and get started. More cooks in the kitchen. So have you ever heard the phrase, too many cooks in the kitchen? Yeah, of course you have, right? Don't have too many cooks in the kitchen when my device and the premise behind this is quite simply that when you have more people in the room, it makes it more difficult to come to any type of decision because you've got lots of different inputs and competing forces. And yet in product teams for product, it's all about getting more information, more data, more evidence, more validation, and more cooks should be welcomed into the kitchen as a result. And yet in many product teams, again, not all, but in many product teams today, there's a portion of that product triad that doesn't have a lot of involvement in the discovery process. And that is, of course, engineers. So there's a huge opportunity, as I mentioned, in order to combat this, and we're going to talk a little bit about why it's valuable, why it's important. Okay, so here's the question. Maybe you've asked this in your mind, how can I get engineers to move faster and ship features more quickly? Yeah, I think we've all been there, right, even as an engineering manager, like thoughts come through my mind about how can I get more or get engineers to move more quickly. Maybe this is something that you've asked, hopefully not out loud. But maybe you had maybe, I don't know, like the relationship you have with your engineering teams or your engineering counterparts. But this is kind of the crux of why this is important, we want to move faster, we want to move more quickly. And this question comes to mind because we think that there's a secret formula for getting engineers to move faster. And so this idea of having engineers involved more in discovery kind of seems counterintuitive, right? Like my engineers are already overworked in, yeah, the backlog is a million miles long and they don't have time to do what they're currently doing, let alone be involved in the discovery process. So we're going to talk a little bit about that as well here in just a little bit. But first, let's go back in time a little bit and talk a little bit about how this discovery has come to be. So you might recognize this chart, this is sort of a diagram that, of course, we know this as waterfall, where you've got different phases of the development process, starting with requirements, and then it goes into design. And then those designs get turned into a specification that gets developed phase three. And then that implementation goes into testing. And then after testing is done with QA or test engineering or whatever the case might be, it goes to deployment. And then that cycle sort of continues on. And again, we know this as waterfall in software development. And part of the problem with this, there are several, but part of the problem is this model kind of assumes that requirements are fixed, that they're not changed, that they don't change, that you can define what a requirement is and then get through the process. And hopefully by the time you get through phase five, those requirements are still valid, still appropriate, still relevant. And of course, that's not always the case, especially in technology where things are moving so rapidly. The other issue with this is we tend to see some silos of information, right? Between these phases, there's usually some sort of artifact that gets developed or gets created to sort of communicate that to whatever that next group is. And so because you have development in like later in the process, like in phase three starting, it's oftentimes the case that feasibility hasn't been sort of addressed or hasn't been looked at earlier in the process when it comes to requirements and such. So we like to say that having engineers involved early in the process is critical, is a critical thing to your development software cycle. So again, we know this as waterfall. We sort of over time modified it to look kind of like this. The thought being, if we can create this cycle that's faster, that's more nimble, that's quicker to iterate, then we can ship things faster, right? And so the idea is that this loop is continuous on the inside, but there's data that gets fed into it in order to start the process. Once it started, it just keeps on going. And out of that, we have sort of our CI CD in order to create consistency in our deployments and such. So C planning requirements, analysis and design, implementation, testing, evaluation, those things just continue to happen. We get good hopefully at being incremental and being iterative. And as a result of that, we're able to get more things coming out of that green arrow for deployment. And so we know this as kind of the agile model, right? And yet we still see some challenges in this model, because again, planning requirements that light blue arrow in the upper left, there is oftentimes siloed and reserved for maybe it's project managers, maybe it's UX researchers, maybe it's UX designers. Wherever it's like siloed and we oftentimes don't have folks involved in that part of the process. And becomes a bit of a stickling point. Why? Well, let's talk about the discovery and delivery ownership. This is really where I feel a lot of teams end up struggling. Because for discovery, these are sort of the questions that we might be asking what problems do customers have? Which problems are worth solving? How might we solve these problems? Those are typical for discovery and the goal of discovery. And then on the delivery side, it's like, let's build and ship a product. And so naturally, you oftentimes have engineers really focus in on that delivery part, let's build and ship the product. And you've got project managers, you know, serve owning that process of discovery. And so why, well, we won't talk about the why as of yet, but the result of this is that we get these silos, right? That we just looked at in the previous slide. What we really need, love this slide, is a good pairing, right? I don't know how many foodies we have out there. And I by no stretch would claim to know a lot about this topic of pairing. But that idea is fascinating, right? It's intriguing. There are certain compliments to a good meal in a fine wine that really work to bring out the flavors or bring out the aroma or bring out the flavor of different foods that we eat. And the pairing is what's magical, right? So, yeah, again, what I try to do, someone told me this a long time ago. I don't know if this is going to gross you out, but if we have a steak lovers in the house, that's me. I do enjoy good steak. They say, at least this is what I've heard, you can certainly cut and eat your steak anyway that you want. But they say that a great way to eat steak is to cut your piece in a bite-size manner. That's pretty self-explanatory, right? If you're going to put it in your mouth, it's going to be bite-size. But you put it in your mouth, you chew on it, and you let those juices form in your mouth. But you don't swallow just yet. Instead, you take the wine and then you take a sip of the wine. And it's that wine flavor mixed and merged with the flavors that are coming from that steak that make it just absolutely delicious. So, give it a try if you've never done that before. I'm sure there are other foods where that's also the case. But why am I saying this? The point is that we need a good pairing. Good pairing. And the pairing here for FRAG teams is discovery and delivery. Now, discovery, building the right things, delivery, building the things right. And the idea is that you're continually going back and forth between discovery and delivery. Delivery is being fed from discovery. And as we're doing that, we're taking things on at the same time. So it's not like doing one thing and then you don't do it anymore. It's a continual process. You see those two horizontal lines there? Those are happening at the same time. And I would encourage you to really consider having engineers part of that discovery process. And we'll talk a little bit about that right now. So as we go through this presentation, I just want to introduce you to some of the cooks at Full Story. This is Chef Lucy who says, I like the triad partnership between engineering design and product rather than the typical model of FRAG and design, funneling feedback towards engineering. Instead of a waterfall model, we're able to be true product partners and spend less time on communicating and context sharing. That's a huge, huge time sink in just how much time do we spend in trying to explain context and re-explain context because engineers specifically aren't necessarily involved earlier on the process. Because of that, you continuously are trying to help them understand context, understand the problem space, understand what customers are truly needing, and whatever it is that you're building applies to the greater business or the greater strategy. You might recognize this definition from Tim Herbig who says, at its core, product discovery is the evidence-informed process of reducing uncertainty as you find problems worth solving and solutions worth building. It emerges through a series of nonlinear activities conducted as a cross-functional team, so important. Find problems worth solving, solutions worth building, doing that as a cross-functional team. So we've got problem discovery and we've got solution discovery. And oftentimes we think of discovery in just that first box, the problem discovery space. And then after problem discovery, it's like now we're ready to build it. We're ready to look at the problem, now it's time to go out and deliver on that and get that implementation. Understand the problem space, validating that existing or future problems are future problems worth solving by answering these questions. What's the impact of the problem? How's the problem manifested? How widespread is the problem? I'm going to pick customers to solve it and how does this problem affect our business? And on the solutions discovery side of potential solutions, because there's probably more than one way to, I won't say that, but the phrase is like more than one way to skin the cat. I don't know if we have a way to say that more animal friendly, but it's a phrase, please don't be offended. But all the potential solutions choose the best option while validating each to properly de-risk along the dimensions of feasibility, usability, and viability. By answering, can we build it? Can customers use it? Can the business support it? Problem discovery and solution discovery. Engineers are really good at the solution discovery piece, right? We're problem solvers as engineers and we just relish in the idea that there's a problem that we can find a solution for. And oftentimes it's that building of things that really energizes engineers. But oftentimes there's an energy that comes out of being involved, like being in that problem discovery space as well. Oftentimes engineers haven't experienced that enough to know whether or not it's something that they'll really, that they'll really enjoy. But I promise you, as we go through this, you'll learn that there are ways to really get engineers to really enjoy and embrace the problem discovery space. Just as much as a solution discovery space. Okay, here's another chef. This is Chef Prashant. He says, our team is happy to gather customer feedback to consider what we can do to make an impact next quarter, as opposed to waiting for someone to tell us what we should focus on. Here's what Chef Ralph says. Love this picture with the tilted sunglasses. Way to go, Chef Ralph. I really enjoy the creative problem solving of discovery. Again, like solution space, right? This is when your creative neurons are really firing and you're exploring the cross section between customers, their challenges and what's possible. It's that intersection of things that's really interesting and fulfilling from Chef Ralph. So why should we get engineers more involved in discovery? I realized that was, you know, that was a big lead up to this question here. Like, why should we get engineers more involved in discovery? I'm just going to pause as you ponder this for yourself. Maybe you've got engineers somehow involved in the solution discovery, or maybe they're already doing some things in the problem discovery space. Maybe you guys are doing that as a team, like you have activities for problem discovery that you guys are collaborating on and doing together. I think that's fantastic. But why should we get engineers more involved in discovery? There are many reasons I'm going to focus on three. Here's the first. Who's that? Well, that's your customer. Your customer is like, what in the world is going with the salad? I don't know if the salad's missing salad dressing or what, but the point here is that the first reason for getting engineers involved in discovery is an increased customer empathy. So your customer has a problem, clearly by his expression. And we're trying to get everyone involved to understand, to really feel the problem and to create that customer empathy, because there's no greater motivation for engineers than to experience that pain for themselves that customers are facing. So increased customer empathy. That's the first. Here's what Chef Clint says, directly hearing from the customer allows for shared language, making the issues they are facing understandable. Understanding that perspective and how problems impact them specifically changes how you think about size, scope and priority of possible solutions. It's great for context. Okay, sometimes it's critical that folks hear directly from a customer versus having it translated through multiple people to really get that. So the more engineers can be in the room when these problems are being discussed by customers, the better. I truly believe that. Here's what Chef Jordan says, customer interviews provide useful insight into the specific problems we help customers solve. But even more importantly into how customers feel about using our software. I learned something unique about each customer's experience within moments of talking to them a difficult feat without interviews. Okay, so that's the first reason increased customer empathy. Here's a second. What is going on here? Second is self discovered context. We've been talking about this idea of context context is so really important. There are many, many, many decisions that are being made by engineers and being able to have that first hand context that engineers can discover for themselves get to a point where they're understanding it. They can embrace that context and utilize it when it comes to making making those decisions. And that in turn helps engineering move, move more quickly. So self discovered context. And again, I think this is the reason why this is on screen is because this is a vegan bowl, right? Lots of vegetables. And you would never stick a slab of steak in this bowl here because you know the context is it needs to have vegetables. It's vegetable only right? It's it's vegan. Okay, so here's what chef Evan says. He says I love to see teams dripping with context so everyone is equipped to make informed decisions. The PM should go on vacation. How many of you guys go on vacation? Hopefully you do. PM should go on vacation and the team should generally be able to make the right decisions for the customer. Lots of decisions need to be made. We don't want the PM to be the bottleneck, but we want to use this self developed context in order to help drive and direct those decisions that do need to be made. Okay, here's the third. Why should engineers be involved in discovery? This guy right here and just let you digest what you see here. But you see how distraught this guy is? That's a picture of you. That's a product manager. And the point of this slide is the reason is so that you can share the load because look at him. He's like exhausted. He's realizing he needs more cooks in the kitchen. He's all there by himself. Well, with the exception of his design friend in the back who's washing pots, I think. But he's thinking like wouldn't it be great if I could share the load if I wasn't the only one doing this? Being a PM is sometimes a very lonely, very lonely space, right? Because you're taking on the brunt of these problems that customers are having and you're dealing with lots of different stakeholders and opinions and everything else. And it'd be great to be able to share that load with the rest of your team. So here's what Chef said, says it's I've got more than enough time to do everything I need to do, including all the vetting and validation work on future requests coming in from all our product stakeholders. It's from Chef never said. Yeah, wait for it. Okay. So in all seriousness, here's from Chef Ivan, one of our practice designers. I think about the Steve Jobs quote a lot design isn't just the look and feel designs also how something works, especially true in practice line for that reason. It's crucial to have input from an engineer who has a deep understanding of the inner workings of a feature. So share the load. All right. So how might we get engineers more involved in discovery or HMW, right? How might we get engineers more involved in discovery. So now we're going to shift gears and talk a little bit about the tactics that we can use in order to get engineers involved. Okay. So let's, we're going to go through these pretty quickly. There's four stages to this invite, equip, activate and celebrate. So on the invite, we've got to invite engineers into the kitchen first and foremost. So how do you do that? One, let's state the problem. The share of the impact of not having engineers involved in holistic discovery. Again, we just looked at at some of those read we looked at three reasons right but that context one will resonate there very strongly with with engineers, especially as they're asking lots of questions. It's like, well, you know, what might be more effective is to get you involved more directly in assessing and understanding this context around whatever the problem space is, right? So let's find ways to, to get you involved because without it, you're just going to continue asking questions and I know that's that could be frustrating because now you're waiting for, for a response and that likes or holds you up and such. So that's one way to actually state the problem to be generous with information, right? There's no better way to build trust with your engineers. In fact, because you do hold the keys for with all this data that you have gained from all the customer reviews that you're doing. Maybe you've got some analytics or you've got other tools in place to to really surface information for yourself and data that you can use. Be generous with that information. And by doing so, you'll build trust with the engineers. Three cast the vision of one team. Love this. It's not a we versus them. It's like, we're all in this together. And if you can cast this one team where it's like there's no egos and there's no like sort of structure to it, but we're all involved in this because as a team, we've got goals and we have objectives that we're trying to accomplish. And then four, as for optional participation, don't force this on engineers. That's one sure way to make it unsuccessful, but start small. Start with, you know, who might be interested in getting involved in a customer call once a week or who might be interested in saying up a regular weekly meeting where we're talking about the problems that we're intending to solve. Or how can we sort of meet on a regular cadence at the start of our development cycle at the start of our process to define what these requirements are together. Let's find who those champions are within the engineering side that can that can help get that get that through. Okay, so share the problem be generous with information cast the vision of one team and ask for optional participation that's in bite. Just a second equip. Right, so no chef can be successful without the right tools, talking about the tools here. One, Leah discovery workshop. So explain what discovery is and not. Again, a lot of times folks are thinking that discovery is just that problem discovery space, and then solution discovery is actually the implementation. Like draw the contrast of we need to make sure that we know the right things to build. And then we need to know how we're going to build the right things using the right solutions right so help engineers understand and demystify this idea of what what discovery is you can lead a workshop. We've seen that very successful where you know, engineers are curious about what what that is, and how they might be able to play a part in the discovery process to host a book club. Synchronized reading to foster discussion share and understand discovery. We did this a full story. We went through the inspired book by Marty Cagan. I'm sure you're all familiar with that book fantastic, fantastic read. We went through it in 10 weeks actually have a slide on this in a bit. Let me just get to it. Here's a book club slide right here where you're not going to be able to read this, but reach out to me and I'll send you the sort of how how we broke it up into 10 weeks so you don't have to squint in order to try to read this. Let's go back. Create space for discovery work. Again, what's what's difficult here is when you're empowering engineers to actually do this discovery is to help them understand how they're going to fit that into their existing work. I mean it's probably the number one challenge right. How much time can you offer engineers to dig into problem discovery and solution discovery. And so you can time box discovery activities like prototype experimentation. I've seen that done very well, especially when it comes to like evaluating different options for solutions and such being able to create a time box for for that is is is really effective. But ultimately, find ways that engineers don't feel like they're doing discovery on their own time, but find ways to work it in. Sometimes that means sticking discovery tasks on to your JIRA board. I think that's a great way to do as well so that there's no perception of the work on the JIRA board is the most important stuff. And then we're going to find time outside that in order to do discovery because the reality is if it's not on the board then it's likely not to get done for for many reasons. We won't dive into that right now. Okay, and last but not least share exemplars of successful discovery. So map out the steps of your discovery process help engineers understand how to connect the dots between idea. To the problems to the potential solutions vetting those coming up with the solution and then getting that into the delivery process. So we do that using a framework called powerful execution. You're not going to read this it's you're going to squint but this is our discovery flow chart and though you can't read it. It takes things from that very ideation stage and ideation meaning not just that you're generating ideas but your. Yeah, you're curating ideas from all your various stakeholders and data points that you might have. And then how is that sort of matriculate its way all the way down into that yellow sort of de risking space where we're talking about feasibility we're talking about value we're talking about business viability. And then like a little bit later in the process we talked about usability, but this is kind of how we lay this out and might not look the same way for for you and your teams but this is a great way to. To help engineers just really understand the mapping and create a mental map for themselves to to be able to. To visualize like how how how they can sort work things through the process. I just mentioned the execution tree this is kind of framework it was I think it was invented by Spotify so there's a blog post about that. Do Google search stuff execution tree you'll learn more about that maybe it's something appropriate for you as well. Okay, so activate number three. So look at this kitchen here. We get everybody's working collectively working as a team. Everyone's got their job their role and they're sort of effective at that now the analogy isn't quite. Yeah, it's not great necessarily because what we're talking about is having additional context but I guess you could say, you know the folks who are plating on the front left I guess the guy who's bending down right there on the left. Like, you know, you sort of have to know like what are the, what are the, I don't know where the foods that are going to go on that plate in order to know like how or you got to know like what the presentation should look like or I don't know I'm making it up now. But the point is we need to activate. So let's talk about that carve out time from weekly stand weekly team meetings. Yeah, we do this we've got discovery activities where we're looking at, you know, sessions of customers like trying to figure out like where the problems that that folks are breaking down. We call it game film. You might call it something else where you can sort of look at and internalize as a team and yeah just talk about like where the where the trouble spots are. That's just one aspect of it. There is also sort of aspect of, and we talked about this a little bit of creating space where you're actually diving into potential solutions and your brainstorming is such like you know use, use your weekly meetings that you have in order to really activate this concept of, of engineers being a part to empower empower with data access, talked about you hold the keys right so how about enumerating and providing access to these customer interviews, there are lots of tools available and or do that if you use gong or other similar tools make those available customer behavior data is another one. And there are other data sources that I know that you're using in order to gain more context that make those available as a from a self serve standpoint so folks don't feel like they're asking a favor in order to get access to that. Three, adopt processes that focus on customer insight, find simple tools and frameworks that can be used to share learnings from customers, like the customer interview pyramid principle. Yeah, you should Google that one as well it's a really good one you guys are probably familiar with that game film and watch parties we talked about that. And for conductor regular discovery activity interview customers that you know, let me just emphasize this point. Discovery isn't just customer interviews, right. It's a piece of it, but, but it's not the whole thing, customer interviews is a subset maybe that's the part that that folks get my engineers get most anxious about it's like, I don't want I don't feel like I'm good at talking to customers. That's fine there's lots of, there's lots of room within the discovery space where where maybe they can do something that's that is of interest to them. Okay, run surveys, collaboratively review problems talked about that bill prototype experiment with ideas de risk solutions. So that's active and last but not least celebrate. There we go. Did we did a thing. Now let's celebrate a thing, right connect the dots show the connection between problem discovery and solution discovery. Show how these are things that we came up with in the problem discovery as we dove more deeply into the problem space, and we came up with some potential solutions for that. This is how we went through the process of choosing the right solution, help to connect the dots it'll make it much easier and reduce that cognitive load for for folks. There's tools like the opportunity solution tree Teresa Torres. It's a great resource as well. Take a look at that if you're not familiar with it. Recognize when engineers create wins. Maybe it was hopping on customer interview celebrate that a deep dive in the customer problem celebrate that a fruitful ideation session celebrate that successful experiment or working on prototypes celebrate celebrate celebrate all those things so that you're building this and reinforcing this culture of discovery and how important it is, you can very, very much be successful at, you know, encouraging and fostering more of that activity by celebrate. So that's definitely what you want to do and it's fun, right, you know, this work should be fun. And that's a big motivator for folks. We like to be recognized to so all those things can can certainly help when it comes to further adoption. And then last and not least share the wins with others in the company as you continue building culture provides success stories to encourage other engineers to participate in discovery. This is the superpower here. Again, we're going to start with some an optional set of, well, an option set, we're going to start with engineers who opt into this process. But what's going to happen is they'll start to see because you're sharing these wins with with others they're going to see like how effective and how enjoyable and how, how important these discovery activities are, and then they'll to in turn be interested in getting involved in the story. So that's it. Thank you. Really appreciate the time and the opportunity to speak with you here. And if you want to connect with me here's just a couple ways to do it Tim sims at full story that comments email but LinkedIn. You know, try to be active on on LinkedIn regularly so definitely reach out and stay in touch. And if you've got questions I've got a bunch of resources as well that I mentioned throughout this presentation here so if you're interested in this or you want the slide deck then happy share that just reach out. Okay, well thank you product leaders really appreciate you guys keep up the good fight and hopefully as you start introducing engineers in the discovery, you guys will make your teams more successful and your teams being more successful means that your business will make better products. So that's my hope. My name is Tim Sims. Thank you everyone. Have a good one. We'll talk to you soon. Bye.