More Cooks in the Kitchen: Getting Engineering Involved in Discovery

Tim Simms at UXDX USA. Video: https://youtu.be/e4HkRlG2KQs

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Who's in the room

[00:00:00] What's up everybody, how we doing today? Oh yeah, yeah, I feel the energy. Thanks for being here. If you're watching online, great to not see you, but glad that you're tuning in. Special shout out to Catherine and Rory for putting on such an amazing event. I'll just give them a round of applause. Awesome.

[00:00:19] And I'm super excited to be here, so thanks for having me. I'm super excited because we are talking about — let's see if we can get into slides — okay, we're talking about more cooks in the kitchen. And we're at UXDX, and yet if you look at my title, there's no mention of product or design in my title. I say that because, maybe[?] not all of you, but some of you, have been in situations where there's an unhealthy tension between engineering and product. Yes? Not probably not most of you, right, but maybe a couple of you.

[00:00:55] And so sometimes we find situations where a designer is clashing with a front-end engineer, or a PM is clashing with an engineering manager. And here at UXDX we get the opportunity really to collectively help others that are coming into this community to build better teams that can ultimately build better products. So super excited about that.

[00:01:18] Let's get into... oh, before we do, let me just see a show of hands to see who's here in the room. If you are a product designer, just let me see your hands. Ah gosh, that's like 80 percent of the room right there. Okay, all right, I might do some adjusting on the fly. How about PMs, if you're a product manager? Okay, I see a healthy mix of those. If you are an engineer, where are my engineers in the house? Okay, I see you, I see you, I see you, I see you. You know, strategically placed throughout the room here. So that's awesome. And anyone else, if you're in management or you're a researcher or otherwise, let's see a show of hands. Okay, probably about 15 to 20 percent of you here. Okay, awesome, hopefully there's something valuable to share.

[00:02:07] We're talking specifically about the product triad, so we're talking about PMs, designers and engineers, but this can apply to others. Researchers, you guys don't get nearly enough credit for all the work that you do on a regular basis, so we appreciate you as well.

Too many cooks in the kitchen

[00:02:24] All right, so before we get into the meat of the conversation, I just want to talk a little bit about how I got here. This is a picture of my dad right here. Growing up he taught me many things as a kid. One of the things he taught me was a very strong work ethic. See, my dad worked for 30 years at Chrysler Corporation in the Newark assembly plant in Newark, Delaware, where I grew up. Any Delawareans in the house? No, there's not too many. Oh, look at this, look, we've got someone sleeping, her head down. I understand.

[00:03:00] So my dad worked for 30 years, ultimately landing him as the superintendent of the maintenance department at Chrysler Corporation, where he would lead teams that went around and troubleshot different machinery when they broke down and fixed those things so that assembly line was operating properly. So in addition to spending his career at Chrysler, he also was a sole proprietor. He had his own business, a tax preparation and accounting business, and would work tirelessly by himself, okay, by himself, in this business.

[00:03:35] So you can imagine, as a sole proprietor and a superintendent leading teams, that he was constantly making decisions after decisions after decisions, lots of decisions. And he had this phrase that he would tell me, he would say, "Tim, make sure that you don't have too many cooks in the kitchen." Don't have too many cooks in the kitchen. He would say things like, "If you want something done right, then..." fill in the blank. "You've got to do it yourself." That's absolutely right. Maybe you had a dad like that too.

[00:04:07] So while that might be sage advice for a teenager growing up with some self-confidence issues, let's say, for our product teams that couldn't be anywhere further from the truth. In fact we value the inclusion of other ideas, and the diversity of thought and diversity of perspective, and bringing in multiple points of view to be able to build the products that we build. And so we're going to talk a little bit about that here today.

Thinking agile but not working agile

[00:04:38] But before, let's just do a little bit of baselining here. How many of you guys have asked this question to yourself, maybe not verbally, maybe verbally: how can I get engineers to move faster and ship features more quickly? Yeah, yeah, yeah. If you did it out loud it might not have been a good situation.

[00:04:59] But we're constantly looking at ways that we can shorten the development cycle. And it kind of goes back to what Rory was talking a little bit about earlier today. We've got these different phases. We all know this is waterfall, right? Like a big behemoth of a process, where you've got different phases here, different people associated with each individual phase, and obviously between those phases there's some type of handoff process. And we focus so much on that phase three, develop, how can we shorten that time. And yet there's a lot of waste that goes on in other areas that we can make more efficient.

[00:05:35] So we got cute and we adopted agile. So it's kind of different. The idea is like, you make a smaller wheel that can move faster, ship features out more quickly. There's a deployment section, where we use CI/CD in order to automate the process, make things... very confidently we can ship software, and the cycle keeps on continuing: analysis, design, implementation, testing, evaluation.

[00:06:03] But even when you look at this screen right here, PMs are typically in that light blue in the upper left there, and then you've got designers, and then you've got implementation there, that's where the engineers are. And the problem is, even though we're agile and we're thinking agile, we're not working agile. And so part of the problem is the fact of ownership: delivery and discovery ownership.

[00:06:28] And the issue is that we still have these silos of where we believe, or where we perceive, that PMs, designers and engineers fit. So these might be questions. Discovery is all about build the right thing, delivery is all about build the thing right. And so these are some of the questions, but ultimately these are represented by discovery owned by product managers and product designers, and delivery by engineers. And what we really need is a pairing.

A pairing: discovery and delivery

[00:07:03] Okay, now I know it's lunch time or just about lunch time, and I've got to preface this with a disclaimer: there are a couple of food oriented pictures in my slides, so if your stomach starts grumbling, just sort of look away, just look away.

[00:07:21] But the idea behind a pairing is you've got a food and it pairs nicely with some type of wine or some type of beverage. Or if you're in Maryland like I am, maybe it looks like this, right? You can't pick crabs without the nice cold draft beer. But getting back to the pairing, someone told me — and I'm by no stretch a steak or a wine connoisseur — however, they told me that the best way to eat a steak is, you slice into a steak, then you take it and you put it in your mouth, you start chewing, let those juices fill your mouth, but before you swallow, even though you're chewing, you swirl that wine, and then you smell the aroma, and then when you taste the wine, the flavor of those berries mixed with the juices of the steak creates just a fusion of flavor that, just as you swallow, it's a wonderful thing. Any steak lovers in the house? Steak lovers, okay, just a few, just a few. Wow, okay. Okay, vegans in the house, vegans? Okay, all right, we'll get to you later.

[00:08:32] But the point is that in product discovery and delivery we need a pairing there as well. This slide might be familiar to many of you guys here. We're talking about continuous discovery. So it's building the right things and building things right. You've got a discovery track and you've got a delivery track, where you've got incremental features that are going through experimentation, validation, and then going into delivery, and then the next thing is taking off, and we're going along a path of developing a capability. But it's going sequentially, while these two tracks are working in parallel.

[00:09:11] And so I've got a couple of slides here, we're going to meet some of the cooks from FullStory. This is what Chef Lucy has to say: "I like the triad partnership between engineering, design and product, rather than the typical model of product and design funneling feedback towards engineering." Instead of a waterfall model, like we just talked about, "we're able to be true product partners and spend less time on communicating and context sharing."

Problem discovery and solution discovery

[00:09:36] Okay, so here is a quote from Tim Herbig, you guys are probably familiar with this. "At its core, product discovery is the evidence-informed process of reducing uncertainty as you find problems worth solving and solutions worth building." Okay, there are two parts to discovery: it's finding problems worth solving and solutions worth building. So we've got problem discovery and then we've got solution discovery.

[00:09:57] Now your engineers are likely very comfortable being in the solution discovery realm, where they're answering questions like, can we build it, can customers use it, can the business support it. We're talking about de-risking feasibility, design and the viability of the business. And so they probably are familiar with that. What they're likely not doing right now, maybe they are at your organization, is getting involved in the problem discovery space. So they might be running experiments, they might be building prototypes, they might be brainstorming on the best way to solve or create solutions for these problems. But how much are they involved in some of these questions on the left hand side?

[00:10:43] Okay, here's Chef Bershoff[?] here, who 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." That's Chef Bershoff[?] talking about the problem discovery side of things.

[00:11:01] And I've got another chef here. This is Chef Ralph, who says, "I really enjoy the creative problem solving of discovery. This is when your creative neurons are really firing and you're exploring the cross section between customers, their challenges and what's possible. And it's that intersection that's interesting and fulfilling." So he's talking more about the solution discovery side of things. My point is that engineers can be very much motivated to be involved in your discovery process, whether it's problem discovery or solution discovery.

Why get engineers involved

[00:11:31] Okay, so let's pause. Why should we get engineers more involved in discovery? Let's just see by showing hands, if you've got engineers right now involved in the problem discovery and the solution discovery, can you just raise your hand? I just want you to shout out. Oh wow, you've got a lot of people right here in the front. Just scream out real loud. Oh, I'm sorry, I didn't give you the prompt. So the prompt is, if you have that, what are some of the things or some of the reasons why you would say it's valuable to have engineers a part of the discovery process? And there's probably going to be some similarities here.

[00:12:10] Bandwidth, yes, yes, yes. What's your role right now, you're a designer? Bandwidth, exactly, your own bandwidth, you don't have enough time. Yes, who else, right here? Feasibility, yes, being able to determine whether or not something's feasible or not. Yes, right here. Developing empathy, yes. Right behind you. Alternate solutions, different perspectives, yes. Accuracy, making sure that everything that you want is possible, yes. In the back there. Edge cases, oh my goodness, edge cases, okay, good. Anyone in the top section? Yeah, you're right there, sir. Awareness of scope creep, yeah. Sometimes, if you have engineers that are capable of identifying and preventing scope creep, that would be a very, very important one.

[00:13:02] Let me just give you three, and some of these we've touched on. Here's the first, this guy right here. That's your customer right there. I guess he doesn't have dressing on his salad or something, but he's confused, he's frustrated, he's looking for your help. This is increased customer empathy, which we just talked about: creating empathy within engineers for your customers.

[00:13:24] Let's look at what Chef Clint says. "Directly hearing from the customers allows for a shared language, making the issues they're facing understandable. Understanding that perspective and how problems impact them specifically changes how you think about the size, scope and priority of possible solutions." One more here from Chef Jordan. He says, "Customer interviews provide useful insights into the specific problems we help customers solve, but even more importantly into how customers feel about using our software." Okay, so that's creating customer empathy, increasing the customer empathy.

[00:13:56] Here's a second. Yes, like, why are we showing a bowl here? This is context. See, this is a vegan bowl. Vegan bowl. I told you vegans I was going to bring you in here. So it's a vegan bowl, and you would never put meat, as a chef, into a vegan bowl. You've got to have that context. And when you're able to self-discover context, you're able to make good decisions that are good for the business and for the product.

[00:14:24] So let's look at what Chef Evan has to say. "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 want to go on vacation, PMs? Yeah. "The PM should go on vacation, the team should generally be able to make the right decisions for the customer." So that's self-discovered context.

[00:14:45] And the third one here is this guy right here. PMs, that's you, that's you PMs. And look, he's distraught, he is just looking, he's saying, I need more cooks in the kitchen. I don't have any cooks except for my design buddy in the back there who's slaving over the stove there. But how can I get more help, because I'm just exhausted by all the work that I have?

[00:15:10] So this is share the load. Share the load is the third reason why we would do it, someone mentioned that earlier. So this is Chef Nev, who says, "I've got more than enough time to do everything I need to do, including all the vetting and validation work on feature requests coming in from all our product stakeholders." That Chef Nev said, product manager right there. Okay, that's what he said. Okay, wait for it, wait for it. Okay, all right.

[00:15:35] Really though, here's our designer, Chef Ivan. He says, "I think about the Steve Jobs quote a lot: design isn't just the look and feel, design is also how something works. It's especially true in product design. For that reason it's crucial to have input from an engineer who has a deep understanding of the inner workings of a feature." Okay, someone mentioned that as well. So those are the three reasons that I would present as far as why this is important.

Invite: bring engineers into the kitchen

[00:15:56] So let's talk about how might we get engineers more involved in discovery. And again, I've got to apologize to my PMs, I know you guys are used to seeing "HMW get engineers more involved," but here's the list right here: invite, equip, activate and celebrate. We're going to spend the remainder of our time just talking about these four ways in which we're going to get the engineers more involved.

[00:16:27] So let's talk about invite. We've got: invite engineers into the kitchen. So here are just a few things that maybe you might think about as you consider how to get engineers more involved. We're going to start with the problem. We're going to share the impact of not having engineers involved in holistic discovery. Super important. You guys start with the problem. Let's use what we've learned in product design as a way to introduce this process.

[00:16:56] Second, provide access to information. PMs, I know you guys are in the room, PMs, you guys hold the keys in a lot of respects with regards to information. You've got informational assets that you're going to use to build trust in your engineers. You're going to share access specifically about customers, business, market and customer behavior. Those are four of the things that your engineers are currently relying on you to be able to gain that level of context. So that's number two, provide access to that information.

[00:17:28] Three, cast a vision of one team. Now I realize you guys are working in one team right now, but are you really working collectively as one team? Here's what you're going to do: promote collaboration, eliminate the intra-team silos, and paint a picture of what the team can accomplish when more united in simultaneous discovery and delivery.

[00:17:51] Okay, we're not going to force feed this to our engineers. Please don't do that, don't do that. But you're going to work with those who are interested. I bet that you'll be surprised by how many engineers are interested in being a part, as you share the problem and give some context to what discovery is all about. So you're going to form a discovery team around a particular problem that you're looking to solve within your product. Let's use that as an experiment that you can do. Others will likely follow. So that's invite.

Equip: prepare engineers for success

[00:18:19] What's next? Equip. Every good chef needs the tools of the trade. So equip is all about preparing engineers for success. We're going to start by leading a discovery workshop. That's what you're going to do for your team, so that you explain what discovery is and is not. It's those two tracks. If you ask an engineer, more likely than not they would equate discovery with customer interviews. And customer interviews is one of the tools of discovery, but it is not in itself discovery. And so by describing and explaining what discovery is and is not, you're going to allay the fears. And you're going to share your discovery playbook. If you don't have one, write one. What's the process for something going from just a concept, or something that you're hearing from your customers, and getting that into a releasable feature or capability?

[00:19:16] Okay, so most important though, you're going to tie the tasks to individual strengths. Now if you guys are familiar with CliftonStrengths, there are 34 possible strengths. They all fall into one of the quadrants of strategic thinking, relationship building, influence and execution. And you're going to find where your engineers fit, where their strengths are, and you're going to align some of the activities to their strengths. So for example, if you've got someone who's very strong in relationship building, then I recommend they be a part of your customer interviews, because they're all about connecting with other people and understanding how to relate to the things that they're experiencing. And so you're going to tie tasks to individual strengths.

[00:19:58] Second, host a book club. We're doing this at FullStory in fact. Synchronized reading to foster discussion, shared understanding of discovery, that's what it's about. We're going through INSPIRED by Marty Cagan. EMPOWERED is another good one, you guys probably are familiar with that as product folks. But invite your engineers to read that as a shared experience, and I promise it'll be very valuable for you.

[00:20:21] Three, create space for discovery work. How much time can you offer engineers to dig into problem discovery and solution discovery? How might we time box discovery activities like prototyping and experimentation? Super, super important, create the space. If you don't have space, then the engineers are going to feel pressured, and if they feel pressured then they're not going to be able to reap the rewards and the value that comes from being a part of discovery.

[00:20:44] Fourth, share exemplars of successful discovery. You've got your discovery playbook: map out the steps of your discovery process that systematically gets you from "what problems might we solve" to a validated feature that you release and measure.

Activate: carve out the time and the data

[00:21:01] So that's the first one, and the second one, and then we're going to equip, now we're going to activate. Look at this kitchen here. We've got, this kitchen is running very smoothly. I don't know about that guy who's up high there, he's standing on a counter or something, maybe he's crushing grapes, I don't know, but he's up there for some reason. But the point is that everyone's sort of doing their job and they're collectively executing in an effective kitchen, as you can see.

[00:21:29] So here's what we're going to do for activate. Carve out time from weekly team meetings. You guys have weekly planning meetings or weekly sprint meetings and your standing meetings. Share the inputs to and the findings from your discovery activity, even for engineers that aren't necessarily in the discovery process. Super important that you state and you share how valuable discovery is to you, by creating time where they're able to see what those inputs and outputs are.

[00:21:55] Two, empowering with data access. We've talked about this before with the PMs, but we're going to enumerate and provide access to customer interviews, customer behavior data. How many of you guys are doing that right now, like you have access to that, if there are Meet recordings or Gong or whatever? Okay, some of you guys have that. Provide access to that for your engineers, and other data sources, either in real time or using tools.

[00:22:18] Now here's a little plug. I do work for FullStory. FullStory has a great solution for providing insights into customer behavior. If you're not using FullStory right now, definitely, we've got a booth out there, would love to talk to you about why. If you do have a session replay or other type of product analytics tool, definitely check them out as well, so they can share with you the differences between our solution and others on the market. Okay, and a PSA, here we go.

[00:22:48] 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. Definitely look for that. If you're online, game film watch parties, we've got that available that you can do in FullStory. Interview customers, run surveys, collaboratively review problems. These are all the things that you would typically do in your discovery activity.

Celebrate

[00:23:12] And then last but certainly not least, celebrate. You're going to celebrate the activity that engineers are involved in. Connect the dots, show the connection between problem discovery to solution discovery and how all that ties into the delivery tracks, using tools like the opportunity solution tree. If you guys are familiar with that, great; Google it if you're not.

[00:23:37] Two, recognize when engineers create wins. Engineers love to be recognized for the work that they do, as we all do of course. Maybe it was hopping on a customer interview, maybe it was delivering a successful experiment, building a prototype that's actually working, or whatever. Celebrate, that's the bottom line.

[00:23:54] And third, share the wins with others in the company as you continue building culture, which is all about recognizing the success. Your culture is the activities that you reward. And so you want to reward engineers for being a part of that. As you continue building culture, provide success stories, urge other engineers to participate in discovery, use it as an experiment. As we've said in other sessions as well, we're going to use what we know about building products to actually build successful teams. And that's it. Thank you, thank you, appreciate it. Questions?

Q&A

[00:24:31] Host: Yeah, all right, I mean that was incredible. I'm like sitting in the back fire-reacting, you know. I love how you are talking about bringing the team together as true partners, as true collaborators. Questions out in the crowd for Tim? Right here first, yes.

[00:24:51] Audience: So I know it has to be like an organizational change. Let's say that you're stuck in the build track[?] and your engineers don't really have the time given to them to do that. Do you have any tips on that[?]?

[00:25:07] Tim: Yeah, it's an organizational change that needs to happen in order to enable this type of thing to happen, was the question. And so, how do you get engineers to have the time in order to do it? A couple of things I would say. Number one, I would say this is, first off, it's something that you can do on your own team first. Okay, it doesn't necessarily have to be rolled out wide. And so whenever you're building something new, like a new process, it's always good to experiment with that as well, and then share the success story.

[00:25:38] Tim: The other thing I would say is, it's important to cast this vision not just within your own team, not just for direct reports that you have or people on your team, but also promote it up the chain as well. Like casting the vision and the value that's going to create within the business. And so I would say, let's find the places where we can showcase that for others, and you'd be surprised by how possible it might be in order to find that time. Great question, thanks. Right here, yep.

[00:26:16] Audience: In one of the slides you mentioned prototyping is one of the activities that engineers could be part of[?]. From a design point of view, we create prototypes in Figma or XD[?], or even whiteboards, but the engineers would be building software typically. So what's the difference[?]?

[00:26:42] Tim: Yep, that's a great question. So the question is, as a designer I'm building prototypes, what's the value of engineers building prototypes? Yes, they're building prototypes. And the point goes back to what Tim Herbig said before, which is, we are attempting to de-risk and validate that whatever it is that we want to build is feasible. So the prototypes could just simply be, can we take this large piece of the solution that we don't know how to build, and can we experiment to see what's the best way in order to build it, before we get into a product?

[00:27:28] Tim: Like, most people think MVP means minimal viable product. It doesn't, it means minimal viable prototype. Which means that you shouldn't be building things necessarily directly into your product. Now there are some exceptions obviously, but when it comes to big features that have risk, our number one goal is to de-risk based on feasibility, so that what we're building then into the product is a solution that will carry. Yep, good. Yes, right there.

[00:28:00] Audience: I'm being circumvented in this entire process. You know, UX is still relatively new and people don't always understand our processes or their value. How do we approach this in a way that we're not excluded, or that now the engineers feel we can just do all this on our own, we don't even need you anymore?

[00:28:20] Tim: What's the structure of the team?

[00:28:24] Audience: So at my company specifically we actually contract to our customers, and so do the engineers, so we don't have that power to even combine our teams in that way.

[00:28:35] Tim: Okay, do you have PMs, product managers? Okay. So I would recommend that you speak with the PM and see if there's a way to create this cross-disciplinary team that we've been talking about here, even within the context of just taking one small problem, and taking that through, inviting engineers into the process. Now the reverse, I think, is that engineers oftentimes feel like they're excluded, or they're not necessarily invited into the process. That's why that invite step is so critically important, to be able to share with engineers that there is absolutely not just space for you at the table, but we require that you're a part of figuring out what problems we're going to address and what solutions we're going to build. Yep, maybe one more.

[00:29:45] Tim: How do we invite engineers into the process, or at what point do we invite engineers into projects, and how do we have meaningful meetings? Yes. So I would say, to the first question, when: as early as possible. As early as possible, literally meaning when we're thinking or concerned about the problems that we're solving, that's the time to get engineers involved, absolutely.

[00:30:13] Tim: And I would say, with regards to what's the cadence and such, different teams are going to work in different ways, different companies have different pieces. But if you have a regularly scheduled standing meeting where you're able to dive into some of these processes or some of this discovery activity, I would say definitely invite the engineers to that. But it's only going to work if you sort of map out what that discovery process is, so that they can see themselves as part of that process and how they can bring value.

[00:30:47] Host: Yeah, that's good. All right, awesome, thank you so much Tim. Another round of applause please. Thank you.

[00:30:55] Tim: Thanks.