The other day someone asked me how I define “product realization.” The question is one I have considered recently because the problem has changed significantly over my 25 years as a product developer. Historically "product realization" was defined in a practical sense by CEMs (Contract Electronic Manufacturers) with the leader probably being Plexus who still uses it as a tagline. CEMs and Original Equipment Manufacturers (OEMs) used the term in an operational manner which led to being defined in ISO 9001:2008. Product Realization in that context was basically a process that anyone who could, as a single point of contact, design and manufacture a product. Expanding from manufacturing to Product Realization services was a primary CEM strategy from the late 1990’s to mid-2000’s during which many acquired design firms to expand their value to existing customers and capture new customer relationships earlier before manufacturing decision criteria became purely cost.
However, some CEMs are not using that language as much anymore. Today their message is about information. I suspect the change is partly because “product realization” has become dated in marketing speak, but also because of the Internet of Things (IoT) has changed the capabilities necessary to accomplish the objective. Outsourcing and partnering in IoT ecosystems have changed the use of the term. Today traditional Industrial Design firms like Frog, who previously were looked at as strictly creative design resources, are claiming to do product realization.
The transformation has been driven by the problems faced by branded product owners – the OEMs. In the 1990's the primary OEM pain to be addressed was the transition from design to manufacturing created when the OEMs started to outsource manufacturing. The CEMs addressed this by adding engineering. Today the primary issue being addressed by OEMs is systems integration and business model transformation in the more complex connected world and the more diverse technology ecosystem. Porter and Hepplemann recently did a deep dive on these changes in Harvard Business Review in the second of their two part IoT strategy expose. Today an OEM has to add ongoing cloud services to their physical product so anyone who thinks of themselves as systems thinkers or design thinkers, which design firms like IDEO and Frog are, will feel empowered to say that they can do product realization because they can figure out what they need to build the system and then find and manage or find and recommend the necessary ecosystem suppliers. “System Integrator” is the new buzzword and from Silicon Valley to Main Street we see SI’s emerging everywhere a vertical is gaining traction in the IoT.
The challenge with the product development landscape now, as affected by IoT, is that product or solution realization has a much longer and ongoing life cycle -- it's more complex. Whereas the traditional CEM definition more or less ended with the shipping and sale of the product, in the IoT product realization has to include the ongoing delivery of the digital service including data analytics. The data analytics is usually not even defined at the point of product launch but can have great value if done with the right domain knowledge. In that case the value is defined and the sold after the product realization service is sold, i.e. a post-sale add-on for the supplier.
Product realization today is more complex so the challenge for OEMs is managing the new complexity. We see how both OEMs and those who serve OEMs have responded. Major OEMs like GE and IBM create their own IoT platforms. Branded holding companies like Parker-Hanifin invest in or acquire value chain suppliers to gain expertise as have traditional OEM development tool vendors like PTC and Autodesk. The OEMs now struggle with the complexity of launching solutions in the IoT, so today a product realization firm is one that follows Gall’s Law and tenants of creating complex systems. Today product realization is accomplished by those who make the complex simpler – but not too simple.