Hi it's Dianna Deeney. We do work with cross functional teams or we have cross functional team meetings. But then nothing much comes from it. We don't get what it is we need for product design or we barely have contact with our team until after we're far along in the design and then it blows up. Our design doesn't match with their expectations, and this is a problem. We're not getting what we need to design against before or at the time that we're designing. So what do we do about it? Let's talk more about stepping up after this brief introduction.
Hello and welcome to Quality during Design, the place to use quality thinking to create products others love for less. Each week we talk about ways to use quality during design and product development. I'm your host Dianna Deeney. I'm a senior level quality professional and engineer with over 20 years of experience in manufacturing and design. I consult with businesses and coach individuals and how to apply quality during design to their processes, listen in and then join us. Visit qualityduringdesign.com.
So we're working with our cross functional team and we're not finding value in it. We're not getting what it is we need. Or worse, we're just waiting for the phase gates or technical design reviews to get their input on what it is we've been working on by ourselves for months. This is a communication problem, which then morphs into a product development problem.
Let me tell you a story about a communication problem that I think that you'll be able to relate with. I was a board member on an HOA and the HOA managed the outside of the buildings, including the roofing and the landscaping. We met quarterly. That's four times per year. One of my neighbors, one of the other homeowners. Came to the fall meeting prepared with a complaint. The complaint was that there was a butterfly Bush that the landscapers had planted years before overgrowing, and it was next to her front door. Now butterfly bushes. If you're into landscaping, they are very fragrant and they attract a lot of butterflies and other things. Like other bees and other bugs, so this Bush was growing next to her front door, and it was overgrown, and it was crowding her front door and covered with bees. She was allergic to bees. She was afraid of going in her front door. She would sort of dive into it. She came prepared to this meeting to describe all about her problem. And her question was, why doesn't anyone cut back my butterfly plant? Don't they see that it's crowding my front porch? The HOA is supposed to hire the landscapers and tell them what to do. Why isn't anybody helping me? My neighbor waded through all of the summer months through all of this growth of this butterfly push and waited for an HOA meeting to complain about it, and to finally ask for help. So I said of of course we can take care of that and I wish that next time you would reach out to someone on the HOA board to ask for help earlier instead of waiting for a meeting. And I reminded her that we're neighbors, we would have arranged for something to help her, but instead she kept herself and dealt with it until a formal ho a meeting. On the other side of that, as part of the board, members of the HOA, is there something that we could have done to make it easier for her to communicate with us?
How does this story relate to product development and design engineering? As engineers, we may see things like, "Why don't they like my design?" or, "Why don't they tell me what they need instead of waiting until we're nearly done?" And that has to do with communication with the cross functional team, getting those design inputs. On the other side of that, our cross functional teammates, including quality and reliability, say things like, "Why didn't the engineers involve me earlier in the design? I could have helped them with that. It looked like they had a lot of problems. I have experience or ideas that could have made it easier for them." Or, worse,, they say things like, "Why don't the engineers design what I want?" or, "This design makes it so much harder for me and it didn't need to be."
As design engineers, we don't want to wait until phase reviews or formal meetings to work with our cross functional team. We want feedback and input for our designs. We want that input to be able to design against. If it's information that we need, then we need to be able to go get it, and that involves figuring out a way to get design inputs from a cross functional team.
Think of your cross functional teammates as your internal customers to your design and you are doing research into what it is your internal customers need or think they need out of the design. It's a form of self advocating. There was a previous episode of the Quality during Design podcast titled "How to Self Advocate for More Customer Face Time, and Why it's Important", and it is important! I'll link to that podcast episode in the blog for this one. In that episode, we talked about getting involved with those external customers, the end user meetings that our companies have, the discovery meetings and the customer interviews and even the usability testing. Engineers getting more involved with that interface with external customers. The insight to action from that episode is that there's certain things that we can do. To help us self advocate for that customer experience so that we can get the design inputs that we need. Those same kind of steps also apply when we're working with our cross functional team or our internal customers. And those things were preparation, getting involved and knowing our role, keeping an open mind, and doing something with what we've learned. Let's go over each one of those in relation to working with our cross functional teammates and our internal customers for design inputs.
Preparing involves figuring out what it is you want to learn. You've heard this before when you're trying to accomplish something: have the end in mind. So by the end of whatever discussion you want to have, you want to have learned about "this", and get specific. The way we can get specific about doing this is by doing some pre work. You can choose a quality tool to get started and that will help us identify what it is we need to learn. That quality tool can also help us facilitate the discussions with our cross functional team. In many of the cross functional team meetings I've facilitated, there's only been a few times where I came unprepared, where I haven't had the end in mind and I didn't do some of that pre work and those handful of times were not very useful or constructive, so preparation. And what it is you want to learn and what you want to get out of the discussion and also preparation of your cross functional team to be able to discuss and have ideas about what it is you want to discuss. Both of those are very important.
The second step was get involved and know our role. In the case of asking cross functional teammates or co-working with them for design inputs, design engineers may want to facilitate the meeting. I mentioned using a quality tool to help with preparation. These quality tools also act as frameworks for team to work around, have discussions around. Using a quality tool like that can help you with facilitating. And you can also get help with facilitating by setting up a process. At Quality during Design, we use ADEPT: align, discover, examine, prioritize and teamwork. Those are not only steps, activities that you can take with your cross functional team as you're meeting with them, it's also the kind of things that you want to target. You want to target alignment. You want to take time to discover and examine, and you can prioritize what's important.
The 4th important aspect was to keep an open mind. The most important thing to think about when you're working with your cross functional team for design inputs is this: we're not looking to eliminate ideas, we're looking to develop ideas into the best solution we think there could be. Sometimes this is different than the typical engineering approach. We do expand our thinking and look at different alternatives. But then we quickly want to narrow down and make decisions: the design, about the components, about the layout, and etc. - all things engineering. When we're working with our cross functional team in order to get design inputs, we want to ensure that we have the mindset that is more open. We can handle ideas systematically with our team so that we can get maximum benefit out of it. We can do that around the quality tool that we choose. But we want to approach activities with the spirit of developing creative ideas. So saying things like, "Well, that's a great idea. What can we do to make it work?" or, "What is it about this idea we can use?" If we approach our cross functional teamwork from a viewpoint of, "I want to learn from this other person who has different experiences and few points than I do. I'm going to ask them questions and gather their ideas so that we can decide together, come to a consensus on what the best solution might be for this product."
The last thing is just to do something with what we've learned. I've participated in some useful meetings where things happened, decisions were made, there was a lot of consensus. Everybody had aha moments. We felt good leaving the meeting and then I don't know, something just didn't happen with what it is we learned or what it is we developed. Nobody took the time to capture what it is we learned so that we could do something with it. Or the things that we learned... we decided there are different priorities in our day and we didn't implement what we learned. So that's the last important step of working with the cross functional team. Things are going to happen. People are going to have discussions, there's going to be a lot of ideas. You need to be able to collect that and come to a consensus of what it is you're going to do. What are you going to do with this information? Are you going to translate it into a design input? Do you need to do more investigation into something that someone brought up, to even see if it's a viable solution? Is there more research that needs to be performed on a particular topic? These action items are really important coming out of a cross functional meeting because you want to be able to have them be constructive.
So what's today's insight to action? We may have access to a cross functional team or to people that would be on a cross functional team. We may meet with them once a quarter or during phase reviews or official meetings that are part of the product design development process. When we're working in the design space and collecting those design inputs, there are times where we're going to need to work with our cross functional team to really understand the concept space and the product ideas so that we can start developing the design. But this isn't typically something that they're just going to give us. We can't be like my old neighbor who is just hoping that somebody would notice that this butterfly bush was causing her a lot of angst. We want to be proactive, reach out.
We know what it is that we need for design. Our cross functional team doesn't. With a little pre work and being willing to step up to be a facilitator to ask those questions. We can avoid a lot of the communication problems that lead to product development problems.
On qualityduringdesign.com, there is a podcast blog. It's not just the podcast episode, it's also show notes and transcripts and links to other episodes. And like I promised earlier, I will link to that other episode of the podcast where we talked about self-advocating for end user customer interfaces. There's also the catalog of all the other podcast episodes that we've published in the last 2-1/2 years. Please visit the website and explore what we have to offer. This has been a production of Deeney Enterprises. Thanks for listening!
As a product designer, you need design inputs. Many of us have communication problems with our cross-functional teams about product ideas which then morph into product development problems later.