Sunday, September 21, 2014

Customer satisfaction & technical debt

Time to market is a key concept for product delivery.  Reducing time to market can preempt competition, show responsiveness to customer requests, and generate revenue sooner.  It is the basis for commitments to sales, to customers, and to the market.

Without ignoring time to market, I propose you plan, design, and deliver software with an additional concept in mind: Time to customer satisfaction.  

Bringing a product to market and having satisfied customers are not the same thing.  Time to market is straightforward.  It is when the product is released to sales and to customers.  Time to customer satisfaction is difficult to measure. It is a subjective combination of a customer's willingness to purchase, deploy, and use the software.

With an ideal product delivery process, the gap between time to market and time to satisfied customers is zero.  Alas, we don't live in ideal worlds.  Periodically, the gap is significant. When this occurs, the development team incurs a subtle of technical debt.

Let me step back for a moment.  Generally, plans expect version "X" to go to market with little or no additional work.  Reported defects are handled by a maintenance or customer support team. Requested enhancements are considered for a future release.  All is good.  

But, what happens when the feature itself is rejected?

Regardless of the reason for the rejection, you are forced to repair fundamental flaws immediately. These require depth that only your development team has.

The challenge is that your development team is executing plans and commitments for version "X+1."  Those have been communicated to sales and customers.  Product delivery commitments are commitments for revenue.


You have a few options:
  • Replan and change commitments.
  • Overwork your team to repair version "X" and maintain delivery of version "X+1" simultaneously.
  • Cut corners on version "X+1" as much as possible without impacting revenue and customer satisfaction.
The right option depends on your business.  For example, a small start-up needing cash is going to go for the latter two choices.  Whether or not the choices are sound business decisions is irrelevant.  What matters is that they feed on themselves to increase the likelihood of a future delay in version "X+1" time to customer satisfaction.

You might say at this point, "Adjust the plan and change the commitments." That is the engineer talking, not the business person.  Changing commitments can not be taken lightly.  The consequences range from lost credibility to severe financial harm (lost contracts, stock price, etc.).  

Your goal as a development leader is to reduce the risk of a gap in time to customer satisfaction.  Now that I've introduced the concept, I'll stop here. My next post will focus on things you control (or, at least influence) to decrease time to customer satisfaction.