Value, Features and Workflows

In sales school we are taught to sell value. Initially that approach was designed to defang the threat of endless haggling over price, but it took an extra twist in the software industry. Since software companies rely on user's desire to " buy the next version" to secure revenue from maintenance and upgrade sales, a feature war was the consequence.
As a result, buyers frequently request feature comparison tables, driving the proponents of "value & vision" up the wall. It also creates tension inside a sales organisation, when a customer asks for a specific feature and the seller is reprimanded for " not selling value". How can this split in expectations be reconciled? As learned in Negotiation Basics, we need to step back and see beyond positions at the interest that drives them:
The seller doesn't want to do feature to feature comparisons, since they never match and are time consuming and tedious. On the other hand showing how trustworthy, visionary and future-prove the product is, makes creating confidence much easier.
The buyer is very aware, that software doesn't have any inherit value, but only its application has. Using software requires invoking its features, so the feature comparison is a proxy for the quality of workflows it can provide in the buyer organisation. The challenge here is that any change in feature set will break somebody's workflow.
An example:
Outlook users quite often add themselves as BCC into an outgoing eMail, so the message appears in the inbox again. From there it is dragged into a folder in an archive, so it is kept in the local, not size restrained PST file where it can be found. IBM Notes doesn't allow to drag from the inbox into a specific folder in an archive. The equivalent workflow: The user doesn't need to add herself to BCC, but simply uses Send & File on the original message. The automatic scheduled Archive task moves the message later without user action required. The searchbox will find messages regardless their location in the main mail file or in one of the archives - same result, IMHO less work - but a different flow.
The solution to this is consultative selling, where a seller looks at the workflows (that are mapped to features of existing tools or practises) and proposes improved workflows based on the feature set of his products and services. A nice little challenge arises, when the flow isn't clear or the proposed product has no advantage.
A little story from the trenches to highlight this: Once upon the time, when files still were mainly paper, a sales guy tried to sell one of my customers a fax server, stating that having the fax on screen, thus eliminating the need to walk to the fax machine, would be really beneficial. He looked quite dumbfounded when the manager asked: "And how do I write on this?". The manager's workflow was to scribble instructions onto incoming faxes or document that it had been acted upon. The software couldn't do that.

In conclusion: there is a clear hierarchy in software: To have a goal and destination, there needs to be a vision, that vision needs to be supported by software that has value in implementing this vision. Value is generated by supporting and improving workflows by that software. Workflows use one or more features of the application. Comparing features is aiming one level too low, the workflows are the real value generators. A change in software most likely requires a change in workflow.

Quite a challenge!