Finding Our Way podcast

#Tech #Arts #Graphic Design #Jesse James Garrett #Peter Merholz #User Experience #Design #Design Management #Design Leadership #Organization Design

28:39

For centuries, members of the B’doul Bedouin tribe lived in the caves around the ancient city of Petra, Jordan. Then, in the 1980s, the government forced the tribe to move in the name of preserving the geological site for tourists. But if the residents are forced to leave, and if their heritage has been permanently changed, then what exactly is being preserved? SHOW NOTES: Meet The Man Living in The Lost City Carved in Stone Jordan: Petra's tourism authority cracks down on Bedouin cave dwellers The tribes paying the brutal price of conservation “There is no future for Umm Sayhoun” Jordan’s Young Bedouins Are Documenting Their Traditions on TikTok Check out Sami's company Jordan Inspiration Tours Learn about your ad choices: dovetail.prx.org/ad-choices…

Finding Our Way explicit

Series home•Feed

UX design pioneers and Adaptive Path co-founders Peter Merholz and Jesse James Garrett discuss the evolving challenges and opportunities for design leaders.

56 episodes

Finding Our Way explicit

24 subscribers

updated 16 days ago

Series home•Feed

UX design pioneers and Adaptive Path co-founders Peter Merholz and Jesse James Garrett discuss the evolving challenges and opportunities for design leaders.

56 episodes

#Tech #Arts #Graphic Design #Jesse James Garrett #Peter Merholz #User Experience #Design #Design Management #Design Leadership #Organization Design

All episodes

Finding Our Way

1
56: Design’s Role in the Evolution of Product Management (ft. Sara Beckman) 57:46

16 days ago57:46

57:46

Transcript Jesse: Hey everybody, it’s Jesse James Garrett here. I wanted to let you know before we get into the show, we’ve got a special event coming up this week on Friday, March 28th, we are celebrating the 25th anniversary of the elements of user experience with a live 90 minute virtual seminar at 8:00 AM Pacific, 11:00 AM Eastern. I will be talking about the elements of UX in the age of AI. We’ll be looking at the connections between the history of user experience design, and the future of artificial intelligence. You do not wanna miss it. Peter Merholz will be there conducting live q and a. So please join us on Friday, March 28th. Get your tickets now at jessejamesgarrett.com. Stay tuned for another special announcement at the end of this show, but now on with the show. I’m Jesse James Garrett, Peter: and I’m Peter Merholz. Jesse: And we’re finding our way, Peter: Navigating the opportunities Jesse: and challenges Peter: of design and design leadership, Jesse: Welcome to the next phase. Joining us today to talk about what’s next for design is Dr. Sara Beckman, Professor at Berkeley’s Haas School of Business and longtime observer and commentator of the dynamic between design and business. We’ll be talking more about the legacy and impact, for better or worse, of design thinking, how design leaders should talk about metrics and how they shouldn’t, and what she’s learning from educating the next generation of product managers. Peter: Hi, Sara. Thank you so much for joining us. Sara: It’s a pleasure to be here, Peter. Peter: To start off, while I’ve known you for over 20 years, our audience doesn’t. And so I’m curious how you introduce yourself these days. Sara: It’s always a good question. I’m on the faculty at the business school at UC Berkeley, where I have, for multiple decades now, been teaching topics in design, innovation, product development, product management et cetera. I kind of hang out between two worlds there, between the College of Engineering and the business school. I was involved in starting up the Jacobs Institute of Design Innovation. So a lot of focus, I guess, broadly speaking, on cross-disciplinary work in the university, particularly as it relates to design. The ability to create new stuff, I guess. The Intersection of Business and Design Peter: Excellent. I’m going to dive right in to something I was thinking about literally yesterday, where I was attending a session, it was a webinar given by a design leader talking about the intersection, wait for it, of business and design… Jesse: ooh, Peter: And how it’s important for designers to understand, and to be able to speak in terms of metrics and stuff like that. And as he was talking, I was reflecting on work we did together over 20 years ago. So for Adaptive Path, you were kind of an advisor when we did a report on, at the time we called it, like, the working title was The ROI of UX, the official publication title is Leveraging Business Value: How ROI Changes User Experience. And the question I have is, why is it 20 years later we’re having the same conversation about how you connect design and business? Why doesn’t it feel like it has progressed? , Sara: Well, can I say something maybe a little provocative and say, Peter: Yes! Sara: Design Thinking got in the way. Jesse: mm-hmm Sara: So, 20 years ago, we were talking about, I’m going to call it real design. So, whether it’s UX designers, industrial designers, graphic designers, there was work that they did that we were trying to put value on. We were trying to say, if I make this product more usable, I can sell more of it, for example. So how do I make a connection between the deep work that designers are trained to do in design school, and the outcomes I can achieve with a product or service in the marketplace? Design thinking came along, and, in my opinion, it trivialized the work of real designers, I’ll call them, and we said everybody can do design and we had all these things going on that we turned design into, frankly, to some extent, soundbites. Oh, go talk to a customer and then design something cool and new. Nothing wrong with going to go talk to a customer. We kind of skip over a lot in design thinking the idea of actually getting insights out of talking to real customers and then designing to those insights. I’m put in mind of Barry Katz’ book on the history of design in Silicon Valley and how it evolved. First, started at Hewlett Packard, where I happened to work way back when, as really usability or user interface, right, design. And then as we moved into wrapping services around things, as we moved into software being the core of the delivery of capability, we migrated what design did, but design thinking was a whole different thing. And so was looking through your recent interview with Roger Martin and, thinking about what is design thinking relative to what design was about. Sometimes they call them little d and big D design. That implies one is bigger, better than the other. But we used to do that in manufacturing. It was big M manufacturing, which we thought of as manufacturing strategy and sort of the wrapper that went around manufacturing. And I think that was different than the actual execution of manufacturing processes. Somehow de-linked with design thinking, sort of the big D design stuff, we de-linked it from the actual actions of real designers. And that’s part of why people like Lucy Kimball talk about designerly thinking, as opposed to design thinking, because design thinking was a broader mindset and it left behind some of the roll-up-your-sleeves, we have real work to do here, because it made it seem like I could just draw a journey map and then design something, or I could just brainstorm for a bit, diverge, converge, and come up with something. No design process is that easy, right? I mean, you both know this from… Jesse: Right. Yeah. Sara: And so we left all that behind. Well, what’s the ROI of design thinking? First of all, nobody even knew what it was, right. I mean, you look at the academic literature on design thinking. I always felt like this was a bit of a tautological. Oh, well, let me go study companies that say they do design thinking and then I’ll define design thinking and then sort of over time we defined this thing called design thinking, but then next thing you know, design thinking isn’t just design. Oh, it’s also teaming. Oh, so design thinking is going to resolve all the teaming challenges. Like we, it just kept getting bigger and bigger without an anchor around what is this thing. It became bigger and undefined, but we also lost track of… design thinking, which is different than the practice of design, is not the only way to frame and solve a problem. And Roger talked about, well, scientific method is another way to frame and solve problems. Critical thinking is another way to frame and solve problems. Total quality management or DMAIC or Six Sigma, whatever you wanted to package all that stuff in, that was another way to frame and solve problems. Systems thinking is another way to frame and solve problems. And the design thinking proponents came along and said, this is the way to frame and solve problems. And it became, therefore, a fad, right? Because, because you can’t say there’s only one way to frame and solve problems. This is one of my great frustrations, honestly. So that’s what led me to the model that I’ve been using almost 20 years now, which is this experiential learning based model that basically says problem framing and solving is a process of sense making, toggling between the concrete and the abstract world, observing and noticing, framing and reframing the problem, and solution making, agains toggling between concrete and abstract worlds. Sara: I have a great idea in my head. I go try it out. I can put all of those other problem framing and solving methods into that model, which then led me to say, well, then shouldn’t we be teaching students, at a generic level, the core capabilities of problem framing and solving, and then have them say, ah, this problem could use scientific method approaches. It’s hypothesis-driven, right? I observe customers or users and I create a hypothesis about a problem they have. And then I go test that hypothesis by playing around with different solutions and prototypes. Scientists observe nature, maybe. We observe people in the design world, but they’re observing something and then forming a question about how it could be different. So, Sal Khan, in his book, One World Schoolhouse, his last chapter says, What if the university were a place in Silicon Valley that companies threw problems into and kids solved them for four years? And it took me a while to really kind of digest that notion, but I think, and by the way, it doesn’t have to be in Silicon Valley, and it doesn’t have to be corporate problems, but a general notion that education would really be about iteratively framing and solving problems of different types of different magnitudes over time with different methodologies. I think of different mindsets, different skill sets, different tool sets, right, that students would then learn in this setting. A systems thinking mindset, skill set, tool set is a better way to tackle this problem than in this other situation over here, where scientific method might be more applicable set of mindset, skill sets, tool sets. Taking The Time to Get It Right Peter: So you’re laying out a robust, detailed, savvy framework for approaching, tackling problems. What I’m wondering is, I don’t think I have ever been exposed to a company that would engage in the kind of rigor that you are proposing as they work through their challenges, and so, what’s the misfit there, right? There’s a misfit, I mean, you’re a B school teacher, I know you do exec ed. So you’re talking to people, not just students who’ve not necessarily had real jobs before, but people who are in the working world who are trying to get better at it, you’re engaging with folks with real world challenges. Square this, you know, thousand points of light, very robust framing of all the ways an organization can consider how to best tackle the problem in front of them. One of the reasons I think design thinking became popular is, in part, because by underselling design, it could be done quickly. And these companies just want anything that can be done quickly. They don’t want to spend a lot of time thinking upfront. You might not be familiar with this. There’s this saying “big design upfront,” which is like a bad thing, right? You’re going to spend three months doing all this work and designing, and then we’re going to get to start building it. So square the rigor and robustness that you’re discussing with what we witness every day with companies who are barely able to tie their shoes, much less engage in any meaningful research to inform how they solve problems. Sara: Yeah. I mean, I think that’s that’s a fair judgment. I teach hundreds of product managers every year. So I watch a lot of this. Clearly time matters, but there’s a couple of things that I try to do here. One is, you know, I used to teach design for manufacturability forever ago, my industrial engineer side of me used to teach operations management, and we taught a case study about a disk drive company. These are commercial disk drives, right? So they’re very, very high volume, low cost product, right? And this company was working in a partnership with Japanese company that was doing the manufacturing. And the engineers at the Japanese company would say, We need you to properly spec this product. And the engineers in the U. S. company would say, We don’t have time to properly spec this product. And the Japanese engineers ultimately won. They won over the ongoing complaints on the part of the U. S. product development team who they said they just want us to be able to put the parts on the table and hit the table and the parts will jump together. Like that’s ridiculous. But in the end they spec’d this product and they were able to ramp to volume manufacturing in way less time, way faster ramp to very high quality levels, because they had done some amount of initial investment. The parallel I draw to that in the design and product management world is that having some degree of clarity around what problem you want to solve for the customer or user up front will buy you a whole bunch of time in the long run, because you won’t keep putting the wrong thing into the market. Now, I’m not suggesting that I sit around and look at my belly button all day to do that. That’s where the innovation cycle comes in, right? I talk to a few customers. I take a step back. I go from dance floor to balcony. I get in the balcony. I say, what problem do I think the customer’s trying to solve here? Then I say, well, if that’s the problem, here’s three ways I could solve it. And I take those three ways back out, and I find out they don’t really have that problem. So I pivot, right? Or alternatively, I could say, I observe three critical problems that the customer has. I’m going to then generate ideas for each of those three problems, take them out, and figure out the customer’s going to say, I want to take that one home. Then I know I’m solving a problem the customer cares about. So the whole notion of rapid cycle prototyping is super critical here. But to frame it in terms of, I’m not just rapid prototyping to create the best product, I’m rapid prototyping to make sure I’m solving a problem that someone cares about, and there’s huge value in that, right? Jesse: What I hear from many of the design leaders in my leadership coaching practice is that their leadership is on board with many of the ideas that you’re describing. They are on board with being customer centered, with really listening for the right signals and tuning the product to the market in these ways. They just don’t see design as necessarily a partner in making that happen. And I wonder about design’s value proposition as it relates to this value that you’re describing because, you know, as you mentioned, you teach product managers how to do product management. And there are many, many people who see all of these things that you’re describing as being fundamental to the product management role, much more than to the design role in the organization. And so I wonder your thoughts on design, where design plays in these spaces. Sara: So that’s where I have to go back to this question of so-called little d design, right? I mean, product managers are generally not experienced or not taught or trained in doing UX design, right? So who is their partner, to be able to say, put this kind of curve on the product and this will happen. This goes back then to Peter’s original question of, you know, back 20 years ago, we were trying to characterize those kinds of connections, not this meta design thinking thing, right. We could have a long talk about customer centricity and whether companies really are or whether it’s just a lot of words and right, so, there’s a whole problem in companies. The Folly of Net Promoter Score Sara: I use net promoter score as my sort of measure of that. It has nothing to do with customer satisfaction. In fact, there’s no correlation between customer satisfaction or increased profit and net promoter score for any number of reasons. First, it’s ill constructed from a statistical point of view. It randomly eliminates 2 of the measures. It’s not even a proper average. I look at mine, I go, it got better and I think I’m good, but I don’t know that my competitors is 2 points higher than mine. In which case, getting better wasn’t really relevant. Peter: I like how for you, net promoter score, what it indicates, isn’t customer satisfaction, but a company that is kind of foolishly trying to engage in the idea of customer satisfaction. Sara: I mean, they think it’s an appropriate proxy, right? And I think that’s, well, it’s not an appropriate proxy for really understanding, are my customers now able to achieve an outcome better than they could before? Now, you might have a proxy for that outcome, right? But I want to have a way to know, have I actually helped my customer execute the jobs to be done that I intended them to execute. As long as you have these broader metrics, it’s very hard to connect what a UX designer does, right? I mean, I think it was an Adaptive Path conference where I put a DuPont chart up there. This is very old stuff. DuPont charts. Accountants would know what a DuPont chart is. Like, It starts over here with profit, which is made up of revenue versus cost. Revenue is price versus volume. So it basically backs all the way through financial metrics. And I put that out there and I said, “So where do designers affect this?” Jesse: Right. Sara: It could be at any of those levels. Remember Sam Lucente at Hewlett Packard. He had these multiple layers when he went in as the head of design. He said, well, it was clear that I had to do cost reduction stuff to prove my value. So I standardized the logos on all the pieces of equipment that HP sold at the time. Saved a boatload of money. Also, by the way, created sort of a standard brand identity in the marketplace. So he had, at one end, let me save cost, right, by good design, and the other end, he was working on revenue growth opportunities, right? If I can identify an interesting new need in the marketplace, then I’ll be able to grow revenue. Connecting Design to Business Value Sara: So to me, we have opportunities to make very explicit connections between what designers are doing. We had a discussion about the DuPont chart. And I was trying to get the designers in the room to think about the CMO, the chief marketing officer as their customer. And I said, what outcomes is the CMO trying to achieve and how are you going to connect the design you’ve made over here to helping them achieve those outcomes? And it was really hard to get them to do that. I can’t remember exactly the details now or I would tell the whole story, but, in effect the person said, yeah, but it’s Claudia Kotchka’s, you know, put a gold rim around the top of a face cream so I can put it in CVS or Walgreens and have it look more upscale, and everything, there. And the executive saying that cost two cents per jar, take it off. And her having to say, but then it won’t say that it’s… Peter: Premium. Sara: Premium, right? Jesse: Right. So, in some ways what you’re talking about are really qualitative outcomes that design creates in this increasingly, as Roger pointed out, as has frequently been a theme on this show, in an increasingly metrics-driven world. And I wonder what you see as design’s relationship to business metrics. Get Your Proxy Metrics Right Sara: So when we teach product managers, we try to have conversations about this. There’s a great case study, and this is kind of the classic case of Kodak. What was Kodak selling? Memories, and they knew that. What was their proxy measure for you to capture and share memories? Two core jobs to be done. Capture and share memories, right? Proxy measure, how much film and paper do we sell? So what happened to Kodak? They got too hung up on film and paper sales as the proxy metric, and when we shifted to digital, they didn’t shift their internal proxy metrics. They knew they were in the business of memories, right? They invented one of the first, if not the first, digital camera. they were on top of all these things, but when it came to execute, the metrics they had in place, they needed to be changed as a proxy for that. So mostly we use proxies, right? Like monthly average users. Well, you know, monthly average users is just a number that customers don’t care about. What did they care about: learning from the site, or getting a job, or whatever it is. So, how do I get proxy metrics? I’ve always hated sort of measuring everything myself, like it frustrated me when I worked in business, so I’m not not here to say, I think you have to be able to measure everything. But if you’re going to measure, then for heaven’s sakes, don’t use net promoter score, at least try to use something that gives you some information about the customers and whether they’re achieving something they want to achieve. And I think the Kodak story is a great example of knowing what you want to help, but not migrating or connecting metrics over time to the outcome. Peter: So you say, don’t use net promoter score. I agree. Many UX types agree. Jesse: I also agree. Peter: A few weeks ago a head of design shared with me that their boss, in an effort to give design some accountability, “We’re going to have you held accountable for net promoter score.” And this design leader was uncomfortable about that. I’m wondering what you would counsel someone, ’cause I can point to dozens of design leaders who are in a similar situation, what have you seen, if anything, that works to start changing that conversation? Shifting it, when you are also not the one in power, right? This is your boss saying this. Jesse: Right. Peter: You might be new. This person’s relatively new in the organization, right? Like, so they’re still earning trust, building credibility, like, there’s some things working against them to be able to just say, no, that’s not the right way to do it. It should be X. Any thoughts on how you turn that ship, to start advocating for what you do believe is right? Sara: Yeah. Many years ago when I worked at Hewlett Packard, HP at the time was divisionalized, had 50 or 60 manufacturing sites globally, which was a lot, and they were all very small, and so we were trying to provide some evidence that consolidation of those sites might be useful, so we made a cost volume curve. And where was HP? Above the curve, on the steep portion of the curve. So we start showing this to people and we say, hmm, opportunity, right? Increase volume, reduce costs. Oh, no, we do better quality work than that. Okay, how many quality engineers would you like me to add to the curve? Jesse: Hmm. Sara: And it would move up, you know, a teeny, teeny, tiny amount and we’d go at it again. For a year, we had these conversations. Until one of the very senior, senior guys said, wait a second, how many engineers do we have working in each of those sites? I said, well, it’s like two per site. You’ve got a hundred across the company, but the two, whoa, if we put them all together, we’d have an awesome printed circuit board assembly site. Like, okay. So it took me a year to get there. Two morals of that story for this conversation. You’re not going to change the boss’s mind overnight. But you keep bringing this up. So there’s a whole bunch, there’s articles–the wallet allocation rule. There’s a whole bunch of articles out there, first of all. So I would start with, there’s evidence of the problems of using net promoter score, right? So I can put some of those out there. But probably more importantly, I would start trying to build up some understanding of how I can create a metric that connects more closely to what the customers and users are trying to achieve. So I would start thinking about, is it weekly active users in the example views, or is it weekly learning users? Ah, well then if it’s weekly learning, what do I actually watch people doing? Do they scroll more? Do they post more? What evidence would I have that they’re actually on the site learning something? So I would start to build up a conversation around what can we replace this with. If you’ve got to have a metric other than revenue, right? If you’ve got to have a metric, then what metric might I have that would allow me to connect to something that is the agenda that I think I have for helping customers and users. Jesse: And it takes time. So part of this is patience. I’m new here. I’m not going to walk into my boss’s office, although I’ve been known to do stuff like that, walk into my boss’s office and say, you know, this is dumb. You should think differently. But, you know, building up a case. Maybe being able to collect some of that data, maybe talking to the data scientists and saying, if I wanted to construct a metric that evaluates memories, whether they’re shared and whether they’re captured, do you have data that could help me do that? So why don’t the designers make friends with the data scientists and say, you know, if this is something I would like to be able to evaluate, do you have a way to help me do that evaluation? So we begin to get little better integration. You talk about organizations basically falling in love with their proxies and becoming so attached to their quantitative measures that they forget what those quantitative measures were intended to stand for, which had to do with some sort of different kind of qualitative impact. Jesse: I work with lot of design leaders who are basically trying to break that spell of having fallen in love with those specific quantitative proxies. The challenge with that is, and I love your suggestion that like, don’t try to convince them to become a qualitatively driven organization, just give them different proxies, better proxies makes a lot of sense. The attachment that happens in these organizations is often connected to financial incentives. It’s often connected to power. And design leaders often find themselves literally the least powerful person in the room when having these conversations about how we measure the value of the work that we’re doing together. And I wonder about your perspective on the arguments that are going to hold water in a situation where you are the least powerful person in the room, arguing for everybody else in the room to change the way they measure their success. How do you do that? Find Your “Trojan Horse” Move Sara: It’s hard. There’s no… it goes back to my HP story, like, I couldn’t change the whole company. Jesse: Right. Sara: I could only change it one person, one division at a time. And so we used to talk a lot about, what’s our Trojan horse move, what’s our subliminal messaging, like how do we create shifts in thinking over time. And the kinds of things I use with product managers are, I can’t implement a big thing all at once. I have to often start small. So what if I open every meeting with a customer story? Oh, I was talking to a customer the other day. You know what they were doing with our product? What if every time somebody came to me with a feature they want me to build, I said, cool, happy to consider it, what’s the customer going to do with it? What problem are they going to solve with it? So there’s a whole lot of really simple little things, and design thinking did contribute a whole lot of these, but I can change my own behavior, and then what happens, you start to hear other people starting their meetings with customer stories, or you start to hear other people saying, but what problem is this solving. But we have, to your point, incredibly entrenched behaviors in organizations. And I’m going to take that all the way back to where we started this conversation, standardized testing and the way we structure our school systems has caused us to reward people for quickly having the answer to a question rather than saying, wait, is that the right question? Or rather than saying, is there more than one answer? We’ve got behaviors like that, that have been entrenched since middle school? Before? You’re not going to change those overnight, right? This is the whole thing I have about problem framing and solving, right? And, Roger sort of describes it as scientific method, analytical, but we’ve trained a generation of people and then we rewarded them for those behaviors. It’s not going to change if we’re just talking at this big level about everything. It’s going to change because we model behavior changes ourselves. So when I teach not just product managers, but executives, this is what I talk about. Say, you can’t ask the people in your organization to do ABC if you’re not acting that way yourself. But they don’t even know that they’re acting that way. So they need to be, in effect, called out on it in a nice way, right? So I would literally, at HP, my boss would do stuff in a meeting and I would walk up to him afterwards and I’d say, don’t ever say those words again, because here’s how they are heard. Don’t ask people to do X. Suggest that they do Y. Or, right, like I was trying to do literal behavior change work with him in order to get some of these changes in behavior, so it’s, you know, it takes systems thinking. It’s a big systems problem. This is not going to get undone overnight. I’m sure you’ve done this in your coaching. How many times do you have somebody, you know, you say, oh, well, you should be customer centric about that. And three seconds later, they’re telling you what feature they want to put in the product, Jesse: Right. Sara: And you go, what problem is that solving? And they’re like, Oh, it’s hard. It’s hard. Jesse: Yeah, so it’s interesting because it suggests there are several layers of the kind of culture change that’s really needed in organizations in order for design to genuinely deliver on its value proposition, because you’ve got to evolve the way that the culture engages with decision making. But you also have to evolve the way that the culture engages with problem framing and problem solving… On Being Customer-Centric Sara: And measuring itself. And, right? The reward systems. It all has to align around achieving… That’s why the customer centricity thing, there’s actually not as much academic literature on that as you might think. It’s kind of surprising. If you say, Oh, are you a customer centric CEO? Well, of course I am. I talk to customers all the time. Like about what? Oh, well, that do they like the curvature of this or did they like this feature? No, I don’t want you to talk to them about that. I want you to talk to them about their lives, about the problems they have about, right? We don’t have those kinds of conversations, but we think that because we shared a roadmap with the customer that we’re customer centric, right? It’s not. It’s not. But if you don’t get down to that level, and they’re just going to go, well, we are customer centric. And I work with some large companies where they’ll, “Oh, we’re customer centric.” I go, okay, write an interview guide to go learn something about your customer. And we’ll get specific about X kind of problem. And what do they write? “What’s the last product you bought from us? Did you like that product?” “What do you…” right? Like they’re not able to get into a mindset of learning, not selling. Of being present with a problem as opposed to with the solution, so it’s incredibly hard for them, but they think that because they’re talking, I mean, particularly in a complex B2B large technology kind of company, they are out talking to customers all the time, but they’re mostly talking about the features they’re developing. Not about the problems those features are aiming to solve. Peter: More proxies. Sara: Right. you know, to Jesse’s point, why is it so important that this change now? And you probably read Experience Economy… Jesse: mm-hmm. Sara: Pine and Gilmore stuff. Jesse: Mm-hmm. Sara: I really like the trajectory it lays out, which is to say, Commodities, the only differentiation is price, right? So coffee beans the value is can I get them at the lowest cost? Then I make goods, grind up the coffee beans, put them in a can. I’ve added some value to the end customer. Services, I’ll make the coffee for you and serve it to you at Denny’s. Now I’ve added more value to the customer. Staging customer experiences. Now I’m, you know, at the Starbucks level of coffee where it’s the third place, there’s more going on than the coffee. They’re now writing another book on guiding transformations. It used to be that most of the companies I taught were somewhere between goods and services. Now, most of them are trying to migrate to designing experiences. And very recently, people are starting to talk about guiding transformations. I cannot do experiences and transformations well, unless I truly understand what I’m trying to help my customers accomplish. Jesse: Mm. Sara: So, the trajectory we’re on, that trajectory is true. That increases differentiation and personalization, therefore increasing my opportunity to capture value, right? So there’s an economic return to increasing the value I provide to the customer. Then we have no choice but to go through the cultural shift that you’re suggesting, Jesse. And that’s kind of the broader argument that I’m trying to get people into, like, where do you want to be on this spectrum? You know, companies also talk about, well, hmm, sometimes we went to goods and then they got commoditized. So we went backwards. Oh, huh. I don’t know that I want to do that very often. Sometimes I might have to. But how do I always have my eye on the possibility that I might add additional value and differentiate in some way. Embracing AI Sara: Now, why is that being driven so fast? Because AI creates all this possibility to create, to stage experiences, to guide transformations. But if I’m looking at it totally internally, I’m just going, how do I get AI into my product? So what’s everybody flocking to these days? Courses on how to put AI into their product. Rather than asking the question, how do I augment my ability to stage customer experiences or guide transformations? AI will spit out a customer journey map for you, which, this is another place we talked earlier about, how do I get people to do this? I don’t have to spend time on this. It used to be I had to go interview a bunch of people. By the way, I’m not saying not to spend time with real customers. That’s a whole other conversation. But, but it used to be that I had to spend months to get an as is customer journey map, and now I can get one in less than a minute. Are they always right? Are they always complete? No, they’re not. But in my experience in the last year or two, they’re pretty good, and that means I’ve had a lot of people try out prompts to get a customer journey map, and they can get a pretty good starting point. Ah, if I can start there, now I’m playing a whole different game, because I don’t have to say, I don’t have time to blah, blah, blah, blah, right? I can start somewhere. I can get a list of jobs to be done. What’s the customer support engineer trying to get done when resolving a customer issue? Here’s all the personal jobs to be done. Here’s all the professional jobs to be done. Do I still have to go play with that and say which of those jobs to be done would I like to support? What does my product support now? What are my competitive products support? Yes. But now I can do it with, more real detail. Now, none of that is quantitative, right? You’re talking about a qualitative list of jobs to be done. I might try to do a quant evaluation, like how do I match up to my competitors on the ability to do those jobs for customers. That’s why I want a partnership with data science people. Now I’ve got to get creative. And how do I take that existing experience and make it a whole lot better? So you’ve also got a whole bunch of questions about what are the roles of designers in a world when some of the artifacts that they’ve created historically, I can create pretty quickly now a first draft of. But now, now you’re in a cycle. Now I can go in with a first draft, I can say, you don’t have to pay me for six months of work… Jesse: Well, there’s a catch in there though, right? Because the AI can make the journey map for you, but it can’t sell it to the executives for you. You’ve got to be the one to make the case and to frame the deliverable in some larger meaning, which comes back to this quant versus qual thing that we’ve been talking about. But it also comes back to the notion of culture change, and the notion of organizational evolution that is a part of this. It is very common for design leaders to see themselves as organizational changemakers, as champions of a different way of thinking about decisions, a different way of thinking about prioritization, a different way of thinking about how you go to market as a business. And you know, what I’m hearing reinforced in what you’re saying is that, like, you’ve got to really not just bring the data, but you’ve also got to bring the persuasion on a human level, to bring people around to this mindset as you describe it. The challenge that I hear from my clients is they feel like as design leaders, they are not sufficiently empowered to actually drive the mindset that is required to create design success. And again, coming back to the fact that you are not a design professor. You are teaching product managers. I find myself wondering about those design leaders who are asking, Am I even in the right place to create what I see myself creating in this organization as a design leader, or do I need to be somewhere else in order to actually accomplish these outcomes? Create Your Own Power Sara: Let me first say it is not just designers who say that. Product managers say that, you know, lots of people, so that’s not an uncommon concern. Part of the challenge we have is that the world is moving way faster, particularly since COVID, and we hit the knee of the technology change curve. The world has been upended. The people who are running the companies today have no experience in this new world. I would guess if you talk to some number of them, they’re terrified because… Jesse: hmm. Sara: …they don’t have the tools, the sense of what can happen. And so we’ve got real conflicts between the top of the organization and the people doing the work. And the people who are doing the work often know more, but are feeling disempowered and I think part of it is this challenge of things are moving so fast, you can kind of get it. Even at HP when things weren’t moving that fast, you know, those of us more junior grew up with more technology then the people running the company, and so for them to be making judgments, they actually didn’t have that empathy, if you will, for what was happening out in their customer’s world. So, so this kind of goes back to, create the power for yourself. I mean, no-, nobody’s going to come to you and say, I empower you to change how I think, right? It just isn’t that way. Now, you could be in an organization that you should leave. And I assume that you coaches help people figure that out. Like if you’re pushing rope uphill, you know, there’s a point at which, don’t do that anymore. But I ran the change management team at Hewlett Packard, right? Nobody said you’re empowered to help the company improve its teaming, change its product development process, improve supply chain management. I figured out that those were things that needed to happen, and went around and found places that would experiment with me. I don’t have to change the whole company at once. I just have to redesign one product, and show that redesigning one product increased acceptance, adoption, whatever it is, right. So change doesn’t have to be, oh, they don’t understand me. No, they’re probably not going to, until you find that– I’m gonna go back to my thing. I didn’t get that they cared a lot about consolidating engineers, not about consolidating production, right? Boom, I was telling the wrong story because I wasn’t listening to my senior management team. That’s the same thing at the Adaptive Path conference where, you know, we were having somebody pretend to be the CMO. The designers who were sitting in my group weren’t listening to what the CMO cared about and creating a connection, right? it also goes to the whole storytelling thing, right? We teach storytelling a lot in product management. Why? Because, as our storytelling faculty member says, when you open with data, people receive it with their dukes up. Where’d you get the data? How’d you analyze it? Why are you sure that’s the average? Start with the Story, Then the Data Sara: If you open with a story and then provide the data, it’s heard in a different way. Even in companies that have very data driven focus, and I think, increasingly, in the product management space, I was just with a bunch of them this morning on storytelling, and one of them said, when we have a product that’s languishing, I use storytelling to figure out whether I should just kill it or what I need to do to fix it. Because you can’t tell a good story if you don’t have a good story to tell. Peter: Hm. Sara: So it’s in the structuring of the story that I’m testing… “Once upon a time, there was a customer who really wanted to and could not do so because…” If I can’t tell a compelling, right, problem, then I don’t have something. So I would link these things together, right? Like, how do I bring the qualitative side? And I’ll come with data. “Once upon a time, there was a customer who really wanted to do this, couldn’t do so because, and by the way, there’s 400, 000 of those… Peter: right. Sara: in the United States alone.” Okay, now I’ve got my data. But you can’t expect it to happen overnight. I mean, that’s thing that I think is so… it just doesn’t, it just doesn’t. Peter: Right. Sara: So I’m a big “guide on the side” rather than “sage on the stage” as an educational concept. And so to do guide on the side work, you’re gonna have a classroom that has tables and chairs, not the amphitheater style, right? And so I used to go to these meetings about our new buildings and I’d be like, no, we’ve got to have flat classrooms. And it got to the point where I was in some meeting and it’s like 10 minutes into the meeting. So he goes, “Sara, you haven’t brought up the space problem yet.” So that’s what happens, right? Mean, to me, that’s what you have to sort of, with humor, be a bit of a pain in the neck, you know? Oh yeah, what problem is that solving? Oh yeah, what problem? Pretty soon you start to hear it back again and they’re not even attributing it to you, which is the other part. You can’t take credit for it, right? Because, you’re just trying to get them to understand something and eventually it’ll click and then they’ll say it in their own terms and you’ll hear it come back. You go, well, I’ve said that. That’s right. Peter: You’ve mentioned your work with product managers. Sounds like you’re teaching them working with maybe dozens, if not hundreds of them over the course of year. And I want to take advantage of your distinct kind of opportunity and perspective that that gives you, and I have a question which is, What are you hearing from them? What are the patterns you’re seeing in product management and with product managers? What are the things that are keeping them up at night or what stage are we at with product management? I’m, just kind of curious as you look at the world of product management from your point of view across dozens if not hundreds of people from a lot of different enterprises. What have you witnessed? What insights do you have that could be of interest to people who are working with product managers and who don’t necessarily understand the challenges that they’re facing? Sara: By the way, we have some number of designers who show up for the product management program. So it isn’t just product managers, we have fair number of technical or, engineering managers who show up as well. And I think it’s in part because they would like to understand a little bit better how business cases are being made for this. So, first, let me say, because I’ve always been in this boat as long as you’ve known me, or maybe even before, I’ve always taught human centered or customer centered development, right? That’s what we taught at Berkeley in the MBA programs. And that’s really how we anchor the product management program. So, yes, we teach segmentation, targeting, positioning, pricing strategy. But the Trojan horse, if you will, is it’s all customer centric. So the first thing I would say is that companies used to push back heavily on that, let’s say, 15, 20 years ago. A lot of the stuff you’re saying, Oh, no, we can’t do that. My boss would never let me do that, etc. There’s a lot less of that now. In fact, it’s pretty rare. I can credit design thinking with that, if you like, that there’s been enough conversation and agenda around some of these first principles of customer centric work, and adoption of things like rapid prototyping, although aside, we teach risky assumption testing rather than minimum viable product, because there are often assumptions you can test without a minimum viable product. So rapid prototyping has become minimum viable product instead of risky assumption testing. Jesse: Right. Sara: So being clear about what are the risks associated with the idea that I have for creating a new customer experience, and how might I test them, could lead you to, I’ll test them through a minimum viable product, but it doesn’t have to lead you there. But most companies don’t get that until you really push them. This is another one of those things where you can push them at a micro level. It’s like, what do you want to learn from making that minimum viable product? And often they can’t even tell you, because it’s just built into their agile process that they all spit out minimum viable products. These are all the little things that, if you could get that mindset to shift, then you end up in a different place. So that has definitely changed. And there’s a lot more acceptance of customer centric thinking on the part of product managers. The second thing that’s really big is that, of course, the field of product management, as you probably well known, has grown significantly. So there are a lot of product managers now. I don’t remember the numbers on LinkedIn, but it’s grown significantly. That includes not only the classic externally facing product manager, but it also includes a lot of internally facing product managers. So they might manage a platform on which products are built for that external customers or users. So, product management is sort of propagated in a lot of ways, which is probably why you see it encroaching more and more on what designers do, because, theoretically anyway, the product manager’s job is to bring together the customer with the engineering community, to make stuff happen, right? It’s more complex than that, but they’re supposed to be a representation of the customer. I would say in big companies, most of them have CX/UX design group, but it’s not always accessible. So you can’t get your project in there unless it’s prioritized in some way. So not everybody in the organization feels like they can get to those capabilities. B, very often what is produced is a bullet point list of things to build. So it’s not bringing alive the existing customer experience or the experience they want to build. Dorothy Leonard at Harvard used to call this empathic design. That I have in the guts of the engineers empathy for the customer. Well, if the CX design group is doing all that, but it’s not presented to the product manager in a form that allows them to use it to create that empathy, right, then we’re missing a connection. So the product managers are not really doing that kind of design work. Like many of them don’t interview customers. Somebody else does that. Which is too bad because they should be out in front of customers themselves. So this becomes the place where your question gets messy in the sense of, first of all, who does what, but then, where’s the connection between the two? I had a PhD student write an entire thesis about this question of how I present the results of design research to the people that will execute the product and not lose something in the process. So this could be another reason why designers feel left out, because maybe the bridge, there’s a gap, like something’s jumping across from the customer experience group into the PMs, but it’s not really a connected thing, like, could they bring the PMs on interviews with them? They probably should once in a while, right? So the PMs can actually see the customers. Do they help digest the data with the PMs? Probably not, right? What’s Next for Design Jesse: So, I wonder what all of this suggests for the future of design. And I’m curious what you think and what you see from your vantage point, in terms of what’s next for where design is going in organizations. Sara: Yeah, designers have very particular skill sets that are not generally present in the rest of the organization. For example, the ability to conduct a good ethnographic interview with a customer or user. The ability to create representations of an offering, whether it’s an experience, a service, whatever. There are capabilities that don’t exist elsewhere in the organization. Jesse: So what you’re saying is they have a very particular set of skills. Peter: Ha! Sara: That are important, and the question is, how do they get embedded in the organization, right? How and where? So, do product managers really understand… And this goes back to, in 1993, a woman who was a fashion designer in New York came to get her MBA, and after she took my operations class, she came to me, and she said, shouldn’t business people know more about design? And I said, sure, start a class. So she started a full on three unit class called Design as a Strategic Business Issue. And, Davis Masten, Jerry Hirshberg, Sara Little Turnbull, Bill Moggridge, right? Like, name people in that world. They came with their 35mm slide trays, and they showed what designers do. And it was eye opening and mind blowing for the MBA students. That class isn’t taught anymore. Partly because Design thinking came along, and so we started teaching design thinking, and now we’re not teaching what those critical skills that designers bring are and what they produce, right? I mean, there’s all kinds of stuff that we talk, oh, in design thinking, we do visualization because we put post its on the wall. Well, that’s not the same as, you know, my friend Michael Berry sketching what a new drive-through would be for a fast food company while everybody’s talking about it, right? And so part of the challenge then becomes, how do I make clear what those unique skills of designers bring to an organization. Then I would also ask the question, if I centralize something, then it’s not part of the fabric of the organization. So do I need a UX designer on every single team? Like does every product manager need one? I don’t know. Do they need at least consulting with one once a week? Maybe? I’m throwing this out there because I don’t know if anybody’s even asking those questions, probably the two of you. But, how do I bring that skill set to bear when it’s most valuable and needed? Right now, my sense is that it’s separate out there for a lot of big companies. It’s somewhere up here and maybe I’ll get access to it, right. And by the way, rapid testing of things is primarily A/B testing that’s owned by engineers, or MVPs that are owned by engineers. So this capability to do early testing is not embedded in the organization. But the agile feature mill is a fast cycle, but I lose the front end then. Like, product managers works gotten sucked into the agile feature mill. Well, ditto with any front end design work, right? So the question is, where do you want to embed those capabilities, as opposed to thinking of them as people? I know they’re people and they’re wonderful people, but really thinking about what is the capability set? What are the jobs they can help with? And where do I need to have those jobs done in an organization? And then how do I make that happen on the front lines, as opposed to in a big, you know, hand wavy way, which we kind of get stuck in, don’t we, when we talk about design? Jesse: Dr. Sara Beckman. Thank you so much for being with us. Sara: It has been my pleasure. Sara where can people find you? I’m reachable on LinkedIn. I just would ask if somebody reaches out on LinkedIn that they tell me why they know me. Peter: Not just a message that says hello. Jesse: Mention the podcast. Mention the podcast. Sara: Mention the podcast. There you go. and I’m also available by email, which is just Beckman at Berkeley dot edu. Peter: Awesome. Thank you so much. For those who have stuck around, we have a special treat for you. We have revamped our website at Finding Our Way dot Design, and we have also launched a new online community through Discord called The Way Station. So go to Finding Our Way dot Design. Click on the link that says The Way Station, and you’ll see a link to our new Discord server. Hope to see you there. Jesse: For more Finding Our Way, visit findingourway. design for past episodes and transcripts. You can now follow Finding Our Way on LinkedIn as well. For more about your hosts, visit our websites, petermerholtz. com and jessejamesgarrett. com. Peter recently launched The Merholz Agenda, his semi weekly newsletter. Find it at buttondown.com slash petermerholz. And if you’re curious about working with me as your coach, book your free introductory session at JesseJamesGarrett. com slash free coaching. If you’ve found value in something you’ve heard here today, we hope you’ll pass this episode along to someone Else who can use it. Thanks for everything you do for others, and thanks so much for listening.…

Finding Our Way

1
55: The Maker Mindset Connecting Product, Design, and Engineering (ft. Todd Wilkens) 53:54

4 weeks ago53:54

53:54

Transcript Jesse: I’m Jesse James Garrett, Peter: and I’m Peter Merholz. Jesse: And we’re finding our way, Peter: Navigating the opportunities Jesse: and challenges Peter: of design and design leadership, Jesse: Welcome to the next phase. Joining us today to talk about what’s next for design is Todd Wilkens, part of our leadership at Adaptive Path years ago, who has gone from design leadership to product leadership to fully integrated leadership of design, product, and technology. He’ll talk with us about his increasingly holistic view of product development and leadership, the signs that an organization is right for him as a leader, and what the C suite really talks about behind closed doors. Peter: All right. So this is a little different than the conversations we’ve been having recently, ’cause this is one with an old friend. We are joined by Todd Wilkens. Todd worked with Jesse and I at Adaptive Path many years ago, helped lead our Austin office, and then went on his way and we have him here today because his journey is one that we find potentially illuminating as we explore what are paths forward for design leaders. So, welcome Todd. How are you? Todd: I’m doing good. It’s really great to talk to both of you again. It’s been a while. From Design To GM to Product Management Peter: It has been a while. And yeah, if you could share just like your story beyond Adaptive Path and kind of that evolution you’ve had from design leader to whatever it is you call yourself now. Todd: Sure. Yeah. So I think actually Adaptive Path was a place where I had a very pivotal thing happen, which was I moved to Austin and opened the second studio, and had to kind of own part of the P and L for the company. There was a little piece of the P and L, but I was still running part of the business all of a sudden. And I learned from that, that there are a lot of challenges when you try to run something holistically, instead of just doing a part of it, you know? And I, I ended up kind of liking it. And so I say that because that, sort of is the theme of my career path now. Which is, I left Adaptive Path. Went to the Mayo Clinic doing design work. Left the Mayo Clinic, went to IBM when they were doing that big design kind of transformation some years ago, also doing design work there. But within that change at IBM, we realized we needed to change some of how product management worked as well, because you can’t just change the design stuff. And so I spent my last year at IBM actually sort of masquerading as a product manager. I helped redefine the product management practice for all of IBM, and thousands of people there at the time thought I was a product manager, even though I was technically a designer, right. And then I kind of went on this path where I went to Atlassian as a designer, VP of design at Atlassian. And then this was the moment where I was like, the holistic thing really kicked in, which is I had this opportunity to go become the GM of a business. So I moved to a company called Automattic. They do WordPress and I became the GM for WooCommerce. It’s one of the biggest e-commerce platforms. And did that for a while, which was really amazing. And I learned that… I learned a lot of things. I learned that I don’t get up in the morning excited to do all the business stuff, even though I can do it well, right. I was there for two and a half years. We managed to grow at, it’s like 40 percent the first year, a hundred percent year over year growth the second year. It was like, the business was succeeding, but I got up in the morning, excited to do the engineering and the product and design stuff. So I kind of moved my way back into product and now I’ve done a series of chief product officer, chief product technology officer jobs at a variety of different companies. What I’ve realized is the theme on my companies is I like growth stage companies, typically that sort of series B, series C, there’s somewhere between 100 and 250 people there. They figured out that they have product market fit, but everything is kind of like held together with duct tape and bailing wire and now they want to scale it. And so they have to figure out how to do that. And I like to work in what I’ve started calling invisible industries. I work almost entirely in B2B and they’re always industries that make the world work that most people don’t know anything about. So like shipping and logistics, employment, payroll and benefits, quality and compliance for life sciences. I really love those. They’re intellectually challenging areas to work, but I haven’t been a designer officially since 2013, 2014. All my titles and jobs have been general manager, product, chief product officer, chief product technology officer, ever since then. So I, definitely, I sort of jumped ship from the design world officially, though, almost everything I do every day is, completely influenced by my experience as a designer. Peter: Sure. Jesse: I’d love to hear more about that because, you know, so many of the design leaders that I work with as a coach, they look across the other side of the aisle and they see these other functions and they don’t see themselves in it, you know, they don’t see the ways that they’re used to delivering value, the ways that they’re used to engaging with ideas, the ways that they’re used to engaging with problems. They really don’t see those things represented in these other areas, in these other titles that you’re talking about. And so I’m curious, how has the designer in you stayed alive as the problem set and the problem space has changed over the course of your career? Todd: Yeah, well one thing I will say to that is that in my first forays into being a product leader, I definitely sort of struggled, because what I tried to do was do the product leadership thing the way I saw other people doing it. And I really didn’t like it. And it turns out I actually wasn’t very good at it that way. And through a lot of mistakes, I realized that I needed to find a way that was very authentic to my understanding of the world, how I see truth, how I make sense of the world, how I do things. And so I sort of have crafted a sense, a way of being a product leader that is very designerly. It’s not only designerly, it’s doing the things that I’ve always done. So, very… dig deep into research, understand the problem, both the problem of the customer and the problem of the organization that I’m in charge of, right? It’s a very human science kind of attempt to understand and then articulate what we’ve learned and what the major parts, major levers are that we can work with to accomplish a goal. I’ve learned over time that while I like to think abstractly, and will write and that sort of thing. I do my best work as a leader when I’m making things. So, I’m a much more hands-on leader than I think some people would think. Not like I’m in there always, you know, I don’t open up Figma and start designing the screens or whatever very often. But I do get in the weeds on things and I spend time making things to… either prototyping stuff or what have you. And I find that that helps me stay grounded. It helps me understand what I’m doing in a way that’s really, it’s just, it’s richer, right? Like, I’m not just thinking about it, or it’s like the difference between when someone says they’ve read about something versus they’ve done it. Jesse: Mm-hmm. Todd: I feel like a lot of people switch disciplines and get high enough up in the ladder that everything is like, well, I read about that, or I thought about that, or I understand that, but they don’t take the time to do the practice, to do the thing that needs to happen. And so the level of understanding they have is not very rich. Whereas I think designers, like, they make things, right? That’s it’s like, so core to how designers do things. And I feel like especially since I’m not the sales leader, right. I’m not the chief marketing officer. I do product, design, and engineering for the most part. And so they’re all maker disciplines really anyway. So having that maker mentality, the leadership level is a good balance. But I do think that sometimes I approach things in an unusual way because people often don’t expect me to behave the way that I do as a leader. I’ve had several people tell me that they’re usually happier about it, but they’re usually surprised. Leading Product in Unexpected Ways Peter: And, what is that expectation that you’re flouting specifically, like what are they expecting you to do and what are you doing that’s not what they expected? Todd: Yeah. So like, when a growth stage company hires a chief product officer, it’s usually… one of the most important things is that they’ve been struggling to articulate their product strategy and roadmap. That is almost always one of the things that is missing. And people assume that one of the very first things you’re going to do is come in and like, start to lay that out. Like, you’re gonna talk to a lot of people, and you’re gonna, you’re gonna create the diagram that tells the story. And so people assume that that’s what I’ll do, and that then I’ll try to get people to execute on that thing that I put together. So that’s what they expect. And what I usually do is I show up and I spend the first couple months, like, just going to the, to the sprint meetings, like, and, I go into JIRA and I start digging around and looking at what’s going on and I just try to pull the stuff that’s in there up. I like, I really want to bottoms up it. Like, I don’t want to start with some weird abstract thing. And the reason for that is because something I, feel like I sort of learned when I was at IBM was it’s like one of my mantras, which is you have to execute well in order to earn the right to do strategy. Jesse: Mm. Todd: And so I always start off by saying, are we executing very well? We’re not. And I was like, all the ideas we have, we could be working on my first six months, none of them are bad ideas. The concern we have is which one is the best one, but I don’t care. Pick one of them and let’s execute on it really well. And then pick another one and execute it on really well. And then we’ll worry about finding the absolute best thing to do, right? Because if you spend all your time worrying about the strategy and you can’t execute it well, everyone is disappointed by that situation, but most people expect that from a leader, right? Most people expect the leaders to be telling stories and making diagrams and that sort of thing. And I do do that, but I always start with, how do we make things? And one of the reasons I will say is because I’ve tried to get the team to fall back in love with making good stuff, because that goes a long way. If I can get the engineers, the designers, the product managers to fall back in love with making good stuff, then they’re ready for us to figure out what the strategy is. Jesse: So the phrase back in love suggests to me that somehow they’ve fallen out of love. And I wonder, what you see is the dynamic there. Todd: Again, engineering, design, and product are all making craft kinds of disciplines, right? So these are almost always people who got into what they’re doing because they liked, they like to make things. They’re usually driven by some sort of passion or creative endeavor, right? But then they end up working in a place where they don’t see the work they’re doing coming to fruition. They don’t feel like they’re connected to what the company at the highest levels is saying or doing. And so what they start to do is become a little insular. Like they start to lean in on their disciplinary stuff. They’re like, I can’t really deal with the cross functional stuff, but I can be a really good designer now, or I can study product management skillset. And I can learn how to do all the, whatever the GIST method and the whatever method into this, right. And I can get really, really good at whatever, you know, like, doing AI and, like, prompt engineering, ’cause it’s an interesting thing to do that’s technical. And that’s not really what they got into this for. They didn’t get into it to get good at a craft, though the craft is good. They got into it because they saw what the craft was able to accomplish. And, so that’s what I mean. They usually fall out of love. it loses its shine. It’s also one of the reasons cross functional teams stop working well. It’s because they don’t know how to work well together when there’s not a clear direction and they don’t have a clear process for working well together. And so they become disciplinary insularity as well. You get to that, the designers really want to talk to the designers, and the PMs want to talk to the PMs, and the engineers want to talk to the engineers. So it’s a love thing to some degree in that sense, also, I think. They need to fall in love with their teams again. Operating as Scale Grows Peter: So it’s funny, I’m having this conversation less than an hour after I spoke with a design leader of a company, that’s probably series C. 300 employees. Exactly the kind you were talking about, and what I identified when I was talking to him as as an issue they were facing was one of scale. They were wanting to operate as if they were 100 or 150 people, but the reality is there’s 300 people, and I’m wondering as, since this seems to be your sweet spot, when you go in and you see an environment like this, where there is that desire to get back to the love, but where my intuition would be scale is probably the issue here, right? It’s big enough that you need to put some processes in place, some communication and coordination standards in place that maybe they’ve been fighting. And because they’ve been fighting it, they’re now kind of almost operating at cross purposes. How do you get them to, as you said, execute, execute, execute, or get back to execution at this and help them recognize that this, new waterline that they are operating at requires some different ways of working, but by embracing some new different ways of working, they can get back to kind of the magic that they once had when they were smaller. How does that conversation go? Todd: Yeah. So I’m a back to basics kind of person, right? Like I use very simple frameworks for things, which tends to be good. So like what you end up finding is that up until, I don’t know, company gets to like 200 person range, they can actually swing a whole lot of things based on just intuition and people talking to each other on a regular basis without a whole lot of real process. And then what happens is they’re not thinking about what they’re doing and why they’re doing it. They’re intuiting their way to making decisions and intuiting their way to what seems to be the right approach or the right thing to do. And if you ask them to describe what it is they’re trying to accomplish, they can’t very easily. And so in that situation, I’m like, Hey, this is a little bit chaotic right now. Let’s just get back to basics here for a second, okay? What are we doing? What are we trying to accomplish? And I literally break it down. I’m like, the only thing that matters for our company is new customers, expanding with current customers, retaining customers, right? That’s actually all that matters. And I was like, it’s that simple. And I said, so let’s just talk for a second. Is everybody in the product development org and sales and marketing, are we just really aligned around how well we’re doing on that? Like, can anybody, tell me how we’re doing on that? And then we eventually get to the place where we can. And then I say, great, what can the product organization do to bring in new customers, expand with current customers or retain customers? And what’s interesting is like most people in product development organizations have a hard time answering that question in any specificity. They have these kind of random things. It’s like very hypothesis, but like not good hypothesis. They’re like, well, we think if we did this, it would kind of grow new customers, because there’s a giant TAM out there or something. And I always like to just take people and say like, no, like literally, let’s just take the three biggest initiatives that we worked on in the last quarter, before I got here, or that we did, and just say, what’s the real hypothesis that we had about why this was going to bring new customers in, retain customers, or grow or expand the current customers? And what’s interesting is you start to walk that back. And then, because then the next thing they’re like, Oh, well, here were the hypotheses. I was like, well, did it pan out? We don’t know. Well, that’s terrible. Or yes, it did. I was like, well, that’s wonderful. No, it didn’t. I was like, that’s not so good, but we learned why didn’t it pan out? Right? Like we have this conversation, then I really have to tell them, I was like, all that you should be doing as a product development organization is defining what are the initiatives we’re going to do. And I use the word initiative very explicitly. It may include multiple teams in a 300 person organization. It will include multiple teams, right? But the initiative has to be directly tied to one of those business goals. And then you start to break it up and you start to execute on it. So I do that. And then the only other thing I ever do, this is the love part, actually, quite honestly, and gets people is I always say, when somebody starts to get big and the first time somebody starts to put process into a product organization, they usually start with things like ticket burndowns and how many commits from each engineer and they start looking at, like, these in-process metrics, and I usually walk in and I say, “Hey, everybody, I don’t care how many commits, I don’t care how many things you shipped, I don’t care any other things, I only care about, if you made something and a customer or a colleague is using it. And if you have some sense there’s value from it. That’s the only thing you should care about.” And so I just start championing the outcome. You made a thing and people are using it, which is back to the basics of what most people did when they were a startup that had five people. They’re like, Oh my gosh, our first user. It’s amazing, right? Right. That can exist to a 10,000 person company, but people lose, they lose sight of it, right? And so that’s how I take them as I say, we’re going to put some process in place, but the process is based on super basic things, customer growth and retention. We have initiatives. We have clear hypotheses about those initiatives. All we care about is outcomes. All we care about is shipping a thing and getting it into someone’s hands and knowing whether or not it did a good job. And then people are like, Yeah, let’s do that. And then we just start to say, well, where are we failing? Oh, we need to get a little bit better at the way we track JIRA, or we need to do a little bit more of this or we need to get really good at instrumenting the code because we don’t know how we’re doing or who’s using it. Like all that process stuff falls out. Like people just start doing it. I don’t have to tell them to do it because it’s a natural implication from the fact that we’ve aligned around this kind of cross functional product outcomes kind of approach. And like I said, used in a small company, but it works… you can take this to whatever scale of company. You just have to make sure the company gets out of its own way. ‘Cause sometimes it’ll get in its own way you lose that culture and you lose that approach. Jesse: Yeah. So you talk about the importance of driving alignment and really creating a sense of shared purpose for the team beyond the immediate metrics that are sort of presented to them. I wonder about the nuts and bolts of that, you know like how do you in the day to day actually engage people with these ideas, actually help them believe in the things that you’re saying and keep them motivated through the process. Of trying to create these outcomes that you described. Soaking in Salesforce Todd: Sure. So The first thing is this is one of the weird thing I realized about myself in the last year or so is that I spend so much time in Salesforce. Peter: I’m sorry. Todd: Yeah, well, so you can say whatever you want, but that’s where the rubber meets the road for our customers, either, you know, landing new customers, what have you, right? So I spent a lot of time in there trying to understand what the dynamics are. And I say that because that’s the first thing I tell the product development team, all the designers, all the engineering leads, all the product managers, is I said, “If you can’t just tell me off the top of your head what our numbers are? If you haven’t looked at Salesforce at least twice this week, right? There’s no way you can have a conversation about any work that you want to do.” And it’s not like I’ve forced that on them. I’m just like, we can’t talk about anything you want to do. ‘Cause nothing you do matters unless it relates to those things. And so I start with that and then you can start to break it down almost like social scientific, right? Like you can start to say, well, we have an initiative that we want to focus on. We’re growing new customers. Growing new customers is usually a matter of… the mechanics are relatively straightforward. Do we need to improve conversion rates? Which in my experience, there’s a couple of things you can do there. Are there certain features that it seems are missing, that come up in the closed-lost all the time. Let’s go out now, that’s a signal. That’s a very rough signal, which you can take that signal and then you can go off and do some deep research and understand what are those jobs to be done? How do we know what’s successful there? Some companies can get very sophisticated, but most of them actually hide behind sophistication, right? Like, I think any company can go a long way if they just truly measure adoption of anything they ship. Like really measure the adoption, and you have to know what adoption means, right? I’ll give you an example. I was working with this company called Qualia, we make a quality compliance software for life science. In that situation, it’s very document centric. There are lots of documents. And so when someone hires us, they usually have thousands of documents that they need to migrate into our system. And it’s not the same thing as, like, copying something in. It has to get modified into our sort of format. And it used to take our onboarding specialists, like, weeks to do that. And, that was bad for them. And it was really bad for our customers. ‘Cause our customers, like they just were kind of sitting and waiting. We talked to one of our product teams, I was like, we need to solve this problem. How are we going to do it? And they said, okay, they went in and they started looking and they were like, well, what is it, how do we solve this problem? And what do our onboarding specialists need? And what do our customers really need? They wouldn’t define their own metrics because they went in and looked at what’s going on. And what’s interesting is the metric they defined was, they said, it turns out most customers are bringing in, let’s say a thousand documents, but in the next six months, they’re going to use 20 percent of them. And they actually already know what 20 percent it is because of the dates on them. And because of the stuff that they’re doing. So, we’re going to focus on migrating this 20 percent in a couple of hours. And then we’re going to let them ad hoc bring the other ones in as they need them really fast. So we took something that would have taken two weeks down to taking a day. And the team defined that metric by just going in and figuring out what really needs to be done there. That’s a super designy design research thing to do. It was such a design research kind of project to go do that, but it was not just the product team because our onboarding specialists were as equally involved in that, project as we were, cause they had to change the way they worked when we updated some of the tools and updated the approach. Jesse: Well, you talk about scale, right? And the difference between the scale of 150 and the scale of 300 is that at 150, you’ve got a shot at directly influencing everybody, at least according to Dunbar. And then you get beyond that, and it’s like, you’ve got to wield some more sort of indirect influence. You have to wield cultural influence. You have to wield influence through things like strategy, things like roadmaps, things like milestones. And I guess I get curious about what the hands on work of leadership looks like for you when this is your job. What does a CPO do all day? Todd: Yeah. Yeah. So, I, what do I spend my day doing? Like, if you want me to, you know, yeah, Yeah. sure. So I am in… I probably spend Jesse: hmm. Todd: a third of my time during the week in either Salesforce or Looker, digging around to make sure I understand what’s going on. And part of the reason I do that is because it keeps my hands in the weeds of the work. But it’s also ’cause that’s something I’m particularly good at. I have a social science background. So I spend a third of my time in there, partially ’cause it’s a skillset I have that a lot of people on my team don’t have, and partially because it keeps me really close to like, what’s really happening. I spend another third of my time in mostly group meetings. I usually try to keep my direct reports down to close to like four or five. So I have one on ones with them, but I run almost everything as a team instead of with unilateral or bilateral kind of interactions. So I find that it’s really helpful to just any part of an organization, I tend to just pull everybody into a weekly working session. And we have a set of tools and things that we prepare for that. And we go through it for half of it. And then the other half of it is ad hoc deal with issues. I have those group meetings. That’s how I manage the teams. And then I have one third that is blocked off as focus time with zero plan. Jesse: Mm hmm. Todd: And then, that is for me to fight fires or to dig in on something that allows me to think about something that’s way in the future. Like that’s where I do my strategy thinking a lot, my own kind of research. And then sometimes that’s when I go and like, review a thousand SOWs or whatever, right? But I’m pretty good about those three parts of my day. Parts of my week. Peter: When you mentioned Salesforce and Looker, I mean, a third, that’s like 12 hours in tools, what are you… Todd: yeah. Peter: What are you getting from that? What makes it worthwhile to spend 12 hours a week fiddling with user interfaces on these tools to understand what exactly, and then coming out of that, what does that then drive in terms of what follows from that? Todd: One of the things that I think product teams have a hard time with, and then this is another thing that design really taught me, is they have a really hard time with ambiguity. They have a really hard time of having lots of questions and not having answers to them. And they usually lack confidence in the sort of pseudo answers that they’ve come up with. And so they’re usually uncomfortable making a decision about something because they haven’t sufficiently reduced the risk that they feel around making that decision. And so that is something that I see kill organizations of all sizes. And so the reason I spend a lot of time in those two data- centric things is because that’s where I can get questions answered for myself or my teams so that they don’t feel afraid to make a decision, to move forward on something. And I’m trying to model for them that they don’t have to understand the thing perfectly. They need to understand it well enough to reduce the risk. And so I do a lot of that over time. I spend less time doing that because the teams start doing it. But it takes quite a while to teach a team to feel confident of knowing just enough, to make the decision to move forward. So that’s why I spent a lot of time in there. I mean, I’m doing this as much for my colleagues, the other C level people on leadership teams. Like everyone in these situations is often uncomfortable making a decision. And what you end up finding is that a lot of people won’t make a decision, or they’re like, they push it off because there’s uncertainty, or they make a decision almost like because they trust their intuition too much, right? Like there’s those two kinds of leaders really, in a sense, like, they’re like, I’m always right because it’s me, and I’m not sure if I’m right because I’m too humble or I’m too risk averse. There’s a lot of those. And so I’m often trying, that’s what I’m helping with my teams, but I’m also helping with my fellow executives is saying, no, no, no, right? Like, my intuition doesn’t matter really. We’re not gonna make a decision just ’cause my gut tells me, and we can make decisions without perfect knowledge. And so that’s where all of our knowledge tends to lie. That and talking to customers. I mean when I can, I talk to customers a lot, but usually I’m talking to customers when there’s a problem because of my role, as opposed to getting to just go talk to them when things are going well. I wish I talked to more customers when it was going well. Leading Design as a Former Design Leader Peter: I’m going to get back to something that relates to this conversation I had with someone who’s just joined an organization that is operating at scale, a design leader now, new to an organization that hasn’t really embraced what it means to operate at this scale. And so what I’m finding myself wondering is, how you articulate your expectations for your team and, considering the nature of our podcast, we’re about design and design leadership, you know, what is your relationship with your head of design? How do you… Jesse: hmm. Peter: …set expectations for them? What are you looking for them to provide? Like, what is that dynamic now that you’re on that side of the conversation? Todd: That’s a great question. I struggled with this for a while. When I first started what I’ve done, over the course of the last, let’s call it six, seven years, I’ve been slowly developing a sort of career framework for product development. It covers engineering, product management and design. It’s a skills matrix. It talks about competencies and skills. It defines the different roles and what the expectations are and the levels of mastery of all the skills of the different ones. And I’ve been kind of modifying and working on it, but I use that a lot. And what I tend to do is, I bring that to the team pretty quickly, because I think it sets out expectations really well. Like, these are literally the expectations I have for you and your role. Here’s what it looks like for you to do the role that you’re in. Well, these are the skills and competencies and you’ll execute them in this kind of way. And I think it’s relatively straightforward. And what I usually do is I say, take this, it’s a table. Add a column, rate yourself one to five. And then I’m going to go chat with a couple of people around the organization. And then I’m going to rate what I think for you one to five and we’ll just have a chat about it. Like, how are you doing, right? And we align on what the expectations are pretty quickly that way, but it has nothing to do with my subjective understanding, right? I’m just like, I use this and they look at it and they’re always like, oh, that makes complete sense. And I’m like, great. It’s not my opinion. Let’s just use this. It usually fosters a really good conversation. But to get really specific, okay. The thing I have done over time is I have learned that if you really value a cross functional team as the core unit of getting stuff done, 50 percent, at least, of the competencies that you have, need to be shared across engineering, product, and design. They need to be measured on the exact same competencies. And they’re things like user understanding, strategic thinking, communication, collaboration. But I break them down and I literally use the exact same ones for all three of the disciplines. And then there’s a set of craft skills that are usually very specific to the discipline. And I found that that is also quite amazing because now most people have the same expectations from me, but from each other. And so that’s a very specific thing I have started doing that I found very powerful and works really, really well. And most of the time, it’s the first time for designers in particular, because we’ve always been trying to get the seat at the table, right? It’s always, the perpetual conversation about designers. And so oftentimes a design leader, when I tell my expectation is that you’re going to do all these things, many of which you’ve already been doing, but just so you know, your engineering leader peer and your product management leader peer have the exact same expectations, all of a sudden they’re like, Oh, I’m at the table, right? Like I’m not, I’m not cordoned off doing something special that only I can do. There’s a set of those things, but mostly there’s a set of shared understanding about what we as a leadership team are expected to bring. That usually works really well for the people I work with that work for me that are design leaders. Peter: So your career kind of gives lie to the whole idea of roles, right? You’ve been very fluid with your roles over time. And the structures that so many organizations place, I think, you’re an indicator of those things are fabrications. And so I’m wondering, as you’re talking about how you’ve set up this professional development career matrix… Todd: mm hmm. Peter: What role roles play in your organization? Because if everybody’s sharing 50 percent stuff, you could just call them product developers and put three to five people in a room and say, have at it, come back to me, when you’re done. Like, where do you see the value of role distinction, given just how much fuzziness you’re trying to encourage. Rethinking Roles Todd: That’s a great question. Yeah, yeah. So the craft and disciplinary background plays out a lot. Let’s say I have 10 competencies for every one of these roles. And let’s say six of them are shared. So there’s four that are specific, that I call a craft competency. Even though it’s less of the competency number, it still plays a huge role in what makes each person bring a unique thing to the table, right? Even though they should share a lot. And so I found that no one is really great at being a generalist at everything all the time. You know, like, I’m a little bit of a successful, dilettante generalist, but I still really, there are things I just don’t do that well. And there’s some things I do really well and I can acknowledge that. And so there are certain kinds of jobs I probably shouldn’t have. Like, I don’t think anybody wants me to be the CTO where there’s also someone who is a CPO. That would be a bad role for me because engineering is something I can help run. I understand engineering well enough, but I only do it really well when it’s combined, right? And so I’m just going to acknowledge, like, that. So I think that what’s important about the role backgrounds is also that what makes a team really effective is the diversity of experience and skill that they bring to the table. And so the roles matter because you can’t make a product with five people with a product management background. You also probably can’t make a successful product for very long with five people who are all engineers. You can, but, it’s less likely. Same thing with designers, right? You need the disciplinary backgrounds, partially because of the skill sets and partially because they’ve been and done different things. So the roles are important. They’re just not the most important thing, right? They help you find people. They help people figure out what path they want to chart for themselves. Where do they want to lean? Where do they not want to lean? What’s expected of someone in a different kind of role? It makes it easy for people to move between a management track and an IC track. It makes it easy for someone to say, I’d love to try product management. And I’m going to be like, great, here’s what’s expected of you, and here’s what’s different from what you’ve been doing. Let’s give it a shot. And after, you know, six months, we’ll go back and assess you and see how you’re doing, right? And a lot of people try it and go back because they realize the craft part of it is something that matters a lot to them, right? But my cultures that I set up do not do a great job of having a lot of folks who are just really, really, really deep in a single thing. Having some is great, but like ratio wise, right, the bigger the organization is you want to have, I don’t know, like, 60 to 80 percent are going to be people who are a little bit more generalist, and then you may have a couple of like super deep design researchers, super deep, whatever, AI prompt specialists, super deep, whatever, market research, or, you know, product management specialists in some special place, right? Over-specializing often makes it hard to collaborate. That’s the reason that I talk about shared competency a lot, because I think collaboration is most important thing. Jesse: I’m glad to hear you talking about this because this has been such a huge theme in my coaching work over the course of the last couple of years with design leaders, as I have been really advocating for them to advocate for being measured on shared outcomes across functions. And for there to be really, you know, shared success cross functionally. And often I meet resistance from design leaders who find that if they don’t have something that is unique to their team, that is their particular value that they deliver that nobody else can deliver, they lose their voice, they lose their power if it feels like the outcomes are shared. In part, sometimes because it makes them vulnerable to having that power simply taken away by other people who can claim those same outcomes. But also I think that it comes back to the sense that their own seat at the table is itself a result of them having kind of created a moat for themselves around their own value delivery in the organization. And I wonder if you’ve encountered this mindset and how you’ve addressed that in the organizations that you’ve built. Todd: A thousand times I have, yeah, like that is such a common thing. And it’s a really hard question to answer but I think there’s two parts. One is the expertise versus effectiveness kind of statement, right? A lot of people establish value in organizations by demonstrating their expertise. And that is a totally valid and very common way for any discipline to establish value. Jesse: Especially a craft discipline. Todd: Correct. Correct. Yes, exactly. And so the fact that that has happened makes complete sense. And a lot of organizations actually explicitly value expertise. And so the organizational culture, the DNA of the culture actually encourages people to lean in on their expertise. What’s interesting, though, is that the vast majority of companies really only care about outcomes when it comes down to it, which is effectiveness. And so the challenge there is twofold. One is the person, if they’ve defined themselves by their expertise versus their effectiveness, it is a great personal risk to ask for shared outcomes and to change things. There’s a personal sort of, like, overcoming fear, taking a risk, trusting in your own value and changing, evolving, but frankly, that flower is not going to grow in every garden, right? It requires an environment that can also support that thing. And that’s actually often the hardest part. This is one of the reasons I don’t go work at big companies very often. Like, I haven’t worked at a big company for a while. And it’s because I’m usually very disappointed by the fact that most big companies take on this, like, expertise focus. It’s like incredibly sort of bureaucratic and like big lines are on disciplines and that sort of thing. And I find that I don’t know how to fix that, right? Because I’m never going to be the CEO of a big company. But I don’t want to go to a little company, which is why I like the growth stage, because there’s an opportunity for me to step in and create a culture that is pervasive. And then people have this opportunity to sort of blossom, right? And it can be done. My one tangent to this that’s really interesting is, I also learned… In between jobs a couple of years ago, I was thinking about what I wanted to do next. And I was like, maybe I do want to go back to a big company somewhere. Like, I liked working like at IBM. I really loved working at IBM in a lot of ways. And I started interviewing, and what I realized was that nobody knew what to do with me, because I did a lot of things. I didn’t fit into the mold, but the other thing was that was when I was looking at a middle management job. But I had really great success talking to companies that were relatively large about C level jobs. I just sort of jumped past the middle management part because the middle management is often in so many organizations settled on this, like, it’s just very segmented and whatever. But companies would hear the culture I was trying to build, or I’ve had built in overall product development organizations, and they’d be like, we need that. So come be our CPO and help create that culture here. Because they recognize there’s just no way for me to even have a chance at it unless I’m there. So I have this kind of weird spot where, like, I know I’d only take C-level jobs in what most people consider a smaller company, but like there are several other companies that were two, three, four, five thousand people that I talked to in the last couple years about C level jobs also and got really close to taking them. But I had no luck at anything that was like a VP. No one had any idea what to do with me as a VP anywhere. What does the C-Suite Discuss? Jesse: Earlier, you talked about the conversations that happen among the C level and among design leaders who… not many of them actually find C level roles for themselves. They are usually on the outside of those conversations. There’s this intense curiosity and this kind of like wondering about like, what are they talking about in there? Like, how is the conversation different at the C level from how it is in these other levels in these organizations. Todd: That varies a lot based on the organization. I mean, the things people talk about, like the topics, all conversations I have ever had in C level, like leadership teams, you’re doing a review of revenue. You’re doing forecasts about sales. You’re talking about budgets and that sort of thing, boring stuff, but that makes the company run. You tend to be talking about major customer escalations and issues. And then people have like a period of time to have the fun conversations, which is usually something like, let’s talk about strategy. What are we going to do in the next quarter or the next couple of quarters? And those are the topics in almost every place I’ve ever been. And that’s also this for board meetings, right? Those are kind of the topics for board meetings often to less of the strategy stuff, more of the reporting, but there’s still a bit of it. Boards kind of want to talk to you about some of those same things. But what I found is the people in those meetings, the people in that leadership team, the nature of the conversation is really different, Jesse: Mm-hmm Todd: right? Like some people go through it, like they’re going through a checklist. It’s like we talked about this. We talked about this. We talked about this. Okay, great, let’s go, you know. And when it gets to strategy, like, what’s interesting, how do we figure out the strategy, right? Here’s what I think, right? And then other places are like, why is this thing happening? I think this is happening because of this. Let’s go confirm that. Because if so, we need to do X, Y, and Z. Like some of them are very… get in. And then when they talk about strategy they want to, like, start where what the customers are asking for, or start with, like, a BHAG, a big hairy audacious goal that they’re trying to get to, and then work back from that, and say like, Oh my gosh, we have to do something completely different if we really want to make that happen. I’ve been in leadership teams that worked in very different ways. Some are more functional, some are less functional. But the things you’re going to talk about are exactly what I said. Jesse: Mm-hmm Peter: You mentioned middle management earlier, and this is something Jesse and I’ve been kind of exploring over the last however many years we’ve been doing this podcast, if not longer, is, as designers grow within an organization, they are often living under an assumption that the people in the C suite or executive level and above know what they’re doing, and there’s a rationale and there’s evidence that’s driving decision making. And then when they hit that middle management, that kind of director level, they look around and they’re like, oh, it’s kind of a bunch of chimpanzees flinging crap at one another. Maybe not that bad. But, like, what you’ve seen as you’ve had your evolution, like, was there an aha moment… Jesse: how much crap was flung at you anyway? Todd: exactly. Peter: If you’ve maybe even had it, but I’m assuming you did right where it’s like, okay, I have this suite of tools, but I can’t just tool my way to success. There’s a dynamic here that I have to learn how to be part of. And how have you developed, embraced, engaged that dynamic in order to succeed where simply kind of reasoning out no longer was enough to quote, I don’t know, win an argument or whatever. Todd: Yeah. So I can draw a really good thread here from actually my days at Adaptive Path. So we did a lot of really interesting design research work at Adaptive Path, helping companies do some kind of risky things. Like usually they came to us and they were trying to do something they’d never done before. And so they really wanted some help understanding that. Some people go do, like, design theater. Like, we go talk to a lot of people and come back and tell you some interesting stories and run some workshops. And you feel, like, something massive, really amazing happened right? And then some people, I think some companies, and I think Adaptive Path always did this was we took it really sincere. Like, we were, like, we want to deeply understand this thing that you’re trying to face. We believe wholeheartedly in the truth we’ve uncovered, and we want to help you make a good decision, at least that was the way I approached it and I felt like that was true for the company. So that’s kind of my thing, like, we have to just feel like there’s some real truth we’re trying to get to here and we need to hold ourselves accountable for it and we can’t just pretend. And so that is a core piece of how I do almost every job I’ve ever had, but as a leader, it’s especially true. And so what happens when I join a leadership team is that I start using that. I’m usually like, Oh, this team has some pretty clear understanding of what’s going on with their business and their customers and some ideas about what to do with it that are grounded in some evidence. And the pieces fit together. And then sometimes I walk in and I’m like, Wow, there’s a couple people here who are very smart and very loud, and they have convinced everybody that they know all the answers. And so people just do what they say, and they don’t really seem to have a lot of evidence around at all. It pivots around a lot based on the person’s thoughts or feelings for the day, right? And in both of those situations, I always establish that we need some evidence and some truth here. I always start off with the like, I could be wrong here. And if I’m wrong, I want to be right. I don’t want to win the argument, right? And, I start a conversation about that. And what ends up happening is either it goes really, really well, and I can give them some tools. I often use design research tools, like, and design tools, like collaboration tools, like how would we work collaboratively on this thing, whether it’s like post it notes and whatever, or we do it digitally or whatever. I use those tools to bring us together to work so that happens. Or I get organ rejection. People are like, we don’t want to work that way, Todd. And… right? Like, basically, and I’m like, well, I gave it a shot, Jesse: I’m in the wrong place. Todd: I’m in the wrong place, right? And, that’s okay. That is okay, right? To me that’s actually the biggest interesting, let’s say, risk I’ve taken by becoming a serial CPO, CPTO is that I’m always coming in and taking someone’s baby. They give me their baby and they say, raise my baby, and they’re either gonna be like, “Thank you, you’re better at this than I am,” or they’re gonna be like, “You’re not raising my baby the right way. You need to leave,” right? And you can’t know these things before you get into it. But I don’t change the way I interact because I know that it works. I just have to find the right environments for it to work in. Identifying the right environment Jesse: So what are the signs of those environments? You know, you’ve talked about some of the things that you’ve identified in terms of an environment that sets you up for success as a leader. It has to be kind of a certain scale at a certain stage in its evolution. And lots of leaders have their own sort of moments that are the right moment for them to engage with an organization, which is like, I’m the right first leader for an organization, I’m the right 10th leader for an organization, or somewhere in between. Todd: And I’m curious about not just that part of it, but really the telltale signs that you have been able to detect. You had a lot of conversations with people about jobs you didn’t take, right? What were you listening for that helped you know that this was a place where you could do the job the way that you saw yourself delivering the most value? So there’s a few things that I tend to look for. Todd: So one of them is, I’m looking for companies where the business mechanics are not complicated. Everybody on the leadership team, everybody can just tell me, this is how our business works, basic mechanics and here’s it’s profitable or is very close to profitable. That’s why it’s a good business. That is the thing I always look out for. If, most people can’t explain to me kind of how the business works and where the margin is, then I’m usually worried that that’s an organization that will not hold up to investigation from me, and we can’t rest everything else on that, right? ‘Cause like I talked about, like, basics of the business are important to me. If I can’t talk to just almost anyone, they can’t explain it to me. That is a telltale sign for me that there might be an issue for me. The other thing is a sort of culture of transparency, which is, if, in my interviewing process, like NDA and whatever, right, if someone’s not willing to open up the spreadsheet and show me the last three quarters worth of budget, spend, sales, with all the warts, if they’re not willing to be like, oh yeah, I got it, let me open up, let’s talk it through, that is often a sign to me that is not going to be a good place for me because I’m a very transparent, right? Like I, grew up in that era of the internet where like everything’s a collaborative tool and everything’s open by default as far as I’m concerned. And so I use that as a sign. And then for product development in particular. When software’s involved, the ratio of engineers to everybody else is always quite high. And so understanding the engineering culture is really important. And so I always look for signs that the engineers are not insular. They are actually open to true collaboration, because they will always be able to circle their wagons and win compared to everybody else. There’s just so many of them. So, I always look for signs of that. I talk to senior leaders, and then I try to always talk to at least one, like, just engineer and just get a sense. How do you work? What do you think about these people that you’re working with? Sometimes I’ll ask them to show me their Slack. Like how are your Slack channels set up, right? Is most of the engineering conversation in a hashtag engineering channel, or is it, or is it in a, right? Or, or is it in a, product team channel, right? Like, these are really simple things that I can just ask somebody to do. And if somebody’s like, no, I’m not gonna show you my Slack, then like that gets back to my transparency thing. Those are signs that I find that I can work really well with a company, if that’s the case. But if you don’t see those things, I tend to find that I’m not a very good match. Jesse: I’m imagining that there are a lot of design leaders out there listening to this, who are excited about the possibility of wielding the kind of organizational influence you’ve been able to wield, to be able to step into the kind of authority you’ve been able to step into, but have a hard time seeing what the next step is for themselves, or in particular, I think potentially feeling bound to the identity of design in a way that makes it hard to step out of and let go of. And I wonder what thoughts or reflections you have for those folks on your trajectory out of design as a formal responsibility toward this. larger holistic sphere that you now take ownership of. Todd: I mean, the first one is going to sound maybe trite, but it’s like, you have to be a little bit more confident than smart, a little, you know, like you have to be willing to do something that… you have to take a couple of risks, like calculated, but you need to be willing to take some risks to do something, like, so I, like I say, one of the most foundational moments in my entire life and career was when I convinced y’all to let me go open a second studio in Austin, right? And like, it was a terrible idea for you to let me do that, but, but you’re willing to give it a shot. Right. Like I was going to go run part of the P&L and I’d never done that before, but I tried to lower the risk for you. You let me try it. But the fact that I was able to try that thing and work it out, that moment of being, like, I owned, part of a multi-million dollar P&L for a little while, was a toe in the door to a lot of other conversations I was interested in approaching later and that was a big risk I took. And then I’d say the other thing is, like, in all honesty, the first two or three kind of like VP level design and, actually, product type jobs I took, I kind of really screwed them up a lot. And I was able to, like, look at myself and be, like, I’m really screwing this up. I need to really reflect on why I’m screwing this up. Like, they gave me the shot, which is amazing in and of itself. But I was like, I actually need to get good at the thing that they gave me to do. And once I was able to really acknowledge that about myself and look for the places I needed to improve, and how to talk about them to other people, that was a huge win for me, in being able to change my trajectory, right? Like, in this sense, I almost like cheated my way into the job, in a way, like, you know, song and danced in my way into the job. And then I had to get good at it. So I say that in the sense of like, not everybody can do that, but that was the best way for me to do things. And because like, I, said, I’m kind of designery, like I got to go start making the thing. I got my hands in it and that’s how I learned how to do it. I could have read a whole bunch of books, but it was never going to get me there, like trying it. But I had to be willing to have it blow up a little bit, and be self reflective about when I was doing a good job or not. The craft of Product Management Peter: I want to go back to something you said earlier and tie it to something that Jesse and I have been talking about for 15 years. So earlier you mentioned, you know, kind of the three roles within product development, design, product engineering, maybe, you know, if there’s 10 skills or capabilities or whatever, they share five or six of them. And then four or five are specific to the craft. Todd: Hmm. Peter: That begs the question. What are the craft skills of product management? I can imagine. I know what the craft skills of design are. I can imagine what the craft skills of engineering are, but always get stuck on the craft skills of product management, but I then find myself wondering, this harkens back to something Jesse and I’ve been going on about, this phrase, the experience is the product, right? And that, what we are delivering at the end of the day is an experience for our users. And so I more recently have turned that into product management and user experience being very similar. User experience, not design, but user experience being very similar. And so I’m wondering, kind of, where you have arrived at in terms of what makes product product, what are those four or five things, and then what is product management’s relationship to user experience, maybe different than a product development team, or would you argue that the whole product development team is responsible for the user experience? Todd: The latter. User experience is one of those like just general, that’s the outcome. It’s a shared outcome of characteristic of the product or what have you. I think the team should be sort of essentially equally responsible for creating great user experience. ‘Cause great user experience is a mix of: Does this solve a real problem for me? Does it address a job to be done? Does it do it in a sort of delightful, usable, whatever way? And then is it very responsive and reliable and elegant? Like all the pieces fit in to make a great user experience. I do think product managers need to think a lot about user experience. I encourage all my product managers, I always say, when you’re putting together the early stages of an initiative or piece of work, if you haven’t sketched something out, you haven’t thought about it enough. Peter: Which of course would make a lot of designers very nervous when product managers start drawing, but that maybe.. Todd: It’s a, it doesn’t have to be pretty, right? And when I say sketch the thing I mean in particular, I’m like, if you haven’t thought about the flow of screens and steps, if you haven’t thought a little bit about how the thing you’re imagining kind of fits in, you’re not really doing your job as a product manager. Like you don’t need to work out all the details. And in fact, your designer will probably be better at it, but there’s no way that you’re going to have a conversation meaningfully if you haven’t engaged in that a little bit. I tell product managers the same thing about engineering. I’m like, if you haven’t thought or can’t sketch out the basic architecture of our product and what the basic objects are in the database, you haven’t thought about it enough, right? If you don’t have an opinion, at least a little bit you probably haven’t really thought about it enough. I don’t want you to code it. But you got to care about it enough to have thought about it. And so if you roll that back, then you start to say, well, what does a product manager do uniquely? Since I’m just talking about stuff they share. So my trite answer is I always tell people I think of product management as a maker job, not a manager job, even though it has the word management in it. And so people say, well, what does a product manager make? And I say, they make decisions and they make clarity. That’s what they make. They make decisions and they make clarity. And when I say they make decisions, they actually make decisions possible. They don’t have to make the decisions. They make clear decisions possible. And then they make clarity for people. They reduce ambiguity. They, you know, Brandon Schauer used to always say like crushing ambiguity. That’s a product manager’s job. Designers do this really well too. Engineers do this really well too. But for the product initiative as a whole, it’s fundamentally the product manager’s job to make sure the pieces are all getting pulled together, the ambiguity is being crushed, so that we can make decisions together. And so, I look for things like: Can drive decisions with a cross functional group of people. And that kind of grows from, you can set up the characteristics and criteria for decision. And it moves to, you can drive the decision with your team members, to you can help drive decisions across multiple teams to where you can drive decisions with executives, right, like as somebody grows in their group. But that decision making drive is really important. Can reduce the ambiguity and create clarity around user needs, business outcomes and feasibility decisions. But the idea there is that they have to be able to make the decision criteria and the decision super clear, right. If anybody’s sitting in a room arguing about whether their perspective is the right one or someone else’s, the product manager has not succeeded in making the decision criteria clear. Because in most cases, the decision should almost make itself, right? In most cases, it should never come down to who’s got the biggest paycheck or who’s the loudest person. And if that’s what’s happening a lot, then your product manager is not succeeding at making the decision criteria clear, to reduce the ambiguity. So people are willing to take a risk or make a decision to move forward and so there’s lots of pieces. Roadmaps are essentially the same thing. Roadmaps are me saying, I’m going to set in place over time, that helps you understand what we’ve all decided on, or considering doing holistically as a group, right? And most of the time it’s more certain on the next quarter and it gets less certain as you go out. And that’s fine. You just want to make sure that everybody understands the criteria for why something is on that list and why something’s not on that list. No one should ever be coming to you, begging you, I’ll take you out for a beer, if you put my favorite thing on your list. You’re like, like, no, no, no, like, the stuff on this list follows these very clear criteria and we really understand the ones on this side and we understand the ones out here a little bit less, but I’m comfortable saying that we’re going to be going in roughly this direction because it meets these criteria, and we’ve reduced enough of the ambiguity that we can move. So I have a few skills and things tied to that, right? Like when I talk about roadmapping, I talk about it in those terms. It’s not just, can I make a pretty thing with a bunch of horizontal lines on it? It’s like, can I align people around the fact that we really do all agree on it, and we know why we agree. Jesse: You know, Peter and I have been talking for a while on this show about how the relationships between these functions are continuing to shift, and the mandate of design is continuing to shift as our understanding of how to do this work continues to evolve. So I’m wondering from your perspective, what’s next for design? Todd: Selfishly, I would really love, what I think should be next for design, is that people with design skills and experience are able to really step into roles of leadership and companies that may or may not have the word design on them. I think there’s a lot more opportunity for that these days. I think that the nature of how especially software gets developed is changing, like, even the technical skills are not nearly as differentiating as the ideas and moving quickly and learning, and those are all things that designers do really well, right? And so what I would like is that more people take career paths that are kind of like mine, not because I think I’m perfect or that it’s great, but because I think it’s what the world needs, right? The world needs people with those kinds of skills that can move very quickly, that are great at understanding both the human and the sort of, let’s call it, roughly, technical space. And they shouldn’t be locked in something that’s got the word design on it. You know, like you’re a journalist, Jesse, right? Like you’re, you know, but you’re a designer, right? You know, like, and you’re a podcast host and you’re a coach, right? Like your background is design and journalism. But what you’re doing is really different. Like that you’re a success story in some ways of this as well. Jesse: Todd. Thank you so much for being with us. Peter: Thank you. This has been great. Jesse: Where can people find you on the internet? Todd: Toddwilkens.com is probably the easiest way. T O D D W I L K E N S. com. You can get a hold of me there pretty easily. It talks a little bit about some of the work that I do. I’m not a very social media kind of person, so. Jesse: It was great to talk to you, Todd. Thank you so much. Todd: This was really great. Yeah, thanks guys. Jesse: For more Finding Our Way, visit findingourway. design for past episodes and transcripts. You can now follow Finding Our Way on LinkedIn as well. For more about your hosts, visit our websites, petermerholtz. com and jessejamesgarrett. com. Peter recently launched The Merholz Agenda, his semi weekly newsletter. Find it at buttondown.com slash petermerholz. And if you’re curious about working with me as your coach, book your free introductory session at JesseJamesGarrett. com slash free coaching. If you’ve found value in something you’ve heard here today, we hope you’ll pass this episode along to someone Else who can use it. Thanks for everything you do for others, and thanks so much for listening.…

Finding Our Way

1 year ago52:48