How Fog Creek learned to do sales part 2 | Hacker News Reader

How Fog Creek learned to do sales part 2

blog.fogcreek.com

88 pointsbuzzcut14 comments

What I find most inspirational about FogCreek is that they have managed to survive and thrive in even in the face of powerful "incumbents" i.e. free solutions that have a longer history.By that I mean that when the sales person for Fogcreek for Version control s/w makes a sales call, he could be faced with groups who are using either PVCS or CVS or SVN -- and yet he or she manages to close that sale. I would love to know how you get past that barrier to entry ? In more general terms, when if you are making a sales call to a prospect who already has a solution which may be inferior but nevertheless in production, how do you get them to switch ? When do you know to move on to next prospect and when to further pursue the lead ?

You should remember that the existence of open source or home-brew solutions is not in itself going to prevent me (as a person who makes purchasing decisions) looking at a paid-for version. For example, I use Dans Guardian at the moment but am looking at Smoothwall to do much the same thing. I use Amazon S3 + s3ql for backups, but also use Nasuni for the same thing. I can make forms quickly and fairly easily with Django but prefer Wufoo for all sorts of reasons.

I've been told by my manager to favour off-the-shelf solutions - he feels it will allow us to hire more easily if I decide to leave. I prefer not to have the hassle of writing software myself, or downloading and configuring often very complex software which might not be that polished. Sometimes, I just want a support person to call who can fix stuff quickly so I can get on with my work rather than dealing with support issues. The people I work with are not very tech-literate so I need software which even they can use easily (otherwise I just end up doing their work for them).

There are many products I would never consider buying, and many top-rate open source products I cannot live without. But if you can encapsulate your expertise and knowledge in software and sell that to me and make my life easier, I will cheerfully part with money.

Going to echo this sentiment, however unpopular it may be. Free solutions are great and make business a lot easier and/or cheaper to conduct. However, you get what you pay for.

Your mileage may vary, but I have found that many free solutions offer some of the worst support in the world. Even worse if you are trying to use their software in a way that they hadn't intended.

> However, you get what you pay for.

No. You get what you reward for.

While payment is one form of reward, many customers reward a vendor with unconditional-repeat-business, in which case they usually get much less than what they paid for, even though they paid dearly. They just didn't reward for quality.

A lot of expensive products are pure garbage, and in those cases, you certainly DON'T get what you pay for. The simplest example I can think of is HDMI cable. They cost $30/6ft at RadioShack when on sale, and $1/6ft at Amazon or MonoPrice. Customers pay RadioShack for it; what do they get? How is this different than the general case, and how is this different than the specific case of software?

In context, I was referring to "getting what you pay for" from free services, not so much the paid ones.

With paid services and products, you're aiming to get the best bang for your buck, so obviously you would evaluate cost vs. output or some other measure. As such, I would say "Hey, why is this HDMI cable from Radio Shack so expensive compared to Monoprice?"

And blam, I've made the best decision in terms of value.

I think.

I don't honestly know the exact pitch that our sales team is using right now, but in the case of Kiln, stories that show how powerful DVCS is compared to legacy solutions usually make one hell of an impact. You can check out http://www.fogcreek.com/kiln/worldtour2010-dvcsu.html?fccmp=... for example, which is the talk I gave as part of the World Tour. A lot of people who previously didn't "get it", suddenly did.

That can't work for everything, sadly. I know that products that centralize all of your communication, like FogBugz or Flowdock, make one hell of a difference, but it's hard to demonstrate that centralizing communication is helpful if someone doesn't currently believe that.

The talk you gave, which highlights how DVCS can help you seamlessly manage bug fixes and features in multiple versions of software, was an excellent example of explaining benefits over features (which Dan talked about in the source article). Sure, Kiln has a ton of great features for getting the most out of DVCS, but explaining the benefit of how DVCS can positively affect your team helped tons of people "get it," myself included.

It's easier than you think if you target organizations with non-technical decision makers. I've seen "directors of software" force LAMP development groups to switch from SVN to TFS.

How does that work? The dev team spends a day writing a mirroring script and setting up the svn server on someone's workstation, and then forgets the decision was ever made?

No, that's a good idea though. What transpired was SVN use became deprecated, and the entire group had to learn TFS (TEE-CLC).

Cost is often a perception thing. For example, I work in a mostly outsourced IT shop - the only thing in-house is our custom coding. With a $100 million annual budget, the difference between free version control or $200 for FogsBugz licenses for our 8 devs is negligible.

Around here, until you hit the 5-10K mark, it is as good as free. (Not that I condone such wanton spending.)

This is kind of off-topic, but I've always wondered, the pictures in Joel's articles (and this one, even though not by Joel) always seem to be completely random. Am I missing some relationship to the content? If not, what is the reasoning for having random pictures?

Joel has taken inspiration from Philip Greenspun, as described here: http://www.joelonsoftware.com/articles/fog0000000021.html

Elsewhere Joel has talked about how just having pictures (any kind of pictures) in his blog articles made them much more readable and that they were accepted much more positively than just a wall of text.

Reply on news.ycombinator.com