In the late 1970s, the AT&T Bell System rolled out a marketing campaign around the slogan, "The system is the solution." Part of its marketing copy at the time was a statement that, "To solve your problems, we have to understand your problems." Whether you recall the days of Ma Bell with fondness, loathing, or not at all, few would deny that there were smart people working in that corporation, and that they got some things dramatically right. One of them was their understanding of the value of a systems approach to meeting their customers' needs.
One of my job-related roles is to run a team of Product Definers for the RF Solutions Business Unit. This team has the responsibility to understand at a very deep level the technical requirements of our customers. This means we have to understand the whole system in detail, even when we only deliver part of that system. This is a challenging job in any serious semiconductor company, requiring a good understanding of what is feasible in terms of technical tradeoffs, as well as the ability to get into the shoes of the customers. It necessarily involves spending significant face time with our customers wherever they may be found in the world, and using that time well.
Beyond that, a sufficient understanding often involves exploring interactions and tradeoffs using appropriate behavioral simulation tools. This is a dramatic increase in scope from an earlier time where the philosophy might have been summarized as: Design a better widget, and they will come. These days, the industry focus is on integrated solutions, driven by increasing expectations for miniaturization, low BOM cost, and high reliability.
The higher the level of integration, however, the more decisions are necessarily prebaked into the silicon by the semiconductor vendor, which places greater responsibility on the product definers to get those decisions right. Fundamentally, failure to grasp the system from the customer's perspective results in a failure to specify the most sellable product. Or, as Ma Bell once put it, "To solve your problems, we have to understand your problems."
Product definition is only one part of an overall Systems Engineering approach to product creation. I really like the International Council on Systems Engineering (INCOSE) definition of Systems Engineering, which reads in part:
Systems Engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem.
Bringing analog together is challenging in itself, but bringing the right analog together is not just an integration problem; it's a systems engineering problem which requires all the engineering steps to be done while considering the complete problem.
Is there such a thing as too much requirements analysis before starting a project? How do you ensure fast time to market while making very sure you are building the right thing for the market? Please feel free to share your thoughts below.