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.

Oops.

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.

Why Planning Matters

A few weeks ago, I wrote that I love Agile Development because it provides an opportunity to learn. Ultimately, my example led me to the point where the repetitive planning inherent in Agile Development allows my team to get better at it. I left off by stating "Since your customers don't buy plans, consider why this matters."

So why does it matter?

What do customers buy? Certainly, they buy products and services. But let's go a bit deeper. In the enterprise world, which I've been part of for twenty years, there is something intangible that goes into selling. There is something a C-level buyer wants.

Commitment.

At some point, you have to look your customer in the eye and commit to delivering what she needs. This was true many years ago when I was involved in non-stop mission critical systems, and it remains true today.

You can make a commitment and hope for the best. Alternatively, you can create a plan that demonstrates how you are actually going to achieve the commitment. This is the connection back to my earlier post. By having more "at-bats," you plan better and faster. You are able to have a realistic shot at collaborating with your customers on a real commitment - one that is negotiated based on mutual trust and respect.