Case Study: Product Management for voting issue resolution

When: Winter/Spring 2023

Problem space:

The Lawyers Committee for Civil Rights runs the US’s largest Election Protection program to monitor and address ballot-based voting interference. Between a cadre of poll-watchers, a hotline, and behind-the scenes partners on deck to correct issues, they keep track of thousands of incidents each year.

In 2020, their digital intake systems had been upgraded but still were swamped – I joined a team maintaining this project in 2022 to do a needs assessment, revise limited UIs, and revamp the tech training service. We got through without major issued but agreed: the system in place, a hodgepodge of older open source softwares and API scripts, not all of which were maintained, had to be replaced.

In 2023 I lead a product discovery, spoke to several dozen stakeholders and key users, and put together a full PRD, alongside my technical partner, and vetted contractors, which lead to the organization deciding on a new path forward and kicking off Dec 2023, ahead of the 2024 election. 

Outcome: The program team will be able to 

  • Compress 3 softwares into 1, reducing API and technical maintenance, lessening the neds for as many contractors, as well as reducing overall complexity
  • Reduce time to correct errors from 2 minutes to under 30 seconds [edit instead of re-do]
  • Battling workflows will happen in parallel, instead of in a challenging “turf war”

Approach:

  • User and stakeholder interviews to identify key journeys and points of friction
  • Jobs to be done-centered service mapping
  • Stakeholder prioritization workshops
  • Full Product Requirements document 
  • Communication, analysis of solution partners 

What came up & what I learned: :

The Election Protection program has multiple services, each of which has a different software system to address it – but until I took a system design approach, some of this nuance was missing

Most software systems were designed intelligently at their inception: but technical debt, organizational knowledge loss, software that is not maintained, systems that are pasted together with complex [yet, genius!] APIs, and a pastiche of contractors added complexity. 

Leave a comment