Product Principles

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.

Wikimedia Products should be...

 * 1) Community-centric: enabling a welcoming, vibrant place where people come together to create, share, and discover knowledge through positive collaboration.
 * 2) Usable for all: promoting equity through usable, useful, and inclusive tools and services that meet the needs of a diversity of people and machines across user experiences.
 * 3) Intentionally transparent: demystifying the knowledge creation process and encourage participation by giving everyone visibility into how information is created, verified, and improved over time.
 * 4) Extensible and sustainable: creating the conditions for people and machines to use, reuse, and build on top of our platform, extending free knowledge and supporting a sustainable future for Wikimedia.

Why these Principles?
Wikimedia is a place, not a database: We believe that Wikimedia is and must remain a vibrant place on the internet. Welcoming spaces are vital to the work of building and maintaining the wikis. Providing readers a place to consume and engage with free information is more indispensable than ever. So, we must build tools that promote positive collaboration and vibrant knowledge communities.

Usability is an equity issue: These principles also rest on the contention that free software isn’t free unless it’s usable. If software is free-as-in-beer and open source, but you can't actually use it, it is not really free for you. We seek to make Wikimedia software highly usable and useful for people and machines. We will break down the software barriers that prevent participation while giving users the tools to control their own experience. In short, we will “make the simple things easy, and the hard things possible” for as many people as possible.

We must serve more than just facts: Finally, these principle rest on the movement strategies assessment that we play a vital but poorly understood role in the knowledge ecosystem. Our products will make knowledge literacy part of everyone’s experience of Wikimedia, exposing people to how information is created, verified, and improved, and encouraging people to participate appropriately.

Purpose
As explained in the intro this exercise and resulting principles have the following purposes:


 * Define the kind of products and experiences we aspire to build
 * Distill a shared sense of purpose for the impacts, plans, technologies and tools that the department will create
 * Give leadership a chance to define abstract expectations for our products
 * Explain what we hope we’re doing here to other staff and communities
 * Not a strategy. Not a new direction.

Process
These 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.

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.