Laying the foundation for an Activation team

A short story of how I helped establish process and working agreements for a growth team at Output

Project Summary

Senior Product Designer
Process alignment
Team working agreements
Team Structure
1 Product Mgr/Designer

Output is a music tech company with a mission focused on enabling the democratization of music-making on a computer to people of all musical backgrounds. To help realize this mission, Output released Arcade in 2018, a subscription-based music sample-based performance engine with new kits (or sound packs) delivered each month, one of the first of its kind in the industry.

In order to help continue to scale Arcade, Output established a Growth pillar within the company to focus on Arcade’s key growth metrics. At the time I was working on a “tiger team” spun up to build features for Arcade’s core product that would improve retention. Output’s senior leadership tasked me with helping get this new Activation team up and running until they were fully staffed.

The Problem

A skeleton crew

As a new domain and a new team, the Activation team was short staffed, at the time only consisting of a Product Designer/Manager tasked with building the team. There was no process in place for how the team should work, who the primary stakeholders were, and where to find information related to this space.

Desired outcomes

Having recently secured a Series A round of fundraising, Output was focused on growth and scaling the company to deliver better experiences that engaged and retained customers and that would enable Outcome to build new products. As part of this, Output committed to fully staffing an Activation team to help retain and engage new users starting a 30 day free trial of Arcade. In order to set the future team up for success I was enlisted to work with the Product Manager of the new Activation team to help establish working processes and documentation that the new team would be able to use to begin work quickly.

The Approach

Identifying a reporting and working structure

In order to help future team mates understand how work We established and documented who our primary stakeholders were for the team from the design and Product perspectives. We did this to help ensure a smooth stakeholder feedback and review process.

Establishing a high level set of working processes

Together with input from another Product Manager that I was working with, the Activation team’s Product Manager and I met together to review initial workflows that she had put together. I was able to contribute to this process by outlining phases centered around internal problem alignment, stakeholder alignment, having a clear hypothesis or opportunity statement, how we might use research and discovery methods to validate or invalidate our hypothesis, aligning around a v1 experience (or MVP) and outlining clear product requirements for engineering, and lastly, how we would measure success.

Additionally, we outlined how we would ideally work with our Engineering team mates to help them understand goals and have enough time for conducting technical spikes and investigation for more complex items. We documented this process in Miro and made it available to everyone in the company.

Documenting decisions, resources, and work

As these team working agreements were being established, we spun up documentation resources within the company’s Clickup space and we listed everything from our working processes, our primary and secondary stakeholders, primary team KPIs and success metrics, our team’s roadmap, and any resources related to design or related to the team’s space. Other teams in the company would later go on to use similar frameworks and documentation practices.


Based on the outcomes of those who were enrolled in the variant in the experiment, here's what the team learned:

Efficient kickoff

Because we spent the time to work on our high-level process and working agreements, when the team eventually was fully staffed, the team was seamlessly able to continue where the PM and myself left off and were able to deliver 2 key project deliverables soon after

Org-wide transparency

Because we put the work into setting up these high-level resources, other teams had clearer expectations around the kind of work we were doing and how we planned on operating. Additionally, our stakeholders understood their involvement and understood how we would be approaching our work.

Looking back...

Overall, this was a successful kickoff of the team given the unique constraints. However, there are always things that could have been done to improve the experience. Reflecting on this project, here are a few things I would focus on in hindsight.

Establish clearer practices around experimentation

In retrospect, I would have advocated for more experimentation around the key assumptions we established earlier on. I believe we could have delivered incremental value and quick learnings by conducting a series of experiments to test our key assumptions into a more immersive onboarding experience rather than a larger upfront test.

Develop a holistic North Star vision of the experience in Arcade through the lens of Activation

I’ve learned that any time an organization is spinning up a new practice or experience it helps to rally the team around a central North Star vision or experience. This serves as a way to inspire the team and open up conversations about what the ideal experience should be. While I was able to ideate on a few key ideas, In hindsight, I would have taken some time to carve out a more singular Northstar vision for Arcade that would articulate the possibilities for how we could achieve our goals and spark ideas for experiments that the team could work on in the future

Up Next
A new Learn page within Arcade