jobs-to-be-done
by deanpetersUse the jobs-to-be-done skill to turn customer feedback into a structured JTBD analysis of jobs, pains, and gains. Built for Product Management, discovery interviews, positioning, and unmet-need analysis when you want more than a generic prompt.
This skill scores 78/100, which means it is a solid listing candidate for directory users: it has real JTBD workflow value, clear triggering guidance, and enough structure to be useful without a generic prompt. Users should still expect some adoption friction because it lacks executable support files and relies on the SKILL.md content plus template/examples for implementation.
- Clear trigger and intent: it explicitly says to use it when clarifying unmet needs, repositioning a product, or improving discovery and messaging.
- Strong operational structure: the skill lays out customer jobs, pains, and gains with functional/social/emotional distinctions and a full template.
- Good install decision value: a long SKILL.md plus a worked example gives agents enough context to execute with less guesswork than a blank prompt.
- No install command or support files, so users must adopt it as a documentation-heavy skill rather than a tool-integrated workflow.
- Evidence is mostly conceptual and template-based; there are no scripts, rules, or references to enforce consistency across outputs.
Overview of jobs-to-be-done skill
The jobs-to-be-done skill helps you turn a vague customer problem into a structured JTBD analysis: functional jobs, social jobs, emotional jobs, pains, and gains. It is best for Product Management, messaging work, discovery interviews, and product repositioning when you need to understand why customers choose a product, not just what they say they want.
This is a good install if you want more than a generic prompt. The skill gives you a repeatable lens for separating surface feature requests from underlying motivation, which makes it useful when roadmap debates, churn analysis, or new-product discovery are stuck on opinions.
What the jobs-to-be-done skill does
It organizes customer context into a practical template you can reuse across products or segments. The main value is clarity: it helps you define the job, identify friction, and spot what “better” actually means to the user.
Who should use it
Use the jobs-to-be-done skill if you are a PM, founder, marketer, UX researcher, or analyst trying to improve product discovery or convert customer language into actionable insight. It is especially useful when teams already have feedback, but not a clean interpretation of it.
When it is a strong fit
Choose it when the goal is to understand unmet needs, validate an idea, sharpen positioning, or compare current solutions against the customer’s real job. It is less useful if you only need quick copywriting or a high-level brainstorm without customer evidence.
How to Use jobs-to-be-done skill
Install and point it at a real problem
Use the jobs-to-be-done install flow from your skill manager, then work from the repo path skills/jobs-to-be-done. The upstream skill is lightweight and file-based, so the most useful first read is SKILL.md, followed by template.md and examples/sample.md.
Give it a specific customer context
The skill works best when your prompt names the audience, situation, and decision. A weak input is: “Analyze our product.” A stronger input is: “Use jobs-to-be-done for Product Management on a subscription invoicing tool for freelancers who switch from spreadsheets after missing payments.”
Convert a rough goal into a usable prompt
A good jobs-to-be-done usage prompt should include:
- the target user segment
- the trigger event that creates demand
- the current workaround or competitor
- the outcome you want to improve
- any evidence you already have, such as interview notes or support tickets
Example: “Create a JTBD analysis for small agency owners who need to send invoices faster after project delivery. Focus on the job, pains, and gains, and highlight where manual follow-up creates friction.”
Read the template before you write
template.md shows the structure the skill expects, and examples/sample.md shows the level of specificity that makes the output useful. If your input is thin, the output will usually be thin too; the template helps you see what details are missing before you ask the model to fill them in.
jobs-to-be-done skill FAQ
Is jobs-to-be-done better than a normal prompt?
Yes, when you need consistency. A normal prompt can work once, but the jobs-to-be-done skill gives you a reusable structure that reduces drift across analyses and makes comparisons between segments easier.
Is this jobs-to-be-done skill beginner-friendly?
Yes, if you can describe a user and a situation. You do not need deep JTBD theory to start, but you do need enough context to avoid generic output. The skill is strongest when you already know the product area and want a sharper framing.
What does it not do well?
It does not replace interviews, behavioral data, or market research. If the input is only internal opinion, the analysis may sound plausible but still miss the real customer job. It also is not the best choice for purely technical documentation or feature specs.
Is it useful for Product Management?
Yes. The jobs-to-be-done skill for Product Management is a good fit for discovery, positioning, prioritization, and message testing because it forces you to define the problem in customer terms before jumping to solutions.
How to Improve jobs-to-be-done skill
Give richer source material
The biggest quality jump comes from better inputs: interview quotes, support themes, churn reasons, sales call notes, or examples of what users tried before your product. The more concrete the context, the less the skill has to infer.
Specify the job, not just the feature
If you ask for “better onboarding,” you may get generic advice. If you ask for “help first-time users complete their first invoice without asking support,” the jobs-to-be-done output becomes much more actionable because the job is testable.
Watch for common failure modes
The main failure mode is overfocusing on features and underexplaining the user’s situation. Another is mixing multiple segments into one analysis. If the first pass feels broad, rerun the jobs-to-be-done guide with one segment, one trigger, and one desired outcome.
Iterate using gaps and contradictions
After the first output, improve it by asking what is missing: Which pains are most costly? Which gains are essential versus nice-to-have? Which social or emotional jobs are driving adoption? This second pass usually produces the most useful material for Product Management decisions and messaging work.