User led product developmen

Email Article |  digg it |  reddit |  delicious |  StumbleUpon |  Facebook |  Twitter |  LinkedIn 

In my previous post I wrote in general about how we take most of our decisions based on input from the community and in this post I am going to detail that with examples and practices that make user led product development possible.

Initially as we brainstormed (or is it bullshitted) within the company regarding the target space for an open source web conference product. E-learning space was one which emerged due to its cost-sensitive nature at the same time being pretty demanding in terms of features and scalability. So I contacted the developers and lead users of a few top open source e-learning products and immediately we started the process of learning from their experience. The founder of one such product helped us so much that we turned to him to get feedback every time we felt we had taken a significant step. This resulted in building trust between us and he even recommended other lead users and developers in that particular community who might be interested in Dimdim. This helped us immensely as each person on that list was very knowledgeable about the needs of users and ways to fulfill the needs. We even found a developer who wanted to integrate Dimdim with the e-learning product so that he could use it in an upcoming conference. This was god-sent manna for us as such a move would expose our product to the wider community leading to much needed feedback from early adopters. Through word of mouth we also found other value added resellers and solutions providers of the e-learning products who were interested in knowing about Dimdim.

Well enough of this self-congratulatory stuff, let me now talk a bit about what I feel are necessary attributes to ensure positive interaction between a company and the wider open source community:

• By default most people have more good in them than bad. No I am not launching a new religion or cult but what I mean to say is: most people want to help a positive effort even if it has no direct bearing on them.
• Respect the users by being genuine; don’t tell lies, ideally under promise and over deliver. They are as intelligent if not more, than you and can easily see though a gimmick or sleight of hand. When we gave the first demo to a potential user I started out by saying that it was pre-alpha build with potential bugs and it didn’t even have the main features he wanted. He thanked me for being polite enough to say that upfront and when some bugs were found out, he understood the situation enough to have confidence in us to go forward with the process.
• Talk and more importantly, listen. That way you will not only know the problems and issues encountered by users but also most probably the users themselves will give the solution. For example, when we talked to a user of an established web conferencing product the main points which came out were: Slow to respond, Needs software to be installed on the attendee side even if the attendee does not participate actively but is more of a viewer and the need for integrated audio instead of calling in through a separate phone line. So solving these issues became part of our core features of our product.

I feel these principles are true for any interaction: be they between a company and a community or between two individuals. Now that I have established that, did I mention I am an uncommitted bachelor looking out for a suitable female companion? :)