Influence Without the Title, with Jenny Wanger (A Chat with Cross-Functional Experts)

Why do product teams stay misaligned? Jenny Wanger explains the structural problems: efficiency-focused handoff workflows, unclear strategy, and people left cleaning up decisions they didn't help make. She shares tested practices for influencing upstream decisions without formal authority: clarifying strategy through curiosity, bringing the right people in early (pre-mortems work), and publicly recognizing collaborators.

Key Takeaways

• Fire drills and half-finished features often stem from lost customer context in handoff-driven workflows
• Use curiosity, not criticism, to surface strategy gaps - Interview leaders and highlight missing pieces
• Run cross-functional pre-mortems early; rank risks by likelihood × impact, not opinion
• Make others look good publicly (CC their boss); build a reputation as someone worth inviting

Timestamps

• 02:42 The Misalignment Before Picture
• 05:05 The Handoff Trap
• 17:00 Strategy Gaps & Curiosity
• 23:00 Pre-Mortems & Early Involvement
• 32:00 First Steps

Resources

• Jenny Wanger: jennywanger.com | LinkedIn

Your Challenge
Pick one: Share a kudos with someone's manager, approach a colleague about a past bottleneck, or volunteer to run a pre-mortem.

Work with Dianna I help product development teams build quality into the front end when it's cheap and easy, not late when it's expensive and painful. 

Book a 20-minute discovery call with Dianna's calendar. Whether you're navigating the "fuzzy front end" of product development and want to explore a workshop or advisory partnership, or you'd like to be a guest on this podcast. You'll leave with a summary, relevant resources, and a clear path for next steps within 24 hours. 

Pierce the Design Fog (piercethedesignfog.com): my book on aligning cross-functional teams, defining clear design inputs, and accelerating product success. NIEA Finalist Award, reviewed by PDMA. "Great for fans of Tony Fadell’s Build, David H. DeWolf and Jessica S. Hall’s The Product Mindset."-BookLife Reviews (Publishers Weekly)

Connect with me: I'm most active on LinkedIn. 

Free Resources for Subscribers Subscribe to the Quality during Design digest — https://newsletter.deeneyenterprises.com — for monthly actionable highlights, plus access to the Strategic Quality Integration Checklist (a free self-assessment download) and my Swipe File Vault.

Transcript

Copy Transcript Copied

Dianna 0:00

Getting alignment in product development is harder than it sounds. Teams stay misaligned because they don't share a clear picture of what they're solving for, why it matters, and how their piece fits. The consequence? Fire drills, half-finished features, and people who feel like they're cleaning up someone else's mess. Jenny Wanger works with product organizations to redesign how teams actually operate so they can execute on strategy. One of the most powerful tools she uses is getting the right people into the room at the right moment, not after decisions lock, but before. Today, she walks us through how to do that, especially if you don't have formal authority to demand a seat at the table. Her ideas work whether you're engineering, quality, manufacturing, or sales. Let me introduce Jenny more formally after this brief introduction. Jenny Wanger helps product organizations navigate major transitions, AI transformations, reorgs, mergers, and leadership changes by redesigning how teams operate so they can actually execute on the strategy. She also coaches senior product leaders navigating these changes. Her clients describe the shift as something you can feel: alignment, clear direction, and a product org that's finally humming. She holds degrees from Harvard College and MIT Sloan. Jenny, I'm so glad you joined us on the Quality during Design podcast. Welcome.

Jenny 2:11

Hi, Dianna. Great to be here

Dianna 2:14

I've been reading your articles and seeing your presentations, and you have a lot to say on influence without authority. So I'm really glad that you could join us today to talk about how to influence upstream engineering and design decisions. And, we're going to learn how the software experts do it today. So thanks for joining me for this important topic.

Jenny 2:37

Yes, of course

Dianna 2:40

What does the before

The Misalignment Before Picture

Dianna 2:42

picture usually look like when teams are struggling with alignment?

Jenny 2:46

Yeah. So I think, uh, there, there's a couple of different things that, that you'll see, right? I'm thinking about, uh, one, one client that I worked with recently where they didn't have a clear direction on where they were trying to take their product, and why where they were And so therefore, where, how the product was com- was contributing to the overall picture of the company. And what that one looked like was a lot of fire drills where they had to stop and pivot, right? "Oh, we were going to go and work on this, but nope, now this is more important. And okay, now we're, we're getting somewhere on this thing, but then we decided, wait, no, maybe we should be working on this thing." And the way the CEO described it to me, he said, "We've got five things we've started in the last year, and all of them got to 80% and none of them have actually gotten out the door." Right? And so you've got this thing where there's a lot of activity, and there aren't actually the outcomes to go with it, and I think that's one form of what you'll see when you're struggling with alignment. Another thing I'll see in, in different organizations is the statement of like, "Oh, well, it's a real- it's really political here." Right? There's a lot like, you gotta know who to go to, or you know, this person is like, they're always trying to undermine you. Watch out for that. Things like that where it's just this, this constant, um, finger-pointing and there's a, just, there's just a lack of trust. Uh, and so y- when you have that a You know, when you're aligned, you all know you're headed towards the same thing, and it just, it's a much healthier work environment as a result of that

Dianna 4:36

Along the lines of the, of the political alignment, um, I've heard other people, I call them the cross-functional team for product design, so it's marketing, sales, manufacturing, quality. I usually hear this phrase from them is, "I wish the designers had involved me earlier." This seems like a persistent structural problem across industries. Why do you think that is? Um, you mentioned the political and the lack of trust.

Jenny 5:04

Actually

The Handoff Trap

Jenny 5:05

my, my first product job I, I was in manufacturing too. I worked at Steelcase many, many years ago, uh, in furniture manufacturing, and everything that you hear on the factory floor is efficiency, right? Safety and then efficiency. And I think it's very much the same thing in product development. And when you over- when, when you over-index towards speed and efficiency, there's this thought, right? And I saw this at an- at an ed- ed tech company I was working with a few years ago, uh, where they were really focused on how fast can we get this out the door. And so they said, "Okay, you're gonna take this part and you're gonna work- you're gonna do the upfront design, 'cause that part's slow and it take- it means you gotta talk to lots of customers and learn this and learn that. And once you know all those things, then pass it over to this team, and they'll actually build out the content related to it." And they're, you know, like, they're experts in building content, and so we're gonna and we do this with, with software engineers a lot too, right? Like, you figure stuff out and then give it to the engineers so that they can build it. And we're gonna try to max the way we get the most value out of our engineers and our content designers is if we can keep them hands on keyboard, writing the content, writing the code all the time. And that's There's this thought of, like, that's the most efficient way to do it. That's the way we can get more stuff out to market faster. But that absolute fixation on efficiency actually ends up slowing you down, because what was happening at this company is that the first person was going and they were talking to customers, and they were hearing all of the subtle stuff of like, "Yeah, I wanna learn about this, and specifically in this angle and I like to learn things in this way, and here's how I interact and with content, and I'm usually in my car so I need it to be repeated a lot because I'll miss this when I'm making the turn," right? And the, like, all of these little subtleties. The report that this person writes up that they pass over to the content designer just says well, they wanna learn m- you know, more about this particular networking service, uh, and here are the things they don't know about it. And so the content person goes and starts writing, and then they're making all of these assumptions 'cause they weren't actually in that conversation. And so it's this drive towards speed where you end up then relying on handoffs, and that's the structural issue here, in software we actually talk about it as the factory mindset, but it's not the Toyota factory minds, right? It's not TPS. Um, this is like, you know, old school Ford factory- of um, each person has their individual job and they have to be on, the more that they are doing that one job all the time, the better. But you can't design that way successfully because you lose the context. And so you can't treat all of that upfront design work in that same, handoff oriented, you do your job, I'll do mine kind of mindset

Dianna 8:04

Yeah. Yeah, so the, that drive towards speed leads to a lot of those assumptions, and that lost context like you're talking about. So I mean, as a result of all of that, um, what are some of the other downstream costs that you've seen?

Jenny 8:22

Yeah, I mean, the biggest problem is you build the wrong thing.

Dianna 8:25

Yeah

Jenny 8:27

Right? At least in software, if you're lucky and you build the wrong thing but you pay attention to the metrics, you notice that you've built the wrong thing before, um, before everything really turn, really goes south. But at the end of the day if you're not collaborating in what you're building, it really does end up that you ship something that doesn't make sense. And so that was what was happening at this ed tech company, is their products were just not landing with their customers. the lucky thing is when you can go back and try again and iterate a little bit, right? but it's a huge, a huge cost. Uh, and then also all of those people who are not being included upstream and are just sort of being given an idea that's thrown over the wall, right? It's not really a way to make them feel like valued members of your team and your company, so you're gonna i've seen a lot of places where that has, that kind of treatment has higher turnover, right? Where you're not retaining your employees as much, you're not getting the most out of them because they kind of feel like it's their job to clean up the mess that other people make for them. Um, so yeah, there's real costs to it

Dianna 9:44

Yeah. Yeah, and then and then also, if you do ship it, then you have those other people that are trying to sell something that's not a good fit or answering to the customers that they've built a base with. Yeah, those are lots of problems. So then some lessons from software development then. So software development has spent the last decade or so trying to solve this exact bottleneck. So what are some of the most translatable lessons or frameworks from software that physical product or systems engineering teams can adopt?

Jenny 10:28

Yeah. I mean, it's funny 'cause we spend so much of our time talking about what we can learn from physical engineering teams.

Dianna 10:35

Oh, really?

Jenny 10:36

oh, we absolutely, right? Like, a, a huge conversation in our world is prototyping and how, like, well, can you sketch something out and try it? And I think a lot of that philosophy came really from physical pro- right, like, can you make a cardboard prototype before you actually go, you know, and then 3D print something, and go through the steps to figure out what you need to build ahead of time. And we look at that process, and we've brought that in, I think, as a big practice in digital design now of, like, okay, well, let's first sketch something out on a sheet of paper, and then we'll, build it smoke and mirrors. And I mean, now with AI, you can kind of just tell your AI to go ahead and build the whole thing and see what happens. But, uh, even there we still look at it as a prototype before we go through the work of making sure that it's scalable and, uh, a hardened piece of software that'll, that's secure and can handle, thousands or millions of users as opposed to that first prototype where you don't really care if it breaks after 10 people use it. Uh, so we spend a lot of time looking at manufacturing and seeing things that can be brought over. some of the things I would think, like, that I think are really, that, that could be really applied here is a durable, dedicated team to a single mission and really being outcome focused. So the You know, product manager, design, and engineering are the three core roles within the team. Um, engineering in this case being software engineer. And the th- the trio is responsible for driving a particular outcome. So maybe it's that we're trying to get more users signed up for our product or for our, uh, service, or we want to, um, see, you know, more people reaching success with this particular thing for the ed tech company, right? They wanted to see more people actually getting through the entire course and passing the exam at the end. So it was really, dri- driving towards particular things that you want to have happen. And the way that we always do it is that you have that team then figure out what the solution looks like. And the more successful... I think a lot of companies that really do well with this, the company leadership is focused much more on what's the company strategy, right? Where are we, um, where are we going? And so, like with that company I mentioned at the beginning where the CEO said, "Yeah, we've got a whole bunch of stuff at 80% and nothing going over the finish line," the first thing we actually went to work on was, okay, let's make sure that everybody's totally clear on what our strategy is. And so we sat down and walked through, we are working on solving these particular problems. Uh, here is why we think these are the most important problems for us to solve. And really it was a services company, so they were in accounting, right? And so we said the point of this technology is to allow the accountants to not have to spend their time on double-checking that they put the numbers in correctly, right? The numbers should just be there, and they should be able to trust that those numbers are correct so that they can actually do the, the hard part, which is the thinking through what the strategy should be for their clients. And once we articulated that, that, like, the goal is to create, you know, right now our strategy is this level of trust, is this, you know, that there aren't problems in the system, that they know that the data is right, then we were able to look at all of those 80%-done projects and we were able to prioritize them. And say like, "Oh, now..." Right? Like the engineering and product team could now look at that and they could say, "Oh, well, this thing that we never finished is actually the most valuable thing we could do because it's about automating how we get that data in. And if we can get it so that they're not doing any manual entry, if they're not doing data entry, then obviously there's gonna be fewer typos. And then all of these other things that we were working on, yeah, those are cool, but they're not gonna get us there." And so having that strategic focus and then the team that was dedicated to a particular outcome made it really much clearer what to work on.

Dianna 14:38

So now with this these different projects that were only getting 80% done and none of them were making it, were they all for one particular product? That's, so they were like, uh, goals or projects that they had started but never finished?

Jenny 14:53

Yeah, the way we talk about it in software is that they were a bunch of features that were all for one product. So, you know, you can look at a product as a suite of different things, right? if you think about your email that you've got, you know, you've got the inbox, you've got the composers that you can write new emails, you've got your contacts list because that's, right, like you need to know who you're emailing, right? So each of these is a feature in the email product. And then under the hood, you've got all of these additional features that allow you to actually send emails and receive them and all of the infrastructure there. Um, and so yeah, all of these 80% things were new features or enhancements to the basic suite of things that could have been done. And, you know, th- lo and behold, there's always more you wanna do. Oh, wouldn't it be cool if we could add this? Um, and I think, that's one thing where, um, software's a little bit different 'cause there's almost never a marginal cost to adding additional things versus in manufacturing obviously, right, you have to always be balancing, well, is it worth adding in that extra feature because it's going to also change the underlying manufacturing costs and complexity of, um, of how we build. So a zero marginal cost world is a little bit of a different space. I think those are some of the big things to think about is like what's actu- you know, really making sure that the team is anchored to an outcome much more than they're anchored to, oh, we've gotta build this thing. Um, and figuring out then how do you get we're all responsible for different pieces of this puzzle, and we have to do it together because any time you're gonna shift, um, you know, for that integration with making all of the data automatically show up, there were still things where you have to think through like the, the design experience of that, right? Do they approve the stuff before it gets written to the file to make sure that there isn't a mistake somewhere else in the system that's getting propagated? How do you let them know when things are in there and that they are automatically in, right? All of this stuff contributes to the experience. Um, it's not just the technical engineering

Strategy Gaps & Curiosity

Jenny 17:00

of put column A in column B.

Dianna 17:04

it sounds like you're talking a little bit about the review process of changes, and I do wanna come back to that. Uh, but I wanna go back to the outcome focused and the strategy because many engineers start with product requirements document or customer needs. But it sounds like the outcomes and the strategies are mostly linked to what customers experience and the business needs. Is that right?

Jenny 17:35

Yeah, I would say that the role of product management in general, you talk about it as sort of finding the optimal alignment between the business needs and the user needs, right? and the sort of classic thing as well, if you asked your users, "Hey, would you like this for free or would you like to pay for it?" They're always gonna want it for free. But you can't run a sustainable business on giving everything away for free all the time.

Dianna 17:58

So I would imagine that just recognizing that there is that kind of a gap, that there's not a link to the outcomes and the strategy is one particular skill set that you'd watch for. But when you recognize that that's missing what are some of the first steps that you do to rectify that? Um, is it through the team? Is it talking with other managers? How do you handle that?

Jenny 18:27

there's a couple of things that I've learned over the years. One is that, um, if you go around and tell people that they don't have a strategy, it's a very fast way to get yourself completely ignored. There was one company I was working at where, uh, this was the case, the strategy was, well, we have this technology and this IP, and we're gonna just monetize it. And I was like, "How are we gonna monetize it?" And they're like, "We're gonna monetize it."

Dianna 18:55

This is getting back into circles, huh?

Jenny 18:57

yeah. And so I brought the other product managers together. I was like, we need to figure something out here because all of us are just sort of running around guessing, and there's nobody, in charge here. And so we sort of sat down and sketched out an idea. Well, we could do this and that, and if we put these things together and this, then yeah, we've got a strategy. And I took it back to my manager. I said, "Here you go. We put together a strategy for you." And the utter look of disappointment on his face when I did that Um, e- every manager thinks that they have a strategy, whether or not they do, right? And every company thinks that they are being strategic. And if you go to them and you say, "You're not being strategic, you have no strategy," you know, in this case I was lucky that I just got a performance review saying that I was abrasive. Um, but, uh, I think in other cases it could be a more, more serious outcomes than that. And so what you always have to do is you go to, you go to the leader and you say, "I know you've got a strategy and we've talked about it some in meetings, but I feel like it would just be so much easier for me to work on it, it and to support it if we had it written down. one of my favorite tricks, "Can I interview you about your strategy? And then I'll write up the document and you can share it with whoever, or it can just be used for me. But that way we've got it written down and we've got something to, that, th- those of us who need to read something to process it, it would be really helpful." And usually the leader's like, "Oh, you wanna know, you want me to talk more about my brilliant ideas? Why, yes, of course." Um, and so you then, you run the interview and at this point in time, right, like, you just, you know, you can work, record it and transcribe it, let your AI take the notes and then translate it into a strategy. And there's always gonna be a situation there where there are some gaps left behind because especially, like... And sometimes you're lucky and they actually have a strategy, but they've just never articulated it very well. And in those cases voila, you now have it and you can share it, and you can give it back to them and let them share it out further. Uh, but a lot of times there's going to be some major holes, and that's where you can use that interview. You can be, "And what about in this situation?" Right? And you can see what you can get out of them, and if they don't give you answers, it's your opportunity. That's actually a really big opportunity for you to start to have some voice in it, right? And you can, you c- as you're writing up your doc, you can put in what you think is the missing piece of the puzzle, and you can highlight it with a comment, right? "I just put this in. Is this the right thing?" Um, get that back over to them and get them to react to it. And at least by getting reaction to it, you now have a lot more clarity. And so it's a way to nudge the leadership towards, um, becoming stronger communicators about their strategy. It gets you much better understanding, which allows you to be more effective. And hopefully you end up with a document or th- with some kind of material that you can, share and circulate, uh, that can help others in the organization also have that kind of alignment

Dianna 22:11

So, would you say it's, um, approach the gap with curiosity? And and to try to, try to understand, um, what's there and what's missing?

Jenny 22:22

Yeah. a lot of times leadership has access to data that you don't have access to. I think that was one of the things with that role where I said, "You don't have a strategy," um, where I, there were things going on behind the scenes, and there were different pieces in play and different outcomes we were driving towards than what I saw. but I have used this skill in other organizations. another technique to use that I've done before is I say, "Okay, I'm gonna write up a strategy for my area, and I want you to review it, and then make sure that it f- it aligns with what you're trying to achieve as well." And that can be another way where they say, "Okay, well yeah, I see how like

Pre-Mortems & Early Involvement

Jenny 23:00

these pieces work, but then over here this is actually not gonna work and here's why. Because over here we're trying to do this other thing and this counters that," right? the more that you can make sure at least that your team that you're working with when you're, designing these products understands here's what we're trying to do, this is what's really important, um, and here's why it's important right? That there's the full context around what you're trying to build. And I always say that the context has to be both the why and the how. we're trying to build this new product, it's going to be used by these people, and it needs to have these features to it for it to be considered a useful product. But if you don't include the why of why this product, both for what it means for the company as well as for why the person you're building for wants that product, again, right, this is another case similar to that ed tech company where you're missing all of that user insight. Um, you're gonna end up building the wrong thing

Dianna 23:59

And then we're back to all the downstream problems we've been talking about.

Jenny 24:04

Right.

Dianna 24:04

so if you're starting and you got a good handle on the outcomes and the strategy, uh, and you mentioned that, um, as you're making changes or as you're going through iterations you're following a process to make sure things are being reviewed. So what happens-- what's important to happen during that process to make sure that we're still applying influence without authority, uh, or inviting other people in? How do you handle the process part of that?

Jenny 24:40

Yeah. So I think, I mean, I think you've really said a lot of it, is that make sure that you're bringing the right people into the room. Um, so a good example of this is SpotHero. Which is a parking app, right? it's a, an app where you can, you know, if you're going downtown for a work m- meeting or dinner, you can reserve a parking spot ahead of time and pay for it, so you just scan your app and get into the garage. I was working there for a number of years, and I really learned how important that is because there was the time that I launched a new feature, and I didn't tell customer service about it ahead of time. and my thought was, oh, well, we're just, you know, a lot of times what we do in, in software is we'll release to a small percentage of our users. So we'll release to 10% of our users ahead of time, make sure it works, see how they react, make sure it hits our outcomes, and then we'll ramp up until we've released it to everybody. And I think I said, "Well, I'm just releasing it to some of these people, and so, like, it'll be fine. Um, it's not that complicated. It's not very confusing. It's just, you know, I've, I've moved this section around a little bit so that it's easier to follow and easier to read." Uh, except that customer service started getting calls, and the phone started lighting up 'cause there was a bug.

Dianna 26:08

Oh

Jenny 26:09

everybody's getting these error messages. I realized how much of a disservice I had done them, right? That I had not warned them that this was going out, and then when there was a bug, right, because they didn't know who had r- you know, what was happening or what had caused these issues, they didn't even know who to report it to. So now we've got customer service people who are scrambling to figure out who to let know that there's a bug so that we need to roll it back and fix, you know, make the fix. And it was a really good lesson of, like, even if it's a small change, even if you think it's not gonna affect them at all, you really have to loop everybody in who's gonna be involved in this. And I learned from a bunch of other ones there, right? I learned to show customer service the prototype and actually do a user feedback session with them. Because it turns out that since they were the ones who were always fixing issues, they could look at a design and they'd say, "Oh, well, people are gonna get confused by that word." I'm like, "Well, that, no, that word is totally clear." And they're like, "No, I promise you, that word is going to be confusing to people, and here's why." "They're not gonna be able to find this button because you have to scroll to get to it." And I'd be like, "Well, we have to scroll to get to it because we have to put all this stuff beforehand." And they're like, "Well, then, it's not gonna work." And they've, they had talked to so many people that they had just the most valuable instinct about our product of anybody. So I learned that back to making sure that what you actually put out in the world is the best product you can, the more that you call these people into the room who have that knowledge and talk to them ahead of time, uh, the better it goes. And we even started formalizing it into doing a pre-mortem, uh, before we started the development process, where we would say, "Okay, here's our goal. This..." We, it was once we had, like, a maybe a 50% idea of what we were gonna be doing, 50 to 80%. "This is the direction we're gonna go. These are the pieces we're gonna put in it. And here's what we're trying to achieve and why." And we'd have customer service in the room. We'd have design engineering, product, marketing, sales, uh, operations, right? Ev- we'd try to get g- good representation across the entire team. And we'd say, "What's gonna go wrong? Imagine that we're 90 days after we've launched this. What went wrong?" And everybody from their experience can say, "Oh, well, this is gonna go wrong," or, "Here's gonna be a different problem." And we were able to actually then rank the issues by how worried we were about them actually happening, right? Sometimes somebody would say, like, "Well, imagine that, you know, we had a fireball that landed on the garage that we're testing with, so the garage is no longer able to park cars." I'm like, "Okay, I don't think we need to worry about the fireball,

Dianna 28:55

There's always someone in a group that does that, yeah.

Jenny 28:58

but, you know, uh, but, but it's, it's, it's a yes and experience, right? So you like... You say, like, "Okay, maybe it's not gonna be a fireball, but maybe there is going to be a power outage, so you can't... Like, the gates aren't gonna lift up for the garage. And so what do we do if there's a power outage?" Which is a very legitimate concern. And so that's where, you know, saying, being positive and saying those yeses is really valuable. And that exercise was always a great way to make sure that everybody's voices were heard before it was too late.

Dianna 29:32

that does sound like a great review process, and I like that you ranked everything by how worried you were about it. So that probably, that helped the engineers make trade-off decisions. Is that right?

Jenny 29:44

Yeah. Well, it, it absolutely, and it, it's, it's, we did a classic two by two, right? How likely is this to happen and how impactful would it be if it did happen, right? A power outage at the garage, pretty impactful for that one garage, but we could also redirect everybody to the garage next door. So not tremendously impactful. Also low likelihood. There aren't power outages all that frequently. So we could say like, okay, we're not gonna be worrying too much about this one. But customers not finding the thing because they can't scroll to the page, they're having trouble scrolling, high likelihood of happening and high impact because it means the entire thing we're building won't get used. So that meant like, okay, we need to actually, we do need to solve this to make sure that the thing that they need to see is not something you need to scroll to. it was an exercise to be able to then come up with the list of, yeah, what are the things where we need to design around it? What are the things where we're gonna, we're willing to take that risk, that, the trade-offs are worth it for us to not solve for that particular issue

Dianna 30:45

So about what percent got added after you would have that kind of a meeting? I'm, I guess I'm trying to talk about the value of having all those different representations in the room to talk about this. Did you find that it was surprising the things that people added or things that, uh, engineering hadn't even thought about or product management?

Jenny 31:11

There were always things that had never been on my radar.

Dianna 31:13

Hmm.

Jenny 31:14

Um, right, sometimes engineering would say like, "Well, I'm worried because this particular database wasn't designed for handling a high volume of searches, so it's going to crash." And which is not something that I had thought about, and so we, it, that, that would be one direction. The customer service is gonna bring in other things. Marketing is gonna say, "Well, if, one of my worries is that if we don't market this ahead of time and we just launch it, people are gonna be surprised and confused. So we should make sure that we actually are planning ahead." this pre-mortem meeting actually was the moment to then, you know, cue to marketing, like, "Hey, this is your opportunity to get ahead. We're telling you now before we've even built it that it's coming." so they can't say, "Oh, you didn't tell us. why are you surprising us by launching this

First Steps

Jenny 32:00

all of a sudden?" So it also is a good chance to get things on people's radar. But I think a little bit of what your question is of how do you tell the value of this, is the challenge of any quality person trying to prove their value.

Dianna 32:16

Yeah.

Jenny 32:17

Right? It's the You, you can't say, "Hey, look at the five disasters I averted," because the disasters never happened. this meeting is, it's the software version of quality because we've had this conversation, we know these risks. maybe we would've designed around a bunch of them anyway, and that's often happens in the meeting if you can check a bunch of them off. Yeah, we've already accounted for that one. We've accounted for this one. So these, these are ones that we don't need to pay attention to. Uh, and then there's al- there are always some that show up but there's always the what, you know, well, how likely is the power outage? How likely is the fireball? and so there is a certain point where in quality you just have to trust that the investment is worth it, and that it's preventing disasters, and that's all you can do.

Dianna 33:07

Yeah So if somebody listening wants to take the first step, if they wanna stop being, stop waiting to be invited to the table upstream, first low-risk move that they could make tomorrow

Jenny 33:24

as we've talked about as sort of a theme here is start with curiosity And if you can find somebody who's upstream who's running into a problem, and you can help them solve it, and maybe solving it is because you're getting involved a little bit earlier, and so you can see around a corner that they weren't gonna see around, that's you showing your value, right? And they're gonna want you then to come and solve that problem next time too. And so maybe it's approaching a colleague and saying, "Hey, I remember for this, you know, for this last thing we were working on that we all got caught up in this particular, you know, this, this particular challenge really tripped us up, and it caused several weeks of delay. I wanna make sure that we're not going to hit that same delay this time. Can we sit down and have a talk now and just make sure, you know, let's do a review for that. Uh, let- let's make sure we're not gonna get surprised by that same thing, and I can help you with that." And especially when you're coming up to somebody and you're saying, "Hey, let me take this off your plate." The more that you can phrase it and make something of I'm gonna make this less work for you, and I'm gonna take it on, You know, I'm gonna make you look better, the more likely it is to help. one of the th- other things I really love to do is I love to try and highlight other people's wins,

Dianna 34:54

Hmm.

Jenny 34:54

right? So if somebody does something, um, where they brought you into a meeting you know, early, right? And you appreciated that. You say to that person, you can say, you know, publicly, right? Communicate it out in whatever formats, forums make sense at your company. Uh, send out a message or send a message to their boss and CC them and just be like, "Hey, I just wanted to say this person just ran an awesome meeting. I really enjoyed talking about X, Y, and Z, and was glad to be able to be a part of it." And if you make that person look good in front of their boss, they're gonna invite you back. public praise of other people is another really strong move for, helping them, uh, want you to be there more

Dianna 35:43

So curiosity and also just, I guess an eye toward being helpful, even if it's some kudos to their boss.

Jenny 35:52

I would say it's not an even if it's kudos to their boss. that's a great thing to just get in the habit of doing as much as you can of like, "This person's doing awesome." let their boss know, and it's a good way to get some visibility into the work you're doing, right? 'Cause that boss might be like, "Oh, well, this person's getting praise for bringing you in their meeting early. Maybe I should also check with my other reports and make sure they're bringing their counterparts in early 'cause look at this. It's working."

Dianna 36:18

Well, so that could be a whole trickle-down effect,

Jenny 36:21

it can be a, it can be a whole ch- or yeah, you know, you get a reputation for being the person to go to early to get extra help. Um, you're creating a reputation for yourself, too. So I wouldn't say it's an even if. Like, it is a key, a key move to make, uh, to unlock some, some of that, uh, that access

Dianna 36:41

it's been a pleasure talking with you. Where can listeners go to learn more about your work and read your articles like I do? Or connect with you? Where's the best place they can do that?

Jenny 36:52

Yeah, absolutely. So I'm on LinkedIn, um, Jenny Wanger, W-A-N-G-E-R and at jennywanger.com. Uh, both of those places you can sign up for my newsletter from my website. And, uh, I would love to I would love to have some more conversations about the overlaps between software and manufacturing. I think it's a really Fun exchange of ideas and the different ways that we both, uh, support and think about the challenge it is that, of turning an idea into something real. And we go about it in different ways, but a lot of similarities too

Dianna 37:31

That concludes our interview. Here are the three moves Jenny keeps coming back to. First, start with curiosity, not judgment. If you see a problem upstream, approach it as, "How can I help?" Not, "You're doing this wrong." Second, bring the right people into the room early. Show up before decisions solidify. Offer to run a pre-mortem. Review a prototype. Loop in the folks who will have to live with the consequences. Third, make others look good publicly. When someone brings you in early, tell their boss. When a decision gets made collaboratively, recognize the people who made it possible. It builds culture, and it builds your reputation as someone worth inviting back. Your challenge for this week is to pick one. Share a kudos with someone's manager, approach a colleague about a past bottleneck you could help prevent next time, or volunteer to facilitate a pre-mortem on an upcoming project. Don't try all three, just one done well. This has been a production of Deeney Enterprises. Thanks for listening