Michael Feldstein

1. State of community product management functions

• What do you think of the product development lifecycle (have you looked at it)?
  I think it's a good starting point, particularly for 2.x. I'm not that worried about getting it absolutely perfect right now. We can iterate over time.
• What are the critical functions that the community needs in the context of managing the product?
  "Managing the product" is not the same as "managing the project." There are a bunch of things that you do as part of software development (e.g., QA, documentation, etc.) that are vital but are not part of product management. A product manager (1) makes sure that the product being developed is intended to meet needs that users have prioritized as important, (2) makes sure that the product is being developed in a way that is consistent with meeting those user needs, and (3) makes sure that the product is being developed in a way that is consistent with other products being released by the community or company, particularly as related to user expectations.

In our context, that means (1) ensuring that a development project has sufficiently broad community sponsorship to ensure that there is strong enough need to drive support commitments, (2) ensuring that the development plan for each project appears likely to meet the users' previously identified functionality, usability, and accessibility needs, and (3) ensure that each project is meeting community-defined standards for things like coding, QA planning, documentation, etc. A fourth and more nebulous (but very important) area would be facilitating community conversations around the coherence of Sakai (2.x or 3.x) as a whole, beyond the basic standards for each discrete tools. In other words, what are the larger goals we're trying to achieve with the CLE as a whole and how do the discrete development projects align with those goals?

• For which of those critical functions, if any, do you think a product council is needed?
  Theoretically speaking, none of them. Practically speaking, all of them. The PC is a mechanism for facilitating the development and uniform implementation of community-generated goals and standards. All of these functions can be accomplished without the PC. But my understanding is that the PC was created because the community was not achieving them as well and consistently as everybody wanted.
• How does the product council relate to other groups working on these critical functions?
  In general, product management should have a lot to say and some authority early in the life cycle of any project that has started on the journey to be included in "core", and less to say, mostly in an advisory capacity, later in the development and life cycles. Unlike, say, QA or maintenance, product management is focused more on making sure we get design and planning issues right and less concerned with day-to-day execution. If we do our jobs right (and I speak now as somebody who holds the job title of Product Manager at my company), then we should make the jobs of QA and maintenance easier by, for example, making sure the development teams start with good QA plans, think about test automation when they design their code, write adequate documentation, and so on. By the time actual QA and maintenance decisions are being made, those should by and large be made by the experts on the QA and Maintenance teams, with occasional advice from the PC.

That said, I think there is pretty widespread agreement that the PC could do more than it has done so far to work with the other teams. For example, it makes sense when considering the retirement of some bit of functionality for the PC to advise the maintenance team on whether we think doing so will leave an important functional hole or create some inconsistencies in the Sakai release as a whole.

• Which of those functions are missing from current activity or processes?
  So far, we haven't done much in terms of helping with product coherence/vision and we haven't stepped in terms of advising the other teams regarding the decisions that they have to make.

2. The mission and charter of the Product Council

• When you heard about the product council, what did you hope the product council might achieve?
  The two big issues for me were uniformly enforcing the community-developed standards for tools that go into core and helping to articulate a more coherent vision of the product as a whole that could be specific enough to impact how we go about designing new capabilities.
• How close to your hopes did the product council charter come (have you read it)?
  Close enough for me to volunteer my time.
• What would you change about the charter?
  I haven't had time to reread it recently, so I don't have a useful answer to this one. But from what I can recall, I don't have any suggestions for change in the carter at this time.
• What impression, if any, do you think the product council has on people looking at Sakai from outside the community?
  I think the existence of the PC is important because potential adoptees on the outside want to be able to see that there is some reasonably clear process by which the community defines direction and enforces standards. The PC is part a symbol of that and part an embodiment of it. I can tell you for a fact that Oracle (which is somewhere between inside and outside the community) looked upon the formation of the PC as a very good sign that the community was working hard on coordination issues. That said, I don't think outsiders are concerned with the details of the PC so much as the fact that it exists.

3. Membership

• Have we got the membership right? What constitutes the right mix of people on the Council? How should members be selected?
  It's important to have a mix of people with expertise in development, QA, usability/accessibility, and functional requirements. I think we have roughly the right balance.
• Should Board members be on the Council?
  I don't think it matters. Originally, there was a fear that being on both the Board and the PC could give one person too much power. In reality, since the PC has relatively little power, it's a non-issue.
• What expectations should there be on council members?
  Since most project management work is front-loaded in the development cycle, PC members need to be ready to commit significant time during the release planning and early development stages. We also need to figure out how to be more responsive to QA and maintenance later in the cycle.

4. What the Product Council has done

• What do you think the product has focussed its attention and energy on?
  The main effort was evaluate submissions for the core in release in 2.7. We have just started to dig in on 3.0 and have not yet started to work on 2.8.
• What do you see as the successes of the product council so far? What are the disappointments?
  Let me take this opportunity to respectfully disagree with the evaluations of several of my Sakai colleagues. First, I didn't really expect to get much more done than we have gotten done in the last year, and I think that is reasonable and fine. Product management has to be done in the context of a release. We have had only one release in the last year. We are gearing up for a second and third.

Second, I don't believe that the PC should be doing terribly much more than it has done so far later in the release cycle. For 90% of the decisions where the PC should play a role, if you have to ask for our input during QA, then we have probably already failed. Our main job is to make sure the homework is done coming into a release. Our job is more to prevent problems in development, QA and maintenance than it is to fix them once they arise.

My sense is that we did an adequate, though not spectacular, job with 2.7. That said, I would like to hear more from the QA and maintenance teams specifically on the question of how well prepared the tools that we green lighted for inclusion in core were in terms of test planning, documentation, etc. On average, how confident are they that these tools have been designed and developed in ways that will make their jobs easier relative to the respective states the tools were in before they went through the PC process?

• What has been the net pay-off of the product council thus far. Is the Sakai 2 product better off? Sakai 3?
  My sense is that 2.7 is better than it would have been, though again, I would want to hear answers to the question I posed above from the relevant experts before I would feel confident saying that.

In terms of Sakai 3, we're too early in the process to know the degree to which we will have a positive impact.