Why Your Cross-Functional Team Isn't Communicating Effectively (And How to Fix It)

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 .

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 .

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 . 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 . 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 .

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 . 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 .

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 .

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 .

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 .