# Jtbd Outcome Engineer

> Formulate, audit, or rewrite solution-free Desired Outcome Statements for a specific step in a JTBD Universal Job Map. Use when asked to extract customer performance metrics, remove solution or feature bias from outcome statements, deduplicate outcome metrics, structure customer success criteria for Outcome-Driven Innovation (ODI) research, or prepare desired outcomes for a job-map step.

- **Type:** Skill
- **Install:** `agentstack add skill-lishix520-jtbd-skills-jtbd-outcome-engineer`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [lishix520](https://agentstack.voostack.com/s/lishix520)
- **Installs:** 0
- **Category:** [Data & Analytics](https://agentstack.voostack.com/c/data-and-analytics)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [lishix520](https://github.com/lishix520)
- **Source:** https://github.com/lishix520/jtbd-skills/tree/main/skills/jtbd-outcome-engineer

## Install

```sh
agentstack add skill-lishix520-jtbd-skills-jtbd-outcome-engineer
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# JTBD Desired Outcome Engineer

Formulate how a job executor measures success when executing a specific step in a Universal Job Map.

A Desired Outcome Statement defines a customer's metric of value and performance. It does not describe a product feature, technology capability, job map step, emotional aspiration, or commercial goal.

## Scope

Input must include:
- A Core Functional Job statement
- A job executor, confirmed or explicitly marked as a hypothesis
- A specific `job_map_step` (Category and Statement)

Output:
- A set of formulaic Desired Outcome Statements linked to the target `job_map_step`
- Evidence, status, and classification for each statement
- Identification of solution-contaminated, outcome-compound, or invalid candidate metrics
- Smallest next research question required for empirical validation

Do not:
- Redefine the Core Functional Job or rewrite the input `job_map_step`
- Generate outcomes without an explicit `job_map_step` input
- Include products, features, technologies, channels, or implementation methods in outcome statements
- Calculate Importance, Satisfaction, or Opportunity Scores
- Design survey rating scales or market segmentation strategy
- Fabricate customer research scores or claim unverified statements are customer-validated facts

## Formulaic Syntax Rules

Every valid Desired Outcome Statement MUST follow this structure:

$$\text{Desired Outcome} = \text{Direction} + \text{Performance Metric} + \text{Measurement Target} + [\text{Optional Contextual Clarifier}]$$

1. **Direction**: Must be `Minimize` (preferred for 95%+ of ODI metrics: time, likelihood of error, effort, cost) or `Maximize` (when increasing output/yield without trade-offs).
2. **Performance Metric**: The unit of measurement (e.g., `the time it takes to...`, `the likelihood of...`, `the effort required to...`, `the cost required to...`).
3. **Measurement Target**: The specific action, object, event, state, or result whose performance is being measured during the job-map step.
4. **Optional Contextual Clarifier**: Added ONLY to specify the condition under which the outcome is desired.

## Classification Distinctions

Classify each candidate metric before finalizing:

| Type | Definition | Example |
|---|---|---|
| Desired Outcome | A valid solution-free performance metric for the step | *Minimize the likelihood of omitting required status information* |
| Solution / Feature | A product capability, technology, or interface tool | *Fast Jira export button* |
| Compound Outcome | Multiple metrics combined in a single statement | *Minimize time and likelihood of error* |
| Vague Metric | Abstract likelihood target or non-formulaic quality buzzword | *Minimize the likelihood of error during verification* |
| Job Map Step | A functional action rather than a performance metric | *Verify completeness of information* |
| Emotional / Social Outcome | Internal psychological feeling or social status | *Maximize feeling of confidence* |
| Business / Vendor Metric | Internal company revenue or operational goal | *Maximize subscription renewals* |

## Procedure

1. Validate that `core_functional_job`, `job_executor`, and `job_map_step` are provided. If missing, return `insufficient_input`.
2. Extract direct customer statements or domain rationale related to the step.
3. Label candidate metrics using the classification distinctions.
4. Filter out solutions, feature requests, compound metrics, vague metrics, and emotional goals.
5. Format valid metrics into formulaic Desired Outcome Statements (`Direction + Metric + Target + Clarifier`).
6. Audit each outcome using the Validation Checklist.
7. Return the structured output with `status: hypothesis` (unless direct research evidence is attached).

## Validation Checklist

Reject, remove, or rewrite any outcome statement that:

- Names a brand, product, software, feature, technology, interface, or channel
- Uses vague buzzwords such as fast, easy, seamless, reliable, convenient, or user-friendly instead of a formulaic metric
- Uses abstract likelihood targets (e.g., "error", "inaccuracy", "failure") without naming a concrete undesired event
- Combines multiple metrics (e.g., combining time AND likelihood in one statement)
- Describes a job step (action) rather than a performance metric (result)
- Describes an emotional state (confidence, pride) or social perception
- Describes vendor profit, sales, or business goals
- Lacks a link to a specific `job_map_step`

## Output Format

```yaml
job_context:
  core_functional_job: ""
  job_executor: ""
  job_map_step:
    category: define | locate | prepare | confirm | execute | monitor | modify | conclude
    statement: ""

outcomes_status: provisional | evidence_supported | insufficient_input

desired_outcomes:
  - statement: ""
    direction: minimize | maximize
    metric_type: time | likelihood | effort | cost | output
    measurement_target: ""
    contextual_clarifier: ""
    status: hypothesis | evidence_supported
    basis: direct_evidence | domain_rationale | explicit_request
    evidence: []
    assumptions: []

excluded_items:
  - statement: ""
    classification: solution | compound_outcome | vague_metric | job_step | emotional_social | vendor_metric
    reason: ""

evidence_gaps: []
next_research_question: ""
```

## Reference Materials

Read `references/outcome-statement-rules.md` before:
- Formatting complex desired outcome statements
- Auditing candidate customer metrics for solution contamination
- Deciding whether to use `time` vs `likelihood`
- Splitting compound outcome statements

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [lishix520](https://github.com/lishix520)
- **Source:** [lishix520/jtbd-skills](https://github.com/lishix520/jtbd-skills)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-lishix520-jtbd-skills-jtbd-outcome-engineer
- Seller: https://agentstack.voostack.com/s/lishix520
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.