We’ve all heard the term “vaporware.” Software companies are notorious for selling it. It has become such an invasive practice that customers expect it.

It seems all right at first. The Sales guy has a hot new client. The software “almost fits” their needs. It’s just missing a few fields here and there, a little function over here, one over there. He sits down with a member of the engineering team. “Can you mock up what this would look like?”

“Sure,” says the engineer. “That would be pretty easy to add on.”

“What about this function over there?”

“No problem,” says the eager engineer. He can envision how it would be implemented and it isn’t that large a stretch.

The Sales Rep goes off to his next customer meeting with his “demo” and powerpoint slides in hand.

“See – we understand your business issues, we can take care of your needs.”

The customer debates a bit but three months later, the contract is signed, software purchased.

The Implementation Team has been selected. Before they head over to the customer site, the Services Manager calls the Services Lead into his office. “One thing you should know. The customer thinks the product does this and that and has these functions.”

“What?” says the concerned Services Lead. But it doesn’t!”

“Can’t you just configure it on the outside?”

“It doesn’t work that way! We need some product changes.”

“That’s OK – the engineers said it would be easy.”

The Services Manager goes to the VP of Engineering. “When can we have this product upgrade?”

“Product upgrade? We’re just starting final test right now for our major release. If we put this in now it would delay the release significantly and we have customers who are planning on this schedule.”

“But it’s a ‘must have’ for our new customer. Sales committed to it!”

The Executive Committee has an emergency meeting. Engineering is directed to create a branch in parallel during their final test sprint to try to get these features out right after the main product release, against their policies. The new features will be released 1 month after the major release.

The concerned Services Lead is told that they will just need to “fudge it” for the first few months of the implementation project.

“It’s OK”, says their Manager. “The customer is using the Waterfall method and are first going to firm up their requirements, then spend a couple of months on detailed design. By then the release will be ready.”

An uncomfortable team heads over to the customer site with their instructions. They had been directed that during requirements review, to pretend that the features are in the product and check off the requirements associated with the new fields and functions as “OOB” (out-of-the-box). “It’s all right”, they are told by their Manager, “because they will be in the product real soon.”

During the detailed design phase the customer starts asking to see the product to help them envision the customization changes they are designing. The Services team knows many of the big features they expect to see there just aren’t there. There’s tap dancing.

Eventually the customer figures out that the software isn’t all there. The truth is out. There is a huge blow-up and the customer calls the CEO to complain. The CEO assures them that their features will be in the new release. They are still upset but sit down with the frazzled Services Lead to iron out what a viable implementation schedule would be including incorporating the upcoming product release. They start their work on the current release for customizations that don’t require the new features.

The new release is delivered and the customer’s policies require a total re-test. While re-testing they uncover minor changes in the completed configuration needed due to the new product enhancements not being exactly how they’d envisioned them. Because of re-testing and re-work, both cost and schedule are impacted. Although the contract was “Time and Materials”, they call the CEO and refuse to pay any extra cost due to re-work and he concedes. Still the project costs them more money than planned due to the schedule impact.

The customer isn’t happy but is used to software companies that are less than truthful. Standard practice, they grumble. The skilled Services team eventually delivers the final solution but the customer is less than thrilled.

Replay in a Parallel Universe

The Sales guy has a hot new client. The software “almost fits” their needs. It’s just missing a few fields here and there, a little function over here, one over there.

He sits down with a member of the engineering team. “Can you mock up what this would look like?”

“Sure,” says the engineer. “That would be pretty easy to add on.”

“What about this function over there?”

“No problem,” says the eager engineer. He can envision how it would be implemented and it isn’t that large a stretch.

The Sales Rep sits down with the Engineering Manager. Here’s the features and functions that Client X will need if they buy the product. Is it feasible to get them into the current release?

The Engineering Manager and Product Manager have a quick meeting to determine the feasibility. They will need to move some features out of the current release now to make it happen but there are no clients waiting for those. She gets back to the Sales Rep with an “OK – as long as the customer can commit within the next few weeks while we still have a few Sprints left.”

The Sales Rep goes off to his next customer meeting with his “demo” and powerpoint slides in hand.

“See – we understand your business issues, we can take care of your needs. These few functions are not in the software yet, but if you buy the product the Engineering Management team has agreed to provide them in the next release which will meet your schedule. If you can sign the contract this month.”

The contract is quickly signed, software purchased.

The Implementation Team has been selected. During their internal kick-off meeting, before they head over to the customer site, the Services Manager calls the team into his office. “One thing you should all be aware of. There are a few features that are missing from the product but engineering has already agreed to deliver them in the upcoming release which meets the customer’s schedule. The Product Manager will work with your team and your customer to make sure we build the features the customer is anticipating.”

“Great.” says the Services Lead.

During the detailed design phase they start reviewing the product and proposed changes. The customer can provide input into the new features and iteratively they improve on them before the product development team has started their coding. In fact, they find a way that the product changes can be implemented that remove some of the customizations that had been bid, saving the customer implementation money.

The project is completed on-time. The customer feels they are part of the team and the vendor is the best vendor they’ve ever worked with. They will definitely consider this vendor for their next project.

They are happy to give a Press Release and authorize a marketing blurb for the vendor’s website.

Why Sell Vaporware?

Why do software companies feel they need to sell vaporware? Some misguided notion that customers won’t buy a product unless it has all features today?

The second scenario brings everyone on-board. The company is collaborating. The customer is respected.

Having worked on projects sold both ways, I can attest that the second, honest and up-front scenario is by far the best.