@Esterline Research & Design Marketing, like engineering, is a profgession with specific skill requirements. Too often people assume that mushware is the way to sell products. Well that is true for some dubious products, provided that there is no intent to foster a long terms customer re;ationship. Note that I'm NOT advocating sleezy techniques, but I do want to recognize that mushware techniques do work for most people some of the time.
I'm sure that all of us cn think of technology companies that deliver what they promise with a minimal amount of hype. These enlightened companies use marketing to make the facts speak FOR them - and they tend to have strong customer loyalty providing that the products do what they sayh.
Mushware while defining a product is one thing, Mushware while promoting a product is something the developers cannot do anything with.
For example way back in 1990s , we developed an interactive TV with a bulit in co-processor having the capability of storing small BASIC programs. This was basically aimed at school going kids to learn programming techniques with simple programs.
Our marketing team hyped this feature to such an extent that they sold one of ourr TVs as an Accounting system to one shop keeper, telling him that he can program his TV to store all accounts for his business.
We had a very hard time in answering the after sales querries of this shop keeper on how many accounting entries his TV could store and so on and how can a printer be attached to the TV to print his account books!
@prabhakar_deosthali I used to teach a Software Project Management course in the 1980s during which I purposely had some mushware included as part of a problem statement. About 10% of my students called out those statements as problems for their planning process.
Leaving mushware in product specifications is an open invitation to disaster. It might cost you your job, but ignoring the problem will not allow engineers to make a product that meets the needs.
Having said that, there are times when nobody can be specific enough during the initial description. In these cases, it's time to take a page out of Lean Startup strategy to actively learn what is real - prospects often mean something different that what you heard.
Marketers do not "lie"; engineers just "cannot do their jobs". I have worked several jobs where everyone had "done their job", made the company money, and all we engineers had to do is just deliver the product before we leave for the day. Most times engineering has always been the bottleneck when creating that new little feature that was needed to sell the product. Joke example: a nuclear submarine company's engineers could not make their hatches fully compatible with the International Space Station's air locks and then keep making excuses about not being able to do a full scale onsite test at the ISS to show the customer this little feature that clinched the sale >;-). You have not enjoyed engineering until you have a meeting (with sales, marketing, and management) and finally find out what the product really does just before it ships.
@TFCSD Old school product development still relies on the "waterfall" model - you know, the one where the big, bad, explosion happens when the product is finally "released." Fortunately I've mostly avoided these conflagrations by insisting on what is now called an Agile Methodology.
In the early 1980s working on the IEEE Software Engineering Standards subcommittee, it became painfully apparant to those of us working on the Software Unit Test Standard that the waterfall model was a high risk approach to product specification and design. We discussed product specification alternatives using a "twisted pair" metaphor as an alternative to the waterfall model. Now thirty years later much of the entrepreneurial community has latched on to the concepts that were formulated to address the weaknesses of the atomic bomb approach to development - "all or nothing."
I find it interesting that you call out the marketers of EE products. I was just today remarking how much better the marketing teams were in EE than in consumer/household goods (think cleaning products). Many of the marketing folks I've met in this industry are engineers first, marketers as a second career. That is not the case in the other industries, I rarely met someone who was a scientist first, and then a marketer. Too often, the marketers had no idea what the science/technology could do, and would come in with these amazingly impossible concepts...
@JanineLove Marketing of technical EE-based products is better (by a long shot) than the consumer products you mentioned. And I think that you hit on one of the key differences: many EE marketing folks were engineers first.
Even with the better-than-average folks in EE-based companies, there are still too many cases of bad data from well-intended prospects that goes unchallenged/unvalidated until it is too late - or nearly so.
This is not a phenomenum left to marketing alone. It can be found throughout companies' entire management chain. And I agree, with your observation about EE products having a better than average market presence.
Sadly, there are plenty "pointy haired managers" out there who are just as toxic to the process as apoor engineer or bad marketer. So, the blame has plenty of places to roost.
@henry..12 may be the tech marketers of yesterday fit your description... I would argue now a days (& I blame Facebook / social media for this!) even tech marketing folks repackage the truth! Most often the capabilities and features of products are overstated, stretched, distorted, befuddling...
BTW, I do more marketing as well as engineering these days and I am guilty of the above. My friends say I have caught the marketing virus :-)
The truth is, most marketeers in high tech lie for a variety of reasons. Sometimes they're plain stupid. Often they are scared of looking stupid. Many times they are pressured by the executive team to propagate garbage messaging. The worst situations are those where engineering lies to marketing - either because of a false belief in a feature or schedule, or because they are covering up a fear of being exposed as deficient.
I've done marketing in high tech for over two decades. Nothing gets me red in the face with anger than when someone lies to me. Mistakes are ok - they're very understandable, and in a business as difficult as ours, mistakes HAVE to be accepted, because there is no learning without the experience of failure. But in my book, lying is grounds for INSTANT termination.
Greed and the desire to defend fat stock option and bonus portfolios in the executive team drives a lot of this deception, and it poisons an organization. What many execs are insulated from is the reality that customer engineering teams are often composed of veterans who are adept at sniffing out falsehoods.
The smart marketing guys simply do not lie, obfuscate or evade. They underpromise and overdeliver, and they're very open about it. You have to build TRUST. Especially now, with even the former wildly growing mobile computing markets saturating and the rest of the markets stagnating, you have to build TRUST with your customers. Honesty, directness, underpromising and overdelivering, being open kimono on your strengths and weaknesses - this is what counts. For those who disagree with this, make sure you never work for me, because I WILL FIRE YOU.
I blog about these sorts of issues all the time. Come to http://vigilfuturi.blogspot.com if you want to see more about these very fundamental issues.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.