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.

Solve the problem class, not the instance

Failure reports are specific occurrences of end users experiencing unexpected results.  These typically occur when the system is not designed to handle unexpected user input.  There are really two underlying defects causing the failure.  The first is the workflow and visual design allowing the unexpected input to be entered.  The second is the unexpected result - the failure itself.

When correcting either defect, it is typical to update the system to handle the unexpected user input.  This is where most people stop.   Since systems are built using patterns and models, a defect in one part of the system has likely been introduced elsewhere.  Generally, solutions to reported failures miss opportunities to identify and resolve the underlying class of defects.  

When faced with a failure report from the field (or internal QA), go deeper.  While more an art than a science, there are several questions to ask that may reveal additional latent defects:

• Where else is this programming model used? (E.g., the pattern is used in all our repositories)
• How can the specific user input be generalized? (E.g., a screen blows up because one piece of information was made inactive by the system administrator, but other types of information can also be made elsewhere)
• Where else can these type data be entered? (E.g., Dates prior to today can be entered in many places)

Cultivate this perspective by starting with these questions and extending them to your environment.  Encourage people on your team to generalize every failure reported.  The goal is to get past the specific instance of the failure and to consider the class to which the failure belongs.  You may elect to only repair this instance due to time or money.  At least you will be doing so consciously.  Alternatively, you may find that you identify and avoid serious field failures.

You may elect to only repair this instance due to time or money.  At least you will do so consciously.  Alternatively, you may find that you identify and avoid serious field failures.

Harsh start-ups and smooth landings

I recently participated in an end of release cycle product demonstration. It was a wonderful experience and I was proud of the team’s achievement. It’s a great feature that will make a significant impact to our customers and to our business.

During the product demonstration, I couldn’t help but reflect back on the first several sprint demonstrations. Those were much different. Whole screens were thrown to the scrap pile, basic flows were challenged, and even seemingly simple functionality caused excitement among the stakeholders.

As the sprints went along, the conversations deepened, the team solidified, and the product began to mature. With each sprint, the discussions evolved away from major issues and towards minor suggestions and tweaks. During the last product demonstration, the feedback was positive and only a few cosmetic changes were suggested.

The technical lead remarked that we were doing pretty well if that was all the feedback we received. I had to agree. On my way out of the room, I remarked that we had experienced a “harsh start-up and a smooth landing.” Walking back to my office, I started thinking more about the factors that led to this point in the project.

Here are a few ideas for you to consider:

• Trust
  If a feature isn’t working, is confusing, or just plain wrong, anyone on the team or in the stakeholder community has an obligation to say so. This may appear to be an obvious truth, but it doesn’t always happen.
  
  Someone assumes another will catch it. Someone feels that no one will listen. The list of reasons for remaining silent goes on and on. As a leader, you can create an environment where people will stand up and use their voice. Make it clear that all feedback provided (respectfully) is welcome. People provide feedback if they trust that they will be heard, and that they will not be judged.
  
  In short, this trust is what leads to honesty. You have a vital part in making this happen.
  
  
• My product, your idea
  Our sprint teams welcome input from all sources: customers, internal stakeholders, and each team member. I’ve seen QA folks make design recommendations, customers provide workflow suggestions, and internal groups offer changes to improve service and supportability. The teams absorb the input willingly. They do so because they know it ultimately leads to a better result.
  
  They aren’t interested in whose idea anything is. They are interested in producing a quality product that delights our customers and helps the business. This ego-less attitude has to come from you – their leader.
  
  Praise the team each time they incorporate a suggestion from outside the team. Help them understand their contribution to a culture that promotes others to contribute. Encourage them and reward them when they respond to input from others. Their job is to produce a great product – not pretend to know everything. That often means listening to others.
  
  
• Act on feedback
  Do you want to encourage feedback? Then act on it when you receive it. At our demonstrations, I often hear the team place suggestions (and criticisms) they receive into their sprint backlogs. They then prioritize the feedback accordingly. The person who provided the input knows immediately that they are heard, and that the team and the business are going to treat their input with respect.
  
  Make sure everyone knows that not everything raised will get into the release, or even into the backlog. On the other hand, not everything is ignored. It is critical that each person understand the rationale for why a suggestion does or does not make it.
  
  Equally important is assuring the team that all feedback is regarded equally, regardless of the source. I have been told on more than one occasion that my input will go into the backlog – not immediately addressed just because I’m the VP. And that’s OK. I should have to justify a request just as much as any other stakeholder.
  

In the end, build a culture that honors feedback, regardless of where it originates, and does something with it. You will also likely see the degree of ownership among your stakeholders skyrocket. They will be transformed from talking about “the” product to talking about “our” product.