Introduction to Engineering: The Engineering Design Process and Entrepreneurial Mindset

Foundations of Engineering and the Engineering Mindset

• Definition of Engineering:
  • Engineering is a systematic mindset and structured methodology for solving complex problems.
  • It is not merely a static body of technical knowledge, but an active, disciplined way of thinking and lifelong learning.
• Primary Motivators for Engineers and Computing Scientists:
  • Curiosity: The intellectual desire to explore how systems function and uncover new possibilities.
  • Problem Solving: The drive to resolve inefficiencies, tackle challenges, and build practical solutions.
  • Financial Compensation: Professional career incentives and earning potential.
• The Engineering Mindset Iterative Cycle:
  • The foundational cognitive loop follows a continuous cycle: $\text{Ask} \rightarrow \text{Research} \rightarrow \text{Imagine} \rightarrow \text{Plan} \rightarrow \text{Create} \rightarrow \text{Test} \rightarrow \text{Improve}$.
• Core Competencies Developed Through Engineering Training:
  • Critical thinking and objective reasoning.
  • Systematic problem solving.
  • Quantitative data analysis.
  • Mastery of technical and engineering tools.
  • Clear, structured technical communication.
  • Collaborative teamwork across multidisciplinary groups.
  • Adaptability in dynamic technological landscapes.
  • Ethical responsibility and professional standards.
• Significance for Computer Science (CS) and Software Engineering (SE):
  • Computer scientists and software engineers function as the builders and architects of the digital sphere.
  • They are responsible for designing, testing, and maintaining dependable software systems across diverse computing platforms that drive modern engineering infrastructure.

The Engineering Design Process (EDP)

• Nature and Purpose of the EDP:
  • The EDP is the systematic method engineers utilize to create products, systems, services, environments, and processes.
  • It provides the defining operational methodology that distinguishes engineering practice from pure scientific discovery.
  • The framework is customer-centered, flexible, iterative, decision-intensive, and communication-intensive.
• Key Stages in the Design Loop:
  • Identify: Recognize an unmet need, friction point, or opportunity for innovation.
  • Define (Define the Problem): Determine precise project boundaries, customer goals, operational requirements, distinguishing criteria, and real-world constraints.
  • Research: Confirm and validate the core problem; investigate existing technologies and benchmark their respective advantages and disadvantages.
  • Imagine: Brainstorm a broad range of creative concepts using divergent thinking.
  • Model: Apply principles of mathematics and physical science; construct analytical simulations, computational scripts, or Computer-Aided Design (CAD) representations.
  • Create: Manufacture physical prototypes, assemble functional mechanisms, or write software implementations.
  • Test: Experimentally evaluate and verify the physical or digital prototype directly against operational criteria and performance requirements.
  • Improve: Systematically optimize and refine the design based on experimental test data, performance failures, and user feedback.

• Non-Linearity and Dynamics of the Design Loop:
  • The design process is not a rigid linear checklist; it is fluid and non-linear.
  • Stages frequently overlap, repeat, cycle back, or reverse sequence as engineers acquire new data, uncover flaws, or receive fresh customer insights.
  • The customer remains positioned at the absolute center of every cycle to anchor all engineering iterations.

Structural Features Supporting the Design Process

• Active Role of the Customer:
  • The customer is actively integrated into every stage of the design cycle, not just contacted at delivery.
  • Continuous customer feedback directs refinements, validates functionality, and ensures the engineering team builds a desirable solution.
• Prototyping Principles:
  • Prototyping is valuable and applicable at any point along the design path.
  • Rough, low-fidelity mock-ups serve as tangible thinking tools to communicate complex ideas quickly across teams.
  • Minimum Viable Products (MVPs): Functional baselines developed with minimal resource investment to maximize real-world learning and validate core assumptions rapidly.
  • IDEO Prototyping Philosophy: "Making ideas tangible, learning while building, iterating quickly."
• Project Planning and Execution:
  • Unplanned initiatives waste resources, captured by Benjamin Franklin's maxim: "Failing to plan is planning to fail."
  • Project schedules and resource plans are living frameworks that must be iteratively updated and calibrated throughout development.
• Engineering Notebook Documentation:
  • Engineers must maintain detailed, real-time documentation within an official design notebook throughout every project phase.
  • Historical benchmark: Thomas Edison completed more than $2{,}500$ detailed notebooks across his career to capture data, concepts, and failures.
• Core Integration:
  • The design process successfully synthesizes divergent creativity, rigorous planning, persistent customer engagement, and systematic technical documentation.

Problem Definition: Understanding Customer Needs

• The Pitfall of Misaligned Engineering:
  • Engineers routinely commit resources toward developing brilliant technical solutions for the wrong problem because they fail to understand the user's authentic reality.
  • The engineering process must always initiate from the customer's lived perspective rather than the internal assumptions or biases of the engineer.
• Techniques for Uncovering Authentic Problems:
  • Ask "What bugs you?": Anchor problem identification in everyday human frustrations, recurring pain points, and unmet expectations.
  • Validate Across User Cohorts: When a frustration is verified across a substantial population, it signals a legitimate engineering and market opportunity.
  • Differentiate Symptoms from Root Causes: Customers typically complain about surface symptoms rather than structural causes. Engineers must repeatedly ask "Why?" to drill down to the fundamental source of the failure.
  • Deploy Open-Ended Questioning: Avoid binary yes/no interrogations; solicit descriptive narratives regarding user experiences, environmental contexts, and emotional frustrations.
  • Target Critical Operational Vulnerabilities:
    • Everyday annoyances and neglected operational requirements.
    • Functional failures, breakdowns, or usability hurdles in existing commercial offerings.
    • Underlying user goals, emotional motivations, and social or physical barriers.
• Focusing on Verbs Rather Than Nouns:
  • Avoid framing design goals around static objects (nouns); frame them around dynamic human activities and functions (verbs).
  • Example: Shift framing from designing a "toy" (noun) to designing "play" (verb).
  • Targeting verbs broadens the innovation space, focusing effort on fundamental activities rather than copying existing physical form factors.

Framing the Problem: Problem Statements and Point of View (POV)

• Formulating Effective Problem Statements:
  • A properly framed problem statement isolates the fundamental issue without assuming, implying, or mandating a particular technical solution.
  • Flawed Statement: "Design a better mousetrap." (Pre-judges the solution by restricting thinking to traps).
  • Effective Statement: "Keep mice out of the house." (Establishes the core objective, opening ideation to deterrents, sound frequencies, chemical barriers, or structural sealants).
• Point of View (POV) Statements:
  • A POV statement is a concise, actionable reframing of the design challenge grounded in human needs and direct insights.
  • Composed of three mandatory elements:
    • User: The specific individual or distinct group experiencing the problem.
    • Need: The critical task or outcome that must be accomplished, expressed using active verbs.
    • Insight: The core underlying motivation, emotional reality, or systemic barrier that explains why the need exists.
• Worked Example of a POV Statement:
  • User: A 9th-grade girl adjusting to a new school.
  • Need: To feel socially accepted while eating healthy food.
  • Insight: In her peer group, social risk and peer rejection feel far more dangerous than dietary health risks.
• Value of the POV Framework:
  • Cultivates deep human empathy by forcing engineers to confront user emotions and real-world social contexts.
  • Illuminates novel avenues for innovative problem solving.
  • Maintains organizational discipline, preventing teams from wandering into peripheral issues.
• Advancing Toward Solution Boundaries:
  • Establish project constraints and measurable success criteria.
  • Continuously re-evaluate the problem statement and POV as fresh feedback emerges, ensuring the solution tackles root causes rather than superficial symptoms.

Requirements Versus Criteria

• Translating Customer Voice into Engineering Goals:

  • Listen openly without bias during early customer discussions to keep the solution space open to unexpected, breakthrough concepts.
  • Once the core problem is defined, convert user feedback into functional specifications, operational boundaries, and desirable performance metrics.

• The Distinction Between Requirements and Criteria:

  • Requirements (Needs): Absolute, non-negotiable operational baselines that the design must fulfill to be considered successful.
  • Criteria (Wants): Desirable performance attributes and qualitative targets that the design should ideally optimize to distinguish between compliant options.

• Attributes of Rigorous Engineering Requirements:

  • Formal Phrasing: Written as precise, one-sentence "shall statements" that define a binding functional task using the syntax: "The design shall…"
  • Customer-Driven: Derived directly from verified customer needs to establish non-negotiable baseline targets prior to brainstorming.
  • Focus on "What", Never "How": Dictate the required functional performance, never the implementation method or specific material choice.
    • Poor Requirement: "Make the phone out of foam."
    • Good Requirement: "The design shall be unbreakable."
  • Strictly Quantitative: Replace subjective, vague adjectives (such as "thin," "fast," "lightweight," or "safe") with measurable numbers and exact tolerance bands.
  • Incorporate Exclusions ("What Not to Do"): Customers often assume implicit conditions; requirements must explicitly define excluded features (e.g., prohibiting mayonnaise or vegetables).
  • Respect Real-World Feasibility: Must not violate the laws of physics, material thresholds, or platform constraints (such as operating software parameters across Android versus Mac environments).
  • Unambiguous Testability: Every requirement must be verifiable through an empirical pass/fail test with zero subjective ambiguity.
  • Iterative Evolution: Requirements mature and adjust as engineers query customers with probing questions, preventing wasted development cycles.

• Case Study: The Turkey Sandwich Requirements Evolution:

  • Initial Customer Request: "A turkey sandwich on white bread."
  • Preliminary High-Level Requirements:
    • The design shall represent a sandwich.
    • The design shall contain turkey.
    • The design shall be made of only white bread.
  • Revised, Quantified, and Verifiable Engineering Requirements:
    • The design shall contain Turkey.
    • The design shall contain white bread.
    • The design shall exclude any vegetables or mayonnaise.
    • The design shall contain meat sliced to a minimum of $3\,\text{mm}$ and maximum of $4\,\text{mm}$.
    • The design shall be formed with bread surrounding the meat.

• The Function and Application of Design Criteria:

  • Once an engineering team devises multiple valid design concepts that satisfy $100\%$ of all mandatory requirements, criteria are applied to evaluate and rank them.
  • Sandwich Criteria Examples: Creativity of assembly, bread softness, overall physical dimensions.
  • Scoring and Ranking: Criteria are structured, measurable metrics, often scored along an ordinal scale (e.g., rating bread softness from $1$ to $10$, where $1 = \text{hard}$ and $10 = \text{very soft}$).
  • While requirements enforce strict pass/fail compliance, criteria allow engineering teams to trade off desirable features based on customer priorities.

The Imagine Stage: Ideation and Divergent Thinking

• Context within the Design Loop:
  • Occurs after the market opportunity is identified, the problem is defined, requirements and criteria are cataloged, and foundational research is complete.
  • Dedicated to generating the operational concepts that will achieve design goals while keeping customer needs central.
• Core Activities for Concept Generation:
  • Information Gathering: Deepen research into existing competitive products, detailing their functional strengths and mechanical weaknesses.
  • Brainstorming: Generating broad concept pools without judgment.
  • Visual Organization: Structuring concepts through sketches, functional diagrams, mind maps, and design matrices.
  • Rapid Prototyping and Sketching: Building quick physical mock-ups to think tactilely.
  • Methodological Variety: Employing diverse ideation methods, recognizing that cognitive strengths differ across team members.
• Divergent Thinking Principles:
  • Divergent thinking requires branching out in multiple cognitive directions, generating the greatest possible quantity and variety of ideas without early self-censorship.
  • The objective at this stage is raw volume and conceptual breadth, not immediate technical perfection.

• The Seven Core Rules for Successful Brainstorming:
  1. Defer Judgment: Completely eliminate premature criticism, cynicism, or negative critique; all ideas are initially valid.
  2. Encourage Wild Ideas: Welcome extreme, unconventional, or physically "impossible" ideas, as they often trigger breakthrough innovations.
  3. Build on the Ideas of Others: Use collaborative synergy to combine, modify, and expand upon teammates' concepts.
  4. Stay Focused on the Topic: Keep discussions anchored to the defined design problem and customer requirements.
  5. One Conversation at a Time: Maintain group focus and active listening so that every shared concept is heard and captured.
  6. Be Visual: Use quick hand sketches, diagrams, and physical gestures to convey spatial and structural concepts.
  7. Go for Quantity: Target generating $40\text{--}50$ discrete ideas in a session; initial concepts are rarely the most innovative.
• Practical Tools for Ideation Management:
  • Sticky Notes / Post-Its: Record one idea per note to facilitate modular physical grouping, sorting, and synthesis.
  • Idea Cards and Whiteboards: Create visual surfaces for rapid group manipulation and open evaluation.
  • Mind Maps and Associative Diagrams: Map linkages, systemic relationships, and hierarchies between concepts.
  • Morphological Matrices: List design subsystems against possible technical mechanisms to create new combinations.
• Avoiding the "First Idea" Trap:
  • Engineers must never halt ideation simply because their initial concept seems fully formed and workable.
  • Pushing past obvious initial ideas into subsequent ideation tiers regularly yields more innovative, robust, and cost-effective solutions.
• Early Prototyping Dynamics:
  • Construct fast prototypes out of paper, cardboard, wire, foam, fabric, or household items.
  • Early mock-ups bring ideas into physical reality, highlighting ergonomics, spatial footprint, and operational issues before committing engineering capital.

The Entrepreneurial Mindset and Value Creation

• The Core Mandate: "Don't Make Junk":
  • Technical engineering skills alone do not ensure a meaningful outcome; technical execution must be paired with genuine human need.
  • Engineers must move past asking purely "Can we make it?" to evaluate "Should we make it?"
  • Essential Qualifying Questions:
    • Does this product definitively solve an authentic problem?
    • Will anyone actively want to buy, adopt, or use it?
    • Is this solution genuinely superior to existing market alternatives?
• Primary Causes of Engineering and Product Failures:
  • Developing an efficient technical solution for the wrong problem.
  • Failing to realize that users are already satisfied with current workarounds or alternatives.
  • Releasing products that are cumbersome, frustrating, or confusing to use.
  • Being outmatched by competitors that solve the core issue faster, cheaper, or simpler.
• The Engine and Steering Wheel Analogy:
  • Engineering Skills = The Engine: Supplies raw power, technical capability, mathematical modeling, and manufacturing proficiency.
  • Entrepreneurial Mindset = The Steering Wheel: Guides, directs, and maneuvers technical capabilities toward real human impact and value.
  • This mindset is not restricted to commercial startups; it applies equally to established companies, research institutions, and non-profit projects.
• The KEEN 3Cs Framework:
  • Curiosity: Maintaining vigilance toward an evolving world; constantly questioning current realities, studying consumer behaviors, and identifying latent needs. Curiosity drives the initial stages of the EDP.
  • Connections: Linking disparate concepts, academic disciplines, and technologies; synthesizing customer insights with technical capabilities to spark original innovation.
  • Creating Value: The governing purpose behind every engineering decision; delivering solutions that tangibly improve human lives while remaining desirable, usable, sustainable, and economically viable.
  • Reference resource: Additional case studies and frameworks are cataloged at engineeringunleashed.com.

Real-World Case Study: The Engineering Design Process at Netflix

• Industrial Deployment of the EDP at Massive Scale:
  • Netflix software and platform engineers continuously apply the EDP to build, monitor, and scale distributed architectures supporting hundreds of millions of concurrent global users.
  • Their engineering workflow follows the cyclical pattern: identify opportunities $\rightarrow$ research and analyze telemetry $\rightarrow$ brainstorm and model architectures $\rightarrow$ build, test, and iteratively refine services.
• Approaches to Identifying Problems and Opportunities:
  • Direct User and Engineer Feedback: Conducting internal and external user interviews to uncover friction points, workflow bottlenecks, and system inefficiencies.
  • Long-Term Architectural Visioning: Planning infrastructure for projected demands $5\text{--}10\,\text{years}$ into the future.
  • Data-Driven Telemetry: Constantly monitoring telemetry, latency metrics, and user drop-off data to spot underperforming systems.
  • Continuous Incremental Deployment: Practicing a philosophy described as "many small meals a day rather than one big dinner" by releasing continuous micro-updates rather than massive, disruptive monolithic software overhauls.
  • Lesson for Engineers: Avoid waiting for an elusive single "holy cow" breakthrough; continuously resolve small operational problems and learn from each iteration.
• Research Methodologies at Enterprise Scale:
  • Internal Analytics: Collecting telemetry on how internal developer tooling and platform services are navigated.
  • External Peer Benchmarking: Actively studying architectures across external technology firms and industry peers, deliberately avoiding an insular corporate bubble.
• Brainstorming, Prototyping, and Non-Additive Engineering:
  • Gap Analysis and Visual Whiteboarding: Structuring collaborative team brainstorming sessions around whiteboards to converge on unified system solutions.
  • Empirical Multi-Variant Testing: Building concurrent feature versions for live user evaluation, expanding simple $A/B$ testing into comprehensive $A\text{--}G$ multi-variable experiments.
  • Non-Additive Engineering Philosophy:
    • "Engineering does not always have to be additive."
    • Superior engineering often focuses on simplifying, refactoring, and pruning bloat, removing redundant code, and eliminating unnecessary features rather than continually adding complexity.
• Testing Rigor and Technological Adaptability:
  • Internal Validation: Testing new tools directly within internal engineering teams ("dogfooding") prior to customer rollout.
  • User Analytics: Combining hard system telemetry with qualitative user survey responses to verify feature adoption.
  • Guiding Engineering Axiom: "Don't fall in love with your technology, focus on the problem."
  • Modular Architecture: Constructing flexible, decoupled systems that can be updated, refactored, or discarded without destabilizing the broader infrastructure.
  • Utility Over Novelty: A technically "cool" feature provides no real engineering value unless it satisfies genuine customer needs and functions reliably within the host system.
• Core Takeaways on What Engineering Truly Means:
  • "Take someone's complaint and make it into a product."
  • "Take what's there and make it better."
  • Engineering transforms complaints into solutions, and existing designs into superior systems, in a manner that remains systematic, scalable, repeatable, and economically viable.