How To Sell Golden Hammers

Techies who believe in GoldenHammers seem frustrated by the fact that they can't convince others to buy into it. Here is the place to present ideas to sell them.

Relevant and Many Examples - Produce many code samples and scenarios relevant to reader's domain. The reader may not relate to Foobar ("lab toy") examples or consider them only academic exercises that ignore or cannot extrapolate to real-world issues.
- On the other hand, when asked how the tool solves problem P, don't spend time focusing on how the tool also solves problems Q, R, and S. Come to a mutual understanding of goals up front.
- Isn't this covered below?
Focus on Their Problems, Not Yours - Be aware that not everyone shares the same goals in the same proportion as you. For example, showing how closures may reduce the probability of "forgetting to close off the sandwich" may be appealing to you, but the reader may not see that as a common mistake in their own coding, and thus don't really care. Find out what really bothers them about current tools or techniques, not what you think bothers them or should bother them. You won't sell ovens to people who want ice-cream.
Be Clear about Benefits - Be clear about exactly what X does better and be prepared to provide specifics, not something that will be perceived as nebulous brochure talk. General mantra may work on non-techies, but good techies will press you for solid evidence and details. GoodMetricsUseNumbers. If the tool will save steps, show them exactly what steps it saves compared to the alternatives. List the steps out of both tools being compared.
Don't Patronize - Don't be arrogant or talk down to people, such as "pearls before swine" or "real programmers get it" (even if you believe it true). Arrogance, even pride merely perceived as such, doesn't work. It puts them into a defensive battle mode instead of focusing on potentially helpful tools. They are no longer thinking in terms of tools but in terms of personal turf wars, and start using a different part of their brain.
Show, Don't Tell - Don't expect them to accept anecdotal evidence. Most people are bombarded by anecdotal claims from every direction. There is no shortage of zealots; thus, don't be one.
- Like providing PDF files, rigorous scientific references, real world examples from experts that have been proven over and over.. which some people seem to provide none of other than personal experience and what worked best for me, take my word for it.
- I was thinking more in terms of UseCases and samples that are a good match for their domain. Scientific papers are a nice addition, but you cannot expect it to be digestible to a non-academic. You can instead apply it to their scenarios, however. In other words, apply the science to their "world". Do the footwork (see below) to put the evidence in terms of their world instead of expect them to step into your world. If they want evidence that your vehicle rides smoother than the competition's, don't give them blueprints and lab equations; take them for a ride.
Be Patient and Persistent - One "sales session" won't do it. You have to be willing to go the extra mile. Selling well takes practice. Expect to "waste" time up front to gain the selling experience.
Cool Head - Tolerate the heat. It won't be easy, so don't get down when it doesn't go smooth. Take a breather if need be to cool off. See "Take Breaks" below.
Listen - Listen to the sellee. He/she may offer subtle clues to what they are looking for and why your approach is not working. If you don't focus on subtle clues, you may miss them. Generally people wish to give their point of view first. After they are done or "talked out", they'll be more willing to listen to you. Take notes about questions instead of interrupt if possible.
- The buyer (sellee???) may be wrong and uneducated (not academically, but in real world theory/experience, etc), and may need to be told what the real deal is.. politely, convincingly, with some humor added for easing it in.
- "Educate" them with the techniques listed here, such as using scenarios they find relevant, or perhaps considering ending the attempt (below). Put the theory to work to produce something tangible to their world. For example, if you want to show the dangers of insufficient statistical sampling size, you don't need to write statistical equations, but can show via simple and inspect-able simulations of coin or dice tosses the potential errors of small samples. If you are just plain unable to turn your favorite theories into something practical, relevant, and demonstratable to your target "customer", then it may be time to step back and ponder or "debug" your assumed relevance of the theory to the customer's world.
Change Strategies - If one approach is not working, try a different angle. For example, ask about a tool they did like and why they liked it.
Take Breaks - Sometimes our best ideas come at night, while taking a poop (AhSimple), while working on something completely unrelated, or while driving home. Give communication time to sink in and digest so that you can regroup later and apply the new lessons.
Know When to Quit - If its not working or you don't want to invest the time needed to illustrate your point of view, consider abandoning the attempt and let be.
Repetition is a Symptom, not a Method - If either side keeps repeating the same points, then most likely there is a communication breakdown somewhere that yet more repetition won't solve. Perhaps back up and look at the forest instead of the trees, or otherwise change strategies (above).
Leave Gracefully - Don't fall into the temptation to become aggressive and patronizing as a last resort, because that is usually a recipe for ill-will, making the sellee defensive, which burns bridges.
Learn From Them - Nobody has a monopoly on all knowledge. They may be able to teach you techniques or viewpoints you hadn't considered before. The learning can be two-way.
- And if they show you something new, thank them for it. It shows you are not arrogant.
Get Help - Perhaps your communications style is not a good fit for the target person and you should consider inviting somebody capable of a different approach.
Don't take shortcuts. Do it right or don't do it at all - If putting your point across requires an explicit example or relatively complete demonstration, finish it. Don't try to use words alone if they are not sinking in. Otherwise, you'll frustrate the person and lose their confidence.

When selling products instead of ideas:

Don't bother with the programmers - Sell to the PointyHairedBoss, who will take care of "motivating" the programmers to use the product for you. Thoroughly kiss his (or her) ass, making outlandish promises of productivity gains. A round of golf doesn't hurt. Be sure to point out that those programmers who object to your GoldenHammer are only thinking out for their own careers, as the GoldenHammer will allow the boss to replace highly-paid programmers with inexpensive and expendable junior engineers. HaHaOnlySerious.
- This topic was originally meant to address the selling of ideas (paradigms, language features, etc.) not so much products, and has thus been moved to a new section. Perhaps both are applicable, but the above would only apply to the latter.

Regarding Learning Curves

This sounds like a way to sell a good hammer, or a golden hammer, not just a gold hammer. The drawbacks of a genuinely good tool are that it has a bit of learning curve and requires education before mastering.

Are you saying that one must accept by faith your claim that once they learn the tool/technique it will improve life? How do they know up front that your tool pays off better than another tool that also allegedly requires a long learning curve? "Just trust me" is not sufficient. "It's great once your master it" and "if it failed for you, you must not have been using it right" have been over-used claims, and should be met with healthy skepticism.

Generally a great tool will improve some factor that is measurable or demonstrate-able. A customer can see that a car moves faster or that a rocket flies higher before they understand how your new engine works. Focus on these.

Eli Whitney sold the idea of mass-manufactured rifles to the military by demonstrating how he could take parts from one rifle and swap them with another and how both still worked. The existing semi-custom weapons of the time couldn't do that well. Swappability could allow damaged weapons to be "fixed" faster in the field. (Eli still faced technical problems because his ideas were slightly ahead of existing manufacturing accuracy, but the net result was still slightly better than the alternatives even with the kinks.)

I have a whole stack of "to do" tasks for learning new languages/tools/techniques, and I'm sure you do to. If all the competing ideas are shouting, "just trust me and dive in, you'll eventually grow to see the benefits", then obviously we have a scaling problem because one cannot invest such time for all of them. You need to show them something enticing up-front. Past just-trust-me-and-dive-in's have flopped for me, and probably others. Thus, there's a reason to be skeptical of JTMADI.

Re: "have been proven over and over"

In what way? How can the sellee verify that it's "proven"?

[The reference to "proven over and over" above is desiderata for "Show, don't tell", with the stated mechanism being via "real-world examples" as opposed to anecodotes. That answer was already provided above. If you need clarification, it means: you prove it works by showing exactly where it has worked elsewhere (which just happens to imply that it can't be a 'new' idea). If you are objecting to the answer provided above, do so in a more straightforward manner.]

Remember, TuringEquivalency means that everything "works" to some degree.

[TuringEquivalency means no such thing!!! A proper TuringMachine has no Input and Output, and no way for part of the output to feed back into the input. As a consequence, a proof of TuringEquivalency means nothing about a system's ability to do interactive or reactive "work" of any sort. TuringEquivalency only guarantees that every possible discrete-mathematics function can be represented. (+567 MilliPeeves for ignorant abuse of TuringEquivalency!)]

[I understand that you really mean something closer to: "any programming language that is not a lab-toy is roughly equivalent in its ability to do useful work". This, of course, means the real differences lie "only" in safety (type safety, termination safety, deadlock safety, livelock safety (wait-free)), security (active, passive), modularity, composability, dynamic extensibility, dynamic configurability, performance (efficiency, latency, resource utilization, scalability), disruption tolerance, persistence, resilience, robustness, semantic and syntactic noise, and so on.]

You are correct in that I meant it in terms of software development tools. But, it may not apply to other more specific tools such as text editors, which may have outright bugs that damage text or outright lack features.
[Granted, though there are no intrinsic lines between UserInterface, OperatingSystem, and ProgrammingLanguage. One also hopes that ProgrammingLanguages lack 'outright bugs' or outright lack KeyLanguageFeatures.]

[If you have no NonFunctionalRequirements (which is a situation I've never seen), then perhaps you can get away with poor characteristics in these fields and declaring that anything will "work" to some degree. But most domains have implicit requirements, some (aeronautics, medical equipment, vehicle systems) even have explicit requirements, and to say something "works" requires that one demonstrate (or even prove) that it meets these NonFunctionalRequirements within that domain. A 'GoldenHammer' in ComputerScience is a language or tool that allows one to (keyword) simultaneously meet a variety of these NonFunctionalRequirements without significant sacrifice to other NonFunctionalRequirements. "Show don't tell" suggests demonstration that such a GoldenHammer will work in a new system by analogy to its existing use in other systems.]

Live walk-in case studies are indeed a great way to go if available. However, that alone may not do it, especially if comparing to alternatives that also have working implementations, including the sellee's current system/tool. Some kind of numerical comparison is still desired, such as less staff members or hours to do a similar task, less bugs logged, etc.

[Perhaps so. But you responded just now as though "Show, Don't Tell" were standing on its own rather than standing among many other points of advice. That seems rather silly of you.]

Perhaps I misunderstood your statement. I find your writing style difficult (to me).

[Do not presume that explanation is endorsement or emphasis. You defended against a frivolous position when you said "that alone may not do it". I never implied otherwise. I suspect you find my writing style 'difficult' because you make assumptions and jump to conclusions that are strange and illogical (to me). You asked your question on a quote pulled from "Show, Don't Tell", and so I answered within that context. That is all.]

RE: There are no intrinsic lines between UserInterface, OperatingSystem, and ProgrammingLanguage. One also hopes that ProgrammingLanguages lack 'outright bugs' or outright lack KeyLanguageFeatures.

If [programming languages have bugs], often one can simply use a different path. For example, if multiplication is broken, it can be emulated using repeated addition. Of course this adds more work and more code, and the language will lose some score "points".

"simply use a different path" => JustIsaDangerousWord. If the language or your application of it has no libraries, perhaps it would be 'simple' to replace multiplication with repeated addition. And, relatively, most 'text editors' and OperatingSystems can also be extended/replaced/emulated (with plugins, scripts, new applications, etc.) to just as "simply" get around their problems.

True, it's often a matter of degree.

CategoryEvidence

MayZeroNine