Implementing Product Process Change in a Mature Organization

Chris Avore at UXDX USA. Video: https://youtu.be/-6jrA5yqt5I

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.

Process change to mature your organization

[00:00:00] All right, folks. Unbeknownst to you, you have entered the second half of the financial design (financial professionals wearing pink) section of the program, thanks to Sali's [?] great intro there. We are going to talk about implementing product process change in a mature organization. That sounds thrilling, right? In fact, I'm going to change it up on you a little bit, and we're going to call it implementing product process change to mature your organization. See what I did there? I wanted to see if this is something that might make you stay awake a little bit coming out of lunch, considering that when you start to hear product and process and maturation of enterprises, it can start to get a little dreary. I'm going to try to keep the energy up a little bit before I really hit you with some boring tactics. I'm hopefully going to be kidding.

[00:00:52] My name's Chris Avore. I head up the design practice at Northwestern Mutual. It's about a 120-ish person design team, inclusive of content, research, program management and such. Prior to that I led teams at Meta and Nasdaq, and I also wrote a book a couple of years ago on design leadership and management, and also contributed to the InVision work, if you all remember them, around design maturity. The reason why I want to bore you with this background is to say that I'm going to try to share thoughts and experiences and ideas and suggestions from a diverse span of employers, of practices, of domains. That way you're not hearing some dude walk up here and saying, "Oh, he's going to talk about process at Meta. Cool story, bro. We don't have 100,000 engineers. We don't have 100,000 product designers at a two-to-one ratio, ready to just build, build, build, build, build." Because that's definitely not how it is at Northwestern Mutual, I can assure you. Hopefully we'll see a little bit of where you work and how you work in some of the ideas that we're going to be talking about today.

[00:02:01] What I am curious to hear is, if we start to think about process, if I started to say to you: imagine if you had more clarity when you were undertaking a new project. Or imagine if your teams had greater awareness of what other possibly useful work was already underway, perhaps by a bigger team or a smaller team elsewhere in that larger organization. Or what if your stakeholders or your partners had a better understanding of what was underway and what was going to be coming next? And what if your design teams operated with more intentionality, or had a better, more deliberate approach to what they were going to do, and more importantly why they were going to operate that way?

[00:02:41] And what if your product management team were connecting the impact of the work to larger goals, instead of what we've sometimes seen, folks being incentivized to just build, build, build? And what if engineers felt like they could apply their product and business expertise earlier in the process, instead of that role that they don't like any more than designers like me, any more than I'm sure product folks in the audience like, when they say, "Oops, sorry, that's actually really hard. I probably could have told you that two months ago, maybe two weeks ago, if you had just let me know what you were thinking."

[00:03:12] And then what if we could do all of that at scale, across teams, across multiple product portfolios, and consistently over time? Well, whose job is that? That's not necessarily something that is going to be one person or one role or one type of job for one person to execute. It's too hard, it's too much, and it requires too much buy-in. What we're going to try to talk about is how to thread that needle, how we are going to be able to establish that partnership to get some actual change underway. Yes, it will be extra steps that a lot of teams aren't doing today, but ideally it will show material gains later on. It may not necessarily be immediately measurable, but we will absolutely start to see improvements in our relationships and in the work.

[00:04:02] And I pinky swear, folks, that a lot of the ideas I'm going to bring out are in practice in some of these roles. I also pinky swear I'm not going to try to use gen AI as a catch-all savior at all times. And I also pinky swear that all of these materials will be available. These slides do get wordy. That is intentional. It's not because I don't know how to search for stock photography. And actually, I do suck at memes. You'd probably see a lot of Drake memes, or you've already seen the Spider-Man meme, and you'd be like, "Bro, is this 2010? Come on, man, get some new material." Instead I try to use language on these slides so that they're more useful to you three months from now or six months from now, or you could take them to your design leader or design partner and say, "Hey, why aren't we doing this?" That way they're a little bit more useful than if you just had a bunch of funny memes in your deck.

[00:04:54] What I want our operating hypothesis to be for the next 17 minutes and 21 seconds is that by improving key moments of the product development life cycle with structured, consistent artifacts and activities, the teams that we're leading will operate more effectively and efficiently (not bad words, folks), and will create more opportunities for innovation, sustained growth and ultimately increased enterprise value. That does get into some business stuff, right? That does start to get a little like, "Okay, this is where the blazer comes in. Now I see where the business guy's going to start talking." But bear with me.

[00:05:30] What I hope to talk through today is that we'll be examining the end-to-end product life cycle. Not a whole lot new there, but we're going to talk about where it breaks down. We're also going to talk about what we could try to do intentionally, where we could create some degree of tactical change that could possibly shift some of those pain points and flip them into opportunities. And then also how this process change can unlock better impact throughout the product lifecycle, but ultimately after launch as well.

The elephant in the room: bashing process

[00:06:03] First off, we're going to talk about trusting the process. How might we be able to shift how we show up as leaders to enact change in the product development process? The first thing we're going to talk about is the elephant in the room when folks hear about process. I'm going to share some quotes from a bunch of old white dudes that have been really successful at doing this and bashing process, starting with Jeff Bezos: "The process can become the thing. The process is not the thing. It's always worth asking, do we own the process or does the process own us?" Pretty sure a lot of folks have heard something similar to that before. This dude, Steve Jobs: "It's not process, it's content." That doesn't mean we don't have process, but that's not what it's about. Hard to disagree with that, right? Of course there's going to be some degree of process, but let's not make that the thing.

[00:06:48] Reed Hastings says that the reason Netflix has been so successful is because it has a culture that values people over process. People over process, folks. It sounds great, right? It's a great idiom. It sounds perfect. It makes you sound like you can just trust your folks to never work in some period or state of lack of alignment, or with competing or conflicting incentives, and everything works out just right. We're going to hear that that's not always necessarily true, particularly at scale, when you have multiple teams all trying to do that.

[00:07:19] And lastly, this one's a little bit more important: process is great when you live in a world where both the problem and the solution are known. Now, in a lot of the work that we are doing today, and I mean we collectively, all of you folks (not knowing what the heck you do, but having a pretty damn good idea), we are not necessarily just building widgets along an assembly line. A lot of the work that we do does have degrees of ambiguity. It does have degrees of complexity. It does have degrees of not knowing if what we are doing can be usability tested to value. That's the sweet spot that we want to start thinking about.

The double diamond and the design squiggle

[00:07:53] When we think about the typical process that we'll try to use today, I'm fine anchoring on the Double Diamond. A lot of us, I'm sure, are familiar with how this works: going from the problem, to better understanding it, to then, now that you know what the problem is, proceeding on through to the solution. I definitely have beef with this. Peter Merholz just recently wrote an article that was saying, "Hey, in enterprise design, let's all agree that we know what we're going to deliver." It's rare that we just say, "I don't know what we should do. Maybe we should go try to figure something out." There's usually an intent when that project starts, and that sometimes makes seeing the model as absolutely accurate problematic.

[00:08:34] How many folks have seen the infamous design squiggle, trying to replicate what the product development process or the design process looks like? A lot of mess up front, trying to get closer to certainty as the process evolves. We go through that Double Diamond phase where the messiness is supposed to be at the Discover phase, and then by the time you're getting to Deliver there's a lot less ambiguity, there's a lot less chaos. Again, I could put my kids to sleep at night telling that nice bedtime story, right? Instead it's usually like this: a lot more compressed, and you still have a lot of that angst, a lot of that turmoil, throughout the whole thing. Rarely is that straight line nearly so straight.

[00:09:16] And oftentimes where that comes through is where there is what I call a rudderless product development process, where we are looking for certainty where there may be none, or where we may not even have a point of view of what we are trying to do with this thing, where we don't necessarily know what questions to ask. We haven't even chronicled the assumptions that we're making when we're trying to start this work. All the way through delivery, where we are overemphasizing deadlines, oftentimes by dates, where we don't necessarily know what the design team is going to be making, or does the engineering team know what design is going to be producing? And not necessarily a culture of iteration, where we're like, we only get one chance, and if you screw it up then the funding goes away, and all of a sudden you've got a project and you go shopping again.

Assembly-line management and a systems alternative

[00:10:04] And a reason for a lot of that is a lot of these old white dudes. This is Adam Smith and Frederick Winslow Taylor and Peter Deming. Is it Paul Deming? It's Deming, I know that part. He's actually a really, really accomplished management writer. I'm just blanking on his name. What's that? "In God we trust." Exactly, there we go. W. Edwards Deming. All right, there we go. See, I like a good call and response. It keeps you folks engaged, instead of being like Homer in the pillows, right? I should have just said, "Well, which one's Adam Smith, folks?" Go multiple choice. But anyway, these guys all operated, obviously, decades if not centuries ago, where work and labor were trying to identify and maximize as much efficiency as possible, where you were going to try to extricate as much unknown as possible throughout the work process.

[00:11:08] If we were to think about how product development leaders today anchor on some of those traits of the scientific method of assembly-line product development, what we probably see (not Paul or Peter Deming, but W. E. Deming) is fixed goals: the specs must be heavily documented, where you're trying to explain everything. We'd be looking at fixed tasks, where we're going to have rote methods every single time, because come hell or high water we are going to have wireframes in this project. We'd be talking about fixed deliverables that may not necessarily change when your work is underway, where you could absolutely learn something new tomorrow, but because you wrote a plan a month ago, you've now got to craft some type of artifact to deliver that. And it's always emphasizing the predictable. This theme is going to come around a couple of times.

[00:11:55] And ultimately, the way we oftentimes try to measure success here is things like: did the boss like it? Did it meet all the requirements? Did we hand it off on time? And, personally my favorite, did dev have to make changes? Nobody cares if they actually built the right damn thing or not. It's, did somebody have to go back and do more work at the job they're being paid to do?

[00:12:14] Amy Edmondson of the Harvard Business School really called out this type of behavior and these types of expectations and these attitudes, when she said that most managers have been either explicitly or implicitly trained to think in terms of accomplishing fixed goals, fixed tasks and deliverables in this predictable world. And then she goes on to say, basically, that we're not in that world anymore, folks. We need to try to figure out how we can embrace process without over-indexing on that predictable mindset.

[00:12:47] If we started to think, well, what type of framework could we apply here, that's when we look into systems thinking. These attributes are from the UnSchool of Disruptive Design, led by Dr. Leyla Acaroglu, where she talks about interconnectedness, balancing isolation versus relationships, in this new way of working. And we could apply the same type of work to her: what if we had her as a product development leader? We could say that emphasizing a clear vision and North Star would be more about that interconnectedness: how are we not just having blinders on, looking for one thing all the way through? Embracing emergence: learning something new that we did not expect, seeing when two things put together are going to create something different than we expected. How do we adapt to that?

[00:13:34] Ultimately, what we can do is think of determining success by: does it create impact? Did it create positive business value? Did it create potential user harm that was unexpected, that now we have to immediately take action on, to prevent it going even deeper or even wider? What do we need to know now that we didn't know, and where else can we be driving change?

[00:14:00] When we're thinking of that type of process, now we can start to see that yes, it's still a process, and yes, it's still based on that slightly problematic Double Diamond, but good enough. What we can see here is that it's still possible, even at the Discover phase, to have clearly defined hypotheses, or to be intentionally looking for a signal that will give us conviction to commit to going to the Define stage. All the way down to the Deliver phase, where we know why we're doing this, where we know with intentionality what is coming and why it's going to be useful and what we can do with it next. And folks already have an understanding of how it's going to be measured and what we're going to do with those measurements as they inform future product development.

[00:14:43] What we'll also see here, when we compare them side by side, is that it's really pretty stark. I don't need to drain this slide and read everything to you. This is what I meant: this is why you want to save these for later. But ideally what we're seeing here is that for every problem with an ineffective process, there is still an opportunity that process unlocks that can elevate that maturity. You can start behaving, acting and embracing the behaviors of that more modern product development environment.

[00:15:14] If we wanted to think about where we could change, we want to think, when you go back to work tomorrow or Monday: where are those moments of unpredictability that you have not been able to lean into? Where could possible artifacts give some moments of clarity, of a shared point of view, where you say, "Okay, now I get that. Now it makes a little bit more sense"?

Discover: role clarity and paired briefs

[00:15:41] Let's get into part two. This is where we're going to talk about some of the things we can do, some of these artifacts. If we think of the Discover phase as that very first step, where we want to talk about arriving at a hypothesis, or perhaps starting to see if there's a there there with a problem worth solving, first off, one of the better things to do is just establish role clarity. Who's going to do what? Let's not get as focused as a RACI. We're just talking about: what is the scope of research, what is the scope of design, how much is product going to shape this? And then trying to capture that in writing, in a pair of briefs, a product brief and a design brief. We have found that this gives a lot more of that clarity up front, sooner.

[00:16:24] What we have seen here is that having product write down some of their intentions, around why this problem is worth solving, who it's going to be for and how we're going to measure success, is a great opportunity to apply some focus, so that design can then have their own answer. And the design brief in my organization is oftentimes much longer than the product brief, because the design brief is meant to ask a heck of a lot more questions. It's supposed to poke a lot of holes in that product brief, where there are those assumptions or those generalizations that designers are probably going to have to work through before they finally come to their ideal solution.

[00:17:05] In practice, what's been interesting to see is that the teams that hesitated to take those steps, to write down what they were thinking, generally had less conviction in their design decisions. They folded when challenged with, "Why do we do it that way?" And they oftentimes operated with less certainty in a lot of their work. They'd say, "We could do more explorations, we could decide to talk to more users, I guess," because they didn't have a firm foundation upon which they were standing. Likewise, by having product and design write these together, we got a lot closer to seeing how this could benefit. There was a lot less ambiguity that created more meetings.

Define and explore: working in context

[00:17:49] When we think of defining these phases, we've tried to set up Figma boards where a lot of this work is all happening in context. This is super useful too, because designers have this info front and center, as do our product partners, as do our business stakeholders, as do engineers, and they're able to see the work starting to emerge, instead of these big aha moments where you just say, "Oh yeah, and then this is why." This is also helpful because we're ensuring continuity with those design briefs, because a lot of that info is now repurposed there, but that's where you're doing the work. Likewise, the types of questions that product, engineering and business stakeholders are asking are going to advance the project more, because they're not getting keyed on some of the things that wouldn't be as helpful. They understand the altitude and the context appropriate for their question, instead of just saying, "Well, why is this blue, or why is this over here?"

[00:18:50] In that exploration phase, what we're looking for is that intentionality of not overcommitting too soon to what we think we need to do. What I want to show here is basically how we are keeping context in mind: what is the current state, what are the solutions, and then what are the benefits of that work? Because what we're trying to show here is practically a dialogue about why we're doing what we're doing and how we're delivering it, instead of, "Oh, here's a Figma link, go check it out." Because that is where you start to get into a lot of ambiguity. People then don't have the focus or the direction around what to even say. They don't necessarily know what altitude they're operating at, and they run the risk of commenting on the wrong thing. And then designers are at risk of over-indexing on that, not to slander it, but inappropriate feedback that's not going to be helpful.

[00:19:45] In practice here, explicitly framing those problems and how the design work is solving them is going to help create a lot more of that clarity downstream. Likewise, as I was just mentioning, by more tightly coupling it, you're going to see better understanding across these teams, without having to just create more meetings to get it done.

Deliver: structured files and managing change

[00:20:09] Lastly, in the Deliver phase, what we're going to see here is super simple. This is stuff that surprises me that we haven't been doing in the design industry for a long time: just talking about how we're delivering files. We've tried to take the step at Northwestern Mutual of deliberately structuring how our Figma files are delivered, so that engineering and our product partners know what to expect. What we're seeing, by just shaping this up, because we have a lot of design teams here, is that designers are spending more time in Figma instead of more time organizing Figma. We're also seeing that we don't have to think about, "Well, what should I name this, or how should I do it this way for this team?" And lastly, we're seeing that product and engineering know where to look. When they come into those files they don't have to reorient themselves every time, especially if they just changed teams and they're like, "Well, this one team did it this way. Now I don't know where the heck we're looking this time around."

[00:21:10] I left you a couple of questions you could start to ask some of your teams, to see if any of this resonates with them. When we think of change management, we don't want to create too much change at once and overwhelm your teams. We don't want to be trying to solve everything in one day. That's oftentimes my risk. I have a strong bias to action and I love trying to create this change. But some of this you have to take bite-sized and piecemeal, and say: what could get us the most impact? But sometimes it's also what's going to be our first quick win, without over-indexing on just what can be.

[00:21:49] And lastly, if your teams are absolutely stagnant, if your teams are absolutely comfortable, what you can do is create that sense of urgency by showing what's not possible. You want that design system we heard about earlier today? We can't do it, because of this, this and that reason. You want AI here? Well, our engineering team is going to need to know a heck of a lot more about what we would be putting in those models, and we don't have that level of clarity yet. All right, I think we're about at time, so I'm going to cut it here. We good? All right.

Q&A

[00:22:26] Host: All right. I mean, so much ground to cover there. We have Adam Smith, the Double Diamond and change management.

[00:22:37] Chris: I bring the show, man.

[00:22:41] Host: No doubt. I don't think anybody was arguing that. Wonderfully academic, which of course we appreciate. Apparently there are no unanswered questions, which makes me feel a little nervous.

[00:22:55] Chris: You're nervous? I'm here, buddy, in my seat, nervous.

[00:23:01] Host: No offense. Wow, where to take that one. Well, I'm just curious: of what you showed, what would you say was the biggest surprise to you, before you went down the path that you went down and what you showed us?

[00:23:20] Chris: General chaos. The degree of chaos that some of these teams think of as normal, I think, is the general chaos. Well, not just in the world, there's plenty of chaos there, but in teams: joining a new team, or seeing how one team operates differently from another, and the degree of chaos that is accepted as just going to work. I think it never ceases to surprise me. That is the benefit of working at a million and one places in my career: I've seen that some of this stuff can be a heck of a lot easier, and folks are just used to it being hard.

[00:23:55] Host: I had to double-click, because general chaos sounds vaguely specific and specifically vague. And I'm right there with you in terms of patterns and trends that play out. What's really interesting about your presentation is if I put it next to where we started, with Richard Dalton. We have the thought of scaling silos, and many, many teams operating, hopefully not 100% independent of one another, but trying to go micro to macro for that. I'm sure it's a challenge.

[00:24:30] Chris: Well, that's some of what these tactics have tried to address. When we talk about those design briefs, one of the things they are super useful for is trying to see what other teams are doing, because now we have some degree of format where we can say: has this been solved before? Have we looked into this? Has another team tried this already? And then to look back at what they wrote and say, "All right, it looks like there's something there that we should try to reuse, adapt, learn from, take advantage of." Because when you have these different design teams... Again, it's not a problem at a five-person startup, but once you start working on two different feature sets or two different users, that problem can start on a 10-person design team, let alone a 100-person design team that is supporting multiple business units, multiple functions and so on.

[00:25:22] Host: And in all clarity, no one on this stage, regardless of jacket color, is saying that a five-person startup doesn't have challenges or problems in and of itself.

[00:25:34] Chris: No. In fact, that's where even starting to add a little bit of intentionality to that process can start to create a lot of downstream wins that people probably didn't even know they were missing. They're saying, "Wait a minute, if I just declared what the heck we want to do, if I just said what problem we are actually trying to solve, or what our assumptions are..." When confronted with it downstream, you have firmer ground to stand on than if you're entirely surprised. Setting up the environment to be surprised is a heck of a lot more useful, and a heck of a lot more of an opportunity, than when you're just straight up surprised and you're like, "I wasn't expecting that." But if you create the ground or the conditions, and your team is expecting, "Well, we don't know about this, so we're going to run an experiment, we're going to run a pilot, and we're going to heavily check this, or we're going to do a heck of a lot of observation and research, and this is what we don't know we're going to hear," then you're starting to get away from what we were hearing about, that expectation of predictability, which is where we don't want to go.

[00:26:40] Host: In a way, our jobs would be a little boring if we didn't have changes and surprises on an ongoing basis. Do you feel like the creative brief helps with the bias toward action and being proactive around those changes?

[00:26:58] Chris: Yeah, absolutely, because what it's setting you up with is what you know at that moment in time. It gives you something to look back on and say, "Well, was I right about this? Did I miss the broadside of the barn on that, and now I have to take additional steps to recalibrate and say what we have to do?" It's helping you be more prepared for what you don't know is around the corner. When we think of predictability, we can have predictable methods without predictable outcomes. Oftentimes where process gets caught is that it's thinking of predictable outcomes. You expect delivery this way, or you expect these types of results, you expect these types of metrics. That can get you into trouble real quick, because that's when you start locking down innovation, because you have to be safe. But when process means we are going to declare our hypothesis, and then figure out ways to learn, and then decide if we're on the right track, that's a heck of a lot different.

[00:27:54] Host: Love it. One final question, which is: when it comes to a team that's been knowingly chaotic and has very little process, how do you enter in and introduce it? How do you make sure that it has fertile ground?

[00:28:12] Chris: A couple of things. We started to touch on it at the very end of the talk there. You could decide what could have the greatest upside, or what would have the least resistance. The least resistance may be something like how you're going to organize your Figma files, because if you're a design leader and that's your problem, you can mandate that. You can say, "All right, design team, this is the way we're going to do it." Or you could say, "We're going to have a workshop, and we're all going to come together and figure out collaboratively what the best way to do this is." But that's not going to require a heck of a lot of buy-in, how the Figma files are going to be organized.

[00:28:47] Chris: But if that's not the problem, if you wanted to go to your product management team that is a peer to you, or perhaps you're in some type of misleveled organization where the head of design is two levels down from the head of product (happens a lot), that's going to be a tougher conversation: "I want your folks to start writing down what they think the problem is, and not just giving me features." You've got to have some social capital in that org to have that conversation successfully, because otherwise they're going to be like, "It's cute, bro," and they're going to scoff and say, "Things are working just fine. You just tell your designers to keep building what we're telling you to build."

[00:29:19] Host: Yeah, I'm sure no one in the room or online is at all triggered by that whatsoever. Sorry. Chris, thank you so much.

[00:29:28] Chris: Thank you very much.