Implementing Product Process Change in a Mature Organization

Chris Avore at UXDX EMEA. Video: https://youtu.be/qlXTQEIncJQ

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.

Implementing process change to mature your organization

[00:00:08] It's going to be a killer experience. We're going to talk about implementing product process change in a mature organization. I started thinking about that and I was like, if I tweak these words a little bit, I might be able to make this a little bit more interesting for some of you folks. What I'm going to try to talk about instead is how to implement product process change to mature your organization, instead of assuming that your org is already mature and operating at a high level of sophistication. Now unfortunately, we're going to go right to our live stream and show exactly what our crowd thinks of this shift. Hopefully we'll be able to keep you all up.

[00:00:46] As Alex will say, my name is Chris Avore. I now head up design at Diligent. Previously I have led design teams at Northwestern Mutual, Meta, NASDAQ, and then also wrote the design leadership book Liftoff. Some of these slides are going to get a little wordy, and so in advance of that I wanted to put up the ability to download this deck, so that way you have it for reference and you're not having to hold your phone up all the time. I'm not going to try to read every single syllable from the top left to the bottom right, but this will give you something to be able to take home and maybe put to use sooner than later, before they're released. Hopefully that will also alleviate some of the stress if you're seeing walls of text.

[00:01:29] What I want us to think about today is: what if we better understood all of the type of details or questions or assumptions when we are starting a new project? What if we had a greater awareness of what other work has already been done or might be underway? Or what if we had a better understanding of what our stakeholders actually knew about the project versus maybe what they said they know? And then any type of status reporting that we were talking about was actually going to be useful and applicable and give other teams a heads up of where we were at and where we were trying to go.

[00:02:07] This goes even further. What if we said something like, what if designers could operate with more intentionality and deliberate purpose while still being trusted to work independently, where they're not trying to go all hovering art director on us and moving our hand along with the mouse? Product managers were connecting their features and their targets and their goals to more corporate targets instead of just trying to tell us what features to build, if we're designers. And engineers felt like they could apply their product and business expertise early, when it can make the most impact, instead of just being brought in at the end and saying, hey, this is pretty hard to do actually. Now that all sounds great, but what if we could do it at scale? What if we could do that across teams, and what if we could do that across the entire product portfolio, and over time?

[00:02:55] When we think about that, we start to say, well, who the heck's job would that be? And we say, well, is it the design ops guy? Is it managers? Is it the executive manager? It's hard to tell. The simple fact, though, honestly, is that it's going to be everybody's job to pull this off. It's also going to require a lot of collaboration and partnership to be successful. It's not going to be one person's job or title to try to execute this type of change. It's also going to include recommendations that may take time to actually get working. This isn't necessarily a bunch of things that you can turn on right away and get people to adopt those changes and start seeing impact.

[00:03:38] To be aware of that, we're also going to have a degree of difficulty in measurement right away. A lot of this stuff we'll see, as we just heard about, as lagging indicators that things are getting better, instead of immediately trying to trace back causality to saying this is actually the biggest thing that we've ever done that's going to make a huge difference in the way we work.

[00:03:55] So let's ground ourselves with a hypothesis. Let's start to say: if we were improving key moments of the product development life cycle with structured, consistent artifacts and activities, then teams should be operating more effectively and efficiently, which will create more opportunities for innovation, sustained growth, and ultimately increase enterprise value. All right, that's the bedtime story I'm going to try to tell you all. Maybe we'll actually get something legit out of it.

[00:04:25] The things we're going to talk about today: we're going to talk about why process gets a bad rap. We're going to talk about the activities and actions you can put to work throughout that life cycle, and then how this emphasis on process will yield tremendous, hopefully, upside to the broader company's goals, and makes you look like a high performing operator who's willing to cross swim lanes, titles, responsibilities and teams to be able to get stuff done.

Why process gets a bad rap

[00:04:52] Let's start off with why process gets a bad rap. We've seen that the process can become the thing. The process is not the thing. Do we own the process or does the process own us? We've seen Jeff Bezos say that more than once. We've also seen Reed Hastings say that Netflix has a culture that values people over process, emphasizes innovation over efficiency, and has very few controls. This is all true.

[00:05:19] And then as product development professionals, we've also probably seen a lot of procedural diagrams that look like this, that try to break down the product development process into a lot of discrete steps that usually we try to model in our own work, ranging from how to design the right thing to designing the thing right, a nice pithy phrase that's probably been out for at least over a decade. We've also probably seen other types of models trying to reflect the product development process that look like this, where there's a lot of mess, and then as we continue to iterate on that mess we get more certainty and conviction, and then that subsides and then we have a more predictable operating model. You can see it: this would go discover all the way through deliver, just like the Double Diamond.

[00:06:06] However, I think in practice it usually looks like this. Discover is done by, usually, the big bosses. The define phase is usually done maybe by product management being told what to do by those bosses. And then the deliver phase is a combination of starting with design, handing over to engineering, and then nobody wonders why some of this stuff doesn't work.

[00:06:28] When we think about the symptoms of an immature product development process, when we think of what happens as a result of that fragmentation across the product development process, we can start to see some things that probably might feel a little familiar, maybe some things that we've seen either in our current roles or perhaps in prior jobs. In the discover phase we might have a lot of confirmation bias, where research is only going to be applied if it actually suits what the big boss wanted, and if the researchers come back and say, yeah, that's probably not a product need, that big boss says, well, go research more until it does.

[00:07:07] If we go all the way through the delivery phase, it's all deadline driven. Let's just throw a dart at a calendar date, and bam, that's when we're going to have all this stuff done, instead of trying to say, what are we going to learn while we're going there? What are we going to learn now that we're there? How are we actually going to execute on this? Teams rarely know what's around the corner or what's next. These are all problems that, heck, how many folks feel this way in some of your roles? I definitely do, still. I absolutely do, and I have, and I'm supposed to be trying to fix this stuff, so maybe I say something about my effectivity.

[00:07:39] Where this comes from, though, I think this emphasis on, where this desire for control, where this desire for predictability comes from, Amy Edmondson mentioned this from Harvard Business School when she said most managers have been either explicitly or implicitly trained to think in terms of establishing fixed goals, fixed tasks and deliverables in that predictable world. Part of that problem, of course, then, is that we all know that that's not really the world we're operating in anymore. The fundamental mindset and skills of management work best for fixed, understandable, reasonably predictable deliverables, but that's not us anymore. That's not the type of work we do. That's not the projects we're trying to work on anymore, and that's not the world we live in.

[00:08:24] As a result, we're going to need to evolve our mindset to embrace the ambiguity and the complexity of the unknown, and do it in such a way that we can make some things predictable, so that we then free up our time as product development professionals to do what we're actually good at: to be able to actually try to solve more of those gnarlier problems, wade into that ambiguity, untangle some of that complexity, or at least be able to put our arms around that complexity and make better decisions.

What a strategic, outcome-focused process looks like

[00:08:53] So then we can think about that as if we were to say, well, where are we trying to go to? What would be the benefits of a strategic, outcome-focused product development process instead of that fractured mess that we have all seen before? At the discover phase we'd be seeing clearly defined intent, cataloging what those assumptions are, where there could be risks, what we can do about it, the way we might try to solve this problem, and how we're going to learn about if we're heading on the right path or not.

[00:09:22] When we get to that define phase, that's when we're going to be having a clear framing of what we are going to work on, so the engineers know what's coming, design knows what's coming, product knows what's coming, bosses know what's coming. We all have that clarity and alignment of what we are all about to embark on. At the exploration phase we're going to have ways to tailor what we need to. We're going to have ways and methods of finding out what problems we need to solve throughout that process, instead of just saying, well, we've only got these three ways to solve this and then we hope for the best. And then lastly, in that delivery phase, we already have plans in place where we can see where we can be measuring the effectiveness of our decision-making. We'll be able to see if our answers or our guesses are accurate, or if we need to go back to the drawing board, or to what degree we need to go back, where we need to iterate next to try to find some of that improvement.

[00:10:16] So now let's go into changing how we work. Let's go into part two of this, and this is where we're going to get into more of the details about how to try to put some of this into practice. We're going to break down those steps between discover and define and exploring and delivering, where there might be steps that we could start to take that can start to create more of that maturity when we are working together in our teams.

Discover: role clarity, time constraints and briefs

[00:10:40] Essentially, at the discover phase, if we are trying to establish tighter and more clear role clarity around who's doing what, what teams are doing what, and also so that other people know exactly what's going on, we're going to see a lot bigger uptick in productivity. We'll also be setting constraints for how long that discovery process is going to take. One thing that I think I've seen firsthand a lot is bosses get nervous when we say, well, we don't know the answer to this yet, and so we need to go do research, and yet we're not necessarily putting some type of limitation on what we need to do, and then it turns out sounding more like a fishing expedition.

[00:11:19] To continue that fishing expedition metaphor a little bit further, you still need to know what size boat you need, and you still need to know what type of rig to bring out with you, what type of rods, and you still need to know what type of bait to bring out with you if you're going fishing. You just can't hop in your boat and say, well, I hope I catch some fish. So on the research side, we still need to be able to say this is going to take us a month, or this is going to take us two months, or once we have learned this, or once we have heard this pattern repeated about this number of times, we can start to have some certainty and conviction to start to consider leaving that discovery phase.

[00:11:52] One of the things that we've tried working on that I think is really adding to the accountability of teams trying to document the discovery phase is having product start authoring epic briefs and having design teams be authoring design briefs, where we're trying to actually get teams to write down what they think they know, to call out what they do not know, and then where there might be risk in those gaps. And then design has the opportunity to be able to say, well, you actually missed a handful of things and we don't have enough yet to be able to start, or if we do, we're not going to have certainty or that conviction to be able to actually do some of this until we get more info. So then you can start to say, well, how do we get that info then?

[00:12:38] Here's a sample of some of the product and design brief topics, themes, attributes, headings, whatever, of where we have tried to pull. Now, not every single one of these is always important to every single project. However, by starting to write down some of these things, that's where you'll start to say, man, I actually didn't know that, or it turns out that even though I knew it, so I wrote it down, my teams did not. My partner teams were not aligned with some of these points of view, and now they're at least aware of it, and now we can try to take steps to create more of that alignment that we need if we're going to move forward together.

[00:13:15] So if we're going to try to summarize our discover phase, by adding that documentation stage, where designers are trying to author their own brief in response to some type of product requirements document or some type of epic brief or something like that, designers are going to be showing up as better partners, because they're going to have more skin in the game and they're going to have had their point of view shared. And then we're also going to be able to identify that lack of alignment across teams a lot sooner and allow you to course correct.

Define: prioritization, assumptions and context for feedback

[00:13:50] When we move into the define phase, what we're going to see here is how to conduct clear prioritization. We're going to see where to challenge and validate assumptions that we're seeing in discovery, and then be able to see how we might try to work our way through that ambiguity via multiple low fidelity renderings. We want to be able to be intentional by saying this is what we need to try to work through, instead of just saying, well, I'll just hop right into Figma and start banging stuff out. And then we'll also be able to be a better partner to our engineering teams by bringing them along with what we think we may be trying to do.

[00:14:25] Now, the way we've tried to solve this problem before is by trying to keep a lot of, we'll call it metadata, or the attributes of the work we're undertaking, when we are trying to plan out the types of research or the types of low fidelity explorations we're going to be doing, so that when we go get feedback from our partners, from our stakeholders, from our leaders, they're going to have more of that context front and center. They're not going to be necessarily asked to react to just a document where it's a bunch of rectangles pointing to another box of rectangles. They're going to have better understanding of what types of assumptions we're having to make to get there, or where we may not have that certainty or clarity, so that they can weigh in, and they're going to feel more included and like they're a more valuable partner to being able to actually contribute to the project as well.

[00:15:16] So to summarize that, we are going to be trying to get more of that clarity and that focus right from the beginning, right when teams start getting together. And then you're also going to start being able to gather more appropriate, timely feedback that's also at the right altitude. You're not going to find yourself having the big bosses say, well, why is the button on the right instead of the left, when you're trying to find out if there's a button that needs to be there at all.

Explore: multiple options, traceability and linking to current problems

[00:15:40] When we start thinking about the exploration phase, what we want to do here is be sure that we are not committing too soon to what type of fidelity is necessary. We want to be able to expect our design teams to be providing multiple ways to solve that problem, so that we're not overly fixating on an early solution too soon that's not taking into account some of that ambiguity or some of that complexity that could totally derail the project. We want to also have some of that traceability back to the design and product brief, where we're saying we're doing this because we said that we think this point of view is over here.

[00:16:17] That is really going to create more sophistication in your practice and in how you show up, because now you're showing that you are conducting essentially intentional practices. You're operating with a degree of deliberateness, that designers aren't just opening up Figma and then starting to put shapes all on the screen and then saying, so what do you think, boss? You're trying to say, no, this is not notional work. This is actually professional thinking here that's going from concept to realization.

[00:16:44] And so to do that same type of thing from that definition phase, what we are trying to really show is what is the context in which this feedback needs to be gathered. What are the challenges? What are the struggles? What is the before state? What is the after state? This also will continue to help identify more of where there could be that lack of alignment, and you can snuff that out sooner, by linking that work to the current problems, by saying this is where it's breaking now, so that you could show, whether it's a screenshot, an animated loop or a quick video, this is the problem here that we're going to be fixing, so that it's alongside the way you're fixing it. And then also providing multiple ways to try to actually get that problem cracked will also start to mature that product development practice as well.

Deliver: standardizing how work is packaged and handed over

[00:17:36] So lastly, now, our deliver phase. This is where we're actually trying to get that work into the hands, across that finish line, in that last mile. What we want to be working on here also continues on from a lot of the documentation and the way we're trying to put a lot of this work together, so that folks know what's going on and when it's going to be resolved. We want to be highlighting the certainty and the ambiguity in the prototypes and the mockups. We want to be able to call out, this is why we still don't know this yet. We also want to be partnering with our engineering, product and design partners to establish how to deliver that work. We want everybody knowing exactly where work is going to be found, what type of state it's going to be in, and what's actually ready to be worked on. And so that way they're going to start better understanding what's scalable, what's easily actually updatable, when it's going to be ready, and when we can start trying to socialize that to our broader partner teams that may not necessarily be on every single update that we're trying to communicate.

[00:18:35] Some of the ways we've even tried to standardize this, and this may seem relatively simple, is actually something that I continue to see is still all over the place. This couldn't be as simple as just shaping up how you're going to be delivering your work, how you're packaging your work, even trying to create a set of standard Figma templates that are going to indicate who's who, the project, what you're trying to get out of it, what state it's in, and where it can be found. Where I've started to see teams say things like, well, I just do it this way because this way is fastest for me. Sure, that may be, but being able to tweak that process so that it's faster for everyone can make a big difference. Whether you're also even getting into color coding what means what, various states that it's in, various stages of reviews that it's in, you're going to find that solving this once is going to solve it for everyone throughout the future.

[00:19:34] There's some other advantages to it too. By starting to standardize how you're delivering work, you're going to create more interoperability between your teams. For those of you who work in larger organizations where you have designers working on project A and you have designers working on project B, and maybe they would never even talk about what they're doing together, you'll be able to assign someone from A to B and get them up to speed a heck of a lot faster if you're all operating at least in relatively similar cadences, methods and approaches, so that they're going to be more productive sooner than if they had to relearn an entirely new way that happened to just work for that design leader who started that process.

[00:20:13] What's also important, though, too, is to not necessarily take, especially for the engineers or for the designers in the room, an overly design centric approach to how you're delivering work, because once you've delivered that, it's not really just yours anymore, if it ever was in the first place anyway. You should be trying to talk to your QA teams, talk to your engineering partners, to say, what's missing from this process? Where are you still hunting for things? Where are you still doing things that perhaps we could probably iron out with a little bit more communication or a little bit more alignment, so that you're getting up to speed faster than my guys in the way we have been doing it previously?

Crossing the chasm from what if to so what

[00:20:50] So if we wanted to think about what we could start doing sooner than later, we could ask ourselves a number of questions that could start to see where we might be on this spectrum of maturity. We could start thinking about: do we know how design decisions are made? Do we know how and when minds are changed? Do we know what people need to expect, and when? Do we know if we think that this has gotten any better or worse over time? So now that can predict, or at least prepare us for, going from what if to so what.

[00:21:30] Because right now this feels like where a lot of us are. This is a chasm that we somehow have to cross to get to where we need to be. We've talked about some of those attributes. Right now we may feel like things are top down and inflexible, or there may be multiple meetings to do the same things, or duplicate work across teams, or solving one problem five times in the course of a year across different teams. Whereas what we're trying to do is get to mutually aligned outcomes, where we're trying to have effective documentation that actually supports a project instead of just more talk, talk, talk, talk, talk about the projects.

[00:22:11] So we need to think about how we can create that bridge from one side to the other. This is when we get into, I mean, we could do a whole talk on change management, of trying to improve maturity. But I think what we could try to think about is: do we have a solid vision of where we're trying to go? Do we have a better understanding of what good could look like at the end of this journey, when we have crossed that chasm of immaturity and now we're operating at that higher level of maturity, and now we're actually able to see the types of outcomes and improvement that we want?

[00:22:46] It's also important not to try to overwhelm everyone by trying to do too much too fast. The good news is, a lot of those steps that we were talking about, about those product briefs and about trying to frame more of your hypothesis next to the work, trying to show multiple ways to solve the problem, that can actually be a little bit like, y'all remember the 80s Karate Kid movies, where Daniel-san gets frustrated that he's waxing the cars and sanding the deck, and he doesn't realize that he's doing kung fu the whole time? It's like that. The more you're trying to do some of these things, people are going to be like, oh, these teams are writing a little bit more down, they're actually calling out some of their questions a little bit more. And then at the end of the project, or maybe midway through the project, they're like, wait a minute, things are actually a little bit different, things are a little bit better now. And so you're not necessarily saying, hey bosses, I'm going to do all of this differently starting tomorrow, let's go. By pulling them along a little bit more slowly and being able to see more of that change, you're going to see a lot more success in those little steps that will all add up over time.

[00:23:51] However, if nobody's buying in, then it's time to start to create that sense of urgency. That's when you start to want to call out what is not available, what is not possible, based on the current operating model that you're working in right now. If you're saying, hey, look, you keep saying AI, but we can't even ship a standard three-click workflow without something falling over. How are we going to be able to do that if we're operating with this degree of inefficiency in our teams? Or we're still solving the same problem that last year's team worked on, and now you still want to build a time machine? That's just not going to be obtainable.

Predictable questions, unpredictable answers

[00:24:31] However, there's still going to be skeptics with this. There's still going to be people saying things like, 100% predictability means 0% innovation. They're thinking that predictability is full on the assembly line, the Frederick Winslow Taylor, Henry Ford automation of, I need to know how many widgets are getting made, I need to know when those trains are running, and I need to know when those trains are getting to the next station.

[00:24:59] However, I would encourage you all, folks, to think about it this way. With predictable artifacts that we are calling out in those briefs early and often, where we're saying these are the types of questions we're going to be asking and these are the types of signals we're going to be looking for, we'll end up having unpredictable content. We'll have unpredictable answers to those predictable questions. In those predictable questions is where we will find those unpredictable answers.

[00:25:31] When we have predictable ways of working, when we know what teams are going to try to do research, when we know that we are going to have methods to be able to address that complexity and the ambiguity, we're going to have unpredictable results. And by striking a balance between the predictable and your ability to navigate what is still unpredictable, we're going to find out that our teams are going to find more success there. We're going to have a greater opportunity for teams to feel capable, trusted and empowered. Thank you, folks, and that is five seconds over. Thank you very much.

Q&A

[00:26:15] Host: Thanks, Chris, great presentation. Okay, we have lots of questions. At the top: as a product manager, how do you kick off this change to all of the members of the team, stakeholders, business owners, development team?

[00:26:28] Chris: Oh, have I got a good answer for Lucy. As a product manager, you probably hold a heck of a lot of sway. Usually the problem would be if this person was a designer saying, I'm trying to get my product manager to do this stuff. As a product manager, you probably have a heck of a lot of influence, where you could be saying, I need more documentation to be able to better understand the ambiguity of what we're about to face. So what I would probably do is try to not necessarily ask permission here, and try to say, hey, I'm going to need these types of questions answered. I'm going to do my best to answer three of these five, but I'm not going to have all of the answers. Who can help me? Document that, and then say, where else do we not necessarily know, or how confident are we in these responses that other teams have tried? And then when you're talking to your design partners, again, we go into that Karate Kid mindset. We start to say, well, could you put your hypothesis next to your mockup? Could you start to say where you need your actual feedback to be applied, where you have uncertainty or confusion around the work, so that you're starting to coach them up to be more intentional?

[00:27:34] Host: Thank you, Chris. Okay, next one from Sabina. As you navigate the process of implementing change, how do you identify what battles are worth the calories, and at what tables? My sense is there is only one table.

[00:27:49] Chris: Yeah, for sure. Honestly, this is when it helps to take a health check, or to do a retro of your biggest project, and what went well and what really went sideways, and deduce from there where you would want to create that change. That goes back to that change management and creating that sense of urgency. For instance, if the end product was great, but there was a heck of a lot of churn on getting the design team to finally break through and understand what the teams were working on, that's probably where you could zoom in, on all those notional or early stage designs that weren't really addressing the problem, and try to create some type of change there. I hate using the usual business metaphors like boiling oceans and crap like that, but usually trying to pinpoint where you want to change based on something that's already happened in the recent past, and a lot of those people are still on that project, so there's a good chance of it happening again, may be a good place to try focusing your efforts.

[00:28:47] Host: Cool, thanks, Chris. Okay, next one. Considering changing ways of working relies on various stakeholders, how do you anchor the proposed product process, who to engage, and who's ultimately responsible for the implementation?

[00:28:59] Chris: Well, who's responsible gets back to that Spider-Man reference, where everybody's pointing at each other. Ideally someone is going to be able to have a leadership voice there, whether it's a high ranking designer or a high ranking stakeholder, to say, yeah, this hasn't been good enough and we have to change. This could be better, and this isn't that painful to change. We just need someone to do it. And then that's when you try to get some of those short-term, early stage wins that don't create a lot of calorie burn, to be able to start to see that there is some degree of positive outcomes to that change. Also, finding some type of champion is also usually really helpful. Who else knows further up in the organization that there is disarray in the product development process? Getting them on board by showing how this process change can help support their political endeavors could probably also usually help really well too.

[00:29:56] Host: Nice. Okay, last question. How do you get stakeholder buy-in for low fidelity designs and concepts? In my experience, senior management struggle to visualize how a delivered solution will look.

[00:30:07] Chris: Yeah, this is pretty familiar. There's actually a handful of ways that I think can do this. In some cases, even sometimes low fidelity design is still too much fidelity, and we have to almost go to no fidelity. This is where we almost could go to note cards outlining the steps of what's the most important thing that the person has to do on the screen, so that we're trying to show some type of sequence without necessarily getting people to even think about buttons. This is when we think of artifacts like storyboards, or when we try to think of storytelling to walk through a hero's journey of where our user is trying to accomplish a goal, and the types of conflicts or threats that stand in their way to achieving that, so that you can make sure that you at least have a baseline understanding.

[00:30:55] Because we continue to see it. I mean, heck, people have been standing on these design stages for over 20 years talking about, oh, just do paper prototyping, or just do low fidelity so the bosses aren't focused on which shade of blue you're using on the buttons, and yet we're still having this conversation. So that's when we start to say things like, all right, just get out of it. Or perhaps you have a refined enough design system that is comprehensive enough that you can have the conversation and say, yes, that button is blue, but it's coming from our design system. We need to figure out where the button is going to be and what happens after you've clicked it, so that we can start moving on from these types of conversations.

[00:31:31] Host: That's great, thank you, Chris. Great insights. Round of applause for Chris.