Agile Marketing and the Concept of Customer Debt

One of the fascinating things about the agile marketing movement is its identification of leverageable similarities with agile development, as well as the necessary differences.  Recently, the Boston branch of the movement identified another possible point of similarity:  an analogy with the agile-development concept called “technical debt.” I promised myself I’d put down some thoughts on the idea of “customer debt”, so here they are.

What Is Technical Debt?

Over the last few years, there has been increasing “buzz” in agile development circles and elsewhere about the concept of “technical debt.” Very briefly, as it stands now, technical debt appears to represent the idea of calculating and assigning the costs of future repair to deferred software maintenance and bug fixes, especially those tasks set aside in the rush to finish the current release. In fact, “technical debt” can also be stretched to include those parts of legacy applications that, in the past, were never adequately taken care of. Thus, the technical debt of a given piece of software can include:

1.       Inadequacies in documentation that will make future repairs or upgrades more difficult if not impossible.

2.       Poor structuring of the software (typically because it has not been “refactored” into a more easily changeable form) that make future changes or additions to the software far more difficult.

3.       Bugs or flaws that are minor enough that the software is fully operational without them, but that, when combined with similar bugs and flaws such as those that have escaped detection or those that are likewise scanted in future releases, will make the software less and less useful over time, and bug repairs more and more likely to introduce new, equally serious bugs. It should be noted here that “the cure is worse than the disease” is a frequently reported characteristic of legacy applications from the 1970s and before – and it is also beginning to show up even in applications written in the 2000s.

For both traditional and agile development, the rubber meets the road when release time nears. At that point, the hard decisions that must be made, about what functionality goes into the release and what doesn’t, what gets fixed and what doesn’t, are needed and are far easier to make. This is the point at which technical debt is most likely to be incurred – and, therefore, presenting “technical debt” costs to the project manager and corporate to influence their decisions at this point is a praiseworthy attempt to inject added reality into those decisions. This is especially true for agile development, where corporate is desperately clinging to outdated metrics for project costs and benefits that conflict with the very culture and business case of agile development, and yet the circle must be squared. Technical debt metrics simply say at this point:  Debt must be paid. Pay me now, or pay me more later. 

I have several concerns about technical debt as it is typically used today.  However, imho, the basic concept is very sound. Can we find a similar concept in marketing?

What’s My Idea of Customer Debt?

Here I focus on product marketing – although I am assured that there are similar concepts in branding and corporate messaging, as well. Product marketing can be thought of as an endless iteration of introduction of new solutions to satisfy a target audience:  the customer (customer base, market). However, as I argue in a previous discussion of continuous delivery, there is some sense in which each solution introduction falls behind the full needs of the customer:  because it was designed for a previous time when customer needs were a subset of what they are now, or because hard decisions had to be made when release time neared about what stayed and what was “deferred.” Customer debt I see as basically both of those things: lagging behind the evolution of customer needs, and failing to live up to all of one’s “promises.” 

More abstractly, in an ongoing relationship between customer and vendor, the vendor seeks to ensure good-customer loyalty by staying as close as possible to the customer, including satisfying the customer’s needs as they change, as well as it is able. Yes, the market may take a turn like the iPhone that is very hard to react swiftly to; but within those constraints, the agile marketer should be able in both solution design and messaging to capture both customer needs and the predictable evolution of those needs.  “We just don’t have the budget” for communicating the latest and greatest to a customer effectively enough, “but we’ll do it when the product succeeds,” and “sorry, development or engineering just can’t fit it into this release, so we have to make some hard choices, but it’ll be in the next release,” are examples of this kind of customer debt. 

The problem with this kind of customer debt is that it is not as easy to measure as technical debt – and technical debt isn’t that easy to measure. However, I believe that it should be possible to find some suggestive metrics in many agile marketing efforts.  The project backlog is an obvious source of these.  There will always be stuff that doesn’t get done, no matter how many sprints you can do before the grand announcement.  There should be a way (using analytics, of course) to project the effect of not doing them on immediate sales.  However, as in the case of technical debt, costs (e.g., of lost customer loyalty and branding opportunities) should rise sharply the longer you fail to clear up the backlog. I don’t yet see a clear way of identifying the rate of growth of such costs.

The Value of the Concept of Customer Debt

To me, the key value of this concept is that up to now, in my experience, neither corporate hearing marketing’s plans nor, to some extent, marketing itself has really assessed the damage done by delaying marketing efforts, and therefore has tended to assume there is none – or, at least, none that every other vendor isn’t dealing with. I think it is very possible that once we take a closer look at customer debt, as in the case of technical debt, we will find that it causes far more damage than we assumed.  And, again as in the case of technical debt, we will have numbers to put behind that damage. 

I am reminded of my colleague David Hill’s story about the Sunday school class asked if each would like to go to Heaven. All agreed except little Johnny.  What’s the matter, Johnny, asked the teacher, don’t you want to go to Heaven?  Oh, yes, Johnny replied, but I thought you meant right now.  In the same way, those who would abstractly agree that deferring marketing dollars might hurt a customer relationship but not really mean it might have a very different reaction when confronted with figures showing that it was hurting sales right now – not to mention even worse in the immediate future.

The Marketing Bottom Line

Lest you continue to think that losses from piling up customer debt are not likely to be substantial, let me draw an example from technical debt in projects in which features are delayed or features were not added to meet new customer needs arriving over the course of the project.  It turns out that these are not losses just if we fix the problems on the next release. On the contrary – and this is an absolutely key point – by deciding not to spend on this kind of technical debt, the organization is establishing a business rule, and that means that in every other release beyond this one, the organization will be assumed to apply the same business rule – which means, dollars to donuts, that in all releases involving this software over, say, the next two years, the organization will not fix this problem either.  

Wait, bleat the managers, of course we’ll fix it at some point. Sorry, you say, that is not the correct investment assessment methodology. That is wrong accounting. In every other case in your books, a business rule stays a business rule, by assumption, unless it is explicitly changed. Anything else is shoddy accounting. And you can tell them I said so. 

(If you want to go into the fine details, by the way, the reason this is so is that the organization is fixing this problem in the next release, but deferring another problem. So, instead of one problem extended over two years, you have 24 monthly problems, if you release monthly. Same effect, no matter the release frequency) 

So what does this mean? It means that, according to a very crude experience-suggested guess, on average, over those two years, perhaps an average of 2-3 added major features will be delayed by about a month. Moreover, an average of 2-3 other new major new features will have been built that depend on this software, and so, whether or not you do fix the original problem, these will be delayed by up to a month. It is no exaggeration to say that major “technical debt” in today’s terms equates to moving back the date of delivery for all releases of this particular product by a month. That is in strict accounting terms, and it is conservatively estimated (remember, we didn’t even try to figure out the costs of software maintenance, or the opportunity costs/revenue losses of product releases beyond that). 

So, to sum up, my version of technical debt is an estimation of the costs from a decrease in business agility. From my surveys, agile software new product development (NPD) appears to deliver perhaps 25% gross margin improvements, year after year, over the long term, compared to traditional NPD. 1/24th of that is still a decrease of more than 1% in gross margin – not to mention the effects on customer satisfaction (although, today, you’re probably still way ahead of the game there). Let’s see, do this on 25 large parts of a large piece of software and – oops, I guess we don’t seem to be very agile any more. Wonder what happened? 

Now, translate that to marketing terms:  an advertising venue unexploited, a product feature delayed, a misidentification of the customer from too-low analytics spending. Again, we are talking about an integral part of new product development – the marketing end. And we are talking just as directly about customer satisfaction.  Why shouldn’t the effects of customer debt be comparable to the effects of technical debt? 

So my initial thoughts on customer debt are:

·         It’s a valuable concept.

·         It can potentially be a valuable addition to agile marketing project metrics.

·         Agile marketers should think about it.