The ideal outcome of a product strategy retreat

I decided to transcribe [these notes]( because on Friday, James Forrester asked me, “What do you expect to get out of the strategy retreat next week?”

My answer was…long. 🙂 I won’t bore you with the details.What I’d like to get out isn’t so much a list of *specific* things we’re doing, or “buy in” on some master plan.

* It seems too “top-down” in a world that despises authoritarian views.
* It’s highly prone to failure and not flexible against setbacks
* It is inherently un-wiki and not egalitarian
* It’s impossible to ever get buy-in on people who can’t for practical reasons participate unless we speak toward universals.

Instead, while I don’t know how we can get there, the best outcome would be for all of usto agree upon a set of ideas: call it vision, principles, habits, frames, patterns… I don’t care. We can use to evaluate all everything we do in the context of this set. These things would be a set that everyone there would agree upon and speak to something that everyone in the movement would agree to. It would be used to:

1. Explain and understand **why** we’re doing each product that we’re doing: No more shrugging your shoulders when someone asks “Why are we doing Article Feedback Tool?” Because a decision to make a product (AFT) would be determined and in-line with these principles. More importantly, even people not participating on a product like could answer this because they have the principles as guidelines.
2. Be used as part of the process of decision-making (**what** we do) within the product. More importantly, while the details may have some variance, on some level they’re the same because we’d all be operating from the same book. In a sense, someone would have **trust** of product because the decisions that were made would be the same ones they’d make if they were given direct control of it.
3. This would, in turn, create a unified front across our our products, but, more importantly, do it in a manner that is both **empowering** and *can be repeated* by others. Why? Because these things speak to things that actually come from the community, they’ll be appealing, but in this way the community will have **ownership** of it, and, if it works, apply it far beyond Tech. A similar application of process/principles/frames/habits could apply in areas we didn’t think to look.

### An example: The Editor and Reader divide

For example, Consider two competing “frames” of interpreting the editor/reader in [the vision statement](

* The vision statement bifurcates the reader and the editor as co-equal: “sum of all knowledge” (created by the editor) “freely share” (among the reader)
* The vision statement doesn’t explicitly call out a reader or editor because it imputes that they are one and the same: “every single human being can…”

I don’t care **which** vision statement was agreed to, but that one or the other is agreed to. (I personally feel that they are equally valid interpretations). Let’s apply this to the Visual Editor (product) and a decision of whether or not to load HTML+RDFa to the read-only output as opposed to an AJAX call when the user clicks the “Edit” button.

Let’s take the first frame:

1. Historically, the Wikimedia Foundation has focused on the reader experience. The VisualEditor marks the first (alpha) interaction in the transition from the reader experience to the editor one, and thus should be worked on because of the neglect of the editor and the need to restore that balance. In addition, the new editor, in particular, would only understand an affordance that represents the web in this manner (GoogleDoc, Word, TinyMCE, etc.)
2. HTML+RDFa to the read-only output is not needed by the reader. It should not be done unless it its impact is negligible since 99.9% of readers will never be editors.
3. An explanation for the decision to build the VisualEditor can be seen from the “sum of all knowledge” in our Vision Statement: we need to more adequately build that “sum.” The decision to HTML+RDFa as the HTML output (and default) will be guided by minimal impact to the reading experience.

Let’s take the second frame:

1. The Wikimedia Foundation should do the VisualEditor because it makes the reading and writing experience identical (WRESIWERG: What the reader/editor sees is what the editor/reader gets). The purpose of the vision statement is not to create an arbitrary bar for editing (learning to work with wikitext and templating), but for making sure “every single human being” can participate in the process of both reading and creating.
2. HTML+RDFa to the reader *must be done* because the reader is the editor. Furthermore, we should encourage the use of HTML+RDFa as the canonical description of content markup with wikitext being a vestigial necessity in the short term.
3. An explanation for the decision to build the VisualEditor can be seen from “every single human being” in our Vision statement: we need everyone to participate not just in access, but also in the creation of the sum, including people who may be experts in their fields but do not have the time to something arbitrary like wikitext in order to contribute. The decision to move toward HTML+RDFa will be emphasized because of the need of every single human being being able to “freely share” **and** create the “sums of all knowledge.”

### The Power of Habit

I hope the notes I took on the Power of Habit make sense in this light. 🙂

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.