The Drifting Goals of Product Excellence

Here is an analytic view into how project goals can drift in a way that lowers product quality, hurting a firm's reputation, a team's motivation, and a customer's experience of the product.

Our analysis will use the example of a software product, but the archetypal idea holds equally well in any product category across any industry. We'll use a systems diagram to visualize the situation.

1) The goal of product excellence compared against the reality of actual excellence creates a gap. This gap might exhibit itself as, for example, a slipping schedule, or long a long bug list, or a user interface that's hard to use.

The "S" at the end of the Goal arrow means that as one variable changes the other one changes in the same direction. As the goals increase, the gap between the goal and actual increases.

The "O" at the end of the Actual arrow means that as one variable changes the other one changes in the opposite direction. As the actual performance increases, the gap decreases.

2) As the gap increases corrective actions are required. These actions are often difficult, because doing the right thing is often difficult. Closing the gap might require, for example, resetting expectations on the schedule, assigning additional quality assurance engineers to the project, or re-thinking the user experience from first principles.

3) There is usually a time delay before the results of the efforts are seen. Delays in a system usually have consequences and side-effects.

For example, re-thinking the way a user experiences a product will generally make the schedule seem much worse – until everything comes into focus, extraneous features are stripped out, the team is aligned with the new approach, and suddenly everything is clicking again.

Once actual results increase, it closes the gap. This is the primary balancing loop B1, which strives for equilibrium. We've got a gap, let's work to close it.

4) But there is more than one way to close a gap. As the gap between goals and performance increases, there is pressure to simply lower the goal.

The easy way out might be, for example, stripping features to meet the schedule, shipping with more bugs than you'd prefer, or deciding to "fix the user interface" in the next version.

5) As the pressure to lower the goal increases, meeting the goal of excellence decreases, which further increases the gap. This second balancing loop, B2, closes the gap by changing the goal.

6) As one feels the gap increasing, we tell ourselves stories to make sense of the situation. One story might be, "We have to ship on time," which makes us feel better about lowering the goal.

Other stories here might be, "All software has bugs," or "It's good enough for 1.0." Customers might not agree, and you might not get a second chance to get it right.

7) Another story might be, "This is really hard," which could either support a team self-identity as awesome warrior engineers, or increase the difficulty as they become lost in the complications rather than driving toward clear solutions.

Other positive stories here might be, "We make good decisions, even if they're difficult," or, "Always try to do the right thing."

8) When you've got a gap between your desired outcome and your actual results, consider whether your decisions drive true corrective actions vs. shortcuts, rationalizations, and blind spots.

Look at your decisions from the perspective of your customer, and see if they would agree with the trade-offs you're making.

When you have a lot of gaps across many projects or teams, "abstract up" to see if some of them can be solved simultaneously by implementing larger structural changes.