Fog Creek Software
Discussion Board

Selling non existent software features

One thing that bothers me is how many times features for software I'm developing get sold that are not implemented.  It's happened on many applications that both my roommate and I have worked on and we constantly discuss if it's necessary.

It bothers me because then I have the stress of delivering a feature in a rediculous tight schedule.  The result is disorganized sphagetti code and a feature that hasn't been fully thoughtout.  I absolutely hate putting my name on crappy work because of some sales guy or the President breathing down my neck and trying to boost revenue at my expense and possibly putting the long term reputation of the software on the line.

There has got to be a better way!  Maybe I don't understand the sales side.  Selling a well defined solid product seems like a lot more fun than stressing out for anybody that will give you a buck.  Maybe that's too idealistic and somebody needs to tell it too me straight, but either way I'm really sick of it.

Colin Jennings
Tuesday, March 4, 2003

This is entirely too common and the problem will likely never disappear. One of the core problems is that many people in management think that by promising a feature, it will make you work harder to implement it.

However, the problem can be mitigated when development folks clearly demonstrate how this strategy doesn't server the long-term goals of the company. At a company I worked for, I felt I was successfull in "training" the management that promising a feature doesn't make that feature appear. It took time, but development and sales/marketing worked together on the feature list and only that feature list was shown to potential customers.

Note that I said mitigate...Not everyone is interested in the long-term goals of the company. I've lost count of how many clueless sales people I've met who are only looking for a quick commission check. They'll promise a customer anything today because they know by the time the poop hits the fan, they will be on to the next sales job.

Go Linux Go!
Tuesday, March 4, 2003

This is common in all industries. Bait and switch or fished in. You get the customer to commit and then milk them. The customer (if its a company) can't say "we made a mistake, lets back out" so they stick with it as deadlines get passed and money gets burned. The more the client spends the more they will likey keep spending...and then word gets out and everyone is trying to sell them something.

Honest Abe
Tuesday, March 4, 2003

This has happened so many times on the project that I'm on, that I guess I turn a blind eye to it now.  I should probably be more adamant, but oh well.

What's worse is that I took over a piece of the project that claimed to have a certain feature implemented, and was billed as such on all of our marketing materials, but was not functional, AT ALL.  It wasn't even that we said we had it, and we didn't.  It was in the program, but did not work.

Nobody ever noticed because the customers as yet had not needed the feature.  After a year and a half, I convinced management to disable the "feature" and remove it from our marketing materials.

I would say that this shows that persistence pays off, but I'm sure as soon as a customer wants it, I'll be tasked with turning it back on and making it work.  Such is life.

Tuesday, March 4, 2003

How are the sales folks learning of the features you're working on?  Perhaps you can keep the sales force from learning about your features, or be extremely careful with what you announce to people outside the team.  You could say, "Well, we're working on <some cool feature>, but that may not make it into the final product."

Brent P. Newhall
Tuesday, March 4, 2003

I don't know how other people's shops run, but many of our features are roadmapped out a couple releases ahead of time (subject to change of course).

Apparently the sales people just tell people that we're farther along than we actually are, and worry about catch-up when they close the deal.

Tuesday, March 4, 2003

In a company I used to work for, the sales team was tasked with doing whatever it takes to get the business.  This entailed what I refer to as "lying" to the customer in order to get their money.

My general reaction was to implement the feature if it was relatively minor.  With major tasks, I would inform management so a timeframe could be worked out or whatever.

I think that eventually, selling vapor-features bites the salesperson really hard at some point, they learn their lesson and are cautious in the future.

Wade Winningham
Tuesday, March 4, 2003

I do try and keep a very open line of communication with the sales and marketing folks.  Fortunately, I work in a smaller company where that is possible and that definitely helps manage the expectations.

One unfortunate thing is that I work on electronic design software and I have minimal experience with these types of applications from a user perspective.  It is very technical.  I generally have a hard time trying to drive features.

Additionally, the President of the company get this "high" from pressure situations.  He really seems to love it, but it just burns me out.  Maybe I would feel the same if I owned the company like he does.

But, I agree, keeping an open line of communication with the "pressure cooker" instagators is a must.

Colin Jennings
Tuesday, March 4, 2003

Back in ... hmm, I think it was around 1993.  The company I worked for was bidding a contract for Bell Atlantic.  They wanted a field deployment in 3 months.  Our prior experience told us that our best time to field would be somewhere between 6-9 months, and probably on the high side of that.  But some of the technology had matured, we could hire some more people, perhaps we could be field testing in 6 months...  So that's what we told them in the bid - 6 months, no sooner.  A competitor, with no experience said 3 months.  They won the contract.  We went elsewhere.

The most interesting part of this, is that the head of North America operations (a guy named Jim Meyer) told my manager specifically that he was watching how he handled this high pressure situation.  Meyer told him that integrity meant everything and that the contract was secondary.  I was frigging impressed.

As the contracts went, that thing was called BA "Video Dialtone", which went nowhere.  We wound up winning a separate contract with TeleTV as a repeat of this a few years later, which also went (almost) nowhere.  FWIW,

Nat Ersoz
Tuesday, March 4, 2003

This is a nasty problem because your sales force is competing against other sales forces that are doing the same thing.  If your sales team levels with the customer saying, "we won't have that feature until our next release," but your competitors say, "we have it now," how do you prevent your customers from jumping ship and chasing what appears to be a competitive advantage?  Even if your competitors offer something completely broken, software users are so used to being guinea pigs by now that they expect not to see it actually working for a few releases, even though they continue to behave as if the feature is ready for prime time the first time they see it.

Note that I am not advocating this practice by any means. I'm just saying that I can kind of understand where it comes from.  I have a few ideas about how to combat this, but I must admit that none of them are guarenteed to work.  What would you do instead?

anonymous coder
Tuesday, March 4, 2003

Unfortunately, I think anonymous coder hit on a major reality, but I think that train of thought is so short sighted. 

But who knows?  Sell crap now and then fix it later.  Maybe that strategy is much more profitable than creating solid software and selling only to the people that can use the features you've got.

Colin Jennings
Tuesday, March 4, 2003

You are in good company.  Microsoft has made a very good living doing just that.  How many of us patiently awaited SP3 on NT 4 for half the stuff to work?

Tuesday, March 4, 2003

I think the key strategy I'd use to fight this in the marketplace is to 1)  establish a reputation for quality by never releasing substandard products and 2)  establish a reputation for very short lead times for feature development and stay lean.

I think if you can pull this off you can win as the customer will learn to think, "if I wait a month, I'll have a working version of the feature"

anonymous coder
Tuesday, March 4, 2003

At the end of the day, you need to sell software in order to make the bottom line.  It's always a pain to have to throw in and throw together new features and last-minute fixes, but if it brings in the needed sales, you now have money and time to fix the "spaghetti code".

The best examination of this that I've seen is the XP idea of "technical debt", where you incur debt by deferring bug fixes or properly implemented features in order to ship on time with a specified feature set.

The catch is that you have to pay off this debt in the future.  If you don't, it will accrue interest in the form of extra bugs and extra work required to maintain and improve old code. 

If you never pay off your technical debt, eventually the code will become unmaintainable,  as the time to add new features or fix bugs will start to be longer that the time to totally refactor or reimplement the software.

Here's the reference:

Colin Evans
Tuesday, March 4, 2003

As Steve Ballmer would say "Get the business. Get the business. Get the business." Selling is the core job of any company and if that means promising features that are not available then so be it. You have a job because of your sales team, and that's the reality of any business. It may not be 100% ethical or 'good' but it works selling products and that's the bottom line.

John Rosenberg
Tuesday, March 4, 2003

I would suggest two things..

Never show the salesmen screenshots of what your implemented feature will look like. Most of them have this "I have seen it and therefore it is almost there" attitude.

Tied to this, shorten your internal development cycles. Instead of doing screen shots and a 12 month roadmap, you might want to have monthly demos of the features currently implemented.

You might suggest what direction you are heading, but those screenshots that look so good on PowerPoint always come back to haunt you! "You showed it to us six months ago, so we thought it was ready. Its your fault."

I realise this will not work in all situations, but it does have the added benefit of giving sales a working demo to play with on their laptops!

Tuesday, March 4, 2003

I used to gripe about the sales and marketing department too, but then I finally understood what they have to go through to make a sale.  The best way to understand why they do what they do is to step into their shoes for a few days and try selling the software yourself.

Of course, the only way something like this will happen is if you get management to buy in on the idea to let you temporarily switch tasks.  Some small companies do actually rotate developers and have them try and sell every once in a while.  In my opinion this is a good thing that should be done at least once every six months or so.

The only thing I'd hate to see though is if we switch over to sales for a little while, and management decides sales people should start coding for a temporary period too.  LOL, I can see the horror stricken faces on those sales guys now :)

Anyhow, if you're going to do anything like move up the career/corporate ladder, then you're eventually going to have to do some selling in some form or fashion anyway.

There's got to be more than chasing the almighty buck for 8-12 hrs of almost everyday of your life.... Sigh.  I'm almost getting sick of this industry and am almost ready to bail if it weren't for my sickly retirement nest egg which is almost nonexistant.

Tuesday, March 4, 2003

How about a "confuse the customer" approach to sales?  In the course of your normal development, add in a few quirky features that offer some marginal utility, but keep them hidden.  When you get into a situation where your competition is announcing some feature that you can't match while still being able to live with yourself, you unveil your hidden features instead.  This at least gives you some leverage because you can claim, "yeah, but does the competition have this?!?!?!"  It also allows you to segment your market a bit better and if the competition takes the bait, you can force them to disrupt their plans to fix what's broken with their new feature while you roll out a superior implementation.  Could work?

anonymous coder
Tuesday, March 4, 2003

A good sales guy is someone who does exactly what he is incentivized to do and can get it done.  If you have one of these people, your challenge is to make sure your incentives line up with what you actually want him to do. 

If you accidentally get your incentives in the wrong places, it's your fault.  The sales guy is not capable of consecutive thought on his own.  He will not try to figure out if his actions are good for the company in the long term.  If he does, he is not a good sales guy.  Fire him and get somebody else.

If your sales guy is selling stuff you don't have, that's because he is personally making more money doing it.

Eric W. Sink
Tuesday, March 4, 2003

So is the solution to personally charge the salesperson for excess development time incurred developing his non-existent feature?  ;-)

Tuesday, March 4, 2003

He'll just back-charge the NO-SALE cost of the feature not being available.

Not A Salesman
Tuesday, March 4, 2003

Maybe my incentives need to be in line with the sales people incentives.  I throw together some feature to lock in a sale...cut me a little piece of the pie.  I have a feeling a few developers, including myself, would willingly throw themselves in the fire for that.

Colin Jennings
Tuesday, March 4, 2003

The problem is that prospective buyers not only let sales dudes talk about future modifications, they encourage that!

I tune out once a sales guy starts talking about features that are not currently in place.

Tuesday, March 4, 2003

A problem with changing incentives so that the developers "get a piece of the pie" by quickly implementing features that have been sold, is that it encourages the developers to not work on features until they get to this stage.  Or at least to hide them from the sales force so that they get something extra from it.

Think about it - why should i start working on this feature now, when i can wait a month until it is urgent and then get a bonus for doing it in a rush.

Dave Bryant
Tuesday, March 4, 2003

But if your going to be doing it in a rush anyway, which you invariably will be why not be included in the action...

Sometimes it annoys me when the sales guys get a commision for selling something and I get nothing but more unpaid overtime.

Wednesday, March 5, 2003

tapiwa said: "Never show the salesmen screenshots of what your implemented feature will look like. "

Or just make screenshots look incomplete, for example, draw them by hand.

Myself, I use the "flat" option in the Visual C++ dialog editor. It is very handy for making screenshots look incomplete.

The uglier your screenshots are, the easier it is for the salesmen to realize that more work is needed before the feature is ready.

Wednesday, March 5, 2003

I have built three different software companies and bought millions of dollars of software over the last ten years and I have realized that the most popular method of buying software is seriously flawed.  The upfront purchase (or lease) of software was developed for several reasons.  Companies purchasing software were familiar with buying capital goods, which required a large upfront payment, which was depreciated over a period of years.  Software was similar to such a capital good in that it required large amounts of money to build and theoretically lasts indefinitely after being built.  Software companies desired to charge a large amount of money upfront for a license fee as it enabled them to recoup their development costs as quickly as possible.  Many software companies were able to “bootstrap” requiring very little capital to grow to very large sizes.  The exchange of a large initial license fee satisfied all these initial goals very well.

However, the end user and developer’s goals quickly diverge as soon as a license purchase is made.  There are two main reasons both of which are clichés in the software industry. 

Once software is installed and utilized for a period of time, the end user finds out that: “its what I said I wanted but now I know what I need”.  The end user needs additional features that are almost never the “gee whiz” features used to sell the software, but rather the mundane “blocking and tackling” reports and features.  In addition the customer needs rock solid stability, not just during the pilot stage when achieving stability is relatively easy.  Instead customers need stability after the rollout stage where loads of data and many inexperienced users are taxing the demands of the system. 

The second cliché is “there are thirty-three days in the month the financial quarter ends” As the financial quarter ends for any software company, there is a tremendous pressure to close sales and make the quarter.  The company needs to align all its resources to win the new customers whose license payments allow it to exist and thrive.  The difference of one or two sales can make or break the quarter.  The software company will do almost anything to get those sales.

Both of these facts are very well understood behavior by both the purchaser and developer.  Purchaser’s wait until the last days of a financial quarter to buy software and demand that additional new features they want are written into the contract for delivery.  In addition they demand and get price breaks.  Software companies write contracts on the last day of the quarter (or as is commonly known days after) with these provisions.  Once the contract is signed the purchaser and developer now have exactly opposite goals.  The purchaser will soon find out what new features it really needs in addition to those its written into its contract, which were quickly “jammed in” so that revenue could be recognized. 

Here is where the relationship now stands: the software company is busy promising and putting in new features to gain new customers, and the end user is left with software that doesn’t fulfill its needs.  The end user needs those new mundane features to help it use the software, but should recognize that there is now another new customer writing a contract with its wants, which will supplant the existing customers needs.  Worse yet, all of these “features by contract” are usually unique to a particular customer and are hastily added.  The end result: bloated software with so many custom features that its unusable, and unstable software that was literally thrown together.  The “golden rule” applies: he who has the gold makes the rules, the software company has the purchaser’s money and will do only the bare minimum to get a maintenance payment fully realizing that the user will have to make the decision to either be orphaned or pay 10-15% of its original payment “to protect its investment”.  No matter how well intentioned, resources always go to adding new features to win sales versus tightening existing functionality to make existing customers more satisfied.

I have lived both sides of this relationship.  No matter how dedicated you are to making the best software you can, there is no way to do it when new sales are driving features.  The only way to build great software is to have a great product manager that is balancing feature requests from existing customers via a dedicated support department, potential customers via strong sales and marketing departments, and just as importantly balancing a tough development department that reasonably limits features and scope so the software is rock solid and maintainable.  An upfront license fee basically reduces a product manager to a keeper of new sales/marketing requests.  They will try to balance needs from support and development, but when push comes to shove it will come down to a final cliché: “we need this feature or we will have to walk away from the business”.  New sales are so important the software company has almost no choice but to meet almost every demand no matter how reasonable or unreasonable.

I now sell software purely on a quarterly fee based on the usage of the software. 

Wednesday, March 5, 2003


Are you making more or less with this quaterly fee arangement?

Prakash S
Wednesday, March 5, 2003

Feh. What a cynical thread this is, even if it might be true.

Whatever happened to 'delight the customer'?
Is it dead?

I guess these comments made apply to business software and not shrinkwrap software?

Dennis Atkins
Wednesday, March 5, 2003

Much less up front, much more later.  I wrote a full article with NPV (net present value) analysis.  I had a company that I sold that had $20M in revenue one year only to have $5M the next (and the $5M was mostly services/support) I was the CFO and saw it coming.  The CEO disagreed with me until the bitter end.

Look at the i2's, Manugistics, etc, etc.  If you actually sell great software nobody needs to upgrade, if you don't and you think in this market people are going to buy your stuff before checking out all your current customers you're in fantasy land.

Therefore the one time license fee looks great during times when people are buying and is absolutely awful when their not.

Thursday, March 6, 2003

*  Recent Topics

*  Fog Creek Home