Product Principles

Wikimedia Products should be...

 * 1) Community-centric: enabling a welcoming, vibrant community 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 to be part of everyone’s experience of Wikimedia, exposing people to how information is created, verified, and improved, and encouraging people to participate appropriately.

Purpose

 * 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

 * 1) Review predecessors - We are not the first to articulate principles which wikis and Wikimedia should aspire to as it builds and evolves our software. In particular we looked at three predecessors which serve related needs. In specific:
 * 2) Ward Cunningham's software design principles of a wiki
 * 3) The Wikimedia Foundation Design principles
 * 4) The Wikimedia Foundation Technical Collaboration Guidelines
 * 5) Wikimedia is a place...
 * 6) 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? Below [TKTK insert exported Mural of places]
 * 7) 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, there were two main analogies that 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, and public/open, for example.
 * 8) Our products must… ¿empower?
 * 9) We then asked the product leaders 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. Below [TKTK insert exported Mural of musts]
 * 10) 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.
 * 11) Exploding “empower”
 * 12) We then dug into the word "empower". Although it seemed to represent many product leaders goal, it also was seen as somewhat problematic. It reads like jargon or self-help terminology. Additionally, there were concerns that it brought to mind power dynamics issues and 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.
 * 13) 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.
 * 14) 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.
 * 15) Framing in light of strategy
 * 16) After settling on the key areas and potential descriptors, the Chief Product Officer and the Product Directors met to refine and review the draft.
 * 17) 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.
 * 18) Word-smithing with the Communications team
 * 19) 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. Huge thats to that team for their insights and improvements.