Great engineering makes a product work. Product thinking makes that work matter.
In engineering, there is a certain satisfaction in getting things right. A design meets its specifications, a system passes validation, a technical problem is resolved, and a project reaches its delivery milestone. These are meaningful achievements, especially in industries such as automotive, where precision, reliability, and quality are essential.
But technical success doesn’t always translate into product success. A system can meet every engineering requirement and still fall short of what the customer actually needs. A feature can work exactly as intended without meaningfully improving the user’s experience.
Having worked across automotive engineering, Product Data Management, Engineering Change Management, process optimisation, and project delivery, I’ve come to appreciate that building a successful product requires more than technical expertise.
It requires understanding how engineering decisions influence customer value, business outcomes, cost, quality, and the product’s long-term performance.
The shift from engineering to product thinking begins when we stop asking only whether something can be built correctly and start asking whether it is the right thing to build.
A Specification Doesn’t Tell the Whole Story
Engineering typically begins with requirements. Specifications define how a system should perform, what functionality it must deliver, and which technical constraints it must satisfy. Engineers translate these requirements into designs, solutions, and working products.
This discipline is essential, but requirements don’t always capture the complete customer experience.
Consider an automotive infotainment system. A specification might define screen responsiveness, navigation capabilities, connectivity features, and integration with vehicle systems. Meeting those requirements is important, but the driver’s experience depends on much more.
Can important information be accessed without unnecessary distraction? Are frequently used functions intuitive? Does the system respond consistently in everyday driving conditions? Will the experience remain reliable over the vehicle’s lifecycle?
A system may satisfy its technical specifications while still creating frustration for the person using it.
This is where product thinking becomes valuable. It encourages engineers to understand the purpose behind a requirement rather than treating the requirement itself as the final objective.
For example, improving screen responsiveness is a technical goal. Helping a driver interact with the system more easily and safely is a customer outcome. The two are connected, but they aren’t interchangeable.
I believe engineers make stronger decisions when they understand both.
What Automotive Engineering Teaches About Product Decisions
Automotive product development is particularly interesting because even relatively small engineering decisions can have consequences across multiple functions. A design change may influence cost, quality, validation, manufacturing, supplier coordination, and customer experience.
Through my exposure to different areas of automotive engineering, three lessons stand out.
1. Cost Optimisation Is About Protecting Value, Not Simply Reducing Expense
Cost is an unavoidable consideration in product development. However, reducing cost and creating value are not always the same thing.
Imagine an engineering team identifying an opportunity to replace a component with a less expensive alternative. The change may appear beneficial because it reduces manufacturing costs while meeting the required specifications.
But the decision needs to be evaluated more broadly. What if the alternative affects durability, performance, maintenance, or the customer’s perception of quality?
A short-term saving could introduce long-term expenses or compromise an important part of the product experience.
Effective cost optimisation therefore requires engineers to distinguish between costs that can be removed without affecting customer value and investments that protect the attributes customers genuinely care about.
The goal should not be to create the cheapest possible product, but to deliver the right value at a sustainable cost.
2. Engineering Change Management Is Also Product Decision-Making
In complex automotive programs, engineering changes are rarely isolated.
A modification to one component can affect design documentation, validation activities, manufacturing processes, supplier coordination, and delivery schedules. Product Data Management and Engineering Change Management help organisations manage these dependencies systematically.
But beyond process discipline, they also reveal something important about product thinking: every change introduces a trade-off.
Consider three common situations:
- Adding functionality: A new feature may improve the customer experience, but it could also increase system complexity, validation effort, and development costs. The decision should depend on whether the additional value justifies those consequences.
- Changing a component: An alternative component may improve availability or reduce cost, but teams must evaluate its impact on performance, reliability, and the broader product lifecycle.
- Modifying an existing design: A change may solve an immediate technical problem while creating new dependencies elsewhere. Understanding those downstream effects is essential before implementation.
These decisions require more than technical feasibility assessments. They require an understanding of customer priorities, business constraints, and long-term product outcomes.
This is one area where engineering experience provides a strong foundation for Product Management. Engineers are already familiar with trade-offs and dependencies. Product thinking helps connect those decisions to the value they create.
3. Product Success Extends Beyond Delivery
Automotive products have long lifecycles. Their performance continues to matter well beyond development and launch, through production, maintenance, updates, and changing customer expectations.
This creates an important distinction between delivering a project and managing a product.
Project delivery focuses on meeting defined commitments, including timelines, budgets, quality requirements, and agreed scope. Product thinking considers whether those decisions continue to make sense throughout the product’s lifecycle.
A design that is easier to develop today might introduce maintenance challenges later. Similarly, an additional investment during development might improve reliability and reduce recurring issues over time.
Working in environments where products remain in use for years reinforces the importance of evaluating decisions beyond immediate milestones.
A successful launch matters, but so does what happens after the product reaches the customer.
Why Engineers Need to Understand the Customer
One of the challenges in large organisations is that customer requirements often pass through several layers before reaching engineering teams.
Business stakeholders interpret customer expectations, product teams translate them into features, and engineers receive specifications for implementation. Each handoff can introduce assumptions or remove context.
By the time a requirement reaches the technical team, the original customer problem may no longer be fully visible.
This is why I believe engineers should be encouraged to ask questions beyond the specification.
A few questions can significantly improve product decisions:
- What customer problem are we solving? Understanding the underlying need helps teams distinguish essential functionality from features that may add complexity without meaningful value.
- How will the customer experience this decision? A technically efficient solution may still introduce usability challenges, additional effort, or unexpected limitations.
- What happens if we don’t make this change? This helps establish the importance and urgency of a requirement, particularly when resources and timelines are constrained.
- What trade-offs are we introducing? Engineering decisions should be evaluated against cost, quality, performance, customer experience, and long-term maintainability.
These questions don’t weaken engineering discipline. They make it more purposeful by connecting technical work with the outcomes it is intended to achieve.
Product Thinking Depends on Cross-Functional Collaboration
Complex products are rarely the result of one team’s work. Engineering, design, quality, manufacturing, suppliers, business stakeholders, and customer-facing functions all contribute to the final outcome.
Each function brings a different perspective. Engineering may focus on technical performance, manufacturing on production efficiency, quality teams on reliability, and business stakeholders on cost and market expectations.
The challenge is not choosing one perspective over another. It is understanding how these priorities interact and making decisions that serve the overall product.
For example, a technically sophisticated solution may be difficult or expensive to manufacture. A lower-cost alternative may compromise an experience customers value. A feature requested by one stakeholder may create additional complexity for other teams.
In such situations, the best decision is often the one that balances competing requirements rather than maximising a single objective.
This is where people leadership becomes important. Listening to different teams, understanding their constraints, and communicating the reasoning behind decisions helps create alignment.
I’ve come to see cross-functional collaboration as more than a delivery requirement. It is an important part of making better product decisions.
Five Principles for Engineers Developing Product Thinking
For engineering professionals looking to move toward broader product responsibilities, five principles can help develop a stronger product mindset.
1. Understand the problem before designing the solution. A requirement is a starting point, not the complete picture. Understanding the customer need and business objective behind it helps engineers make more informed technical choices.
2. Evaluate decisions beyond technical performance. A solution should be assessed not only for functionality and reliability but also for its impact on cost, usability, customer value, and long-term product performance.
3. Treat every engineering change as a trade-off. Changes should be evaluated across the wider system. Improving one component or process should not create disproportionate costs or risks elsewhere.
4. Learn from other functions. Understanding how manufacturing, quality, business, and customer-facing teams evaluate success gives engineers a more complete perspective on product decisions.
5. Think beyond the delivery milestone. Product success depends on what happens after launch. Reliability, maintainability, customer experience, and lifecycle costs should influence decisions from the beginning.
These principles don’t require engineers to move away from their technical expertise. Instead, they help engineers apply that expertise to a broader set of business and customer challenges.
The Engineer’s Advantage in Product Management
Engineering professionals bring a valuable perspective to Product Management. They understand how products work, where complexity emerges, and what it takes to translate an idea into a dependable solution.
They are familiar with technical constraints, dependencies, quality requirements, and the consequences of design decisions. These capabilities become even more valuable when combined with customer understanding and business judgment.
After years of working across different aspects of automotive product development, my perspective is that moving from engineering to product thinking isn’t about leaving technology behind. It is about expanding how we define a successful outcome.
Technical excellence remains essential. But it becomes more meaningful when the product also solves the right customer problem, delivers value at the right cost, and performs reliably throughout its lifecycle.
The strongest product decisions emerge when engineering expertise, customer understanding, and business priorities work together.
Great engineers know how to build things right. Great product thinkers also understand why those things should be built, who they serve, and what value they must create.
That leads to a question worth asking before every major engineering decision:
Are we improving the product because we can, or because it will genuinely improve the customer’s experience?
