Taking a break from having guests on the Substack this week to talk about PRDs and writing tickets with AI.
There have been a lot of hot takes about PRDs on Twitter lately. I'm going to share some "controversial" thoughts on them.
Even if you prototype with AI, you should still have a PRD: Give your team context to the why behind the decisions you made in the design and functionality. While many companies are changing shape, many still need clarity, communication, and handoff between different disciplines. Until you are the design, product manager, and engineer, a PRD is important to communicate the strategic direction of the feature you are building.
PRDs should be written by a human first: Imagine someone gave you a compass and told you to walk from NYC to Montreal. Now imagine that compass is off by a couple degrees. You are going to walk past Montreal. Your strategic direction needs to be aligned by you first, and be very intentional before you involve AI. Then you can use AI to get feedback on gaps. Even when I've given it examples, AI has often given me metrics that are hard to measure or terrible things to measure. Write it yourself first, then use AI. When I've started a PRD with AI, I've had to make so many edits that it wasn't even worth starting with AI in the first place.
Once we get into execution details, it's easier to have AI write for you, like writing tickets. I use AI to write a lot of my tickets these days. In the companion video for this article, I show you how I usually write tickets using Claude and Claude projects. At the bottom of this article, I include an example ticket prompt that you can take and edit for yourself. Who knows how much longer we will need to write tickets with AI involved in more of the execution, but for now, hopefully it's helpful.
AI is pretty good at taking a general set of rules about how you want a feature to function, combined with uploading images of the designs, to write detailed tickets quickly. You still need to review every ticket and adjust things that may be incorrect assumptions on its part. However, I've found it still saves me a lot of time.
Good rule of thumb: If something requires clear, strategic thought, you should write it yourself and get feedback from AI. If something is communicating cut-and-dry details where directional decisions have already been made, AI is pretty good at that.
I teach more about when to use AI tools, why, and how in my new workshop Building Successful Products with AI. Please message me if you're interested in learning more about it.
See you next week when we talk about building AI products that are intended to help with decision making and the challenges that come with it.
Stay curious.
P.S.: I’m a fractional product leader and consultant. Even if you don’t have anything for us to work on together right now, always happy to meet new people for virtual coffee. Reach out here.
P.S.S.: The fifth live rendition of Jumpstart Your AI Career on Pearson/O’Reilly will be February 24. Register here.
P.S.S.S.: I also coach PMs how to 10x themselves using AI in the highest leverage ways, while feeling more empowered and less stressed. I also do corporate workshops on this as well. If you’re interested in working together, please reach out.
Ticket Prompt
You are an experienced product manager and you are writing tickets for an upcoming initiative. Please take the following information, including attachments to help me write tickets. Keep in mind, when I copy paste from Claude, I want to be able to copy the title of the ticket separately than the body of the ticket. It makes it easier and faster. I should see the place to copy the title of the ticket before the place to copy the body of the ticket.
Ticket structure:
The ticket should have the following sections with bulletpointed details below each section: “Summary” (summary of the ticket), “Job Story” (When [situation/trigger], I want to [motivation/goal], so I can [outcome/benefit].For example:"When I'm running late for work, I want to quickly order my usual coffee, so I can save time and still get my caffeine fix.") , “Design” (link to the design), “Location(s)” (where in the app does this live), “Users” (which users are impacted: All, Admin, Project Owners, Project Creators), “Acceptance Criteria” (what details does the developer need to know to create the ticket, and if QA verified the feature or subfeature does these things, it would be successful), “Impacts” (what other features in the app use this feature, will be impacted, or the developer and QA people need to test to see the impact. For example, we have a concept called variables, and it’s not enough to add variable, you need to create documents and test that the variable is updated there), “Notes” (any critical notes or context someone reading the ticket should know)
When something is clickable, please write the requirements as "on click or tap of [name of item]" followed by the action that happens when the action happens.
Things to consider when writing tickets for our team:
It’s easy for humans to misinterpret directions in tickets. Please make the tickets very clear, and assume they could take the direction very literal. However, try not to use large, complicated words that may confuse people. Also, assume different developers could be working on the same initiative but different tickets. We also don’t know what order they will pick up the tickets. Do not assume that because some information is in one ticket that the same engineer will carry that information over into other tickets. You may need to repeat some information. For example, there was a project where one developer worked on a ticket that wrote a migration script that included migrating attachments, but the ticket that discussed the UI for where the info was being migrated to didn’t mention attachments. The two tickets were worked on by different developers, so the developer working on the UI didn’t know about the attachment requirement.
Here is info from the epic:
[Copy paste epic info here]
Please wait for me to ask help for writing each ticket one by one. Be on standby.
After you enter the above prompt into your tool of choice, write a short description of the functionality needed in the ticket, and upload any related design images for the ticket. The video does a good job showing how I do this. Reach out if you have questions.
Share this post