What mistakes in managing software products must be avoided to keep people from hating the vendor?

softwareengineering.stackexchange https://softwareengineering.stackexchange.com/questions/20790

Question

A previous question about why people hate Microsoft was closed. This is an attempt at a somewhat more constructive question along the same general line. This one is both broader and narrower though. It's more general by being about software vendors in general, not just Microsoft. It's narrower by dealing only with management of software products.

So, what steps should be taken (and/or avoided) in managing individual software products to assure that not only the individual products, but the company as a whole is respected/liked/seen in a positive light?

Was it helpful?

Solution

Most important is obviously to deliver a quality product.

Other imporant topics:

  • Honesty. Don't lie when the truth will come out sooner or later anyway.
  • Reliabilty. Adhere to deadlines.
  • Availability. Reply emails, pick up the phone.
  • Willingness to cooperate. If it means to work with your closest competitor to make what the customer needs, do it and do it professinally. No dirty tricks that hurt the customer first.

The last item on my list is probably what got MS such a bad reputation (though I think they are much better now in that respect); and it's even worse when small companies do that.

OTHER TIPS

A non-exhaustive list, starting with two that can go a long way to creating really passionate customers, ones who will go out of their way to promote your product.

  • A responsive, respectful support model. Nothing like being fast and giving your customers good support. Ideally a direct response model. Even with a community support model like a bulletin board site where anyone can ask and anyone can answer questions but moderating it and seeding it with support staff will help. An old maxim about customer service - give someone good customer service and they may tell one person about it. Give them poor customer service and they will tell 10 people. In the web world that 10 people now gets multiplied many times.

  • Using good design - you want to aim for delighting people. This takes not just engineering but design - listening to customers, watching over their shoulders, prototyping, and continuous improvement of released products.

Two others I'd add:

  • Quality - yup, keeping a tight lid on the bug count, not releasing until it is solid. Focusing on a solid product rather than a flaky one with feature overload. I remember sometime during the frenzy of web 1.0, a large vendor announced how great it was to be able to develop software iteratively without a real quality process when developing websites. Around that time, I tried one of their new sites and it broke on me almost immediately. It seemed clear it had NO testing before release. A good way to frustrate your allies and turn away new customers.

  • A licensing model that works well for how people will use the software. People know they need to pay, but if you can reflect the flexibility people need in your policies, then it works for everyone. Example: per-seat licenses that allow you to use multiple computers, or a work and home computer. Because a lot of people have more than one computer.

-- Alex

Some ways to be hated:

When marketing and selling your business product, aim for people with purchasing authority who won't have to use it. Then you don't have to worry about usability.

Ideally, pricing should be confusing and irrational. Have multiple versions with functionality that's not clearly differentiated. Ideally, have one or two particularly desirable features high up on the price scale, so people get the feeling they have to pay big for a lot of things they won't use.

If you have enough power, make later versions of your software not quite compatible with their predecessors, and don't offer upgrade discounts. For extra points, remove functionality that people might be used to.

Advertise features that don't really work. If you've got sufficient control of the product, remove some of them with more or less forced upgrades.

Leave some bugs in, preferably intermittent bugs. Come up with reasons why, if something happens, it isn't your fault. Stonewall your complaining customers. Alternatively, come up with a fix that actually makes the product less usable.

Quality control is for companies that want customer satisfaction. You've got a lot of potential beta testers out there: use them. You'll get reports even if you don't give them any feedback. You can fix a lot of them in the next version (see above about slight incompatibilities, no upgrade pricing, and removing functionality).

Mess up the users' computers. DRM is great here, particularly if you don't tell anybody about it ahead of time (and particularly if they won't expect DRM on something like your product).

Anti-piracy measures are great. Make sure your detection algorithms have plenty of false positives. It isn't necessary to have convenient or easy ways to correct the false positives.

Long confusing EULAs that claim ridiculous things are commonplace nowadays. To get hated over them, you have to bury something onerous in there and enforce it afterward.

Documentation is for wimps. Make sure it's virtually impossible to figure out how to do a few important things from the docs. (Unfortunately, this has become too common over time to be really effective.)

Rebates that require awkward documentation and application procedures are good. Remember that many receipts nowadays are printed in a way that fades over time, so you can save a lot of money by requiring the original receipt and taking long enough to process them.

Arrogance and well-publicized anti-competitive practices are always useful here.

(No points for guessing which suggestions I wrote with companies in mind, or even which ones, or which I've suffered through personally.)

1) Create a quality product
2) Understand the customer
3) Maintain consistency

Price in a manner which is open and clear - this includes not only initial purchase price but upgrades, additional features or modules, support, consultancy, training and any other associated costs.

You don't have to be cheap, you can price as aggressively as you like, but the one thing in my experience that will upset clients more than anything when it comes to price is unclear extras and the idea that they're having more money unfairly extracted from them now they've made the purchase.

Unknown costs aren't about the money, they're about people's reputation. The person making the purchase has put some of their reputation on the line when they put a budget for the project forward. Even if the extra expense is value for money, you've when they have to go back to their boss and ask for more money, you're making them publicly admit that they screwed up and they will hate you for that.

Keeping a software company in a positive light involves both sides of the transaction.

The company must:

  1. Continuously provide code that is most fit for purpose in their chosen fields
  2. Be seen to be continuously striving to improve by acting on customer feedback
  3. Be seen to be fair

The customer must:

  1. Provide feedback to the company that they are doing well/badly
  2. Be reasonable in their expectations of responses

From these simple rules, lots of good things naturally follow. The trouble is, market forces and competition being what it is, sticking to them is a nightmare.

When you are a big corporation like Microsoft, Google or Facebook with lot of exposure in the news, you can't keep people from hating you. It's impossible.

The more you are successful, the more you are hated.

Vendor should create a metric called the hatemeter to measure their success! ;)

That is why one of the biggest quality of an entrepreneurs is being able to understand and handle that. And more importantly, use the bad feedback to improve their products (any feedback is interesting).

The real challenge vendors must face is not hate, but indifference.

EDIT: I found this very interesting website. It allows anyone to give his opinion on a various of popular companies and product. The amount of votes is too low to make the results relevant, but what is interesting voters must explain why. I let you discover the comments and judge by yourself human nature is complex.

Let me discuss this from the angle of the commercial software I've used that has driven me crazy.

Too much flexibility - this is critical. Do not let your desire to offer flexibility mean that you give up on designing the features most people would want. I have never used a "flexible" product that users actually liked using. They don't want to have to figure out how to fix your design errors. We have "flexible" project management software from a well-know vendor that shall remain nameless. It's so flexible it doesn't have things like a field for the client who requested the project (Just how many companies big enough to need a product that costs tens of thousands of dollars don't need to be able to sort projects by client? That would be zero.). When you convert an idea or an incident to a project, the information doesn't automatically move to the project, making searching for details about what was wanted or who wanted it extremely annoying because the devs didn't really design the system, since it was so "flexible". The complexity of trying to add fields and then fix all the forms so you can see those fields means that pretty much everyone has given up using the product for all the "great" features it was sold to us as having and only use it to document time. In general, the more flexible a system is, the more people will hate it.

Lack of consideration for performance by wanting to be database neutral instead of writing the better performing code that might be database specific.

Lack of testing in an environment with hundreds of simultaneous users and a large data set in the database. Database queries that work fine for small data sets are often disatrous for large databases. I worked at a call center once that had a well-know call center software program, it could take ten minutes to move from one screen to the next. You can imagine how much both the call takers and the users liked this. Our most common error was a timeout on the database.

Change for change sake. Nothing annoys users more than getting a new version of something that rearranges how to do everything and yet adds no features that they wanted or needed (see Office 2007 and the crappy Ribbon they added and the menu structure they removed). I don't want to have to relearn the stuff I depend on day-to-day evey year or two years and neither do most users. It's one thing to learn new techiniques to better solve problems and it's another thing to just reaarrange the GUI so that you can't find all the stuff you already knew how to do.

Customer service. If I have a problem, I want you to help me fix it quickly and without it costing too much, especially if I paid a huge amount for the software.

Ridiculously buggy software. Come on, I shouldn't be able to break it doing common tasks in an ordinary way. You did test this stuff didn't you? It is especially anoying when you hit bugs in installation or the first couple of days using the product. It is even more annoying when the stuff that worked great in the last version no longer works. Sure all code has bugs, we know that, but the most obvious ones should be tamed before shipping.

Now as to a company that does it right - I submit that Red-Gate is that company. Their stuff just works, it does what it says it should do without a lot of trouble on my part to use it, it's fast and their customer service is great. Pretty much every experienced SQl Server dba I have ever known recommends buying their tools.

Poor Documentation and No Desire to Improve It - I'm currently working with a software vendor who is not able to give me any database definitions or diagrams. They actually recommended just calling one of their developers since they are the "walking data dictionaries". Now I'll know why they're not improving he application or fixing bugs; they're too busy explaining what is in the customer table.

EDIT: Now I know why they didn't document this database:

  1. There is a naming convention for field names based on the type: dt=date, s = string/varchar, d=float
  2. There are NO primary keys only unique clustered indexes.
  3. No constraints on any tables.
  4. Most of of the Stored Procedures contain: Select *
  5. All Key fields are string types (least of the problems)
  6. Cursors galore!
  7. They did comment and version number their patches, but that's about it.
Licensed under: CC-BY-SA with attribution
scroll top