Philosophy and Working Assumptions
Proposed Structure and Governance
-How is the Product WG structured?
-What decisions does the Product WG own?
-How are decisions made?
-Where does data to inform decisions come from?
Philosophy and Working Assumptions
Assumption 1: Product Leadership
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 project:
-
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 most critical might be informed by the weakest areas of the Core Product Offering. And a tight Core Product Offering will be the framework for deciding which current and future initiatives are included in the Core, or not.
Assumption 2: Centralized Product Decision Making
Decisions around the Product Narrative, the Core Product Offering, and the Product Management Strategy 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 grounded in a key tenant of product management; the single most important thing a product organization can contribute to a project is focus (1). 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 possible or not aligned with the Product Narrative or Core Product Offering.
Assumption 3: Market-driven Decision Making
Though product decisions are centralized, they are guided and informed first and foremost 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.
Proposed Structure and Governance
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.
How is the Product Working Group Structured?
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
Details of Core Contributor Product Manager roles: To be determined
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.
What decisions does the Product Working Group own?
-
Product Vision: To be set by tCRIL Product Management, and open to evolution with regular feedback and input from Members.
-
Core Product Offering: To be recommended by Members, honed by Member/CC consensus, and finalized/managed by tCRIL Product Management. 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, honed by Member/CC consensus, and finalized/managed by tCRIL Product Management. 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 relevant product documentation, inclusive of concept documentation, product requirement documentation, market data, UX designs and user journey flows, and, where relevant, approach specs;
-
creating or collating product documentation, market feedback, etc;
-
coordinating or even collaborating on projects to mitigate duplication.
How are decisions made?
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.
Where does the data to inform decisions come from?
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-driven sources of information and data to assess as part of the decision making framework.
The Working Group is likely to 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. 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.
Footnotes:
(1) The Product Management tenet referenced here is based on the Desirability - Viability - Feasibility model. In this model, the most valuable products are grounded in, and driven by, market desirability, which in turn creates focus for a product. A product may be viable and feasible, but if it’s not what users want, neither of those will matter. It is the role of good product management to “own” the desirability component of a product (the what and the why), driving the product focus, while interfacing with other areas of the organization to balance input on the viability and feasibility (the how).