jobs-to-be-done
Discover what customers truly need by analyzing the "job" they hire your product to do. Use when the user mentions "customer discovery", "why customers churn", "what job does this solve", "competing against luck", "product-market fit", "switching behavior", "milkshake moment", or "functional vs emotional jobs". Also trigger when investigating why users choose competitors, designing features around real customer needs, or reframing product value propositions. Covers JTBD interviews, competition analysis, and jobs-oriented roadmaps. For product positioning, see obviously-awesome. For rapid validation, see design-sprint.
What this skill does
# Jobs to Be Done Framework
Framework for discovering innovation based on a fundamental truth: customers don't buy products - they "hire" them to do a specific job in their lives.
## Core Principle
**Job to Be Done** = the progress a customer wants to make in specific circumstances.
Key elements of the definition:
- **Progress** (not goal, not solution) - customer wants to move from current state to a better one
- **Circumstances** - context determines the job, not customer attributes (demographics are useless)
- **Hiring/Firing** - customer actively chooses a product for the "job"
## Scoring
**Goal: 10/10.** When reviewing or creating product strategy or positioning, rate it 0-10 based on adherence to the principles below. A 10/10 means full alignment with all guidelines; lower scores indicate gaps to address. Always provide the current score and specific improvements needed to reach 10/10.
## Three Dimensions of Every Job
Every job has three inseparable dimensions - omitting any means failure:
| Dimension | Question | Example (milkshake) |
|-----------|----------|---------------------|
| **Functional** | What does the customer need to do? | Occupy myself during boring commute |
| **Emotional** | How do they want to feel? | Have a small treat for myself |
| **Social** | How do they want to be perceived? | As a sensible parent (not buying donuts) |
## Framework
### 1. The Job Statement
**Core concept:** A job statement captures the progress a customer seeks in a specific circumstance, expressed in a structured format that separates context, desired progress, and expected outcome.
**Why it works:** By forcing teams to articulate the job in the customer's language and circumstances, it prevents solution-first thinking and keeps innovation grounded in real human progress.
**Key insights:**
- The format is: "When [circumstances], I want to [progress], so I can [outcome]"
- Circumstances matter more than customer demographics - the same person has different jobs in different situations
- A well-written job statement never mentions your product or any specific solution
- Jobs are stable over time; solutions change but the underlying job persists
**Product applications:**
| Context | Application | Example |
|---------|-------------|---------|
| New product ideation | Define the job before brainstorming features | "When I'm commuting alone, I want something to occupy me and satisfy hunger, so I'm not hungry until lunch" |
| Feature prioritization | Evaluate whether a feature serves the core job | Prioritize features that help accomplish the stated job over nice-to-have additions |
| Positioning & messaging | Use the job statement language in marketing copy | Lead with the circumstance and desired progress, not product specs |
**Copy patterns:**
- "When you're [circumstance], you need [progress] -- that's exactly what [product] does"
- Lead with the situation the customer recognizes, not the product category
- Mirror the emotional and social dimensions alongside the functional one
**Ethical boundary:** Never fabricate or exaggerate circumstances to manufacture urgency. The job must reflect genuine customer progress, not artificially created anxiety.
See: [references/innovation-process.md](references/innovation-process.md)
### 2. Forces of Progress (Push, Pull, Anxiety, Habit)
**Core concept:** The decision to "hire" a new product results from the interplay of four forces: Push (frustration with current situation), Pull (attraction of new solution), Anxiety (fear of the new), and Habit (comfort with current behavior). Change only happens when Push + Pull > Habit + Anxiety.
**Why it works:** Most innovation efforts focus only on making the product better (increasing Pull), but ignore the equally powerful anti-change forces. Understanding all four forces reveals why great products still fail to gain adoption.
**Key insights:**
- Push is frustration with the current situation ("this annoys me")
- Pull is the attraction of a new solution ("I want this")
- Habit is attachment to current behavior ("I've always done it this way")
- Anxiety is fear of the new ("what if it doesn't work?")
- Often it's more effective to reduce anxiety and habit than to increase push and pull
- Passive seekers (vaguely aware of a problem) are easier to influence than active seekers who already have criteria
**Product applications:**
| Context | Application | Example |
|---------|-------------|---------|
| Onboarding design | Reduce anxiety with free trials, guarantees, and social proof | Money-back guarantee addresses "what if it doesn't work?" anxiety |
| Switching campaigns | Address habit directly by making migration effortless | One-click data import from competitor reduces habit friction |
| Content marketing | Awaken push in passive seekers by naming their frustration | Blog post: "5 signs your current tool is costing you hours every week" |
**Copy patterns:**
- Address anxiety directly: "No lock-in, cancel anytime, your data is always yours"
- Name the push: "Tired of [frustration]? There's a better way"
- Reduce habit friction: "Switch in 5 minutes -- we import everything automatically"
**Ethical boundary:** Never manufacture artificial push by exaggerating pain or creating fear. Reducing real anxiety is ethical; creating new anxiety to drive sales is manipulation.
See: [references/competitive-strategy.md](references/competitive-strategy.md)
### 3. The Big Hire & Little Hire
**Core concept:** There are two distinct decision moments: the Big Hire (purchase/signup decision, happens once) and the Little Hire (decision to use in the moment, happens repeatedly). Winning the Big Hire does not guarantee the Little Hire.
**Why it works:** Many products win the sale but lose the customer because they optimize only for the purchase decision and neglect the repeated usage decision. Understanding both moments reveals where retention problems truly originate.
**Key insights:**
- Big Hire is driven by marketing, onboarding, and first impressions
- Little Hire is driven by product quality, UX, and ongoing value delivery
- Many products lose at the Little Hire stage -- purchased but never used
- The forces of progress operate differently at each stage: Big Hire anxiety is about the purchase risk; Little Hire anxiety is about effort and learning curves
- Retention problems are almost always Little Hire failures, not Big Hire failures
**Product applications:**
| Context | Application | Example |
|---------|-------------|---------|
| Retention analysis | Distinguish Big Hire metrics from Little Hire metrics | Track "first use after signup" and "weekly active usage" separately from signup conversion |
| Product design | Optimize the repeated usage experience, not just first impression | Reduce friction in daily workflows even if onboarding is already smooth |
| Customer success | Monitor Little Hire signals to predict churn | Declining usage frequency is a Little Hire failure signaling upcoming churn |
**Copy patterns:**
- Big Hire copy focuses on the promise: "Transform how you [job]"
- Little Hire copy focuses on ease: "One click and you're done"
- Re-engagement copy addresses Little Hire failure: "We've made [specific friction] easier"
**Ethical boundary:** Never design dark patterns that win the Big Hire (e.g., hidden fees, misleading trials) while failing the Little Hire. Both decisions must deliver genuine progress.
See: [references/case-studies.md](references/case-studies.md)
### 4. Competitive Landscape (Non-Obvious Competition)
**Core concept:** True competition is everything a customer can "hire" for the same job, often from completely different product categories. Competitors are defined by the job, not by industry classification.
**Why it works:** Analyzing competition through product categories creates blind spots. A milkshake competes with bananas, bagels, boredom, and podcasts. Netflix competes with TikTok, sleep, family conversation, Related in Design
contribute
IncludedLocal-only OSS contribution command center. Auto-refreshes the user's in-flight PR and issue state on invoke so conversations start with full context — no need to brief Claude on what's in flight. Helps the user find issues to contribute to on GitHub, builds per-repo dossiers of what each upstream expects (CLA, DCO, branch convention, AI policy, draft-first, review bots, issue templates), runs deterministic gates before any external action so AI-assisted contributions don't reach maintainers as slop. State is markdown-only: candidate files at ~/.contribute-system/candidates/, repo dossiers at ~/.contribute-system/research/, append-only event log at ~/.contribute-system/log.jsonl. No database, no cloud calls. Use when the user asks about their PRs / issues / contributions, wants to find new work to take on, claim an issue, build/refresh a repo's dossier, or draft a Design Issue or PR. Trigger with "/contribute", "what's my PR status", "find a contribution", "claim issue X", "draft a Design Issue for Y", "refresh dossier for Z".
architectural-analysis
IncludedUser-triggered deep architectural analysis of a codebase or scoped subtree across eight modes — information architecture, data flow, integration points, UI surfaces, interaction patterns, data model, control flow, and failure modes. This skill should be used when the user asks to "diagram this codebase," "map the architecture," "show the data flow," "give me an ERD," "trace control flow," "find the integration points," "verify the layout pattern," "audit the UX architecture," or any similar request whose primary deliverable is mermaid diagrams plus cited reports under docs/architecture/. Dispatches haiku/sonnet sub-agents in parallel for per-mode exploration, then verifies every citation mechanically before any node lands in a diagram. Not for one-off prose explanations of code (use code-explanation) or for high-level system design from scratch (use system-design).
mcp
IncludedModel Context Protocol (MCP) server development and tool management. Languages: Python, TypeScript. Capabilities: build MCP servers, integrate external APIs, discover/execute MCP tools, manage multi-server configs, design agent-centric tools. Actions: create, build, integrate, discover, execute, configure MCP servers/tools. Keywords: MCP, Model Context Protocol, MCP server, MCP tool, stdio transport, SSE transport, tool discovery, resource provider, prompt template, external API integration, Gemini CLI MCP, Claude MCP, agent tools, tool execution, server config. Use when: building MCP servers, integrating external APIs as MCP tools, discovering available MCP tools, executing MCP capabilities, configuring multi-server setups, designing tools for AI agents.
react-native-skia
IncludedDesign, build, debug, and optimise high-polish animated graphics in React Native or Expo using @shopify/react-native-skia, Reanimated, and Gesture Handler. Use when the user wants canvas-driven UI, shaders, paths, rich text, image filters, sprite fields, Skottie, video frames, snapshots, web CanvasKit setup, or performance tuning for custom motion-heavy elements such as loaders, hero art, cards, charts, progress indicators, particle systems, or gesture-driven surfaces. Also use when the user asks for fluid, glow, glass, blob, parallax, 60fps/120fps, or GPU-friendly animated effects in React Native, even if they do not explicitly say "Skia". Do not use for ordinary form/layout work with standard views.
plaid
IncludedProduct Led AI Development — guides founders from idea to launched product. Six capabilities: Idea (discover a product idea), Validate (pressure-test the idea against fatal flaws, problem reality, competition, and 2-week MVP feasibility), Plan (vision intake + document generation), Design (translate image references into a design.md spec), Launch (go-to-market strategy), and Build (roadmap execution). Use when someone says "PLAID", "plaid idea", "help me find an idea", "product idea", "idea from my business", "idea from my expertise", "plaid validate", "validate my idea", "pressure-test", "is this idea good", "find fatal flaws", "validate the problem", "plan a product", "define my vision", "generate a PRD", "product strategy", "plaid design", "design from image", "translate image to design", "create design.md", "extract design tokens", "plaid launch", "go-to-market", "launch plan", "GTM strategy", "launch playbook", "plaid build", "build the app", "start building", or "execute the roadmap".
nextjs-framer-motion-animations
IncludedAdds production-safe Motion for React or Framer Motion animations to Next.js apps, including reveal, hover and tap micro-interactions, whileInView, stagger, AnimatePresence, layout and layoutId transitions, reorder, scroll-linked UI, and lightweight route-content transitions. Use when the user asks to add, refactor, or debug Motion or Framer Motion in App Router or Pages Router codebases, especially around server/client boundaries, reduced motion, LazyMotion, bundle size, hydration, or route transitions. Avoid for GSAP-style timelines, WebGL or 3D scenes, heavy scroll storytelling, or CSS-only effects unless Motion is explicitly requested.