Impeachment Is a Product
Last week I had coffee with a friend who works with Agile systems development. He made an off-hand suggestion that the best way to think about impeachment is not as a political process, but as a technology product.
Which basically hits all of my pleasure centers. He agreed to write up his argument, but didn’t want credit for it, since he doesn’t work in politics.
Below are his very smart thoughts:
So you’ve found yourself in a familiar place: a seeming insurmountable amount of work laid before you with a looming deadline, thoughts of professional success drawn from satisfied stakeholders set against ill-defined goals and an unreasonable deadline for delivery. Anyone in who has managed a product (in IT or RL) should have no difficulty understanding the dilemma House Democrats face in trying to manage impeachment.
Members of the House are in the same position as countless project managers have been over the years. So they should attack the task like project managers, not politicians.
Because whatever else impeachment may be, it is—first and foremost—a product.
Story Mapping
In developing new software applications, analysts and managers will often use a technique called Story Mapping.
It’s a simple process: stakeholders write down the things that they want the system to do, put them on individual Post-It notes, and hang all of these Post-Its on a whiteboard. The group then moves around the notes, creating a narrative—from left to right—of how they imagine a customer will use this new application, as well as the different options they’ll have at each step (which are arranged from top to bottom). Once the ideas are sorted, the analyst will walk the wall, reading aloud the group’s notes and finding any gaps that exist in the flow. The final step is discussing which parts of each step are essential for the application, and which are “nice to have” items that can be de-prioritized for future product releases.
The final story map is a guide to what the application will ultimately do, both in the essential elements (which can’t be compromised) as well as the bells and whistles that the team can produce later. It’s a powerful tool not only for the people working on the product, but to share with outsiders as proof of concept for what product will eventually look like.
This distinction is important, because in most applications the essential elements are the most important, but the least exciting to the planners. For the team doing the work, they have to stay focused on the must-do elements without getting distracted or delayed by something shiny that a manager thinks is valuable.
The Whistleblower Report
The whistleblower report is almost a story map on its own. It lays out the course of events from left to right (e.g., holding of aid to Ukraine, the call with Zelensky, the archiving of the documents), as well as the top to bottom details (e.g., OMB inquiring why aid was being withheld) that need to be fleshed out and confirmed via investigation.
These details are critically important, as they will (or won’t) provide corroborating evidence supporting the larger product vision: convincing the public that the president misused government for his own political benefits and must be removed from office.
Delivery Schedule
The desire to deliver to a specific date is understandable—particularly in politics—but it’s also one that should be resisted to the greatest extent possible. To paraphrase Shigeru Miyamoto, a delayed product can eventually be good, but a rushed product is forever bad.
The limits of the political calendar means that there would have to be an impeachment vote relatively soon—but even here we can see the benefits of the Story Map in setting priorities. Investigators can define the most essential aspect of each element, keeping them focused on what must be done and also giving them what people in IT call the definition of done—which is the point at which you recognize the diminishing returns of continued work and move on to the next action item.
Even after its creation, the story map continues to be a guide for the team. It provides a visualization of everything they agreed to pursue and how close they are to delivering the critical elements. Even if the team takes longer than expected to complete their tasks (perhaps because someone has ordered witnesses not to testify), the map provides resistance against the urge to deploy before the work is completed and the product is ready.
And if by some miracle (perhaps the White House chief of staff basically cops to everything for no reason), the list of must-haves provides the team with the confidence that they are ready to deploy.
Ready to Release
Releasing a product in IT is a little like Charleton Heston in The Agony and the Ecstasy: It will be ready when it is ready. Release it too soon and the product will be incomplete; too late and the market may have moved in a different direction. A successful product is, by definition, a well-made good delivered at a moment in which people want it.
Impeachment is no different.