A lot goes into production of complex products, and not just cars. Complex software products commonly incorporate and interact with hundreds of other, third-party software and non-software products.
So what does this mean for Product Managers?
Usually, there is no need for Product Managers to get involved with the third-party products used to build their products. Except for special circumstances, this is left to Architects (technology strategy), Engineering (quality and security), and Legal (the IP rights).
PM does however need to direct and provide recommendations and guidance on the third-party products that interact with and enable the operation of their products.
Allow me to use the automobile industry to illustrate this concept.
Let’s look at the role of the third-party components through the eyes of car manufacturers and car users.
When Toyota is producing its cars, it inevitably embeds the output of other companies in its products. For example, the door panels are formed from metal coming from companies specializing in smelting ore into sheet metal. Toyota evaluates what’s available on the market and elects to use the product it believes is best for its cars. In this example, sheet metal is a third-party product that once chosen by the product vendor is permanently embedded into the product and can’t be swapped out. Let’s call this a Class C third-party product.
Next, the Jeep designers equip their cars with Bosch spark plugs. While these spark plugs can be replaced by the product user (e.g. once they are worn out) the car cannot operate without them. Let’s call this a Class B third-party product.
Finally, the car manufacturer recommends certain conditions, care and the use of some third-party products for its car's optimal performance, safety, and longevity. For example, it may recommend the use of high-octane gasoline/petrol, oil change interval or certain load limits. All these criteria are outside of the car manufacturer’s direct control (they are the responsibility of the user), and yet they are expected to impact the product. Let’s call the third-party product in this category a Class A.
Now, to draw a parallel with Software Products,
- Class A is the expected environment, such as hardware configuration, network connectivity, Operating System, web browsers, Java, and .NET that are expected to be provided and maintained by the product user.
- Class B is the stuff that may be included with the product. The end-user has control over it. The vendor should explain the recommended steps to maintain this stuff in optimal and safe working order, compatible with continued eligibility for the overall product support and maintenance services.
- Class C is the stuff that gets embedded or compiled into the product. The end-user has no control over it.
Product Management owns support and compatibility strategy, and communication about Class A and Class B third-party products as explained above.
Please let me know your thoughts or experience with this.
