Customer Reported Issues

Bugs happen. When a customer reports an issue absent a structured process we fall into a game of ping-pong: a ticket lands in engineering, a quick patch is merged, and the customer is left to report “it’s still not fixed.” To break this cycle, we use a product-management–driven workflow that begins by capturing the customer’s definition of success, collaborates on a validated design, and follows through with precise implementation, testing, and customer sign-off. By surfacing and documenting every assumption up front—and embedding customer validation before we write code — we ensure that development tackles the real business problem, not a guess.

We've included a case study below that shows how skipping these steps turned a minor discrepancy into a recurring headache — and how a structured PM/CS partnership can deliver the right fix the first time.

Product‐Management‐Driven Issue Resolution Process

Objective: Break the “ping-pong” cycle by ensuring we solve the customer’s real business problem—not just our first guess at the code fix.

  1. Discover & Define
    • PM-led customer conversation: The Product Manager speaks directly with the customer to understand the issue in their own words.
    • Success criteria: Document exactly what “fixed” looks like from the customer’s perspective (e.g. “Link counts display within ±1% of live site analytics for any 24-hour window”).
    • The key thing here is that we want to capture the customer's definition of success. It doesn't matter if we think it's fixed - it matter if they think it's fixed.
    • There is a possibility that the customer's definition of success is wrong or not informed based on system design. Ideally, this is addressed by Customer Success upstream from this process and we're only getting "real" issues in this process.
  2. Design Solution
    • Collaborative spec: PM and engineering workshop a design (user flow, mock-up or API contract) that meets the documented success criteria.
    • Assumption log: Capture any technical or business assumptions and flag them for validation.
  3. Validate with Customer
    • Prototype or walkthrough: Share the proposed solution (wireframe, API schema, or sample output) with the customer.
    • Feedback loop: Adjust spec until the customer confirms it will solve their problem.
  4. Implement & Test
    • Build to spec: Development executes against the agreed design.
    • Verification: QA tests using the customer’s success criteria; PM confirms internally.
  5. Release & Confirm
    • Deploy fix: Release to staging or production.
    • Customer sign-off: PM verifies with the customer that the issue is resolved to their satisfaction.
    • Monitor & iterate: Track any follow-up feedback and close the loop.

Case Study: “Bad Link Counts” Issue

What happened:

  • We received a support ticket complaining that link counts in our app were “way off.”
  • The ticket was dropped into Jira and immediately handed to dev.
  • Engineering “took a shot” at fixing the counting logic and closed the issue.
  • We notified the customer, “It’s fixed,” and told them to reopen if it wasn’t.
  • They dutifully told us "it's not fixed" and the cycle started anew

Why it failed:

  • Undefined success: We never captured what “correct” link counts meant for the customer.
  • Unvalidated assumptions: We presumed the discrepancy was a simple off-by-one bug without confirming the real root cause.
  • No customer validation: The customer never saw our proposed fix until after code was merged.

By shifting responsibility for context gathering to PM/CS and embedding customer validation into the workflow, we’ll move from “shooting from the hip” to reliably fixing the right problem the first time.