There is a need for leadership in the Open edX ecosystem to define, and set parameters and guidelines for, three key areas of the Open edX platform:
Product Vision, defined as the high-level vision statement for the Open edX project.
Core Product Offering, defined as a clear articulation of which features and experiences come fully supported with a basic Open edX Install/experience, for a clearly defined user base.
Product Management Operating Model, defined as a clear process and workflow for prioritizing initiatives.
The Product Vision will inform a Core Product Offering. Decisions about which enhancements or fixes are critical might be informed by the weakest areas of the Core Product Offering. And a tight Core Product Offering will be the framework for which current and future initiatives are included in the Core, or not.
Decisions around the Product Vision, the Core Product Offering, and the Product Management Operating Model need to be centralized within the Open edX ecosystem. This approach runs counter to how other areas of the Open edX project are organized, for example the decentralized Architectural Advisory Process (OEP-56).
The need for centralized product decision making is a key tenet of product management; the most important thing a product organization contributes to a project is focus. It is also a desire reflected in the Open edX ecosystem, and by general consensus of attendees of the inaugural Product Working Group. Without a clear focus, product organizations run the risk of misaligned work, unnecessary duplicative effort, unhealthy divergence, and most problematically, not evolving with the most important thing in mind - the needs and views of the end users.
However, it is important to note that within the Open edX ecosystem, a centralized approach to product decision making does NOT equate to a top-down, nor a dictatorial, nor a single-member driven approach. Rather, a centralized product decision-making body functions as an air traffic controller, creating clear paths for contributions and integrations, and alternatives when full integration is not aligned with the Product Narrative or Core Product Offering.
Though product decisions are centralized, they are informed by market research and user needs, which are translated by the community and contributors. Thus, product decisions truly require full and collaborative community input, guidance and feedback loops.
The structure and governance model of the Product Working Group should thus reflect the three assumptions outlined above, with centralized product leadership at the helm that is driven and informed by Working Group Member input, community feedback, and market and user input.
As such, the proposed structure of the Working Group is:
Members provides critical input and the voice and perspective of users
tCRIL Product Management and Core Contributor Product Managers refine user requirements, documentation, with tCRIL Product Management serving as the recommending body
Core Contributor Product Manager roles and responsibilities are outlined here.
Role of the ToC:
Serves as a verifying body to ensure high-level mission objectives continue to align with implementation recommendations and efforts writ large.
In cases of rare disputes or disagreements regarding the Core Product Offering that cannot be arbitrated in a satisfactory way by tCRIL and Core Contributor Product Managers, disagreeing parties have the option to make a case for their perspectives with the ToC. The ToC will function as the ultimate deciding party.
Product Vision: To be set collaboratively by Members of the Product Working Group, Core Contributor Product Manager, and tCRIL Product Management. The Product Vision is always open to evolution with feedback and input from the broader community.
Core Product Offering: To be recommended by Members and Core Contributor Product Managers, and finalized/managed by tCRIL Product Management and Core Contributor Product Managers. Key decisions include: What current features/experiences are available in the basic Open edX Install, and why? And, what future features/experiences make it into the core install, and why? And, what is the spectrum of alternatives if a feature doesn’t align with the core (for example, defining a standardized “core-to-edge” spectrum or model).
Product Management Operating Model: To be recommended by Members and Core Contributor Product Managers, and finalized/managed by tCRIL Product Management and Core Contributor Product Managers. Key decisions include: What initiatives should be prioritized to improve/enrich/expand/enhance/fix the Core Product Offering?
In these cases, the Working Group may take on a number of roles, including:
reviewing where features should live relative to the Core Product Offering fall on the core-to-edge spectrum;
advising on product documentation, inclusive of concept documentation, product requirement documentation, market data, UX designs and user journey flows, and, where relevant, approach specs;
coordinating or even collaborating on projects to mitigate duplication.
The goal of the decision making process is - ideally - group consensus, or as close as possible, with clear channels for Members to voice convergence and divergence. To work toward that goal, the group could utilize one or more product management decision-making frameworks.
There are many iterations of such frameworks, all designed to balance speed, efficiency and consensus. They are role-based, ensuring all Members have a clear path toward a data-driven outcome, deliverable or decision. They are also flexible and can be tweaked in practice in order to meet specific needs of the Working Group.
Specifics to implement the process, including details about how roles are assigned, how the process is tracked, etc, will be defined in real time as the Members work through their first decision. As the process is intended to be iterative, a working document will be linked.
In order to make informed decisions, particularly around 1) what becomes part of the Core Product Offering 2) feature prioritization, it’s critical for the Working Group to have market data to assess.
The Working Group will be creating product documentation, OR, reviewing product documentation from a diversity of sources, such as:
individual contributing organizations or blended projects
other community working groups
specific use case focus groups
internal projects driven by the Product Working Group itself
The Working Group should set a framework for the creation / review process, with guiding questions such as:
A full assessment of market data, where feasible. Who does this initiative serve? Which persona/market/sector(s)? What problems does it solve? What is the source of the data?
What is the potential market reach and/or user value?
How does this initiative align with the Product Narrative?
How does this initiative impact the Product Core? What are the risks vs returns of incorporating it into the Core?
The Working Group should also set an expectation for basic required product documentation in order to facilitate the review process, such as:
Product Concept documentation
Vision for the initiative, impact and value
Product Requirement Documentation
Market data, user feedback, reach and metric impact
Approach Specs
Design, UX journey documentation
The Working Group should also oversee the organization and sharing of the above documentation from a central, public location, at this time the Product Wiki.