May 15, 2025 • 16 mins
The hidden costs of poor product development can devastate your project timeline, budget, and ultimate market success. Drawing from Dr. Robert Cooper's research, this episode reveals how skipping proper concept development—the critical "fuzzy front end" of product design—leads many teams into a costly "ready-fire-aim" approach.
Most development teams dedicate a mere 16% of project time to concept work, despite evidence showing successful products allocate 75% more resources to these early activities. The consequences? Designs repeatedly scrapped or substantially modified mid-development, wasted engineering hours, multiple unnecessary prototypes, and products that fail to meet customer expectations.
Through practical scenarios and comparative timelines, I demonstrate how proper concept development using Quality During Design methodology can reduce engineering time by 35% and design iterations by 60%. By engaging cross-functional teams early and using visual frameworks instead of multiple physical prototypes, you'll not only save time but develop products with significantly higher chances of market success—up to three times more likely, with 38% higher market share and better customer ratings.
This approach doesn't mean endless planning without action. Rather, it's about focused teamwork that addresses customer needs, use environments, and potential risks before diving into detailed design. The result? More efficient development, stronger team alignment, and products that genuinely solve customer problems. Visit the blog for additional resources to transform your product development process and start creating products others love for less.
Visit the podcast blog.
DISCOVER YOUR PRODUCT DEVELOPMENT FOCUS: UNLOCK YOUR IMPACT
Take this quick quiz to cut through the 'design fog' and discover where your greatest potential lies
BI-WEEKLY EPISODES
Subscribe to this show on your favorite provider and Give us a Rating & Review to help others find us!
SELF-PACED COURSE FMEA in Practice: from Plan to Risk-Based Decision Making is enrolling students now. Join over 300 students: Click Here.
MONTHLY DIGEST
Subscribe to the free monthly e-newsletter: newsletter.deeneyenterprises.com
Get the short version on Linked-In: Subscribe 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 perform...
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:00):
You're working in new product development in industry
.
You're designing things andpart of a team that's helping to
design things that people finduseful and safe, make people's
lives easier.
It's a great space to work in.
Anything worth doing isn'tnecessarily easy, and that's the
case with product development.
A lot of the challenges that wehave in product development can
(00:22):
stem from our lack of conceptdevelopment, which is that early
phase of product development,before we've even really
designed anything.
There are many hidden costs ofpoor product development in
product design.
Let's talk more about those andways we can combat them or
address them after this briefintroduction.
(00:43):
Hello and welcome to QualityDuring Design, the place to use
quality thinking to createproducts 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 on how to
apply quality during design totheir processes.
(01:06):
Listen in and then join us.
Visit qualityduringdesigncom.
Product development is a greatspace to be working in.
It's very rewarding.
You get to create and designthings, work with other people
and, with the products that youdesign, make people's lives a
little better and, with theproducts that you design make
people's lives a little better.
It's exciting when somethinggets developed and it makes it
(01:29):
into the hands of the customerswith success, and that's really
what we all want when we're onthese product development teams.
We want to be designing anddeveloping things that are
success.
It isn't always easy.
In fact.
We could be developing anddesigning something that we then
share with the team and theydon't really like it.
It gets picked apart.
(01:49):
All that work that we've donejust wasn't worth it.
It's trashed, or we have tochange so much of it that we
really have to start over again.
Or we're in the middle ofproduct development and we
realize that uh-oh, we have amissing customer need, that we
didn't address, a regulationthat we just happen to not be
(02:09):
meeting, or other unforeseenthings that just happen to
happen that make us need to justchange the design in
mid-development.
There are a lot of situationsin where projects just don't
meet expectations.
They don't meet theexpectations of the engineers,
the cross-functional team, ourcustomers.
These are all challenges inproduct development that we face
(02:32):
.
Now, not all, but many of thechallenges relate to concept
development or our lack ofconcept development.
Concept development is thatfuzzy front end of product
development.
Now we have already have aproduct idea, we have customers
that have been identified, theproject has been approved.
(02:53):
We may even have done apreliminary technical
feasibility study.
Then we get into conceptdevelopment, actually developing
ideas about what this designcould be.
Dr Robert Cooper authored how toWin at New Products.
He identified some of theroadblocks with concept
development, or some of the lackof concept development, and he
(03:17):
related it to the end result ofwhat really happens with our
products.
And these are some of thehidden costs that we recognize
but maybe we don't realize howbig they are, how costly they
are, when we don't do conceptdevelopment well.
Based on Dr Cooper's studieswith teams that had a
(03:37):
well-defined product prior tothe development phase, they were
over three times more likely tobe successful with their
project and they also have ahigher market share by 38 share
points on the average, and theirproducts were rated better by
their customers.
So their customer perceptionalso increased.
So well-defined product priorto the development phase leads
(04:01):
to success, market share andcustomer's perception, not by a
little bit but actually by a lot.
I know that even in conceptdevelopment we don't have a
well-defined product prior toactually design development.
We're actually developing aproduct in concept development.
But Dr Cooper's studies alsoshow that sharp, fact-based
product definitions beforedevelopment begins also leads to
(04:25):
products that are more likelyto succeed, and that solid,
upfront homework, includingactivities that precede
development, also significantlyimpacts success and market share
.
But here's the thing many of usaren't doing this early homework
, this concept development, orwhen we're doing them, we're not
(04:45):
doing it to the level that weshould.
Cooper shows that only 16% ofperson days on a project is
dedicated to early work.
So, even though conceptdevelopment is really important
to do, only 16% of our time on aproject is spent doing it.
Quoting Cooper, in too manyprojects we observed new product
(05:07):
idea that moved directly intodevelopment with very little in
the way of upfront homework todefine the product and justify
the project A ready-fire aimapproach.
Dr Cooper further describesthat teams move ahead into
product development withoutcustomer requirements or
customer input, move ahead intoproduct development without
customer requirements orcustomer input.
(05:28):
Comparing successful productsto failed products, successful
ones have about 75% more timededicated to these
pre-development activities.
So we're not spending enoughtime in concept development and
it's costing us.
But I know when we get an ideaor we get an ask the things we
really want to do is startcreating and start designing.
We'd rather be on our workbenchmocking up a prototype or
(05:52):
building something and be ableto get iterative feedback from
our team on it.
In that case, we kind of feellike we're developing as we're
designing, but that can backfirealso.
But that can backfire also.
Doing that is still designingtoo early and can lead to those
problems that we talked about atthe beginning of the episode
Designs being picked apart, lateconcepts changing
(06:14):
mid-development, wasted time andmoney and just projects not
meeting expectations.
The other thing we don't wantto do is just to spin our wheels
and not make decisions and notmove forward with a project.
But by jumping into action andinto designs too early, we're
skipping this conceptdevelopment phase and we're
(06:36):
missing out on opportunities,opportunities for our product to
be in the market, to make it tomarket and to be successful.
Product to be in the market, tomake it to market and to be
successful.
We want to spend more time inconcept development, but we want
to make it worthwhile.
We actually want to bedeveloping a concept.
So how do we balance this withdesign, especially in a product
(06:58):
development lifecycle, and howdo we do this with our
cross-functional team.
Well, we need to be intentionalabout our concept development.
We need focused teamwork.
We can use visual frameworks totalk about concepts and ideas
and to prioritize those ideas,and we can use quality ideals
(07:21):
that's a capital Q quality tohelp us navigate the whole
process.
And that's what quality duringdesign in D&E Enterprises is all
about being able to work withyour team in early concept
development using some qualityprinciples.
It's a philosophy thatemphasizes the benefits of
(07:42):
cross-functional teaminvolvement in design and a
methodology that uses qualitytools to refine design concepts.
Early After the work with yourteam, you should have a better
understanding of your customers,the use environment, the
environment in which yourproduct is being used, potential
use scenarios of your productand generally design inputs that
(08:05):
are based on potential benefitsto the customers or risks that
you want to design out of yourproduct, and also features and
options that will make yourproduct usable for your user to
achieve their goal.
And with your team's input, youcan prioritize that so you can
make trade-off decisions whenyou're actually designing.
(08:27):
In fact, concept developmentcan help you save time.
You can reduce engineeringdesign concept time by 35%.
Plus, you'll have all thatextra information that I just
talked about, and with conceptdevelopment activities you can
reduce the number of designiterations to get buy-in on a
(08:48):
concept by 60%.
You're using visual frameworksto explore ideas and less
mock-ups.
Let me explain this in a couplescenarios.
In our project we're given achallenge to develop something.
We're going to develop it andthen in the end we're going to
have an approved concept design.
(09:09):
In this scenario the timelineis pretty aggressive.
But let's step through atypical scenario when we're
using a lot of mock-ups andprototypes to be able to
communicate ideas anditeratively update our concept.
So let's say we're given aproblem and we take 10 business
(09:30):
days or two weeks to researchand engineer a concept.
Then we take two days to createa mock prototype and one day to
plan a show and tell meetingand then the next day we have a
reveal meeting where we inviteour cross functional team to
review what it is we'vedeveloped and they're going to
challenge a lot of things.
They're going to challenge alot of ideas and it's likely
(09:54):
going to result in big changesto whatever we've engineered.
So we go back to the drawingboard.
We take two days to adjust thedesign, another day to change
the mock prototype and thenanother day for the
cross-functional team.
They have additional feedbackand request a few more changes.
So we go back again and wedon't spend as much time
(10:15):
adjusting the design becausewe're getting closer.
We take one day to adjust thedesign, one day to change the
mock prototype and then wefinally have an approved design
concept Again an aggressiveschedule, but in 20 days of
engineering work we've donethree mock prototype versions
and have an approved designconcept.
(10:35):
Let's compare that against asimilar scenario same start and
end point, but now we're goingto do concept development using
quality during designmethodologies.
Our first big step is to plan ameeting, a co-working meeting,
with our cross-functional team.
We're going to take a day toplan it, three days to host
(10:55):
working meetings and one day tolook at all the information and
prioritize and assessinformation.
And at the end of those fivedays, at the end of a week,
we'll have clear design inputs.
Now we take a day to draw aschematic and this is just a
layout of systems and subsystems, functions, how this product
(11:16):
might work together, and wereview the schematic with our
cross functional team and askfor some feedback.
Now our cross functional teamhas worked with us over three
days in developing a conceptidea based on our customers'
benefits, symptoms and the useprocess.
So they've already beendesigning with us and they're
(11:38):
already on board with how thedevelopment is occurring.
So for them to review aschematic should be not a big
jump.
It's not like you'reintroducing a brand new idea to
them.
They're already been workingwith you.
After the schematic review, youdecide you want to further
develop the design based on allthis feedback that you've been
(11:59):
getting and working with yourcross-functional team to get.
Now you're going to create ageometric layout.
This uses blocks and shapes tokind of start to put a picture
together about what this productdesign might be looking like
and how it's coming together.
And then you host anotherlayout review with your
cross-functional team.
(12:19):
They give you feedback and youtake it back and draw an
interactions diagram.
Now you want to evaluate theinteractions between these
different modules andsub-modules and you're going to
have another review with across-functional team.
Really, your reliabilityengineers are going to be
especially interested in thisinteractions diagram.
(12:41):
At the end of that you're goingto take two days to create a
mock prototype that you're goingto share with the team.
At the end of that you'll havean approved design concept.
Now all of that took 13 days ofengineering work, one mock
prototype plus.
You now have a betterunderstanding of the potential
(13:03):
customer benefits, the badthings that could happen or the
risks, the tasks that they needto take with your product to get
from A to B, the tasks thatthey need to take with your
product to get from A to B andthese are all prioritized and
explored for design inputs, forengineering design inputs.
Plus, you've iteratively workedwith your cross-functional team
(13:24):
to develop this design and havetheir buy-in and understanding
of what it is that's beingdeveloped.
Comparing these two scenariosyou have 20 days and three mock
prototypes versus 13 days andone mock prototype.
Over a week less of time andtwo less prototypes Could save
you 35% of engineering time and60% of design iterations.
(13:48):
So now, with a better conceptdevelopment process, we've saved
time.
We've saved materials andprototypes and mock-ups.
We have increased chance ofsuccess in the marketplace
because we're better alignedwith our customers and we'll
have increased market share.
For the same reasons, I do notwear rose-colored glasses,
(14:11):
meaning that I'm very realisticabout what can be achieved with
a product development process.
It's not to say that if you doreally well at concept
development, you won't have anyproblems later in the product
development process, and that'sprobably just not the case.
Product development isdifficult.
There's a lot of moving pieces,parts, interactions, a lot can
(14:33):
go wrong and you have a teamthat's helping you to manage
that.
During the product developmentprocess you are creating targets
for what you want your productto be able to do, but at the end
your product is what it is andthat's why we test for it.
Part of concept development islearning more about your product
(14:54):
earlier in the developmentcycle so you can make some of
those more informed designdecisions, and it's linking your
design up more closely withyour customers and their
expectations and aligning yourcross-functional team on the
expectations for this productdesign, getting their input and
(15:15):
actually asking them to help youdesign it.
There are certainly times whendesigners and design engineers
need to step away and do thedetail work of design.
There is a place for that.
The place for that may notnecessarily be in concept
development.
Concept development is thatplace to do sharp, fact-based
(15:36):
product definitions beforedevelopment even begins.
So all of this is to say thatconcept development is really
important.
Most of us aren't doing enoughof it, but there are things that
we can do to do it better andin the long run it'll have a big
(15:56):
effect on how successful ourproducts are and how pleasant
our product development processcan be with our teammates.
Applying quality methods earlycan make a difference.
We can be proactive with ourteam in early meetings, manage
budget and market release anddesign what the customers want.
(16:16):
Visit the blog for this podcastepisode for extra information
and more links.
This has been a production ofDini Enterprises.
Thanks for listening.
You're working in new product development in industry
.
You're designing things andpart of a team that's helping to
design things that people finduseful and safe, make people's
lives easier.
It's a great space to work in.
Anything worth doing isn'tnecessarily easy, and that's the
case with product development.
A lot of the challenges that wehave in product development can
(00:22):
stem from our lack of conceptdevelopment, which is that early
phase of product development,before we've even really
designed anything.
There are many hidden costs ofpoor product development in
product design.
Let's talk more about those andways we can combat them or
address them after this briefintroduction.
(00:43):
Hello and welcome to QualityDuring Design, the place to use
quality thinking to createproducts 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 on how to
apply quality during design totheir processes.
(01:06):
Listen in and then join us.
Visit qualityduringdesigncom.
Product development is a greatspace to be working in.
It's very rewarding.
You get to create and designthings, work with other people
and, with the products that youdesign, make people's lives a
little better and, with theproducts that you design make
people's lives a little better.
It's exciting when somethinggets developed and it makes it
(01:29):
into the hands of the customerswith success, and that's really
what we all want when we're onthese product development teams.
We want to be designing anddeveloping things that are
success.
It isn't always easy.
In fact.
We could be developing anddesigning something that we then
share with the team and theydon't really like it.
It gets picked apart.
(01:49):
All that work that we've donejust wasn't worth it.
It's trashed, or we have tochange so much of it that we
really have to start over again.
Or we're in the middle ofproduct development and we
realize that uh-oh, we have amissing customer need, that we
didn't address, a regulationthat we just happen to not be
(02:09):
meeting, or other unforeseenthings that just happen to
happen that make us need to justchange the design in
mid-development.
There are a lot of situationsin where projects just don't
meet expectations.
They don't meet theexpectations of the engineers,
the cross-functional team, ourcustomers.
These are all challenges inproduct development that we face
(02:32):
.
Now, not all, but many of thechallenges relate to concept
development or our lack ofconcept development.
Concept development is thatfuzzy front end of product
development.
Now we have already have aproduct idea, we have customers
that have been identified, theproject has been approved.
(02:53):
We may even have done apreliminary technical
feasibility study.
Then we get into conceptdevelopment, actually developing
ideas about what this designcould be.
Dr Robert Cooper authored how toWin at New Products.
He identified some of theroadblocks with concept
development, or some of the lackof concept development, and he
(03:17):
related it to the end result ofwhat really happens with our
products.
And these are some of thehidden costs that we recognize
but maybe we don't realize howbig they are, how costly they
are, when we don't do conceptdevelopment well.
Based on Dr Cooper's studieswith teams that had a
(03:37):
well-defined product prior tothe development phase, they were
over three times more likely tobe successful with their
project and they also have ahigher market share by 38 share
points on the average, and theirproducts were rated better by
their customers.
So their customer perceptionalso increased.
So well-defined product priorto the development phase leads
(04:01):
to success, market share andcustomer's perception, not by a
little bit but actually by a lot.
I know that even in conceptdevelopment we don't have a
well-defined product prior toactually design development.
We're actually developing aproduct in concept development.
But Dr Cooper's studies alsoshow that sharp, fact-based
product definitions beforedevelopment begins also leads to
(04:25):
products that are more likelyto succeed, and that solid,
upfront homework, includingactivities that precede
development, also significantlyimpacts success and market share
.
But here's the thing many of usaren't doing this early homework
, this concept development, orwhen we're doing them, we're not
(04:45):
doing it to the level that weshould.
Cooper shows that only 16% ofperson days on a project is
dedicated to early work.
So, even though conceptdevelopment is really important
to do, only 16% of our time on aproject is spent doing it.
Quoting Cooper, in too manyprojects we observed new product
(05:07):
idea that moved directly intodevelopment with very little in
the way of upfront homework todefine the product and justify
the project A ready-fire aimapproach.
Dr Cooper further describesthat teams move ahead into
product development withoutcustomer requirements or
customer input, move ahead intoproduct development without
customer requirements orcustomer input.
(05:28):
Comparing successful productsto failed products, successful
ones have about 75% more timededicated to these
pre-development activities.
So we're not spending enoughtime in concept development and
it's costing us.
But I know when we get an ideaor we get an ask the things we
really want to do is startcreating and start designing.
We'd rather be on our workbenchmocking up a prototype or
(05:52):
building something and be ableto get iterative feedback from
our team on it.
In that case, we kind of feellike we're developing as we're
designing, but that can backfirealso.
But that can backfire also.
Doing that is still designingtoo early and can lead to those
problems that we talked about atthe beginning of the episode
Designs being picked apart, lateconcepts changing
(06:14):
mid-development, wasted time andmoney and just projects not
meeting expectations.
The other thing we don't wantto do is just to spin our wheels
and not make decisions and notmove forward with a project.
But by jumping into action andinto designs too early, we're
skipping this conceptdevelopment phase and we're
(06:36):
missing out on opportunities,opportunities for our product to
be in the market, to make it tomarket and to be successful.
Product to be in the market, tomake it to market and to be
successful.
We want to spend more time inconcept development, but we want
to make it worthwhile.
We actually want to bedeveloping a concept.
So how do we balance this withdesign, especially in a product
(06:58):
development lifecycle, and howdo we do this with our
cross-functional team.
Well, we need to be intentionalabout our concept development.
We need focused teamwork.
We can use visual frameworks totalk about concepts and ideas
and to prioritize those ideas,and we can use quality ideals
(07:21):
that's a capital Q quality tohelp us navigate the whole
process.
And that's what quality duringdesign in D&E Enterprises is all
about being able to work withyour team in early concept
development using some qualityprinciples.
It's a philosophy thatemphasizes the benefits of
(07:42):
cross-functional teaminvolvement in design and a
methodology that uses qualitytools to refine design concepts.
Early After the work with yourteam, you should have a better
understanding of your customers,the use environment, the
environment in which yourproduct is being used, potential
use scenarios of your productand generally design inputs that
(08:05):
are based on potential benefitsto the customers or risks that
you want to design out of yourproduct, and also features and
options that will make yourproduct usable for your user to
achieve their goal.
And with your team's input, youcan prioritize that so you can
make trade-off decisions whenyou're actually designing.
(08:27):
In fact, concept developmentcan help you save time.
You can reduce engineeringdesign concept time by 35%.
Plus, you'll have all thatextra information that I just
talked about, and with conceptdevelopment activities you can
reduce the number of designiterations to get buy-in on a
(08:48):
concept by 60%.
You're using visual frameworksto explore ideas and less
mock-ups.
Let me explain this in a couplescenarios.
In our project we're given achallenge to develop something.
We're going to develop it andthen in the end we're going to
have an approved concept design.
(09:09):
In this scenario the timelineis pretty aggressive.
But let's step through atypical scenario when we're
using a lot of mock-ups andprototypes to be able to
communicate ideas anditeratively update our concept.
So let's say we're given aproblem and we take 10 business
(09:30):
days or two weeks to researchand engineer a concept.
Then we take two days to createa mock prototype and one day to
plan a show and tell meetingand then the next day we have a
reveal meeting where we inviteour cross functional team to
review what it is we'vedeveloped and they're going to
challenge a lot of things.
They're going to challenge alot of ideas and it's likely
(09:54):
going to result in big changesto whatever we've engineered.
So we go back to the drawingboard.
We take two days to adjust thedesign, another day to change
the mock prototype and thenanother day for the
cross-functional team.
They have additional feedbackand request a few more changes.
So we go back again and wedon't spend as much time
(10:15):
adjusting the design becausewe're getting closer.
We take one day to adjust thedesign, one day to change the
mock prototype and then wefinally have an approved design
concept Again an aggressiveschedule, but in 20 days of
engineering work we've donethree mock prototype versions
and have an approved designconcept.
(10:35):
Let's compare that against asimilar scenario same start and
end point, but now we're goingto do concept development using
quality during designmethodologies.
Our first big step is to plan ameeting, a co-working meeting,
with our cross-functional team.
We're going to take a day toplan it, three days to host
(10:55):
working meetings and one day tolook at all the information and
prioritize and assessinformation.
And at the end of those fivedays, at the end of a week,
we'll have clear design inputs.
Now we take a day to draw aschematic and this is just a
layout of systems and subsystems, functions, how this product
(11:16):
might work together, and wereview the schematic with our
cross functional team and askfor some feedback.
Now our cross functional teamhas worked with us over three
days in developing a conceptidea based on our customers'
benefits, symptoms and the useprocess.
So they've already beendesigning with us and they're
(11:38):
already on board with how thedevelopment is occurring.
So for them to review aschematic should be not a big
jump.
It's not like you'reintroducing a brand new idea to
them.
They're already been workingwith you.
After the schematic review, youdecide you want to further
develop the design based on allthis feedback that you've been
(11:59):
getting and working with yourcross-functional team to get.
Now you're going to create ageometric layout.
This uses blocks and shapes tokind of start to put a picture
together about what this productdesign might be looking like
and how it's coming together.
And then you host anotherlayout review with your
cross-functional team.
(12:19):
They give you feedback and youtake it back and draw an
interactions diagram.
Now you want to evaluate theinteractions between these
different modules andsub-modules and you're going to
have another review with across-functional team.
Really, your reliabilityengineers are going to be
especially interested in thisinteractions diagram.
(12:41):
At the end of that you're goingto take two days to create a
mock prototype that you're goingto share with the team.
At the end of that you'll havean approved design concept.
Now all of that took 13 days ofengineering work, one mock
prototype plus.
You now have a betterunderstanding of the potential
(13:03):
customer benefits, the badthings that could happen or the
risks, the tasks that they needto take with your product to get
from A to B, the tasks thatthey need to take with your
product to get from A to B andthese are all prioritized and
explored for design inputs, forengineering design inputs.
Plus, you've iteratively workedwith your cross-functional team
(13:24):
to develop this design and havetheir buy-in and understanding
of what it is that's beingdeveloped.
Comparing these two scenariosyou have 20 days and three mock
prototypes versus 13 days andone mock prototype.
Over a week less of time andtwo less prototypes Could save
you 35% of engineering time and60% of design iterations.
(13:48):
So now, with a better conceptdevelopment process, we've saved
time.
We've saved materials andprototypes and mock-ups.
We have increased chance ofsuccess in the marketplace
because we're better alignedwith our customers and we'll
have increased market share.
For the same reasons, I do notwear rose-colored glasses,
(14:11):
meaning that I'm very realisticabout what can be achieved with
a product development process.
It's not to say that if you doreally well at concept
development, you won't have anyproblems later in the product
development process, and that'sprobably just not the case.
Product development isdifficult.
There's a lot of moving pieces,parts, interactions, a lot can
(14:33):
go wrong and you have a teamthat's helping you to manage
that.
During the product developmentprocess you are creating targets
for what you want your productto be able to do, but at the end
your product is what it is andthat's why we test for it.
Part of concept development islearning more about your product
(14:54):
earlier in the developmentcycle so you can make some of
those more informed designdecisions, and it's linking your
design up more closely withyour customers and their
expectations and aligning yourcross-functional team on the
expectations for this productdesign, getting their input and
(15:15):
actually asking them to help youdesign it.
There are certainly times whendesigners and design engineers
need to step away and do thedetail work of design.
There is a place for that.
The place for that may notnecessarily be in concept
development.
Concept development is thatplace to do sharp, fact-based
(15:36):
product definitions beforedevelopment even begins.
So all of this is to say thatconcept development is really
important.
Most of us aren't doing enoughof it, but there are things that
we can do to do it better andin the long run it'll have a big
(15:56):
effect on how successful ourproducts are and how pleasant
our product development processcan be with our teammates.
Applying quality methods earlycan make a difference.
We can be proactive with ourteam in early meetings, manage
budget and market release anddesign what the customers want.
(16:16):
Visit the blog for this podcastepisode for extra information
and more links.
This has been a production ofDini Enterprises.
Thanks for listening.
Popular Podcasts
On Purpose with Jay Shetty
I’m Jay Shetty host of On Purpose the worlds #1 Mental Health podcast and I’m so grateful you found us. I started this podcast 5 years ago to invite you into conversations and workshops that are designed to help make you happier, healthier and more healed. I believe that when you (yes you) feel seen, heard and understood you’re able to deal with relationship struggles, work challenges and life’s ups and downs with more ease and grace. I interview experts, celebrities, thought leaders and athletes so that we can grow our mindset, build better habits and uncover a side of them we’ve never seen before. New episodes every Monday and Friday. Your support means the world to me and I don’t take it for granted — click the follow button and leave a review to help us spread the love with On Purpose. I can’t wait for you to listen to your first or 500th episode!
The Breakfast Club
The World's Most Dangerous Morning Show, The Breakfast Club, With DJ Envy And Charlamagne Tha God!
The Joe Rogan Experience
The official podcast of comedian Joe Rogan.