Meeting Notes/2016-02-16 Strategy planning

Review Timetable

What do we want to change?

Review Pruning effort for Candidate Problem list

Top ten-ish candidate problems

1. How do we involve more voices in our discussions and decisions?
2. How can Wikipedia improve the quality of content by attracting and retaining additional content contributors such as to have a proportionately diverse contributor base with the audience?
3. How do we leverage people that are not employees to collaborate with us and work on our problems with us?
4. No structure for QA on community-contributed code: it relies on people who know people directly, pinging each other for reviews. How do we scale this up? i.e. how do we leverage the abilities and knowledge of those outside our organisation?
5. How can Wikipedia improve the quality of content by attracting and retaining many more content contributors in ways that extend its culture to be more welcoming and embracing?
6. How can Wikipedia surface the high quality content and drive readership to its sibling projects?
7. How can Wikipedia diversify its knowledge representation beyond text-based knowledge through charts, maps, and other rich media?
8. Communication overhead is too high - people feel obligated to go to every meeting, too many cooks in the kitchen
9. Reconciling the desire for consistency of approach and openness with the adherence to the low-overhead, team-centred agile methodologies we've successfully used as teams for a decade.
10. How do we organise our work so that we can rely on people that are, by definition, less available than a full-time employee?
11. Problem 2: User pushback on features and experiments. This continues to be an issue; Gather is a beta-level feature which users are pushing back heavily against for many legitimate reasons. This slows down our progress. How do we improve this situation?

Discussion

Mostly cluster around collaboration w/non-Foundation Too specific - our strategic problem should be broader

1. Stuff around our users
2. stuff around community
3. stuff around communication

Decide how to get to a final decision on the Problem today

What is our ultimate decision rule?

• Unanimous ⬨ All but one ⬨ Gradient of Agreement ⬨ Majority vote ⬨ person-in-charge

What is our decision-making rule for picking a problem? Consensus.

Wes - ...

Katie - primarily int. in re-organizing how we get work done to get more people involved, not just WMF but volunteer. Right now, system seems to be created for a growth model that we don’t have any more

James - Product Group strategy should be around how PG does its job, not the outcome as we can’t run in advance of the WMF-wide strategy. Tied back to communications, not “hey, here’s a central things” but the outcome of communication, that people (not just editors) are involved. Everyone should feel like part of the process of what is forthcoming

Trevor - How to lean into, retain, and expand our super-power, which is that we’re really popular and relevant. It is sort of slipping, and if we let that go, we have no money, no eyeballs, no impact. All the things I picked were relevant to that

Tomasz - More pessimistic - our relevance is dropping rapidly. Partly due to success. … mobile ... . Actually providing an experience that users want to come to rather than content that is re-used elsewhere.

Toby - not to be disruptive to operations of my team. Want it to solve problems that I have. Don’t want to change the way my team works. Spent last 9 months getting my team working, in a specific way, and want to run with that. Change not appropriate in Reading, may be more appropriate in other teams. Strategic problem is communications; if this gets more feedback, that solves my problem. Probably more external than internal.

Wes - Not internal; execs have digital info; it’s about communicating that and executing against it, staying on a consistent timeline.

Something inspirational would be very helpful to employees as a strategy.

Process changes can be inspirational - we can get energy from sources other than dollars spent on full-time req’s. But is that possible with incremental changes - are only transformative process changes inspirational? …

There’s a strategy process above -- we need to fill in the connective tissue [between high-level strategy and our day-to-day work]. Or: there isn’t an effective strategy above us; we have an opportunity to step up, lead by example.

Suppose we sit down and agree on strategy X (e.g., time on site); and WMF settles on a strategy that disagrees. Then what? If our strategy has to be so generic that it doesn’t potentially conflict with WMF strategy, then we should stop [trying to get a Product Group strategy]. Could focus on a process-oriented strategy, but WMF Strategy may also prescribe process, leading to conflict.

[Each person in turn says what they see the top 1-2 issues as, including commentary on candidate possibility voting.]

[Emerged with two basic areas of concern: What the product group produces, and how it produces it. For "what", there was consensus on one key problem. for "how", there were three closely related but distinct candidate problems.]

If the most important problem for the Product Group is about WHAT the Product Group (and/or Movement) does, then the specific problem is Our products are becoming irrelevant.

If the most important problem for the Product Group is about HOW the Product Group works, then we have three candidate problems:

• Product Group doesn’t get enough feedback/participation/? from (non-staff, and not just editors) people
• Product Group doesn't get enough engagement from non-staff people
• People outside the Foundation don’t get enough information about what the Foundation is doing

[We could not easily decide which of the two approaches was more suitable. Some people framed them as Product Strategy vs Management Strategy.]

Strategic Possibilities

[For each of the approaches, we brainstormed a list of possible strategies to address it. This was intended to help clarify which possible problem would be more productive to adopt.]

For WHAT problem

Our products are becoming irrelevant.

• Strategic possibilities
• Enable different style of content that is more bite-sized
• Enable different, overlapping versions of content accessible to different education
• Find new users in the global South
• Update our experiences to match current standards
• Evolving (providing the tools to create) the content beyond text
• Create more engaging experiences for new readers
• Build bridges between our projects and highlight where new content can be created (internal syndication to surface engagement points) (wikipedia is the entry point)
• Infuse articles with other content (in a reading context, not a search context)
• Target different devices, casual consumption, provide unique experiences, provide better experience on wikipedia than on syndicators
• Articles have interactive content
• Recency in author context (more social ehh)
• Responsive content blocks
• Engage deeply with our user community to find new mechanisms to provide content
• Fork the reading experience and leave the existing experience for wikipedia.org editors and put something different on wikipedia.com

For HOW problems

• We need to post participation in the right channels (notifications, surveys, meta, )
• Standard operating set of release paths for communications
• post updates on key features on our blogs as they progress (rather than single page)
• More user research
• rework our internal engineering processes such that we are no longer incentivized to rely on full-time employees
• create a framework within which non-engineering teams or outside parties can pitch ideas and get good work from volunteer engineering (should work with or without staff engineers in process) – could be volunteers doing engineering or staff engineers volunteering
• weekly or whatever blog/summary pushed to every editor about what changed to them that time period (and auto-summarized if they’re away for N periods somehow)
• centralize all feedback locations to one wiki
• gated deploys through editor/community feedback with votes
• roadmaps as collaborative living documents
• binding user research outcomes
• do fewer things at the same time
• focus on users we’re losing, not just ones we’re trying to acquire
• define a quarterly and annual process that actually motivates the community to participate
• centralize communication by making on-wiki tools better than email or IRC
• dedicate resource to own community communications

Discussion

WHAT because it clearly tells us what to do quarter to quarter

HOW because we have control over it. HOW because WHAT involves so much beyond Product Group. HOW because the WHAT-stuff is under control but HOW is not being addressed at all.

Can we have both Management and Product Strategies? They are orthogonal.

Want to release the product strategy so that we have less direct control over it. Is

Moving away from WHAT and toward the HOW because we want the WHAT to be defined at a lower level (Verticals) (or higher level) (Ffoundation) Can’t do a Product Strategy (see previous) but can do a Management Strategy. Management Strategy is not inspiring.

Next Step

Meet as a group again ASAP to do a full cascade on one or more possibilities from each bucket