Posted by D D Ganguly on Mon, Aug 21, 2006 @ 09:30 PM
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? :)
Posted by Sundar Subramanian on Sat, Aug 19, 2006 @ 12:14 PM
My name is Sundar and I am going to use this blog to talk about the stuff I do and my experiences while working in Dimdim.
Initially when we decided to find out if there was a market for a web conferencing tool, what did people need and more importantly at what price, we didn't commission a survey or study, we just asked around. This was very different from the prevailing methodology in other (albeit bigger) companies where there was a formal process of engaging a consultant to study the needs of potential customer specific focus groups or reading white papers etc. We just reached out to the community of people whom we thought would be interested in a web conferencing product. This included users of other web conferencing products as well as developers and users of products where we felt a web conferencing tool would add value (for example, in an e-learning product). I was not sure about the kind of response we would get. Maybe our uninvited emails would be treated as spam or worse somebody might laugh away our seemingly childish attempts at collecting requirements.
The response was unanimously positive and we didn't receive even one negative response in the initial 30-40 people we tried to contact. Of course some (less than 5 people) did not respond. This might be due to spam filters, time pressure or other reasons. But nobody responded in the negative and everyone of our initial contact base gave detailed responses what they would and would not like to see in a web conf product. Of course a majority of our initial contacts were either passionate users of complementary products or were developers themselves of similar products. We got responses saying things which are not obvious like saying that a particular feature was not very important (like video) while a complementary feature (audio) was important. This kind of visibility into a user's mind is nearly impossible if we had not reached out and our immersive user environment, in which all product-related decisions are taken, paid off.
After a couple of iterations we had a minimum feature set without which we felt our product would be incomplete even in the most basic sense. Of course this way of collecting requirements goes totally against the 37signals way (link) but it works for us. At this stage in keeping with our policy of open access we decided to go the open source route and registered to have our product inaugurated in OSCON. We felt going open source had two advantages: Giving the best to the users through the usage of mature open source components instead of re-inventing the wheel and secondly it is easier in the open source world to involve users and other developers while the product is being developed.
At every point of our product lifecycle when we had to make a decision regarding a feature or usability issue we went back to our initial decision of being totally user driven and would resolve the question not through a hierarchical decision making process from inside the company but through user suggestions and observations through user trials. Another result of this way of working is that all the individuals and communities we worked with, are now part of the Dimdim team in the truest sense of the word and spread the good word about Dimdim whenever appropriate and already we are seeing the effects of that.
Since I am a first time entrepreneur my posts might reflect things like immaturity and fear of the unknown in the startup world. I think this blog should become more like a sounding board of our thoughts with input from interested people and would greatly appreciate what you think about the posts on this blog.