A good customer of ours organized a supplier day: A short formal part and then a barbecue and drink together in the garden on the company premises. Nice.
In the formal part, an image film was shown that included a somewhat contrived situation in a restaurant in which the company boss was asked by several different people "What does <customer name> actually do?" and "Does <customer name> do anything for me?"
The whole thing was personal (the boss played in the film) and nicely done, even if it was a bit long-winded. It was simply important to him that his partners knew about the contribution his company makes to society together with his regional partners. As he had also explained beforehand that he puts securing the supply chain before (short-term) profit maximization, the concept was coherent.
If a company manufactures and sells products, then it is clear what contribution is being made as long as you understand who uses these products for what. Those of us who work in product development find it a little more difficult because the activity itself requires explanation.
You see, as product developers, we do not manufacture electronic products. Nor do we sell or maintain them. And when we carry out product development on behalf of customers, we don't decide which products should be developed. No, we make recipes for those who make the products.
The creation of recipes involves the precise recording of customer requirements in all facets (flavor, nutritional content, price, etc.), known as requirements engineering. It involves the careful selection of ingredients (component selection), the skillful combination of ingredients in the right quantities (electronic circuit development) and the arrangement of these quantities (PCB layout).
When the recipes are used to produce a meal on a trial basis, we taste them (verification tests). We also check that the meals taste good on all plates and at all times (validation tests). And last but not least, we make sure that the meals always come out of the kitchen in the same way (process-capable production process).
That's the analogy. This usually makes it very easy to have a conversation about the specifics of product development with people who may have had little contact with technology, such as marketing service providers or accountants.
What do you think? What analogy do you use to explain your work in product development to those around you?
