Phase Gates for High Alignment and High Autonomy
Stops in our product development process to make organized chaos less chaotic and more organized
________________________________________________________________
TL;DR - This is a relatively longer write-up, so I want to offer the following up-front: Within your product development process, introducing phase gates — hard stops throughout that ensure agreement and alignment — can be the magic that brings your team to high alignment and high autonomy delivery. Move slower to move faster.
I joined Spotify in 2021, and it was made clear during orientation — and throughout the first few months of getting to know my new work fam — that I would be working within organized chaos. And that it was very much by design.
Working on enterprise publishing and advertising products for most of my career has led to a strong desire to avoid chaos. Instead, work with rigor, structure, and always towards reducing human capital waste. I use efficiency and effectiveness as measurements for stellar user experiences — learned from working under great leaders who’ve built at scale. So, this notion of leading my team’s work on business products in a radically nimble way … yeah, it felt uncomfortable.
Nearly a year into my role as Global Head of Design for Spotify Ads, I have a different perspective. I’m no longer distracted or put off by the idea of organized chaos. And it’s because I’ve come to learn that Spotify has won the hearts of its customers because of its highly adaptive nature. Spotify remains two steps ahead of customer expectations and introduces unique features, thanks in part to our organized chaos. It’s what sets this company apart from competing music, podcast, audiobook, and live broadcasting products. Behind the dust that signals innovative work, however, there is a durable product development process, and it’s thoughtfully inclusive while allowing our teams to remain fast.
Our Product Development Process
Without going into the weeds, this is “The Scale” — Spotify’s widely adopted product development process:
Understand it: Determine if there’s a problem worth solving, and frame it in a way that invites exploration. Goal: Stakeholders aligned on what success looks like.
Think it: Go broad to develop and test hypotheses for potential solutions that meet success criteria. Goal: A data-informed set of jobs to be done.
Build it: Go narrow and work toward creating a solution that fulfills the key jobs to be done. Goal: A solution that can be given to customers.
Ship it: Give the solution to customers, measure its effectiveness, and determine why it performed how it did. Goal: Learn at scale.
Tweak it: Revise, refine, and rethink to produce better results. Goal: Create a plan to maintain, update, or revisit the challenge
There’s a lot that I like about this process, aside from being a clever nod to the origins of our platform. However, it lacks critical pieces to move sustainably fast: it doesn’t overtly call out getting agreement and alignment throughout all phases of the process. Being aligned is only stated once in the Understand it phase. When building at scale, ensuring your teams and stakeholders arrive at this doesn’t start and stop in the early phase of a healthy product development process.
In Spotify Ads, we lead teams that work cross-functionally within what we call a quartet (Product, Engineering, Design, and Data Science) to solve in a complex, revenue-driven product arena. Our stakeholders span our business, marketing, legal, and finance teams. And thus, a culture of high alignment and high autonomy is table stakes.
Getting to High Alignment/Autonomy
To help Spotify Advertising achieve this, I worked with our leadership layer to introduce a forcing function. As a result, we instituted Phase Gates throughout our product development process for all of our large company bets and initiatives.
These stops ground our business-critical work in the idea that we don’t move from one phase to another without alignment and understanding every step of the way. The inspiration for our phase gates harkens back to an early engineering mantra of Spotify that spoke of a high-alignment, high-autonomy culture, which can be broken down as follows: First off, alignment and autonomy might seem like different ends of a scale. As in, more autonomy equals less alignment.
However, we think of alignment and autonomy as two different dimensions.
In low-alignment, low-autonomy cultures, we have micro-management scenarios. Our people aren’t sure why it is they’re doing what they’ve been told to do. There’s no higher-level purpose, and squads at the ground level feel undervalued.
With High alignment, and low autonomy, the team understands the challenge, but the solution is prescriptive and lacks any space for creative problem-solving. Leaders in these cultures are good at communicating what problem needs to be solved and might even inspire with their words, but they quickly squash those feelings by telling teams how to solve them.
In high autonomy and low alignment cultures, squads do whatever they want and often run in different directions, building in silos and creating technical and design debt with disconnected work tracks. Leaders are helpless here and spend much of their time helping their teams piecemeal the product together.
Finally, high alignment and high autonomy is the culture we’re trying to create. In this culture, the leader’s job is to communicate what problem needs to be solved and why. From there, they support their squads who are more likely to collaborate with each other to find the right solution. As you can imagine, these are the cultures with the highest morale and a strong sense of purpose and belonging.
Alignment enables autonomy.
The stronger alignment we have, the more autonomy we can afford to grant our teams. And this is where the phase gates mentioned above comes into play. Before I speak to those in more detail, let’s review The Scale one more time:
By adding Phase Gates, our product development process contains checkpoints that force our cross-functional teams to answer the question, “Are we aligned, and do we all understand?” in the context of each phase.
We’re aware that these extra steps are likely to cause slow-down but accept that risk to ultimately move sustainably faster with more trust and autonomy.
Let’s take a deeper look at what we ask each team to deliver as part of these phase gates.
Phase Gate 1: Scope Review
In our first phase gate, we’re asking teams to understand and agree on the customer problem, success criteria, and scope -- including business implications.
Reviewers: Approve scope; gut check for dependencies or duplicate efforts; Approved scope matches the business case or appropriate sizing
Initiative Owners gather Product Marketing, Legal, and Accounting for weigh-ins as part of pre-work
Presenters (working team)
→ Define the problem and address what parts the team is solving for and what is out of scope; including sub-discipline groups like Content Design
→ Provide supporting explanation and detail with user research/data science when available
→ Design mocks are not expected or required at this point
Phase Gate 2: Concept Check-In
This is where we ask our teams to gather early feedback from leads and pulse check the general direction. This gate rests in the middle of our process’s “Think It” phase.
Reviewers: Provide detailed and constructive feedback on concepts, confirm dependencies, and mitigate duplicate efforts.
Initiative Owners: Update our documentation source of truth with the latest design explorations, new dependencies, and any timeline impacts. Cascade updates with comms. Conduct Pre-Mortems to identify misuse cases.
Presenters (working team)
→ Low-fi concept walkthroughs
→ Product strategy for each with tradeoffs & implications
→ Engineering Manager Tech feasibility
→ Gut check w/Design Systems for new patterns/components
→ Present initial UX research signal (implies concept work has been shared with customers for qual study)
Phase Gate 3: Build Review
Here, teams get an official “OK” and support from leads to begin building.
Reviewers: Approve and commit to building the solution, provide strategic feedback
Initiative Owners: Update documentation with build timeline + unified RFC + tech architecture from Dev partners and latest/final design specs, mocks, and prototypes that help Eng understand nuances
Presenters (working team)
→ Eng produced a single RFC
→ Cross-functional conviction via comms
→ Product Marketing, Legal, Accounting, Finance review, and inputs
→ Final concepts are illustrated in high fidelity
→ Product success metrics, timeline, and strategy
→ Investigated eng/tech estimate
Phase Gate 4: Pre-Launch Review
Teams conduct a quality check on our go-to-market build.
Reviewers: Product team sign-off and celebration of the work presented.
Initiative Owners coordinate with Product Marketing for their go-to-market checklist/launch positioning and sign-off from legal, finance, and accounting.
Presenters (working team)
→ Walkthrough testable go-to-market build; field questions
→ Content Design must be in final form along with the end-to-end UX.
Phase Gate 5: Retros
The working team documents the project to provide a consistent and easily digestible recap that is appropriate for all staff. We encourage teams to use visuals, pictures, charts, and graphs. The ideal state is an artifact that our comms team would love to turn into a press release or story for broad, external consumption.