Stylized graphic of three mountains, each successively taller, with a flag on top of the last peak

In a recent article here on the AxBlog I extolled the virtues of the accrual of technical credit and provided several examples of how we think the strategy has worked well for us in the past. If you saw that article, you might have come away with the idea that we’re “rolling in it”, metaphorically speaking—that we’ve got credit to burn and we never take on debt.

Today I’d like to correct any such misimpressions. Not only are Axure’s software projects in a perpetual state of debt, but we differentiate between two types: technical debt and product debt. The first of these is pretty widely understood, and we’re constantly taking it on before refactoring and optimizing in order to pay it down. The second type, product debt, I see referred to less commonly. For us, product debt is any aspect of our products which we know is less complete, consistent, or polished than it could be, but which we’ve released the way it is because the product had to get out the door. (If some aspect of a release is less well-designed than it could be but we don’t know that, I suppose that’s just regular old bad design.)

We accrue new product debt just about any time we ship a release. Because many of the features of a complex tool like Axure RP are interconnected, we’ll often make a change that completes or polishes one use case while at the same time leaving another feeling unfinished. Further work to finish the second use case will then impact a third, and so on. And although it can seem sometimes like the work is never truly done, periodically we call it “done for now” and release a new version, adding a few more items to the debt list even as we cross off others.

Product debt is any aspect of our products which we know is less complete, consistent, or polished than it could be, but which we’ve released the way it is because the product had to get out the door.

One area of Axure RP where you can see this give and take play out is in the Outline pane, which has in the past been called the Widget Manager and the Dynamic Panel Manager. When this feature was first introduced many versions ago, the dynamic panel widget had an outsized importance to interactive prototyping in the tool: it was the only widget that could be dynamically moved, hidden, or reordered in a diagram’s depth order (z-index). Reflecting this, the Dynamic Panel Manager was dedicated entirely to keeping track of dynamic panels.

… Except that it wasn’t. Because customers also needed a way to identify all of the masters used on a page, the Dynamic Panel Manager also showed masters. This arrangement wasn’t as clunky as some others we’d considered, like perhaps having a dedicated “masters on page” pane, but it certainly wasn’t ideal. A potential fix that we considered during the development of version 6, which would have sidestepped the inconsistency entirely, was to include all widget types in the Dynamic Panel Manager’s item list—but we didn’t quite have the time to think through all of the implications of that change during the version 6 cycle. We ultimately shipped the release with the issue unresolved—accruing product debt—and planned to implement a fully considered solution down the road.

In the following release, Axure RP 7, the Dynamic Panel Manager gained an option to show all widget types and was accordingly renamed the Widget Manager. The masters’ presence in the list was no longer out of place, and several core use cases—like renaming, editing, and reordering widgets—were provided for. We’d paid down some debt.

… And accrued more in the process. With the inclusion of all widget types in the Widget Manager, the pane had come to resemble the layer lists typical of the graphics editing tools, such as Photoshop and Sketch, that some Axure RP users were very familiar with. The new Widget Manager caused some confusion among these users: we’d moved enough toward the layers paradigm used by other tools that the Widget Manager was now suggestive of a layers list, but not far enough for it to truly behave like one. For one thing, there were no folders. For another, the widget order seemed backward; graphics tools tend to display their layers in front-to-back order, whereas Axure RP, having historically borrowed its conventions from the world of HTML, had always displayed elements in z-index order (i.e., back to front).

The feature landed in a sort of limbo state, doing more than it could before but not as much as some customers expected of it. We’d paid a good portion of the original debt but incurred another (though smaller) debt.

A release without product debt—assuming that were even possible—would be one where work on new features ended almost before it began. Picture the strictest of old-school waterfall development cycles.

It wasn’t until Axure RP 8 that the Widget Manager—now called the Outline pane—came to consistently meet the expectations of our diverse user base. In addition to some other enhancements, the Outline pane now features folders (groups) and an option for toggling list order. (We generally prefer to offer a single, best workflow as opposed to “throwing an option at it,” but in this case we felt that different tasks lent themselves to different depth orders, and it therefore made the most sense to offer a toggle command to quickly switch between them.)

At this moment, the Outline pane basically does what both we and our customers think it should. While there are more enhancements in the queue, we consider the debt on this feature paid … until the next release.

The evolution of the Outline pane is just one example among many. Product debt is an inescapable aspect of our software development process, and we don’t see that fact changing any time soon. A release without product debt—assuming that were even possible—would be one where work on new features ended almost before it began, with most of the cycle dedicated to the reconciling of a few new features with the many pre-existing ones. (Picture the strictest of old-school waterfall development cycles.) On the balance, it wouldn’t be worth the sacrifice.

And the presence of product debt doesn’t mean we aren’t proud of our releases—we are. Release day is a good day. But it’s always a little bittersweet for our product managers, as their pristine product plans meet the constraints of releasing real software into the real world.

Share this: