Quality during Design
Quality during Design is a production of Deeney Enterprises, LLC. It is a podcast for product designers, engineers, and anyone else who cares about creating high-quality products. In each episode, we explore the principles of quality design, from user-centered thinking to iterative development. We introduce frameworks to make better design decisions and reduce costly re-designs. We explore ways to co-work with cross-functional teams. We also talk to experts in the field about their experiences and insights.
Join host Dianna Deeney in using quality thinking throughout the design process to create products others love, for less. Whether you're a seasoned designer or just starting out, looking to improve your existing designs or start from scratch, Quality during Design is the podcast for you.
Quality during Design
Why Your Cross-Functional Team Isn't Communicating Effectively (And How to Fix It)
Have you ever watched a promising product idea slowly die in the fuzzy space between "great concept" and "actual development"? You're not alone.
The journey from product idea to market-ready solution contains a critical yet often overlooked phase: concept development. This is where cross-functional teams must align their diverse perspectives to create a solid foundation for design. But as many product developers discover, this is precisely where communication frequently breaks down.
In this episode, we dive deep into why cross-functional teams struggle to communicate effectively during early concept development and how to fix it.
By creating collaborative moments, you'll transform how your team approaches concept development. You'll uncover insights that might otherwise remain buried in individual reports, align on priorities more effectively, and build stronger foundations for subsequent development phases.
Join the conversation and share your experiences on the blog. Or send us a text at the link above.
BI-WEEKLY EPISODES
Subscribe to this show on your favorite provider and Give us a Rating & Review to help others find us!
MONTHLY DIGEST
Subscribe to the free monthly e-newsletter: newsletter.deeneyenterprises.com
Get the short version on Linked-In: Subscribe here.
SELF-PACED COURSE FMEA in Practice: from Plan to Risk-Based Decision Making is enrolling students now. Join over 300 students: Click Here.
About me
Dianna Deeney is a quality advocate for product development with over 25 years of experience in manufacturing. She is president of Deeney Enterprises, LLC, which helps organizations optimize their engineering processes and team performance by promoting the use of reliability and quality methods during design. She offers consulting services for managers and directors, training for engineers through the Quality During Design program, and other practical resources.
Hello, welcome to the Quality During Design podcast. I'm Diana Deeney. Your business, your company, your team has come up with a product idea that's going to solve a customer's problem. I mean, this is the next big thing that your group wants to develop and be able to manufacture and provide to people. But right now it's still just a product idea. It really hasn't been fully developed yet. Last week we talked about the hidden costs of poor concept development and product design and we kind of pegged concept development as that fuzzy front end area between hey, we've got a product idea and hey, these are the design inputs that we need to design against. You know, after the design inputs we can gather all those things and figure out how to actually make it, what the features are, form, fit and function, that sort of thing. But in concept development it's still early. Now we ourselves can't bring a product idea and design it and make it and market and sell it all by ourselves. It takes a team of people, a cross-functional team, and sometimes they don't always communicate well in early concept development. So this episode we want to talk about why we're not communicating effectively and things we can do to fix it. After this brief introduction, hello and welcome to Quality During Design, the place to use quality thinking to create products others love for less. I'm your host, diana 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 qualityduringdesigncom.
Speaker 1:Welcome back to the episode. We're talking about cross-functional teamwork and early concept development. We've identified a product idea and we don't know where to go with the next. Everybody's sort of off on their own zone of genius. Marketing is looking at it from a marketing standpoint. Sales from theirs, manufacturing may not know exactly how to get involved yet, but they're very knowledgeable about limitations and capabilities that they currently have or being able to identify what they need to develop and design well. Usually when people want to design things, we kind of go off to our corner and like to do a deep dive with ourselves, and that can be beneficial. There is a place for that. Maybe not a concept development, because we've got this fuzzy design idea. Nothing's really defined yet. But if we work with our cross-functional team and do it well, then we're going to be able to have better design inputs and a better design for our customers to use later, and we want to work with our team and do concept development well because of all the things that we mentioned in last week's episode, all those things that we can measure success of our project against. But working with people on a team can be difficult. But then working with people on a team that think very differently from us and may have different priorities and different expectations out of this project can also be difficult.
Speaker 1:Some of the things that happen with cross-functional teams and early concept development is that everyone's producing their own reports looking at this product idea from their own point of view, but then everybody needs to come together to sort of align on everything, and to do that you need to have a conversation. Reports I'm all about reports. They're a very good exercise to do and it's also good documentation to refer to again later. But these reports allow us to capture all the details or to stop and think about if we've captured all the details. Not just the details, but also linking together some of those ideas and details. Report writing and putting things in a format to share with other people not only helps the other people that will read it, but it also helps the author to come to some conclusions and to better understand what's happening and their recommendations and why they're making those kind of recommendations. So there really isn't a substitute for reports. Reports still need to be written and they're still a good thing to do for the author and then also as a cross-functional team member, producing costing reports and you may be part of producing a technical feasibility study, with all of those things in the early phases of a project.
Speaker 1:Do you really read everybody else's report? As a responsible cross-functional teammate, you should at least read them, scan through them, and no, it's not your zone of genius, but you're going to be learning things about the expectations of this product which is going to affect your decisions. So, yes, read and understand. If it's TLDR too long, didn't read or if it's really not anything that you've seen before, you're not familiar with some of the terminology then you really don't have any excuse. We can load it into an AI, use Google's Notebook LM, or if it's proprietary and you're concerned about that, I'm sure there's AIs that you can use through your company that keeps all that stuff in-house.
Speaker 1:But any case, get those reports, look at them, read them, try to educate yourself a little more on their point of view. So even if you do that, even when you do that, there are still some limits with how far we can take that information to develop a concept for product design, if only because there are a lot of assumptions happening. There are a lot of assumptions you're making about what the other people are coming to the table with. They have a lot of assumptions about what it is that you know and how you're coming to this. So there are assumed baseline knowledge and there's assumed consistent understanding of similar ideas. And just assuming things and not talking about it, not getting on the same page and being intentional about that can introduce problems with cross-functional teams.
Speaker 1:So one of the first things is that people produce reports. They're good, they're useful. First of all, we need to read them, but they really are no substitute for a conversation. So we want to have a conversation for a conversation. So we want to have a conversation. But getting updates and just typical check-ins with each other or individually just doesn't work. If you're working on a new project and marketing created a report summarizing the market analysis and market needs for that and you read it, and then you go, stop by their desk or set up a Zoom meeting and just talk with them about it. You can do some check-ins about that, but a lot of times people well, they're busy, they don't have time for that. They say go read my report, I put it all in there.
Speaker 1:Bigger than that, though, is that the interfaces of all these different moving parts that need to be aligned in order for a project to actually happen those interfaces are getting ignored, they're not being talked about. It's difficult to do that one-on-one with one person to another. It's better to have a conversation with the team. The other thing with these individual check-ins is that we're not top of mind. So they may have created a report or did a study and shared it with everybody, and the project's moving forward, but then, oops, something came up. They heard about something else in the field that is applicable to this project and they kind of peg it, but then it doesn't immediately get shared. So those typical check-ins and update meetings where everybody just gives a status update isn't really working toward concept development. We can miss those important interfaces, and the knowledge that needs to be shared just isn't top of mind. And add to that the reports that we're creating and all the assumptions that are happening, and we're getting a lot of misfiring communication and not really aligning on concept development. So giving updates and those typical check-ins don't work.
Speaker 1:So we recognize we must hold space for focused conversations with our cross-functional team. When we have a focused working meeting with our team, they bring their whole selves, their diverse viewpoints and experiences that relate to what the customer wants, the characteristics of the use, environment and what is best for the business. This is instead of what they filtered down into what they felt was important in a report, in a summary, in an email or as a status update. So we decide to have one of these conversations about concept development. Let's get our team together and we'll talk about and develop this idea into a concept that we can further develop design inputs against. Well, when you get in the room, what do you talk about? There is no product to talk about. There is a customer that we can talk about. So just getting together in a room isn't enough. When we facilitate these working meetings, we have to provide a scope and a common focus. That then provides an opportunity for the team to address important information that otherwise might get forgotten or overlooked. Back to the original problem at hand is we have our cross-functional team, but we're not all communicating effectively during concept development. So a way we can fix that is through facilitated, focused conversations with our team.
Speaker 1:Concept development's main purpose is to share knowledge. If we don't facilitate discovery meetings, no matter how often we meet with our teams, we won't have shared what we need to about concept development. We can't control what other people think, say or do, or when they do it. What we can do is to provide an opportunity for discussion and focus when we're looking for information about a concept. Providing working meetings to explore the use space provides the team and the designer that chance. In that space we're not only generating ideas, but we're also getting feedback from our teammates.
Speaker 1:Just relying on our design control process or our product development process isn't enough. We also can't call a meeting without a plan and then just hope it works out. We need a plan to work with others to gain the targeted information we need for design inputs, and this helps them and us to share their knowledge and helps us to close that feedback loop. So what's today's insight to action? If our cross-functional team isn't communicating well in concept development, it's probably because we're not taking the time or putting in the effort to do co-work with them in facilitated, focused meetings where we can share ideas, gather feedback and prioritize those ideas for design inputs. For more information, visit the podcast blog on this episode and this has been a production of Dini Enterprises. Thanks for listening.
