I think the seller should have just sent him a refund early on and forgotten about it. I'd even refund the guy's purchase price of the software -- the seller is just plain wrong when he says that "no one offers refunds for software that can be copied."
The whiny customer does ask for many things that aren't reasonable in an inexpensive product (full power-on self tests), although it's also true that in many cases a lot of self-diagnostics can be added without changing the BOM price at all by just adding more software. Of course I have no idea if that's the case for the particular product in question here.
Hunting down and killing customers is frowned on is it? IMO, he missed the light, or it was intermittent, and on when he looked, and started checking stuff. Once he had that amount of time invested, he wasn't going to admit a mistake.
Very insightful. I think you hit the nail on the head. It's a classic positive feedback loop.
(BTW, I saw your other tries, but couldn't approve them and still keep my promise to keep the topic at least somewhat related to product development. I hope that this doesn't keep you from posting things that *are* at least somewhat related to product development; That was a really good observation about retail.)
Unless I've been mislead for the last couple of decades, software is one of the most expensive items on the BOM. To quote viciously from Jack Ganssle's column:
formatting link
== Firmware is the most expensive thing in the universe. In his book Augustine's Laws, Lockheed Martin's Chairman Norman Augustine relates a tale of trouble for manufacturers of fighter aircraft.6 By the late '70s it was no longer possible to add things to these planes because adding new functionality meant increasing the aircraft's weight, which would impair performance. However, the aircraft vendors needed to add something to boost their profits. They searched for something, anything, that weighed nothing but cost a lot. And they found it?firmware! It was the answer to their dreams.
The F-4 was the hot fighter of the '60s. In 2004 dollars these airplanes cost about $20 million each and had essentially no firmware. Today's F-22, just coming into production, runs a cool $257 million per copy. Half of that price tag is firmware.
The DoD contractors succeeded beyond their wildest dreams. ==
That said, I think POST code ought to be nearly free because the software folks should have written that code early on if only to verify that the first runs of the hardware performed adequately. Better to ship that stuff, hidden from the user, unless you absolutely have no room in the ROMs for it.
Just for completeness, I can think of other situations where POST (Power On Self Test) code should be omitted.
[1] When the I/O is so limited that you simply don't have a way of conveying the result of the POST. One embedded system I worked on had as it's only output a doll moving her hand in a somewhat random manner. It didn't make a lot of sense to write a POST that waved one way if it passed and another when it failed and then expecting the average toy buyer to understand that.
[2] When there is nothing that the customer can do if it fails. Another embedded system I worked on was a toy that had one button as the only input, and a voice as the only output. The button simply applied power to the electronics, which then turned on a transistor to supply power after the button was released, said the phrase, then turned itself off. That was a case where neither a POST or a watchdog made any sense The watchdog resets the CPU and that is being done anyway, and the POST checks the hardware, but hearing the phrase does that. Other examples where where there is nothing that the customer can do if it fails come to mind, such as the electronics that makes a bomb go off when it reaches the target.
[3] When you need very rapid recovery from a power-on reset. This is a surprisingly common situation in small embedded systems that sit powered off, are turned on by another part of the system to do some work and then turned off when they are done. not having a POST can easily double the battery life if the run time is short.
Note that in the above cases it may still be appropriate to have a self test, but started with some special key combination or triggered by holding an unused pin high during power-up.
I do agree that in most cases there should be a POST, and that it should be the first thing the software folks write. Doing it that way allows them to understand any quirks in the hardware, and also makes it less likely that a hardware change with undesirable side effects gets through to production.
It's also a great way to resolve finger-pointing between hardware and software engineers. Whenever a "that's a hardware problem! No it's software problem!" dispute happens, I ask the software engineer to add a test to the POST that makes it fail when the hardware failure occurs. (It is important when doing this to let the POST loop all night or all weekend to catch intermittents) If they can do that, it's a lot easier for the hardware engineer to address a problem that causes a POST failure. If they *can't* do that, it is likely to be a software problem.
That's a great idea, but you will leave an awful lot of money on the table if you decide that you'll only sell to smart people.
Speaking as a propeller-headed engineer, I'm very impressed by companies who have products and marketing that allow the folks on the other half of the median intelligence line to see the need for, buy, and be happy with a product.
Maybe some of us are. If Guy wants to hijack posts from s.e.d. to kickstart his personal newsgroup, he's better come up with a few less boring subjects.
To my way of thinking, every communication with a customer having technical problems should contain a cut and paste section saying:
[1] Feel free to contact us by telephone at 1-800-555-5555, by email at snipped-for-privacy@example.com, or on the web at [
formatting link
].
[2] We offer a money back guarantee; if for any reason you are not satisfied with your purchase, feel free to return it for a full refund, including shipping both ways. See [
formatting link
] for details on how to return the product.
[3] We have a FAQ page with information about operating and troubleshooting our product. The answer to your problem may be there.
A happy customer tells a friend. An unhappy customer tells all of his friends. An unhappy customer who is clearly in the wrong might respond to your pointing that fact out by putting up a [Your Company Name]sucks.com website. Apologize, refund, block all purchases from that person, and then stop responding to them. Not very satisfying, but it maximizes profits over the long run.
I'm more inclined to side with the customer on this one, even though he wasnt a very bright bulb. If I sell something that doesnt work, its my responsibilty to get it to the point of working. If the customer takes part in that process theyre helping me do it. Yes, when you sell something, it is required to work. If your products have a failure rate, as all do, its your can to carry.
Not all products can be made plug and play, when theyre not, the customer needs to be advised at purchase time that some setup will be needed, that tronics knowledge is required, etc, whatever it is. If you dont advise them, unsuitable buys happen, and things go wrong.
I can understand the customer reaching the point of 'ive really had enough of this, take it back,' sometimes there are really more important things to do with ones life than help the seller try to get their thing going. The customer really does not owe it to you to do all that.
If there are common issues with a product, enclose or link to a fault finding FAQ.
And as Guy says, always offer some speedier way to deal with it, like exchanging for a new one etc.
And, at the end of the day, if your product never worked, as is the case here, yes the customer is entitled to a full refund. Sorry, but they are.
The seller never asked if the customer was willing to help them work thru it, just assumed. The seller insulted the buyer re their Eng qual
- and I saw nothing to tell us the buyer wasnt an engineer. I've met the odd bozo that somehow managed to qualify, and even the brightest have times of duh. And I expect not all engs understand IR, basic and syllabus-ic as it may be.
In short I'd say the seller has a whole set of wrong ideas about the seller/buyer relationship, obligations, legal standing, the whole thing.
And ultimately, the question isnt whose fault is it, its how can we avoid this next time.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.