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.