The tools of the trade for product management simply aren’t fit for the purpose of understanding and instrumenting a complex business process. We know this in our bones—we laugh at viral videos that point out the ridiculousness of our daily lives, but until now, we haven’t been able to put our finger on why these broken tools exacerbate the waste that builds up in broken processes.

‍

Andrew and I have been thinking about these problems for years, and we’ve come to the conclusion that there are three main reasons that analysis and reporting coming out of current project and product management tools leads to so much waste.

1. Resolution – current analysis frameworks are too binary
2. Breadth – current views, particularly of “product management” are too narrow
3. Chronography – current platforms have insufficient understanding of “time” and how it relates to process flow

In future posts, I’ll expand on breadth and chronography. But for now, I want to dig into the resolution of modern software tools.

At a fundamental level, the way we track projects tends to be very binary. Almost every tracking tool has some version of a “burndown” chart, showing how much progress is being made against a defined unit of work. The tasks in that chart fit into one of three status types. (I know, I know—having three states means it’s not “binary,” but bear with me.):

1. Todo
2. Doing
3. Done

And the assumption is the work is flowing to completion as each task moves from “Todo” to “Doing” and then to “Done.” How work is progressing becomes a really simple measurement: what percentage of that work has moved to a “Done” state. Here’s a representative burndown chart from a recent Bloomfilter sprint. It shows the amount of work left to complete.

The problem when trying to understand how the work is progressing is you have zero sense of what’s happening inside these states.

At the most extreme level, a sprint where all the tasks are in testing but not deployed will show the same burndown chart as a sprint where the tasks have yet to be started.

Well, burndown is just one chart, right? We can just look at something a little more sophisticated to get a more nuanced view. Maybe we look at cumulative flow?

Hmmm… That’s…unhelpful. All the signal of the process flow is lost amidst the noise of the “done vs. doing” dichotomy. Perhaps the chart will become meaningful if we remove the “In Production” (which for some reason is cumulative for all time) in hopes of getting to a finer resolution of this particular sprint.

Unfortunately, now that we’ve lost our “In Production” tasks, the process flow chart loses all continuity and meaning. Are tasks leaving “review” because they’re being deployed? Are they being deleted? Who’s to say? There’s simply no sense of what’s happening inside the process.

I could go on like this forever, cycling through charts in hopes of getting some meaningful perspective on how the sprint progressed, but I suspect you’re getting an idea  just how productive that exercise is going to be.

I won’t even bore you by trying to stitch this together across multiple tools instead of one product management system (I’ll save that for the breadth post) or trying to do more time-series analysis of the process flow (that’s coming in chronography.)

If we want to understand how the process of product development is working and where to find inefficiency and waste, the most fundamental analysis tooling we need is the ability to look at the process (in a meaningful way) at various resolution levels. We need to be able to zoom out to get a fuller view of the process. We need to be able to zoom in to see the individual tasks, all without breaking frame. We need to be able to do this across arbitrary time frames and filter that data in various ways depending on the needs of the business and analysis.

A big part of the reason product leaders have to spend so much time exporting data into Excel is that current tooling simply doesn’t support varying granularity in the resolution of process data that it displays. It’s too binary. It’s too focused on “to do,” “doing,” and “done” despite the fact that those starts obscure as much as they illuminate.

A modern approach needs to focus on peering inside the three binary states to let a product manager understand what’s happening inside the process. Software leaders need to easily understand (at various levels of resolution) where work sits, where it’s flowing, and where it’s getting blocked. A modern burn chart needs to overlay work that’s complete with work in process and in various other states to easily understand the status at any given point in time.

Similarly, a modern process flow analysis platform must be able to depict the process flow at a resolution that’s meaningful. In the chart below, the user can easily understand the state of work, where it’s sitting, and where there might be process issues to remediate.

Modern software development tooling, especially process analysis, is broken. Most tools provide unhelpful or even potentially misleading information to the users who are trying to build and ship products. We’ll get into some of the more complex topics in future posts, but the first and most obvious place platforms need to evolve is with respect to the resolution of the data present. Simply put, process flow data needs to be presented in a frame that is accurate and contextually helpful to the user—a concept that seems simple enough but is almost entirely absent from current state of the art.