On Wed, Sep 26, 2012 at 6:55 AM, Dave Cottlehuber <[email protected]> wrote:
> On 26 September 2012 13:03, Bryan Green <[email protected]> wrote: > > Hello everyone, > > I would be more than happy to help with the product management area. > > Just let me know who else is really interested in helping in that area > and > > we can start talking. I have extensive experience in product > management-- > > doing and mentoring. > > > > - bryan > > Given I have no experience in that I'll put my hand up. Here's a good > place to start on that. With whatever product mgmt is. I assume it > involves copious quantities of beer. > > A+ > Dave > *Product management is focused on finding, documenting, and prioritizing what users of the product need and/or want the product to accomplish for them.* All of us have our own reasons to work on and use couchdb, and we probably know what couchdb does, but what is our goal as a product team? What is the mission of the Couchdb project? Is it only a "scratch an itch" project for the developers who donate their time to it, or is it a project that, also, actively listens to non-contributor users. There is no right or wrong answer in my opinion, but we do need to establish the expectations of the user before they download couchdb. If we are mainly a "scratch an itch" project it will make some of what follows in this e-mail moot. Our marketing on the web-site needs to make it explicit that we are not overly interested in supporting non-contributing users and their problems, if that is our position. This will save a bitter taste in the mouth of the user when they don't get the support they think they should. It would also help if we could be more proactive in communicating the status of known bugs, and their impact, in existing releases and planned new features. We could accomplish this by sending an alert e-mail sent to the users mailing list, or on a page of the web-site. I think once a month would be acceptable. The key would be that it would be a summary of the bug, or feature, and it's impact. When it comes to identifying what we should be working on next, I think it is great that we have really good minds within the project that are capable of idea generation for the product, but we need to expand this out more to the community. We need to develop user personas, use cases, and what the "competition" is doing. A starting point for all of this could be to catalog the branches of couchdb and analyze why the branch was created and how successful it has been. We need to get feedback from our users about what they are using couchdb for, and what work-arounds they feel like they had to do to use it-- especially work-arounds that they feel like should not have been needed. We should brainstorm what user classes/roles we have. This can be done through irc or e-mail. Basically, you just free flow all the different types of users that you can think of that use couchdb, or should be using it. Then after we have that big list, we will collapse some down (there will be duplicates), and finally we will have a smaller list of user classes. We can build personas for each user class. This eventually helps you understand and identify with your user base. It also helps develop use cases. We should keep up to date on the main NoSQL products out there and know how we are different. We should publicize this information on our web-site. I think transparency is desirable in all relationships, but especially with a user-base. It would be excellent for users to be able to look at a chart that compares features across the main NoSQL products before they download couchdb. I don't think it should be explicit marketing, but just as fair and objective as we can be. If there is a better fit for a user, I think it is in our best interest to help them find the other product. In short, if we are not a project just for a small set of people to work on to "scratch an itch" we need to collect into a usable document what are our product challenges right now, what features are really needed and wanted by the user-base, and set expectations appropriately as early in the relationship as possible. Proposed action items: 1. Decide what kind of open source project we are. Hopefully this e-mail will get this resolved. Explicitly set expectations about support and priority of non-contributing user requested features/bugs. 2. Start brainstorming session on IRC about user classes/roles/personas. 3. Capture what are the other nosql solutions and the feature differences. 4. Identify the innovation branches of couchdb (example is RCouch), and why it was branched, as well as how successful was it? 5. Analyze the mailing lists to build a list of common complaints and requests. 6. Communicate new features status monthly in user mailing list. 7. Communicate top bug status and impact monthly in the user mailing list. 8. Go out of our way to solicit feed-back on a regular basis from people/companies we know are using couchdb. Do not wait for them to tell you something is wrong. They may abandon the product without ever saying anything. I list these as things that I am willing to start doing or help with if the community decides we should do any of them.
