P.S. Don't let me block you though, if you want to forge ahead, I will help you out. For deffo!
On Fri, Sep 28, 2012 at 7:41 PM, Noah Slater <[email protected]> wrote: > Brian, wow! It's great to see you so excited about this. > > For what it's worth, I had expected that I would be doing the PM stuff. I > am a PM in my day job, though I am still learning. I think we should form > an informal (heh!) PM team and take things from there. Perhaps a wiki page > would be a good start. > > Anyone else interested in joining this PM team? I'm looking at you, PMC > members. > > Your action items sound great. I would just caution though that we have a > lot of stuff to catch up on at the moment. And I think we should focus our > efforts on the big items in our pipeline before we start introducing PM > activities. (I only have so many hours per week to devote to CouchDB, and I > need to make sure I'm spending them wisely.) > > Let's focus on getting the docs integrated, and then chasing up BigCouch. > And then I think we should focus on the stuff you mention. Though, my next > biggest priority is actually implementing a release cadence. > > Also, I think we should be doing content marketing. Getting people to > contribute to our blog. Establish ourselves as thought leaders in this > space. J. Chris used to do a lot of this, but he doesn't blog about CouchDB > so much any more. > > And FWIW, we're not just a scratch our itch project. ;) > > > On Thu, Sep 27, 2012 at 4:03 PM, Bryan Green <[email protected]>wrote: > >> 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. >> > > > > -- > NS > -- NS
