incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Green <dbryan.gr...@gmail.com>
Subject Re: Part1: What's up dev? About energy.
Date Thu, 27 Sep 2012 15:03:25 GMT
On Wed, Sep 26, 2012 at 6:55 AM, Dave Cottlehuber <dch@jsonified.com> wrote:

> On 26 September 2012 13:03, Bryan Green <dbryan.green@gmail.com> 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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message