Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:01):
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 tosolve a customer's problem.
I mean, this is the next bigthing that your group wants to
develop and be able tomanufacture and provide to
people.
But right now it's still just aproduct idea.
(00:22):
It really hasn't been fullydeveloped yet.
Last week we talked about thehidden costs of poor concept
development and product designand we kind of pegged concept
development as that fuzzy frontend area between hey, we've got
a product idea and hey, theseare the design inputs that we
need to design against.
(00:43):
You know, after the designinputs we can gather all those
things and figure out how toactually make it, what the
features are, form, fit andfunction, that sort of thing.
But in concept development it'sstill early.
Now we ourselves can't bring aproduct idea and design it and
make it and market and sell itall by ourselves.
(01:03):
It takes a team of people, across-functional team, and
sometimes they don't alwayscommunicate well in early
concept development.
So this episode we want to talkabout why we're not
communicating effectively andthings we can do to fix it.
After this brief introduction,hello and welcome to Quality
(01:23):
During Design, the place to usequality thinking to create
products others love for less.
I'm your host, diana Deeney.
I'm a senior level qualityprofessional and engineer with
over 20 years of experience inmanufacturing and design.
I consult with businesses andcoach individuals and how to
apply quality during design totheir processes.
(01:44):
Listen in and then join us.
Visit qualityduringdesigncom.
Welcome back to the episode.
We're talking aboutcross-functional teamwork and
early concept development.
We've identified a product ideaand we don't know where to go
with the next.
Everybody's sort of off ontheir own zone of genius.
(02:06):
Marketing is looking at it froma marketing standpoint.
Sales from theirs,manufacturing may not know
exactly how to get involved yet,but they're very knowledgeable
about limitations andcapabilities that they currently
have or being able to identifywhat they need to develop and
design well.
Usually when people want todesign things, we kind of go off
(02:28):
to our corner and like to do adeep 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 ourcross-functional team and do it
well, then we're going to beable to have better design
(02:50):
inputs and a better design forour customers to use later, and
we want to work with our teamand do concept development well
because of all the things thatwe mentioned in last week's
episode, all those things thatwe can measure success of our
project against.
But working with people on ateam can be difficult.
But then working with people ona team that think very
(03:13):
differently from us and may havedifferent priorities and
different expectations out ofthis project can also be
difficult.
Some of the things that happenwith cross-functional teams and
early concept development isthat everyone's producing their
own reports looking at thisproduct idea from their own
point of view, but theneverybody needs to come together
(03:34):
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 todo and it's also good
documentation to refer to againlater.
But these reports allow us tocapture all the details or to
stop and think about if we'vecaptured all the details.
(03:56):
Not just the details, but alsolinking together some of those
ideas and details.
Report writing and puttingthings in a format to share with
other people not only helps theother people that will read it,
but it also helps the author tocome to some conclusions and to
better understand what'shappening and their
(04:16):
recommendations and why they'remaking those kind of
recommendations.
So there really isn't asubstitute for reports.
Reports still need to bewritten and they're still a good
thing to do for the author andthen also as a cross-functional
team member, producing costingreports and you may be part of
(04:43):
producing a technicalfeasibility study, with all of
those things in the early phasesof a project.
Do you really read everybodyelse's report?
As a responsiblecross-functional teammate, you
should at least read them, scanthrough them, and no, it's not
your zone of genius, but you'regoing to be learning things
about the expectations of thisproduct which is going to affect
(05:07):
your decisions.
So, yes, read and understand.
If it's TLDR too long, didn'tread or if it's really not
anything that you've seen before, you're not familiar with some
of the terminology then youreally don't have any excuse.
We can load it into an AI, useGoogle's Notebook LM, or if it's
proprietary and you'reconcerned about that, I'm sure
(05:29):
there's AIs that you can usethrough 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 moreon their point of view.
So even if you do that, evenwhen you do that, there are
still some limits with how farwe can take that information to
(05:51):
develop a concept for productdesign, if only because there
are a lot of assumptionshappening.
There are a lot of assumptionsyou're making about what the
other people are coming to thetable with.
They have a lot of assumptionsabout what it is that you know
and how you're coming to this.
So there are assumed baselineknowledge and there's assumed
(06:13):
consistent understanding ofsimilar ideas.
And just assuming things andnot talking about it, not
getting on the same page andbeing intentional about that can
introduce problems withcross-functional teams.
So one of the first things isthat people produce reports.
They're good, they're useful.
First of all, we need to readthem, but they really are no
(06:36):
substitute for a conversation.
So we want to have aconversation for a conversation.
So we want to have aconversation.
But getting updates and justtypical check-ins with each
other or individually justdoesn't work.
If you're working on a newproject and marketing created a
report summarizing the marketanalysis and market needs for
that and you read it, and thenyou go, stop by their desk or
(07:00):
set up a Zoom meeting and justtalk with them about it.
You can do some check-ins aboutthat, but a lot of times people
well, they're busy, they don'thave time for that.
They say go read my report, Iput it all in there.
Bigger than that, though, isthat the interfaces of all these
different moving parts thatneed to be aligned in order for
(07:20):
a project to actually happenthose interfaces are getting
ignored, they're not beingtalked about.
It's difficult to do thatone-on-one with one person to
another.
It's better to have aconversation with the team.
The other thing with theseindividual check-ins is that
we're not top of mind.
So they may have created areport or did a study and shared
(07:43):
it with everybody, and theproject's moving forward, but
then, oops, something came up.
They heard about something elsein the field that is applicable
to this project and they kindof peg it, but then it doesn't
immediately get shared.
So those typical check-ins andupdate meetings where everybody
just gives a status update isn'treally working toward concept
(08:07):
development.
We can miss those importantinterfaces, and the knowledge
that needs to be shared justisn't top of mind.
And add to that the reportsthat we're creating and all the
assumptions that are happening,and we're getting a lot of
misfiring communication and notreally aligning on concept
development.
So giving updates and thosetypical check-ins don't work.
(08:29):
So we recognize we must holdspace for focused conversations
with our cross-functional team.
When we have a focused workingmeeting with our team, they
bring their whole selves, theirdiverse viewpoints and
experiences that relate to whatthe customer wants, the
characteristics of the use,environment and what is best for
(08:50):
the business.
This is instead of what theyfiltered 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 ofthese conversations about
concept development.
Let's get our team together andwe'll talk about and develop
this idea into a concept that wecan further develop design
(09:14):
inputs against.
Well, when you get in the room,what do you talk about?
There is no product to talkabout.
There is a customer that we cantalk about.
So just getting together in aroom isn't enough.
When we facilitate theseworking meetings, we have to
provide a scope and a commonfocus.
(09:35):
That then provides anopportunity for the team to
address important informationthat otherwise might get
forgotten or overlooked.
Back to the original problem athand is we have our
cross-functional team, but we'renot all communicating
effectively during conceptdevelopment.
So a way we can fix that isthrough facilitated, focused
(09:59):
conversations with our team.
Concept development's mainpurpose is to share knowledge.
If we don't facilitatediscovery meetings, no matter
how often we meet with our teams, we won't have shared what we
need to about conceptdevelopment.
We can't control what otherpeople think, say or do, or when
(10:20):
they do it.
What we can do is to provide anopportunity for discussion and
focus when we're looking forinformation about a concept.
Providing working meetings toexplore the use space provides
the team and the designer thatchance.
In that space we're not onlygenerating ideas, but we're also
getting feedback from ourteammates.
(10:41):
Just relying on our designcontrol process or our product
development process isn't enough.
We also can't call a meetingwithout a plan and then just
hope it works out.
We need a plan to work withothers to gain the targeted
information we need for designinputs, and this helps them and
us to share their knowledge andhelps us to close that feedback
(11:04):
loop.
So what's today's insight toaction?
If our cross-functional teamisn't communicating well in
concept development, it'sprobably because we're not
taking the time or putting inthe effort to do co-work with
them in facilitated, focusedmeetings where we can share
ideas, gather feedback andprioritize those ideas for
(11:27):
design inputs.
For more information, visit thepodcast blog on this episode
and this has been a productionof Dini Enterprises.
Thanks for listening.