Product Principles/Process

The Product Principles and the thinking behind them is a form of positive group think, and was created through a series of collaborative efforts, under the guidance of the CPO and Directors of Product.

Introduction
In November of 2017, with the appointment of Toby Negrin as Chief Product Officer, the process of turning the Movement Strategy into more tangible product plans began. The Product Managers of the Wikimedia Audiences team decided to produce a more transparent and understandable explanation of our intentions and, in particular what kind of products we aspire to build. This was not meant to be a strategic decision making process, or even a process about the way we make changes to the Wikimedia software and user experiences, but rather a clear statement of the kind of products we aim to build. These principles provide a shared, and clearly communicated, set of aspirations, and will be used to guide decision making at a strategic, but also at a feature level. They aim to define what Wikimedia's products should be.

Review predecessors
We are not the first to articulate principles to which wikis and Wikimedia should aspire. In particular we looked at three predecessors which serve related needs. In specific:


 * 1) Ward Cunningham's software design principles of a wiki
 * 2) The Wikimedia Foundation Design principles
 * 3) The Wikimedia Foundation Technical Collaboration Guidance

Wikimedia is a Place

 * 1) After reviewing these, we asked the product leadership to think metaphorically, answering a single question: if Wikimedia was a place what kind of place is it? See the image for the answers generated.Wikimedia_product_as_a_place.png
 * 2) We then grouped these and discussed why people chose them, and what their implications were for what we build. As you can see from the image, two main analogies emerged: Wikimedia as a diverse and dynamic urban environment, and Wikimedia as a museum/library or other prestigious cultural heritage institution. In drafting the principles we sought to bring in the characteristics of these places: emergent, diverse, long-living, public and open.

Our products must…

 * 1) We then asked the participants to finish the phrase "Wikimedia products should..." with a single adjective or phrase. The goal of this phase was to force participants to think through their highest single aspiration and prioritize (as Product Managers must do on a daily basis) the many good ways to complete that sentence into the one they believed was most important. See the image for the answers generated.
 * 2) After again grouping and discussing the suggestions, it was very clear that enabling and empowering others (be they editors, developers, program leaders, donors, etc) was the most important thing our software could do. Many suggestions used the word "empower" to represent this core need to enable self-expression/self-determination.Wikimedia_products_must.png

Exploding “Empower”

 * 1) We then dug into the word "empower". Although it seemed to represent many product leaders' goals, it was also seen as somewhat problematic. Some participants were concerned it reads like business jargon or self-help terminology. Additionally, there were concerns that it brought to mind power dynamics issues. Most of all, some felt strongly that it implies (inaccurately) that we saw it as our job to apportion out power, or to re-allocate it among our communities.
 * 2) We also asked the participants to suggest additional principles, particularly in the following areas: community, design, data and research, knowledge equity, knowledge as a service/platform, openness, scalability/maintence and finally, methodology by which we work. Because our goal was to define the kind of products, not the kind of teams or processes that build those products, we stashed the methodology principles, and focused on the other areas.
 * 3) Finally, we created four initial draft principles, which carried the spirit of enabling or empowering our users, but did so in 4 of these more specific principles, rather than focusing on that concept in isolation.

Framing in the Light of Strategy
After settling on the key areas and potential descriptors, the Chief Product Officer and the Product Directors met to refine and review the draft. During this discussion it became clear that we needed to more explicitly tie these principles to the new Movement Strategy, and to ensure that our thinking was aligned with that direction, and provided reasons why these were our principles, as justified by that strategy. This resulted in some wording changes, but also in the framing that we have included in the Why section above.

Word Smithing with Communications
With these drafts in place, we worked with the Foundation's Communications team to make them as comprehensible as possible and to reinforce the alignment between these principles and the terminology and perspectives the Foundation is communicating around Movement Strategy and our on-going work.