Welcome. I'm so glad you decided to join me on this journey.

Let's talk a little bit about design engineering. Is it a lot of fun! It can also be really challenging. Which, let's be honest, that's part of the fun of it. It's also a big responsibility. You're making decisions daily about the product that has end effects through everything else downstream of a product design. Actually making the product distributing it and the users and the customers using the product design engineering touches and affects all the things that make a product well happen.

It's no secret that early fact based concept development with a cross functional team has big benefits. Product design engineering is not a silo activity. Sometimes we don't know how to develop a design at concept. We may not know what to ask our cross functional team to get them involved. We definitely don't want to add pointless meetings and endless paperwork to our day. We already have enough going on and enough responsibility.

We do want to work with our customers and our customer facing teammates like marketing and field operations. We want to get their input so that we can produce great designs. We do want to make decisions based on data and we want to be able to use our work to be able to iterate on it throughout product development, building on the lessons learnt through the product development process.

And this is what we're going to learn in this course.

There are six ideas about product development engineering that I want to explore with you. Some of them. I want to turn on their head,

Let's explore the first idea. Product design engineering is making things work, not figuring out how it will fail. Instead, product design engineering is making things work and controlling failures. It's a balance between making things work and preventing things from failing and controlling the failures if they do happen. If we want to design for excellence, which includes things like design, for usability, design for reliability, manufacturer, ability, environment and so on. We need to consider the other half of products success, which is product failure being proactive about controlling failures is a key to great design. We want to control failures by eliminating them, preventing them and reducing their impact.

Our second idea is that problems are not a source of design inputs. Instead problems are a source of design inputs. Preston smith and Donald Rynerstein are experts in product development, They authored a couple of books, One of them is developing products in half the time and they say product development is just a succession of problems to be solved. So, development speed depends on the speed of the problem solving process and I would add to that, that the development success depends on the success of the problem solving process. This is not a pessimistic viewpoint, customers have problems we're trying to solve and we're also trying to prevent problems from being introduced or from happening with our product. We want products that are safe, easy to use and functional and that requires us to look at problems and design for them. If we want to be strategic about design, we need to base our design in part on risk, reliability and quality. Designing for problems is also a way to talk with a cross functional team about information we need for design inputs. Thinking about what a customer needs. Is one thing. Thinking about what could go wrong is another, it's easier for people to pick apart problems which is going to result in real conversations about features that users want performance needs and other things.

A design engineering idea number three that I've heard is evaluating hazards and failures is done by someone else after there is a design instead evaluating hazards and failures is done by a designer and the team starting with a concept. Some specific analyses can't be done until there is a design but there are many other analyses that can even at the concept phase, I'll be teaching you some quality and reliability engineering tools and processes. Most of these techniques are not a pass off design engineers do need to have a hands on approach to investigating failures and hazards. Design decisions and evaluations happen fast outside of team meetings, Sometimes the ideal time to do some assessments is when we're in the depths of the design details so hazards and failure Information needs to be on hand and sometimes developed real time when designing we still need to utilize our team to maintain our independence and to ensure that we're not blinded by our own perceptions which sort of leads into our design engineering idea number four.

Designers cannot assess their own work for failures and hazards. This is getting into independence lacking the independence of evaluating our own designs. Instead, designers can assess their own work for failures or hazards with their team to make design decisions, especially if we plan and expect to do this as part of the design process itself. Our team is going to critique what we do. There will be less disconnects if we get their input earlier. In addition, we might actually get blinded by our own perceptions of things. So utilizing a team for an independent review of what we're developing is key.

Our design idea number five is that we can iterate on failure and risk analyses throughout the development process. This one's actually true. There's no corrections to this one. They can also be scaled to fit what we need at different points of our product development.

And finally, our design idea number six is that if it's qualitative or subjective, it's not worth doing. Instead, if it is qualitative or quantitative, meaning measurable, it's worth doing. Preliminary data and information can be used. We can use information from our vendors, our past experience bench, top testing, field data and knowledge about standard parts. We shouldn't let a lack of hard data prevent us from analyzing potential problems, failures or hazards. We can use qualitative measures if we don't have the data, it's just that we all need to be clear about that. If we're ever making decisions off of it throughout the project and at the end of the project we're going to be balancing these analyses with testing which is going to be providing that data against which we can more confidently make decisions.

So what are the next steps here? How do you design from a problem failure point of view and work with your team to do it?

Here are some of the things that you're going to work on in this course.

• Understanding root causes what they are and how to get to them.
• You'll be studying risk in order to analyze and control them through design and design decisions.
• You'll develop concepts with a cross functional team and we'll also talk about field monitoring for acceptability and continuous improvement.

What you'll be able to do with this course are several things

• you'll be able to adjust your design activities to include additional perspectives which is solving problems and controlling risks.
• You'll define problems to be able to solve them by resolving their root causes and you'll have proven frameworks to work with with your cross functional team for the early fact based work that you can iterate throughout the development process.
• You'll be able to use that to explore ideas better, understand the products, use, evaluate design concepts, prioritize design features and develop and prioritize design inputs.

Now I feel like we're packed up and ready for our journey. I'll see you inside at the first lesson.

[progressally_media media_id="2"]