Product management in political tech
Balancing short-term needs and long-term sustainability
Product Management on the DNC Tech Team requires a special balancing act. The goal of the DNC Tech Team is to develop the data, infrastructure, and tools that will not only help Democrats win in this election cycle, but also in future election cycles.
Short-term goals are critical, but so is long-term sustainability.
There isn’t a single set of product processes that allow us to achieve this balance. Instead, we are continuously learning and evolving our processes (whether it’s the form factor of critical products review, the steps of our roadmap process, or the planning of sprints).
Since joining the DNC Tech team in December 2018, as one of the early product team members, we’ve continuously adapted how we manage product development. At times, push factors (like the 2018 elections) prompted these changes. In other cases, internal factors like working across four time zones, motivated adjustments.
In all cases, we’ve found that applying the values of Scrum — transparency, inspection, and adaptation — to our processes has allowed us to adapt to the changing needs of campaigns and the election cycle
The DNC’s flavor of Agile
When I joined the DNC in 2018, product was a new addition to the DNC Tech Team. At the time, the team was primarily using a Kanban framework to prioritize their tasks. This development framework worked well for the team because it supported the rapid response needed during the 2018 election period.
Following the 2018 elections, we turned our attention toward 2020, arguably the most important election of our lifetime. We set out to develop sustainable solutions that would empower Democrats at every level. To do so, we needed a product management framework that would help us balance the short-term needs of organizations and long-term sustainability. We turned to Scrum.
Agile V0: Using Scrum
Scrum is an Agile framework that is guided by principles of transparency, inspection and adaptation.
One of the biggest draws of Scrum for our team was the concept of Sprints — a designated amount of time where a goal is set and priorities are protected. This practice gives us the reserved time we needed to focus on dedicated sprint goals, while allowing us regular intervals to reassess priorities and adapt to our users’ changing needs. This reflects the inspection and adaptation principles of Scrum.
Daily stand-ups are another Scrum practice that immediately brought value. As a mostly remote team (even before the pandemic), having a reliable time to check in on video is critical to building cohesive teams and ensuring everyone is aligned. This reflects the transparency principle of Scrum.
Along with sprints and stand-ups, we implemented other standard Scrum practices, including: sprint planning, backlog refinement, retros, and all-team reviews. Each of these ceremonies supported transparency across a remote team, gave us dedicated time to inspect our work, and ensured we were adapting priorities to meet our user’s most urgent needs. In addition, they gave us an opportunity to celebrate wins together, which is particularly important for staying connected on a remote team.
Agile V1: Designated support rotations
After a few months of working in the Scrum framework, we realized that time-sensitive user requests were derailing our sprint plans. Whole teams would shift focus mid-sprint to address urgent user needs. While addressing these requests was critical, the manner in which we were handling them was disruptive to our planned work.
Our solution: We built engineering and data support rotations into each of our product teams. One rotating engineer and data analyst on each team became responsible for ad hoc support requests for the duration of the sprint. They keep the business running, while letting the rest of the team stay focused on our sprint goals. Knowing that we always have one engineer and data human on support duty allows us to properly plan our sprint capacity and ensure we’re bringing in the right amount of work.
Agile V2: Building in a buffer and defining hard deadlines
With a presumptive nominee and less than 130 days until the election, our team recently reassessed our product process.
Our existing product roadmap process, which includes user research, user feedback, internal, and external prioritization exercises, remains important.
As we near the election we expect users’ needs to change rapidly. To balance long-term development with increasingly urgent user requests, we’ve reserved a larger percent of sprint capacity for unplanned work. We included this assumption in our roadmap plan for the current development period.
This allows us to define our sprint goals, make progress against our roadmap, and ensure our users are getting the support they need. If we don’t end up needing the flex time that was reserved for ad hoc user requests, we bring in the next highest priority items from the top of our backlog.
We’ve also incorporated “drop dead dates” into our roadmap process. These are the dates by which a release needs to occur to be effective. Typically agile teams have fungible deadlines for product releases. However with the ultimate immovable deadline (election day) and clearly defined phases of the election cycle (voter registration, GOTV, etc.), the use of “drop dead dates” enables us to prioritize projects and capacity to make sure we are working on the highest-impact project at the right time.
Applying Scrum values
As it has been said many times before, there is no one flavor of Agile; there is no one right way to implement Scrum. Every team must determine for themselves what works best for their users, their industry, and their team.
At DNC Tech, we are continually reevaluating our processes to ensure we’re meeting our users’ needs, working effectively as a team, and balancing short- and long-term goals.
Ultimately, we’ve found it helpful to apply the values of scrum to the framework itself: be transparent, inspect what is working, and adapt.
