Flyway

A Product Development Process at Twitter

Background

At Twitter, I was hired as the first Design Program Manager (DPM). The team later expanded to 4 total DPMs through new hires and role transitions. Twitter was broken into two product organizations - Consumer & Revenue. I was the sole DPM responsible for managing the Revenue Product Organization roadmap and product delivery for the Design & Research team. 

As I canvassed where I could have the greatest impact in a very broad role, I focused on the overall roadmap and design operations structure within all the Revenue Design & Research teams, which spanned 3 Product Design Directors, 2 Research Directors, and 1 Content Design Manager and their respective pillar teams. I started working with this leadership team to develop better design operations to increase effectiveness and efficiency in how we worked with our cross-functional product partners, our design process, and how we managed capacity planning with our teams. 

About 6 months into this work, with good progress being made with our Design & Research teams, I started supporting a product initiative for Twitter Ads both in timeline and in conversation replies. This initiative required working with teams across both the Revenue and Consumer product orgs. As I engaged with stakeholders across disciplines and organizations, I noticed some pretty big gaps and blockers in the product development process. More specifically, I had trouble navigating a project where each team worked using a different product development process with different phases, different requirements, and different jargon. 

And so, I created Flyway. 

Pursuing a near-impossible change

I could’ve navigated around that particular project, made it work, and moved on. But I saw an opportunity to create something that could impact the entire company at a larger scale. I love to work on operations programs that do any one of the following - centralize knowledge, create streamlined templates, increase efficiency of product launches, help people work smarter and not harder (and achieve better work/life balance), or better utilize the expertise of everyone involved in building products - this was an opportunity to do all of those things. 

I started this audacious idea by reaching out to the Strategy & Operations leads for both product orgs. I met with them each individually, then convinced them both to join a weekly brainstorm session around bettering the product development processes at Twitter. The idea wasn’t to combine them just yet, but to find ways to improve them both and make them more uniform. We started a google sheet comparing and contrasting the two processes and doing a sort of SWOT analysis on both. We found a lot of good in both processes but also a lot of opportunity. After each meeting, both of the ops folks I worked with would go back and draft changes to their respective processes. Before one meeting, I started drafting a proposal. After a few weeks of back and forth on maintaining both processes, I wanted to gauge interest in a crazy idea.

What if we had one product development process? 

The question was obvious and simple at its core, but obviously very difficult in practice. As we read through my brief, we came up with a bunch of reasons it couldn’t work, especially since it was hard enough to establish the two existing processes within their respective product orgs. But maybe that was the problem. If we had one well-crafted, designed, and backed by leadership process we could drive adoption across all the teams. That became our hypothesis. 

We shifted our working sessions toward taking the best of each process and building a foundation for the unified product development process we would propose to our leadership. But first, it needed a bird-related internal name. Because back then, that’s how Twitter did things (before it became boring and called itself X). After a ton of deliberation and ideas and polling our peers, we came up with Flyway. It felt good. 

But that was just the branding. Now we had to actually build the machine. 

Putting together a (few) super teams 

We had a framework, a brand, and a proposal. Now we had to get folks on board. This started with us individually getting in front of our leaders to soft-launch the idea in their heads. The two folks I worked with went to their respective product org leadership teams to share our proposal while I did the same with the Design & Research team. We spent a few weeks incorporating some feedback from those pursuits and finally got a 15 minute window with the executive leadership team at Twitter. This included Jack and his VPs and Senior Directors across the product orgs. 

We sent our proposal as a pre-read ahead of time and came to the meeting with a quick presentation that highlighted the talking points we felt would best convince this team to greenlight the effort. Our hypothesis now went beyond simply unifying and simplifying a product development process for the company. We had aims to do more, like:

• Establishing clear product development phases that we could track across a company roadmap.

• Creating templates that would act as the output for each phase - ensuring that expectations were predictable and we had shared requirements. 

• Increase the rate of product delivery across the company by making the process more efficient overall. 

• Better utilize our resources to work on the most important projects and reduce redundant efforts (since we’d be able to see what teams are working on, when, and how).

We had that one shot, and we got a greenlight. The team assigned us an executive sponsor (literally, an executive who was assigned to sponsor the program) and challenged us to have a framework ready to launch in the new year. It was late September when we had that meeting, so we got to work fast. 

Working with our new sponsor and a few other leads that we recruited, we formed our core Flyway team. We had representation from all the disciplines in addition to an Agile coach who had been hired to focus on these types of efforts. We had the framework for five product development phases that would take us from beginning to end:

1. Incubate: Incubate focuses on understanding the customer problem and identifying a proposed concept on how to solve a problem.  In this phase, a project can vary from being well-defined to narrowly defined. This phase is usually led by Design and Research as they go broad on looking for solutions to a customer problem. 

2. Define & Design: The Define phase focuses on clarifying DACIN models, identifying requirements, and defining milestones needed to solve the problem for the customer via the completion of a PRD.

3. Develop & Deploy: The Develop & Deploy phase focuses on building the solution to the customer problem. Previously this phase encompassed the launch of the product. In Flyway, Develop & Deploy focuses on the technical design, software development, and preparation for launch. 

4. Launch & Evaluate: Launch & Evaluate is the fourth phase of the Flyway product development process, focused on evaluating whether your product launch has been successful in solving the stated customer problem. This phase breaks out the steps of planning the launch, launching and evaluating the launch, and retro-ing the launch. 

5. Improve, Maintain, or Retire: Improve, Maintain or Retire is the fifth phase of Flyway. Fast-follow the completion of your evaluate phase to decide on next steps for your project. This is intended for us to understand if a product should continue to be invested in, maintained, or retired. 

With 5 clear phases, our next step was putting together a cross-function, cross-product org working team for each phase. We wanted to make sure design and research had input even in the phase more geared toward development and subsequently, that engineering had representation in the early vision phases that leaned more toward design and research. 

As we recruited ICs and managers for these teams, we set clear expectations on a time-boxed engagement. We specified three working sessions and no more than 10 hours of non-meeting work across 3 weeks. Once our teams were confirmed, we scheduled all our working sessions with notice to make sure attendance would be maximized. The teams started meeting and the details started getting hashed out. The templates, guides, and training materials wouldn’t be nearly as polished without the expertise from all the various disciplines in the room. The approach was intense, but necessary to achieve the quality we needed. The secondary benefit was that we had a built-in mechanism for driving adoption across the various teams. After all, if you worked on this, you’d want to see it succeed too. 

A lot of communication with a bit of creativity

In addition to facilitating these working team meetings, I got to work on building out a centralized knowledge base for Flyway. This started with some process maps which evolved into that cool graphic above. From there, I built an internal site using AEM to allow folks to navigate through the phases. Each phase had a description, a case study, and links to templates and examples. I created a repository for the outputs of each program that went through Flyway. So all of the PRDs that were part of the Define phase or the evaluation plans that were part of the Develop phase could be tracked across a universal roadmap. 

In addition, we kicked off office hours, a training module, and numerous explainers and playbooks for sub-teams to help contextualize the new process in relation to their existing ways of working.  I drafted comms that were sent on behalf of the executive team to launch and explain the new process. We established metrics we wanted to hit in the first half of the new year and sent bi-weekly newsletters tracking progress toward those metrics while also celebrating wins from teams using Flyway successfully. 

After 6 months: 

• We had a 92% adoption rate throughout the entire product org (Consumer and Revenue). 

• We had held 12 office hour sessions where we guided teams through the process. 

• 85% of employees completed the Flyway training module. 

• We saw a 25% year-over-year increase in product launches for the first half of the year - confirmed by quicker product development lifecycles by an average of 2 weeks. 

Flyway stands as one of the better achievements in my career. Not because I came up with the idea or kicked it off, but because I did those things from the ground up and built a team that helped me execute the vision. And it was a great achievement because it wasn’t a singular effort but instead a collaborative effort where we all stayed committed to our north star. 

Yes, there were detractors and complaints. Yes there were times where it felt impossible. Yes, there were times it felt like it would launch and then be ignored entirely. And yes, the program evaporated about a year later when Twitter went through massive change. 

That doesn't change what we accomplished. Before Flyway, I never thought an operational change at that scale was actually possible. Sure, it’s still very difficult and nearly impossible. 

But it’s possible.