Defining product manager role + Product management routines

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?)

@Hakanto how do you imagine this plugging into Kielest?


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.

Returning to this for a bit, I feel key distinctions using the Kielest framework would be:

  • The Exec would only grant short-term Pilot roles in conjunction with a clear Goal
  • For a Pilot role to become long-term, their Initiative must choose to become a self-managing Team
  • A Team’s Steward can advocate for their needs and facilitates decisions
  • A Team has the right to remove their Pilot from their role