Why (Direct) Democracy is bad for Software Products

It seems that more and more software vendors rely on user feedback tools and forums (such as UserVoice, which I mentioned in a previous post). The thought, in many cases, is that user votes can drive the product development roadmap in a way that resembles democratic elections: the more users vote for a feature, the faster it gets addressed. Some tools even allocate a limited amount of tokens for users and let them distribute the tokens across feature requests.

This thought process quickly translates to communication with customers. For example, at Webcollage we recently evaluated a software product for our development organization. We quickly noticed that the product did not work in our environment, and contacted the vendor. The response we got was:

“This functionality is not supported in [Product Name] at the moment. However, you can add this suggestion on our forum at [URL].”

A few months ago we received a more annoying response from an otherwise respectable vendor, whose software (during our evaluation) did not work as expected in Internet Explorer 8:

“It looks as though we also do not recommend the use of Internet Explorer 8 and under with [Product Name] in general. If IE8 is a requirement for your development team(s), please be sure to comment on and vote up the issue I’ve linked above. Please let us know if you have any other questions.”

Such a response misses the mark in almost every possible way, from customer relationship management (if a customer is evaluating your software, do you really expect them to take the time to vote up bugs?) through product positioning and documentation (you either support Internet Explorer 8 or not; if you do—please fix issues; if you don’t, that’s fine—don’t include it in the list of supported browsers), product planning (are you really relying on frustrated customers to drive your browser support strategy?), through simple business sense (do you really count feedback from all customers in the same way, regardless of their level of use of your software, level of savvy and their business potential?).

It seems to me that this approach is derived from fundamental lack of understanding of democracy, and why direct democracy hasn’t survived.

The earliest democracy is typically said to be the Athenian Democracy in the 5th century BC. It was a unique form of political system in which people did not elect representatives, but instead voted on issues directly (a system called direct democracy). A key part of Athenian democracy was the Assembly (Ekklesia), which was a frequent gathering of Athenian citizens to listen to, discuss, and vote on decrees that affected every aspect of Athenian life. In the Assembly each (male) citizen of Athens could speak, regardless of his station.

Somewhat not surprisingly, direct democracy did not survive. One may speculate that meetings with tens of thousands of people did not scale well (if I may use this modern term). Also, it is likely that voting on each issue separately was also far from optimal: how likely are you, as a citizen, to vote for increasing your own tax?

Today, practically all forms of democracy are representative democracies: citizens elect representatives, who legislate on their behalf. This system, sometimes loosely referred to using the term republic, increases the chances that a smaller number of people spend more time studying the issues at hand and making more thoughtful decisions. If the representatives underperform, then citizens are given a chance to elect different representatives. While obviously imperfect, this system lets us—citizens—carry on with our day-to-day lives without having to understand the intricate relationship between issues and without evaluating one against the other.

The analogy to the software world is simple. Given a particular business area (say CRM, or ERP, or your favorite software vertical), software buyers and users elect a software vendor (oftentimes called partner, using a washed-out term). They expect the software vendor to make smart business decisions on how to drive the product roadmap forward. They expect the software vendor to combine a good understanding of the market and technology (oftentimes collectively called vision) and continuously add value to its product. If the software vendor fails to meet the expectations, they reserve the right to switch to another vendor. In essence, this approach mirrors representative democracy, as described above.

This is not to say that communication between representatives and voters is not important. In the software world, user forums are indeed a great tool to obtain user feedback. Asking software users to comment on other users’ feedback is a great way to amplify the learning from such feedback. But, using users’ votes as a key metric in deciding what to develop is plainly a mistake. For one thing, another analogy to Athenian democracy can help illustrate this point. In the Athenian direct democracy system, members of the Assembly received pay. This ensured that citizens had an incentive to participate in the democratic process. In the software feedback world, we are yet to see vendors pay their users to post feedback. Therefore, vendors only hear from a loud minority, which does not represent the real market. The extreme case is, of course, in-your-face bugs; only a small number of customers may complain, but such customers would simply not be able to use the software. Passing such bugs through a voting system is nothing but a folly.

Interestingly, one of the best forms of government for the people is (admittedly arguably) benevolent dictatorship. During the three decades in which Lee Kuan Yew held office in Singapore (essentially as a benevolent dictator), the country grew from being a developing country to one of the most developed nations in Asia despite its small population, limited land space and lack of natural resources. In the high-tech world, Steve Jobs and Mark Zuckerberg both drove their respective companies to act as such, with obvious success. The challenge in adopting dictatorship of any kind in our government system is that with dictatorship, gone is the right to replace the dictator; so, citizens are likely to end up with a bad dictator. In contrast, in the software world, buyers and users can always switch over to another vendor, and free market pretty much ensures that competition will come up. So, there’s really nothing wrong with software vendors which operate as benevolent dictators.

In the end of the day, however, whether a software vendor models itself to be an elected representative (in a representative democracy) or a benevolent dictator, it is much more likely to thrive than those who attempt to operate a direct democracy, and let its users vote on each issue.

So the bottom line is: as a software vendor, if you believe in democracy, listen to your users; let them share their thoughts and opinions; let them express it in person, over the phone and in forums; but, don’t build your product around users’ votes, because you’re very likely to end up where the Athenian Empire had ended: in ruins.

Advertisements

2 responses to “Why (Direct) Democracy is bad for Software Products

  1. Jonna Stopnik

    Eilon has it right. Why don’t companies have more backbone? What happened to common sense mentality vs. mob rule?

  2. Good post. Customer input is good (required!), but there still needs to be someone making the call.

    I wrote about this in a blog post a while back: Product Development is not a democracy, referring more to internal stakeholders; and Ivan Chalif had a good guest post also calledThis is NOT a Democracy on the Cranky Product Manager blog.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s