The genesis of a users group, part 1
It seems every Web development firm has its own content management system and Imaginary is no exception. Landscaper has become more and more popular, so much so that certain clients are clamoring for a users group.
At first blush, the idea of a users group is daunting. It means effort, money, coordination and time - all things lacking in abundance.
However, I also think it pure hubris to believe that the developers (us, in this case) are the best arbiters of change to a product. Surely, those who use it day-in-and-day-out have relevant feedback to offer. The feedback from a wider divergent group of users must result in a better decision making, right? Isn't that what JFK learned (the hard way) after the Bay of Pigs? For that reason alone a users group is a great concept.
For us, the concept of a users group has two "must haves" and one "can't have."
The first "must have" is its need to to bring our users together and facilitate the exchange of information between them. Undoubtedly there are tricks and workarounds that regular users have adopted. Their ability to share these experiences is an important aspect of any users group. So also is their ability to connect with each other for future, offline collaboration. The agenda, setup and environment should encourage these interpersonal connections. Divergent users can get to know each other, exchange business cards and gain an informal resource outside the framework of the event.
The second "must have" is the ability for us to gather feedback for future revisions to the product. This feedback is critical for us to distinguish between a customer-specific modification and a general need. It also provides the opportunity to pool specific feedback and abstract it up to a more general feature set.
The one "can't have" is an ongoing sales pitch. I can't imagine a more destructive users group than one designed as a vehicle for the marketing department. We must resist the temptation to pitch.
All that said, there are still risks. The road to excellent feedback is filled with some criticism. As the product developer it can be hard to hear this and not become defensive. Secondly, we have to have an after-plan. Assuming there will be great feedback, what's next? What are we prepared to do with it?
So , were do we begin? For us it can only begin by talking to clients. Call it a Customer Advisory Committee or something equally catchy, but we start by talking with our best clients about the concept and what value they might expect. Stay tuned.
At first blush, the idea of a users group is daunting. It means effort, money, coordination and time - all things lacking in abundance.
However, I also think it pure hubris to believe that the developers (us, in this case) are the best arbiters of change to a product. Surely, those who use it day-in-and-day-out have relevant feedback to offer. The feedback from a wider divergent group of users must result in a better decision making, right? Isn't that what JFK learned (the hard way) after the Bay of Pigs? For that reason alone a users group is a great concept.
For us, the concept of a users group has two "must haves" and one "can't have."
The first "must have" is its need to to bring our users together and facilitate the exchange of information between them. Undoubtedly there are tricks and workarounds that regular users have adopted. Their ability to share these experiences is an important aspect of any users group. So also is their ability to connect with each other for future, offline collaboration. The agenda, setup and environment should encourage these interpersonal connections. Divergent users can get to know each other, exchange business cards and gain an informal resource outside the framework of the event.
The second "must have" is the ability for us to gather feedback for future revisions to the product. This feedback is critical for us to distinguish between a customer-specific modification and a general need. It also provides the opportunity to pool specific feedback and abstract it up to a more general feature set.
The one "can't have" is an ongoing sales pitch. I can't imagine a more destructive users group than one designed as a vehicle for the marketing department. We must resist the temptation to pitch.
All that said, there are still risks. The road to excellent feedback is filled with some criticism. As the product developer it can be hard to hear this and not become defensive. Secondly, we have to have an after-plan. Assuming there will be great feedback, what's next? What are we prepared to do with it?
So , were do we begin? For us it can only begin by talking to clients. Call it a Customer Advisory Committee or something equally catchy, but we start by talking with our best clients about the concept and what value they might expect. Stay tuned.
posted by Imagescape @
3:52 PM
0 Comments
0 Comments:
Post a Comment
<< Home