A Process to Better Incorporate Customer Feedback into Product Development


When the support team receives a customer report about a defect it cannot resolve or a request for a product enhancement, it has traditionally “escalated” the issue directly to the product owner. The goal of this document is to outline a new escalation process that:

  • Gets the QA team involved much earlier.

  • Helps ensure the voice of the customer is heard by more team members. (Is our solution to the problem addressing how customers use our products in the real world?)

  • Helps promote quality improvement by using postmortem analysis to explore how the issue came about in the first place. 



Escalation Process Overview

Note: When you reach a number, follow it back to the left side of the chart. 


Step 1: Support’s Role 

  1. A customer reports a potential defect or an opportunity for an enhancement.

  2. Support analyzes the customer report. As part of this analysis, the support team replicates the customer’s issue and attempts to resolve it.

  3. If the support team identifies the report as a defect or enhancement that cannot be resolved with in support, the report is documented in a JIRA and assigned to the product owner.  Please note, as with current process there should only be one issue described per support ticket. And equally only one item per JIRA. 


Step 2: QA’s Role


  • QA reviews support’s analysis in the Jira and tries to replicate the issue, if warranted.

  • QA enters a Jira comment titled “Official QA Analysis” with details as to how its result was reached. This postmortem analysis is meant to help identify how the defect reached production in the first place. Some example comments include:

    • There is a test case, it failed and the issue is known. (Ideally, the issue was identified in release notes.)

    • There is a test case and it was incorrectly passed. (The person who passed it should be notified as a courtesy.)

    • There is no test case and there should be. (Perhaps a whole new class of test cases are needed?)

    • There is no test case and there can’t be. (Must explain why.)

  • Next steps are included in Step 3 below. 


Step 3: The Traditional Development and QA Process

For Product Defects & Enhancements

  1. Product owner receives a JIRA from the support team 

  2. Product owner reviews the defect/enhancement and prioritizes corrective actions in cooperation with development. 

  3. Development analyzes the defect, defines a resolution and implements a fix in cooperation with the product owner. 

  4. Once development is completed, development sends fix version to QA for standard testing.


If the product owner decides the suggested enhancement should NOT move forward:

  • The JIRA is updated with a status of “will not fix.”
    • The product owner reassigns the JIRA to the support team agent who first reported it. The Jira should include feedback that support can provide to the customer as to why the enhancement will not be made. 
    • Support works with the customer to design a “work around” solution to obtain their desired results, if possible. When appropriate in the case of a dissatisfied customer, support should inform and engage the appropriate sales and business development team members. 


QA Testing 

  1. QA receives a product release from development. 

  2. QA tests the new release in accordance with the most current Master Test Plan (MTP). If necessary, QA consults with support to ensure testing covers how the product is being used by customers. 

  3. QA determines if the release has passed or failed:

    • Failed: 

      1. QA documents its results and sends the release to development for analysis via an updated JIRA.

      2. Development completes changes and sends the updated release back to QA for standard testing.

    • Passed: 

      1. QA updates the JIRA with test results.

      2. QA notifies the product owner and passes the fix version release on to support. 

      3. Support validates the fix version to ensure the customer’s expectations will be met:  

        1. If the release passes support’s validation: Support either provides the updated release to the customer directly or works with the product owner to determine when the update will be widely released. Support then works with the customer to ensure the release satisfies their needs. 

        2. If the release fails support’s validation: Support sends the JIRA with documentation on the testing procedure and reasons for failure back to QA for analysis.




Jira Index and Definitions


Issue TypesClassificationAssignee
BugDefectProduct Owner
Documentation BugDefectProduct Owner
ImprovementEnhancementProduct Owner
New FeatureEnhancementProduct Owner
TaskDefectProduct Owner


Issue Type:

Bug: A problem that impairs or prevents the functions of the product.

Documentation Bug: Documentation that incorrectly defines the functions of the product.

Improvement: An improvement or enhancement to an existing feature or task.

New Feature: A new feature of the product, which is yet to be developed.

Task: A task that needs to be done to achieve the team's goal and involves resource outside of support.


Classification:

Defect: If the product, for any reason, is not performing as intended.

Enhancement: If the product is working as expected, and we need to add a function not previously considered.