Participation/Lab/experiments

From MozillaWiki
Jump to: navigation, search
Mozilla Participation Lab Focused Experiments
Team Lead: George Roter Mailing List: Participation on Discourse
The Mozilla Participation Lab will build a strategy and outline new approaches to participation that will bring a step-change in the value that participation brings to Mozilla and Mozillians.

Focused Experiments

In the coming weeks the Participation Lab will be initiating experiments around a particular hypothesis about where we believe participation can bring value and impact. All of these experiments will be designed to move a top-line goal of Mozilla (the product side of the virtuous circle), and give volunteers/participants a chance to learn something, have impact or get some other benefit (the people side of the virtuous circle). If the experiments work, we’ll start to see an impact on our product goals and increased volunteer engagement.

We are dedicated to working in the open! These experiments are a work in progress but you can view the proposed experiments and the ongoing planning in this rough document here.

Planning Framework for Experiments (DRAFT)

The hypothesis is that: “Plans are useless, but planning is indispensable.” Eisenhower.

By having a planning framework for describing Participation experiments in Q1 and Q2 across Mozilla, we will capture our thinking in a way that will allow us to audit it against the results and inevitable changes that will happen during implementation. This will increase the fidelity and pace of our learning, providing more value to the overall Participation strategy and direction.

  1. Experiment/idea in a “How might we” single question: Starts with “How might we” and gets to the heart of what this experiment is designing for. e.g. How might we have volunteers collect timely, quality local market data for the FxOS team in a sustainable and scalable way?
  2. What the experiment is all about (specific and general problem/opportunity, general idea, etc): Articulates the context that a particular team is facing and how this experiment addresses that. Also speaks to how this benefits/addresses participation more generally.
  3. What a solution might look like, a descriptive definition of success (along with impact to mission) and how this might scale or be a breakthrough for Participation at Mozilla: Getting into rough details of what the scope and dimensions of a solution could look like. Who is going to volunteer/participate and why (volunteer user stories). Tells a story about success, both in the short term of what we would high-five in a few months, and also in the longer-term for Participation at Mozilla. If there’s a story of scale or broader implications, it makes that clear too.
  4. Where the idea came from and who is implicated: Team that initiated the idea, team that will own it, teams that will be involved in the implementation.
  5. Options for implementation (rapid prototypes of solutions): Some quick different ideas for how this could look. A very rough sketch of the design -- components and options for those, key strategic questions, etc.
  6. Hypotheses and how we test them: Hypotheses that are guiding this experiment, in particular related to topics that are relevant for our Participation strategy. This might be for our approach to Participation or the structure/function of the team.

Examples:

Hypothesis: Having local market pulse teams is a light touch, yet engaging and motivating for regional community members.

How to test: Measure the number of hours of staff time/volunteer leader time/volunteer implementer time. Survey volunteers to gauge their level of motivation. Gather data on engagement level (time, frequency) of volunteers.


Hypothesis: Local market pulse teams provide useful, actionable information to sales teams.

How to test: Observe/ask how data is being used. Ask sales teams to determine how much they would pay for equivalent research.


Hypothesis: Participation staff team can provide value in the setup phase (strategy, mobilizing initial volunteers, etc), but then can wind down its role as the functional team supports ongoing activity.

How to test: Track time spent. Determine value added A/B testing of continued involvement or ending involvement in particular communities.

Get Involved

Already running an experiment you think we should know about? Have a new idea for an experiment? Interested in getting involved? Send an email to George at: groter <at> mozilla.com