01The setup
You’re at your desk, racing to feed engineering.
A long list of priorities. A sprint that starts soon. You’re typing fast because there’s no time. The good old days — when engineering was the slow part — aren’t coming back. You’re the bottleneck now.
Most PMs reach for the obvious AI play: ask an LLM to write the requirements. The first time you do this, the output looks fine. The second time, you notice the tickets are generic. By the fifth time, engineering is asking the same questions they always asked — just a little later in the process. The ceiling on “AI writes my tickets” is low because the AI doesn’t know what your customer is actually trying to do.
There’s a version of this that works. The unlock isn’t a better prompt. It’s a better foundation.
02The foundation
Give AI the context it’s missing.
Jobs to Be Done is a way of describing what your customer is actually trying to accomplish when they pick up your product. Instead of starting with features, you start with the progress the customer is trying to make, the problem they’re trying to solve, and the situation that pushed them to look for something better.
This matters because AI is only as good as the context you give it. Ask an LLM to write requirements with no product context and you get generic tickets. Hand it a sharp Jobs to Be Done framework and it can write requirements that are grounded, specific, and actually useful for engineering.
JTBD gives the AI the customer judgment you’ve been carrying in your head all along.
03Setup
Build the JTBD doc — once.
Keep it to one or two pages. Focused enough that the LLM can actually use it. If you don’t already have one, dump in whatever you have — customer interviews, support tickets, sales notes, briefs, surveys, rough notes — and iterate. Tell the LLM exactly what you’re building:
You are creating a Jobs to Be Done framework that will be used to generate product requirements.
Then iterate. Tighten the job statements. Strip out anything generic. Make sure each one reflects what customers are actually trying to get done. This is the slow part — once. Everything downstream gets faster.
A note that matters more than it looks: I use voice for almost all of my writing now. Requirements, rough product thinking, feedback — talked through first, then structured. AI gets dramatically more useful when you reduce the friction of getting your thinking out of your head. You don’t need a perfect prompt. You need a fast, messy first draft.
05Where this lands
Old loop vs. new loop.
The old loop
idea → writing → revising → copy/paste → ticket → engineering questions → rewrite → ship
→
The new loop
idea → voice → clarify → structured ticket → ship
The old loop is sequential and lossy. The new loop carries context forward at every handoff — that’s where the leverage actually lives. Same job. Half the steps. Better output.
06Takeaways
Stop writing tickets. Build the workflow that writes them.
The PMs getting the most leverage from AI right now aren’t the ones with the cleverest prompts. They’re the ones who put the work in upfront on the JTBD foundation, then built a skill that turns it into output.
- 01AI is only as good as the context you give it. JTBD is the context.
- 02Keep the JTBD doc to one or two pages. Focused enough for the LLM to use.
- 03Use voice for the messy first draft. Reduce the friction to get thinking out of your head.
- 04Build a skill for your atomic requirement. Add clarifying questions. Wire it to your tracker.
- 05Goal isn’t faster tickets. Better tickets, faster.
- 06In startup mode, the same loop that drafts the spec helps ship it.
Idea → voice → ticket. That’s the loop.
