Post Purchase Dissonance – Software Applications

A Google search did not yield a good result to the above topic. Hence I am trying to understand plausible causes for post purchase dissonance in software products. The approach is very simple - try and retrofit the cognitive dissonance theory to software products.

The Case:
Company X uses Siebel (CRM Application Suite) in several of its business units for various applications ranging from catalogue listing to retail execution to call-center operations to sales force management. Company X was not entirely satisfied with the product they were using. There has been a spate of pull back from different units. Usual turn around time before calling off an application ranged between 12-18 months. After investing significant Time and Money Company X pulled out of their usage.

Why do companies choose a certain technology and again why do they forfeit the usage after millions of dollars are invested? Is there anything that can be done to reduce the post purchase dissonance?


Reason 1: Very High cost structure making extremely unattractive for smaller business units.
Cost Structure for Enterprise Software like Siebel
Is the kind of investment justified? The answer is clearly a NO. A roll out in one unit or just one application can never justify such a huge investment. Also it is should be accepted that the first two years of investment can never pull a great ROI. There is certain gestation period companies should be ready to invest.

Reason 2: Availability of alternate attractive solutions at lower cost.
Good alternatives like the Salesforce.com (A web-hosted application) - charges around $900 per annum per user. Its fair to say that Salesforce,com is the fastest growing company in the CRM space adding marquee customers at rapid pace. At this point I would not be able to comment on the flexibility it offers in terms of product feature or functionality. However the package looks very attractive for mid-size companies (size of 500-1500 users).
Close on its heal is Sugar CRM which is an open source application, which offers the basic package for somewhere around $100 per user per annum. Additional features would cost more.

Reason 3: Business Process v/s Software Flexibility
An enterprise application will be built on certain industry standards; however the business processes of each organization would vary and can never be frozen into a template. Unusually Decision Makers start with the assumption that they would be able to make minor modifications to their existing business processes and adapt to newer software process definition. But as time progresses the theory degenerate, everyone wants the software to work in the manner they are used to. Although Siebel offers the flexibility to tweak, every tweak will have a negative impact on the performance. With poor performance comes growing dissonance.

Reason 4: Product Defects & Bugs
Bugs in software products are as old as the history of the software products. When newer industry verticals are being explored – with no known standards available we are in trouble. Siebel has some very good off-the-shelf solutions but in cases where there are none they co-work with the industry leader to develop newer solutions. In difficult terrains like these product bugs can’t be totally over-ruled.

Reason 5: Expectancy Disconformance
There is a pre-purchase expectation which is evaluated against the actual performance. Often there is a mismatch with what the business expects and what the software delivers. Also there might be a mismatch of what is promised and what is delivered. When the product fails to meet certain expectation there is a growing dissonance.



Reason 7: End user Adoption
A software product unlike others will need some level of sophistication when it comes to the usage. User adoption is the biggest problem when it comes to failure of software products. Complex software, hardware, PDA, Handhelds and black berry’s are being used to facilitate business. Increase in number of gadgets doesn’t necessarily turn into improved business. With addition of each new device we are asking the users to learn something new. If the users have never been exposed to systems or were using paper earlier it will be extremely difficult to win them to use the application.

Reason 8: Etc Etc…
An enterprise application is often run by 3 or 4 vendors; it is difficult to orchestrate a perfect symphony when so many parties are involved. For instance we have a software vendor, an application service provider (who configures it), and another service provider (maintaining it). Add to this a vendor supplying hard ware.
If this conducting an orchestra wasn’t tough enough..now we are asking an elephant to dance along with the orchestra!


Each of the above reason would in some parts building up the dissonance. Firstly it’s aired by frustrated users who would find it extremely difficult to perform their routine tasks. Every minute that a user spends trying to understand the system, trying to get the system work means that he is taking away time from what he has to do (his core job gets affected – try telling a sales guy give me 1 hr and I will fix your problem). So a system which was meant to facilitate his work has resulted in additional effort on his part.

Similarly when the system cannot perform in a certain way or the user has to tweak his process he is relearning things which he had learnt over years. This attributes to disconfirmation. Any deviation from what from an expected behavior will lead to dissatisfaction.

Dissatisfaction leads to product being dropped, bad word of mouth and potential legal actions. An enterprise package which doesn’t exactly fit into a volume business will definitely have a tough task in claiming back the tainted imagery.

Are there any answers??
If it were a traditional product like a TV or battery, the product manufacture could have at least the option of calling back his product. Classic cases are Chrysler calling back it Durango’s when it was identified that the wheels would roll-off at high speeds. Even though it costed quite a fortune of Chrysler to call each one of these Durango’s for an inspection and fixing the ones which could have potentially fell off the hook.

Or very recently Dell+Sony combo having to call all the Li-Ion batteries for certain laptop which apparently had the propensity to catch fire. The sample size was 4 laptops out of 4 million? But still Dell went ahead with the damage control calling back the entire shipment … one way to reduce the damage to brand imagery.

Unfortunately software products don’t have this luxury; if lucky they might get one last chance to fix all the loopholes.

Sometime back I had read how important design phase is in software life cycle. I guess we go back to the same place to fix these problems. Get your requirements right, deliver what is promised and what is required. Use your learning from one deployment to other. Don’t repeat the same mistake again. And above all keep your product simple. Cause you may not get a second chance post-purchase.


***Disclaimer:All the views discussed above are mine, and do not reflect any company or individual thoughts. Siebel and Salesforce.com have been taken as examples and similar instance can be found in other enterprise applications.