Design to Avoid Problems: Focusing on Symptoms Early On

Send us a text

Ever stood in that devastating moment when customers finally interact with your nearly-finished product only to hear them say, "I don't like that" or "This doesn't work for me"? After months of development and what you thought was adequate customer engagement, these late-stage revelations can send you spiraling back to the drawing board, costing time, money, and team morale.

This episode dives deep into why this painful scenario happens even to the most diligent product development teams and offers three powerful strategies to prevent it. 

• First, we explore the concept of the "problem space" - that crucial period between identifying a customer problem and jumping to design solutions. 
• The power of cross-functional collaboration forms our second focus. These varied viewpoints collectively create a comprehensive understanding that helps identify potential issues much earlier.
• Our third strategy introduces the concept of "symptoms" - what customers experience when there's an unintended output or event with your product.  By intentionally exploring these possible negative experiences during concept development, teams can make informed design decisions that prevent or mitigate problems before they materialize in the final product. 

Ready to transform your product development approach? Start with these strategies on your next project and watch how they reduce those heartbreaking late-stage discoveries. Your customers—and your future self—will thank you.

Visit this podcast blog.

Other podcast episodes you may like:

Uncovering Customer Desires: Understanding Benefits in Concept Development

The Hidden Costs of Poor Concept Development in Product Design

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!

NEWSLETTER
Subscribe to get updates: newsletter.deeneyenterprises.com

SELF-PACED COURSE FMEA in Practice: from Plan to Risk-Based Decision Making is enrolling students now. Join over 300 students: Click Here.

ABOUT DIANNA
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 and people improve engineering design.

Episode Transcript

Speaker 1 (00:00):
Welcome to the Quality During Design podcast.
I'm Diana Dini.
Picture this you're at the endof a product development cycle
and you're watching a customerinteraction with your new
product design.
It's one of many, becauseyou've been inviting the
customers to interact with youand your team, try out ideas,
give their feedback.

(00:20):
All along the productdevelopment process, even before
you started designing things,you involve the customer.
But now that the customers havesomething in their hands,
you're hearing things like this.
I don't like that.
The way that works doesn't workfor me.
I wasn't expecting that tohappen.
And they're saying that in nota good way, not a pleasantly

(00:43):
surprised way, and yourengineering mind starts solving
the problem.
And, oh my gosh, to fix itwould mean a major redesign.
You wish you knew about thisstuff earlier.
Why didn't it come up in all ofthose other interactions that
we had with our customers andwhat can we do differently next

(01:04):
time?
Let's talk more about it afterthis brief introduction.
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.

(01:26):
I consult with businesses andcoach individuals and how to
apply quality during design totheir processes.
Listen in and then join us.
Visit qualityduringdesigncom.
Welcome back.
We're talking about howcustomers don't like our stuff
and that can be reallydisappointing, especially if

(01:47):
we've been working hard toinvolve them in our decision
making process all along.
Sometimes we don't do enough ofthat customer interaction early
, or often enough in our productdevelopment lifecycle, and
sometimes that can be hard togauge.
Sometimes it's built in and ourcustomer facing teammates have

(02:08):
a lot of contacts that arewilling to talk and work with us
.
Sometimes it's not so easy, butin any case, we're at this
point near the end or what wethought was the end and we're
getting a lot of negativefeedback as engineers working in
product development.
What can we do about that?
There's three major areas whereI can see that, no matter what

(02:29):
product development style orprocess that you have, there's
three basic things that we cando for ourselves and our team in
our new product developmentlife cycles to avoid this.
Learning about problems reallylate.
Even if we do these things, wemay still find out problems
really late, but we're going tosignificantly reduce the chances

(02:51):
of that happening.
So for one, did we jump fromidea to solution too soon.
Did we skip the problem spaceand not do enough concept
development?
I've been talking a lot aboutconcept development in the last
few episodes.
That's that fuzzy front end ofproduct development and it lives
between hey, we have a productidea to hey, let's build this

(03:14):
thing that I've come up with.
I call it fuzzy because it'snot really clear what we're
doing yet.
And within concept developmentis what I call the problem space
.
Yes, we've already identified aproblem, a problem that our
customer has, that we want tosolve with our product.
That's our product idea.
But then we jump right fromthat into designing stuff

(03:37):
because, I don't know, it's fun,that's what we like to do.
We like to design things, butwe skip that middle step, which
is where we want to question andinvestigate a little bit more
about the problem, betterunderstand the problem so that
we can develop designs thatbetter fit the needs to solve

(03:58):
the problem for our customers.
So that's number one.
Maybe we didn't stay in theproblem space long enough to
question, investigate and reallyunderstand what the true
problem is.
The other part of that is if wedid stay in that problem space
and try to do extra work tounderstand our customers, their

(04:18):
environment, the kind of choicesthat they need to make and what
their real problem is, andtheir customer journey, where
they're starting and where theywant to end.
If we did do that, did we do itsolo or did we do it with our
team and some customers involvedtoo?
If we did it solo, we'remissing out on some of those

(04:39):
aspects of teamwork andcross-functional teamwork that
we can really benefit from whentrying to understand the concept
space.
First of all, people fromdifferent departments are going
to come at the same problem witha different viewpoint.
They may understand thecustomers a little differently
than we do.
They have a differentbackground on what's going on in

(05:01):
the environment and, especiallyif we get our customers
involved, they have their ownparticular knowledge base and
information and viewpoints thatthey're going to bring to better
understanding this problemspace.
We can work with all thesepeople to better question and
investigate these problem spaceand really bring clarity to what

(05:24):
it is that we're developing.
They bring a lot of value.
I covered that in a previousepisode also.
Now maybe you're saying, diana,I already know all this.
We spend a lot of time inconcept development.
We work together with our teamand I'm still having this
problem.
The third thing that's importantis being intentional about

(05:45):
finding potential symptoms.
Yes, we got together, we gotbetter clarity, we got some
customer feedback, but did weintentionally look for and ask
about the things that are a painor, within this concept space,
we have a general idea of whatour product is going to be?
What are some of the thingsthat could go wrong that they

(06:07):
would find really annoying?
In a previous episode, I talkedabout finding benefits, the
things that are really going todelight our customers.
Well, the other part of that isthe symptoms, the things that
don't delight our customers and,in fact, just really turn them
off.
In this context, symptoms arewhat customers experience when

(06:29):
we have unintended output orevent.
When we have unintended outputor event In concept development,
we can think of whatever it isthat we're developing as a
system a input, a black box andan output.
Except our outputs are dividedinto two One is benefits, where
things go right, and one aresymptoms, when things go wrong,

(06:53):
and we're looking at this at ahigh level from our customer's
point of view.
Now, a failure may cause thisunintended output in our product
.
A mistake could be made in itsuse, or it could be just an
event in our environment.
It's a negative experience forour customers.
We want to examine thosepotential negative experiences

(07:17):
so we can eliminate, reduce orotherwise control them from
happening with our designchoices.
If possible, we can word asymptom statement like this Our
customers may lose productfeatures or be challenged, which
leads to them experiencing thisnegative impact.
You may think that this sounds alot like failures and hazards,
but symptoms, failures andhazards are different things.

(07:38):
Remember, we're in the fuzzyfront end of concept development
and failures are specific tothe product that we haven't
developed yet, so it's too soonto list those.
We don't have functions andfailures.
However, after we've collectedideas about design inputs
through the concept space, we'lllikely have much more clarity

(08:01):
about our concept design.
That's when we can start.
Things like FMEAs or other riskanalyses will help us make us
more design decisions andprioritize decisions.
It's too early for failures.
What about hazards?
Hazards are top-down negativeevents that are beyond the scope

(08:22):
of the concept space, ourcustomers' experiences.
Risk evaluators usuallycategorize hazards as things
like biological hazards,physical hazards and safety
hazards.
Your industry may use differentcategories specific to your
product type and use environment.
There are hazard analyses thatfocus on what could go wrong and

(08:43):
include sources of hazards andtheir causes.
They're used to identify riskcontrols, which may include some
design choices, but identifyingsources of hazards is beyond
the scope of the concept space.
In the concept space, we'redeveloping a concept design
that's focused on the user'sexperience with our product.

(09:03):
We're not looking to identifyhazards.
Rather, we're looking forpotential experiences that make
our users unhappy.
This is why we want to alignour idea of symptoms with a
customer complaint, want toalign our idea of symptoms with
a customer complaint.
In fact, that's a great way tothink about symptoms.

(09:23):
You can imagine what kind ofcomplaints that they're going to
make with your product onceit's released.
Those are the symptoms that wecan focus on early in concept
development to be able to makedesign decisions against.
So remember at the top of ourepisode, we were really

(09:44):
disappointed in what ourcustomers were saying about our
product design and wondering ifit's something that we need to
go back to the drawing board orredesign.
It's extremely dishearteningand disappointing when that
happens.
That's why we need to do asmuch as we can earlier,
understand as much as we can, asoften as we can or as soon as
we can so we can make thosedesign decisions, design

(10:08):
trade-off decisions, implementrisk controls the things that
are not only going to delightour customers but prevent them
from complaining or experiencingnegative things with our
products.
Being intentional about lookingfor and evaluating symptoms in
concept development can helpgive us more information to be

(10:31):
able to better design, to applyquality during design.
When you're further along inyour product development process
and it's after conceptdevelopment and you're ready to
start FMEA, consider taking mycourse in Udemy.
It's called FMEA in Practice,from plan to risk-based decision

(10:51):
making.
It's hosted by theManufacturing Academy.
You have lifetime access andRay Harkins and I are available
to answer questions.
We're the instructors for thecourse that actively support you
as a student.
I'll include a link in the shownotes.
This has been a production ofDini Enterprises.
Thanks for listening, thank you.