MD+DI Online is part of the Informa Markets Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Why the Big Picture Matters: The Systems-Level Approach to Product Development

Why the Big Picture Matters: The Systems-Level Approach to Product Development
It’s easy to lose track of the “big picture” when you are deep into the design and engineering of a next-generation product. Having a focus on a systems approach is important throughout the process. 

It's easy to lose track of the "big picture" when you are deep into the design and engineering of a next-generation product. Having a focus on a systems approach is important throughout the process. 

Erik Reynolds

In product development, the big picture matters. The "big picture" isn't just theory. It's a mindset that needs to be a part of every decision.

It's important that both engineers and designers tasked with bringing that next great idea to life have a broad systems-level understanding of what's being created. It's also crucial for these professionals to possess an understanding of the market for the device so they can optimize development against clear and decisive goals.

Having a focus on a systems approach is important throughout all stages of the product development process. It's easy to lose track of the "big picture" when you are deep into the design and engineering of a next-generation product. However, by asking the "big picture" question at each of these stages, it will keep your team on track.

Initial Engagement

Most product development companies have seen it many times: Engineering teams tend to focus hard on what they hear first from a customer--market requirements or back-of-the-napkin wants--but fail to consider the total cost of development and the return on investment. Typically, this results in a proposed design that meets the criteria the engineering team heard in its initial meetings with the customer, but ultimately isn't what the end-user needs or wants. And usually, the development route laid out by the engineering team is too expensive.

Register for the MD&M Minneapolis Conference & Expo, November 8-9, 2017.

Design and engineering teams must think bigger. They need to listen and ask lots of questions--not just technical questions, but business questions too. What's the target resale cost of the device? What volumes of the product do they anticipate manufacturing and selling? Is this product meant to be an industry leader? A loss leader? Will the customer be first to market, and if so, how long can they expect to hold this advantage?

Developing this understanding lays the foundation for what the original equipment manufacturer's (OEM's) investment should look like. Product features and scope can be narrowed or expanded to line up with a strong return on investment (ROI) model and weighed against possible impacts to market acceptance. Failure to assess the business model and market conditions creates a narrow view of the product development costs that can hinder companies as they try to find the right balance between scope, cost, and ROI.

The Development Process

Once in development, teams whose members only possess siloed experience tend to focus solely on their area of expertise. This exposes the project to costly oversights, especially as it nears production launch. For example, the electrical engineers may care little for what the software engineers are doing or how they do it, or the software engineer might not have interest in what the production test system might need to do. These are a few classic weak points in engineering teams that prevent the most effective and efficient solutions for customers.

Products come in all shapes, sizes, and complexities, from the highly regulated to the throwaway consumable. Each has a potential ROI and each can be implemented in a variety of ways. Understanding the costs associated with various features, as well as the timeline for their implementation, is important to projecting the appropriate investment for the device development and how fast the effort will become profitable once in production.

Engineers and managers should assess the customer's business plan to understand how their expected ROI and timeline correspond to the development costs they have allotted for the project. This will help everyone involved understand how much non-recurring engineering (NRE) should be planned for, with respect to product cost and volumes. Engineers that propose the work should also actually perform the work. This helps keep a consistent team accountable for managing to their estimates within the assumptions agreed upon in the proposal.

The Importance of Production Test Systems

Product development teams that don't consider production efficiency and don't test to find appropriate efficiency projections are destined for challenges as the production launch nears. A production test strategy needs to be established about midway through the alpha phase of development. This ensures all stakeholders know the tentative approach, effort, schedule, and costs. It also ensures that the required "hooks" are placed in the design both physically and in software to support an efficient test process during production. This communication should be central to the project and ensures alignment among the contributing engineering teams.

Design engineers with experience creating test systems or customers who have worked with various contract engineering and manufacturing firms will know the benefits of an effective test strategy and when and what to do. The test strategy may include plans for in-circuit, functional, and end-of-line tests, among others. These tests should cover all of the product's most critical components and use cases, and addresses which components are tested and where, or if they are tested at speed or while stationary.

Several design components are affected by this strategy, including the test points on what and when not to use, determining how much automation to program into the test, what to put in the boot loader, the printed circuit board (PCB) array, and various size and scoring components. An unplanned board spin near the pilot launch can cost five or six figures in non-recurring engineering and result in added FCC testing/retesting. More frighteningly, extra required testing leads to inevitable delays in product launch, which can hinder market penetration and result in huge losses in unrealized sales.


Synergies exist between systems engineering, electrical engineering, PCB design, and production test system development, so these are disciplines that have good opportunities for hands-on cross-disciplinary growth. Electrical engineering and embedded software development is another great skill combination. Management should also encourage development within engineering teams so individuals build out these cross-discipline competencies. These investments will pay back in spades in proposal development, during implementation, and within project management.

For example, electrical engineers could perform initial board bring-up using Joint Test Action Group (JTAG) tools and emulators. A systems engineer may design the production test architecture, or a test development engineer could review the electrical design of a product. Regardless of which cross-pollinations you decide to incorporate, a good test plan will require Design for Excellence (DfX) reviews at every design review gate to analyze and address production test results and manufacturing risks.

Keeping the "big picture" in mind during all phases of product development helps ensure that the next great idea your team brings to life meets initial requirements but also the needs of the market that will truly drive growth.

Erik Reynolds is senior director of engineering at Logic PD


Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.