Automating ticket creation is solving the wrong problem
I keep hearing about PMs creating AI automation to write tickets. The goal is to write tickets in a consistent format, and reduce some admin.
But is this really where you’re spending a lot of your time? If so, that’s a sign something else is wrong.
Go back to first principles
Why do we write tickets at all?
Tickets are an artefact used to track work. They don’t need to be perfect.
Tickets should only exist when we know we’re going to do a piece of work. They aren’t the right place to log things we might do someday.
Why is that? If we’re not sure if we should do something, we first need to figure out if it’s important enough. That exploratory step works a lot better in a document than a ticket.
Start here instead
Before creating any tickets: write a short PRD to help you validate the opportunity. This should include enough information to decide if this is a problem worth solving.
Here are my 7 questions for writing a good PRD:
Problem statement (What problem are we solving? Why does it matter?)
Target users (Who is affected by this problem? How many customers/users?)
Impact assessment (What is the potential market opportunity, financial benefit, or strategic value?)
What if we don’t solve this? (What are the consequences of not addressing this problem?)
Proposed solution (At a high level, how could we solve this?)
Success metrics (How will we measure success? What are the key metrics?)
Risks and assumptions (What assumptions are we making? What could go wrong?)
This isn’t meant as a tickbox exercise. With this format, you’ll see how the good problems rise to the top - and the unclear, fuzzy ones go back to the drawing board - or get dropped entirely.
Be pragmatic: skip it if it doesn’t make sense
Some things are no-brainers. Things like bug fixes, copy changes, and non-contentious quick wins.
Don’t over-engineer the simple stuff. Don’t force what’s really a ticket into a bloated PRD.
Who should write tickets?
It’s fine for anyone in the team to write the tickets. Teams should not view the PM as the “ticket writer”.
The PM writes the PRD. That defines the problem and the desired outcomes.
Tickets form the “how” - which belongs to the team. One problem might produce one ticket, or ten.
Engineers shouldn’t be waiting for the PM to write tickets.
In summary
If you’re trying to automate ticket creation, you’re focusing on the wrong problem.
If there’s no PRD, or key information is missing - fix that. Don’t go straight to tickets.
It’s a lot simpler to get the documentation right before looking at implementation details. Otherwise, you’ll spend forever working on tickets: splitting, merging, and rewriting them.
Save yourself time in the right place. Nail the PRD. The tickets will come naturally.
Product Notes is free and lands every week. Subscribe to get it in your inbox.