ProductFTW #21: Tips for Terrific Tickets

Every ticket, regardless of type (e.g., bug report, user story, compliance task), should contain a good title, description, impact, prioritization, and due date.

In ProductFTW #15, we discussed constructing quality user stories, and in ProductFTW #13, we covered product requirements documents. Today, we’ll discuss how to write terrific tickets. I’ve been using this material to train my product teams for over a decade.

Why Does Ticket Quality Matter?

Many tickets are extremely unclear because the person (product manager) writing the ticket is focused more on speed than on quality. However, when your original ticket is clear, your issue (and the work required) will be understood and resolved much more quickly, with less back-and-forth communication required. By slowing down and taking your time to write the ticket initially, you will speed up overall delivery.

Examples of Bad Tickets

I need the admin tool to take my uploads
Update the doc so that it’s not out of date
Make sure Bob can use the Admin from home
Fix bug user reported logging into iOS 17.1

Components of Good Tickets

Every ticket, regardless of type (e.g., bug report, user story, compliance task), should contain the following, at a minimum:

The image depicts interconnected circles with labels: "Title," "Description," "Impact," "Prioritization," and "Due Date," connected by a wavy line.
All good components look like tennis balls.

Good Titles

Good titles are brief but descriptive. When I first built this presentation at a company with ~12 product managers and ~100 technical staff, I reviewed hundreds of tickets and found that the best ticket titles had an average of seven words. Good titles include the impacted user, system, or process.

Good Descriptions

Writing a good description is easy, just remember those five “W”s you were taught learning how to write in elementary school:

  • What: What is the ask? What must be true for the request to be complete? Be descriptive!
  • Who: Who is the primary user of the request? Who is impacted? 
  • When: When does the issue occur? What scenarios does the request apply to? Is there a timeline commitment or dependency?
  • Where: Where does the issue occur? What systems or applications are impacted?
  • Why: Why must we do this? What happens if we don’t?


It’s important to provide context to the team working on your ticket. You can do so by being clear about the positive impact of ticket completion (or the negative impact of the ticket remaining incomplete).

For issues or bugs, try to answer questions such as:

  • How many clients/users are impacted?
  • Are the users blocked from performing their intended actions? 
  • How meaningful is the action?
  • Is there a workaround?
  • Are there direct financial impacts? What if we did not solve this issue?
  • Is there any data loss?

For new feature requests, the questions have a different tone:

  • How many clients/users benefit? 
  • Does the request save time or money? How much? How do you know?
  • Is there a financial upside? How much? Over what period of time?
  • What happens if we don’t build this feature?


No surprise: Listing prioritization on the ticket is critical. If you don’t prioritize the ticket, you’re asking someone else to do it, and they may not like it! Use this table to select prioritization:

Table describing common priority levels P0-P3
Save this for future reference.

Due Dates

There are two types of acceptable due dates to add to a ticket:

  1. Specific delivery requirement. For example, a date when a feature or fix was promised to a customer or is required by compliance or legal need
  2. Dependent dates. For example, when another ticket or task depends on the completion of this task.

In many cases, developing the final date involves negotiating with the development team, but you have to start somewhere.

Good Tickets

So, what’s an example of a good ticket?

Title: Enable HEIC uploads of ID verification docs during KYC Processes


As a Tier 1 support agent logging into the administration interface, I need to be able to upload HEIC files of large sizes of driver’s license photos, because that is how users submit them from iPhones. Currently, the admin is only able to accept JPEG or PNG, meaning we have to ask users to resubmit, causing an additional delay and touch to the ticket an additional time.

This is a P2 item; it affects 10% of users each day in the KYC queue.

We have committed to the customer that we will resolve this within 30 days to improve our ticket response time and process.

Impact: We can save an estimated 75 hours per week in support time.

Rewrites are inevitable

Even when you write a good ticket, unforeseen questions will arise, requiring edits to improve clarity and ensure new information is captured. Good (most?) ticket tracking systems store versions so you can see these edits.


The quality of your tickets can significantly impact the efficiency and effectiveness of your product development process. Clear and well-structured tickets reduce misunderstandings and minimize the need for back-and-forth communications, ultimately speeding up the delivery of solutions. As you incorporate these practices, you will likely see a marked improvement in the speed and quality of your product's development cycle. Keep refining your approach, and encourage your team to do the same, ensuring everyone benefits from clearer, more effective tickets.

About ProductFTW

ProductFTW is a weekly newsletter about product management focusing on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it.


Subscribe to ProductFTW

Don’t miss out on the latest posts. Sign up now to get access to the library of members-only posts.
[email protected]