Been reviewing the DSP Draft Collaboration Proposal. Appreciate the work on this! I have some ideas for how this Product Manager role can be clarified, with the hope that we’ll all have the same expectations, future Product Manager included. Let me know if this is helpful. @brndnkng@richjensen@maintainers
Here’s a simplified list of routines related to product management. I aimed to avoid jargon, but if terms are unclear please comment. Feel free to edit, adding more activities or revising these.
Product management routines
Deciding the product vision
Determining product stakeholder groups
Learning requirements of product stakeholders
Deciding which requirements will become product backlog tasks or goals
Rewriting requirements into product backlog tasks or goals (perhaps User Stories, Criteria)
Deciding the priority (sequence) of product backlog tasks or goals
Ensure the product backlog is organized and useful to workers
Ensure the product backlog is visible and clear to stakeholders
Getting feedback from stakeholders about completed goals
Deciding the next product goal
Forecasting future product goals (roadmap)
Onboarding product workers (volunteer and paid)
Training product workers (volunteer and paid)
Hiring paid product workers
When defining the role:
which routines should be the sole responsibility of the product manager?
which routines should be a shared responsibility (with Exec? With Maintainers?)
can routines be delegated by the product manager? (to who?)
Here’s how I imagine this all going down in Kielest:
You’d start by forming a Product Initiative with a Product Goal and Product Pilot approved by the Exec. If the Product Manager were hired for this purpose, they’d be the first Product Pilot.
The Product Pilot could have specialized responsibilities defined, but their main responsibilities would be those common to all Pilots, including participating in the Pilot Collective meetups facilitated by the Exec.
Those on the Product Initiative might elect a Product Steward and become a Product Team. If a Product Team is formed, then the Product Pilot’s role would become permanent assuming that the Team doesn’t remove the Pilot from their role or the Team doesn’t disband.
If the Product Initiative completes its Goal without becoming a Team, then the process would start over. Since the Exec approves all Pilots, they could keep approving the person hired to be “product manager” as product pilot over and over if they wanted.
If we reach a point where multiple Product Initiatives had become Product Teams, then I expect each would choose a less generic name for itself so we could keep track of things: “Verdant Team / Verdant Pilot / Verdant Steward” or such.
Thinking out loud, while a Product Manager hire may turn out better than I think, my sense at this time is that product-related hiring should focus on:
more Maintainers
hiring Pilots, Developers, or Designers for key Product Initiatives which would have a high impact
My impression is that unless rights and responsibilities of the role are defined very clearly, the Product Manager may find themselves adrift between rights and responsibilities already assigned to the Maintainer Collective, the Exec, and the Board.
The Maintainer Collective is already defined as:
to collectively administer, operate, and make decisions regarding Resonate’s core technology assets, and to prioritize—along with other stakeholders—these objectives to provide a clear and focused approach to our tech stack. Inherent to this role is expanding communication with the community (de-siloing), increasing transparency, and supporting and affirming developer worker solidarity in the cooperative.
Would the Product Manager overrule the Maintainer Collective’s decisions? It doesn’t feel clear to me, and makes me think it would be easier and more productive to hire more Maintainers and just reinforce that working group’s capabilities and relationship with the Exec and co-op.
