Implementing Product Process Change in a Mature Organization

We're going to talk about implementing product process change in a mature organization. I started thinking about that and I was like, you know, 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. So 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.
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. 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.

The Vision

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? What if we had a better understanding of what our stakeholders actually knew about the project versus maybe what they said they know? And what if 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?
This goes even further. What if designers could operate with more intentionality and deliberate purpose while still being trusted to work independently, where they're not trying to like go all hovering art director on us and moving our hand along with the mouse? What if 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 what if 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? What if we could do that across the entire product portfolio? When we think about that, we start to say: well, who's job would that be? Is it the design ops guy? Is it managers? Is it the executive manager? The simple fact though, honestly, is that it's going to be basically 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 you can turn on right away and get people to adopt those changes and start seeing impact.
We're also going to have a degree of difficulty in measurement right away. A lot of this stuff we'll kind of see 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.

The Core Hypothesis

Let's ground ourselves with a hypothesis: 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.
We're going to talk about why process gets a bad rap, the activities and actions you can put to work throughout that life cycle, and how this emphasis on process will yield tremendous 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

We've seen that the process can become the thing - the process is not the thing. As Jeff Bezos asks, "Do we own the process or does the process own us?" 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.
As product development professionals, we've probably seen a lot of procedural diagrams that try to break down the product development process into discrete steps, usually trying 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.

The Reality of Product Development

We've also probably seen other types of models trying to reflect the product development process 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 we have a more predictable operating model. You can kind of see it - this would go discover all the way through deliver just like the Double Diamond.
However, 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 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.
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. 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."
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.

The Management Mindset

Where this kind of comes from - this emphasis on control, this desire for predictability - Amy Edmondson from Harvard Business School mentioned: "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."
The problem, of course, is that we all know 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 what our work is 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.
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.

Moving Toward Better Processes

When we start thinking about where we're trying to go - what would be the benefits of a strategic outcome-focused product development process instead of that fractured mess 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.
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. Engineering knows 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, 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."
RM
Yes

Implementing Changes

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 basically 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.
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.
To kind of 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."

Documentation and Process

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. 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 know, 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."
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 epic brief, designers are going to be showing up as better partners because they're going to have more skin in the game. They're going to be able 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.

Moving Through the Phases

When we move into the defined phase, we're going to see 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.
Now the way we've tried to solve this problem before is by trying to basically keep a lot of all of that - 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.
RM
Yes

The Exploration and Delivery Phases

When we start thinking about the exploration phase, you know 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. 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 deliberate purpose that designers aren't just like 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.

Moving to Delivery

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. Where we want to be working on here also kind of 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.

Standardizing the Process

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 could 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 on the project, what you're trying to get out of it, what state it's in, and where it can be found.
Where we've started to see teams say things like "well, you know, 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, what various stages of reviews that it's in, you're going to find that solving this once is going to basically solve it for everyone throughout the future.

The Benefits of Standardization

There's some other advantages to it too. Basically, by starting to standardize how you're delivering work, you're going to create more interoperability between your teams. So 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.
What's also important though too is to not necessarily take - especially for the engineers in or for the designers in the room - an overly design-centric approach to how you're delivering work. Because basically 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, like 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.
RM
Yes

Building the Bridge

So if we kind of 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 kind of this spectrum of maturity. We could start thinking about: do we know how design decisions are made? Do we know how when minds are changed? Do we know what people need to expect and when? Do we know like if we think that this has gotten any better or worse over time?
This kind of can predict or at least prepare us for going from "what if" to "so what?" Because right now this kind of 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 kind of talked about some of those attributes - like 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. So we need to think about how we can create that bridge from one side to the other.

Managing Change

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?
It's also important not to try to overwhelm everyone by trying to do too much too fast. The good news is about 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, you all remember like kind of like the 80s movie Karate Kid movies where Daniel-san gets frustrated that he's like waxing the cars and sanding the deck and he doesn't realize that he's doing kung fu the whole time?
It's kind of 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 like 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, we're actually - things are a little bit different, things are a little bit better now."

Creating Urgency

However though, 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 like "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."

Addressing Skepticism

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 just like "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."
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 "this is 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're going to find - where in those predictable questions is where we will find that unpredictable answers in there.
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 be - and we're going to find more success there. We're going to have a greater opportunity for teams to feel capable, trusted, and empowered.
RM
Yes

Q&A Session

[Audience applause]
First Question: "As a product manager, how do you kick off this change to all of the members of the team, stakeholders, business owners, development team?"
As a product manager, you probably hold a heck of a lot of sway, right? Like usually the problem it 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 kind of go into that Karate Kid mindset. We start to say like "well, could you put your hypothesis next to your mockup? Could you start to say like where you need your actual feedback to be applied, like where you have uncertainty or confusion around the work?" So that they're - you're starting to coach them up to be more intentional.
Second Question: "As you navigate the process of implementing change, how do you identify what battles are worth the calories and at what tables?"
Honestly, this is kind of when it helps to kind of 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 kind of 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 bus 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 - that may be a good place to try focusing your efforts.
Third Question: "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?"
Well, who's responsible kind of gets back to that Spider-Man reference, right? Like where everybody's pointing at each other. Ideally someone is going to be able to have a leadership voice there, right? Whether it's a high-ranking designer or a high-ranking stakeholder to say like "yeah, this hasn't been good enough and we have to change - like 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 too, finding out like - finding some type of champion is usually really helpful. Like 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.
Final Question: "How do you get stakeholder buy-in for low-fidelity designs/concepts? In my experience, senior management struggle to visualize how a delivered solution will look."
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 like 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.
Because we continue to see it - I mean heck, people have been standing on these design stages for over 20 years talking about like "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 "alright just get out of it" or perhaps you have a refined enough design system that is comprehensive enough that you could 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 stop moving on or so that we can start moving on from these types of conversations."
[Audience applause]
"Thank you, Chris. Great insights."