expectation-mapper

Expectation Mapper

The theoretical engine of Tim's practice. Takes any engagement context — a JTBD analysis, a call transcript, a client relationship — and maps the full expectation landscape. Every plugin (Strategist, Speechwriter, Instructinator) uses this framework, but this skill runs it explicitly and produces a standalone deliverable.

Why This Exists

Tim's core thesis: Emotion = Experience ± Expectations. You can design the perfect experience and still fail if expectations are misaligned. Most practitioners try to improve the experience. Tim's edge is managing expectations — the cheaper, faster, more durable lever.

This skill makes that thesis operational. It answers three questions:

1. What expectations exist right now? (Origins)
2. How are they behaving? (Dynamics)
3. What should Tim do about them? (Architecture)

The Framework: Expectation Architecture

Three layers. Each builds on the previous.

Layer 1: Expectation Origins — Where expectations come from

Every expectation has a source. The source determines how visible, stable, and manageable it is.

ORIGIN TYPE     | DEFINITION                                      | VISIBILITY | STABILITY
────────────────|─────────────────────────────────────────────────|────────────|──────────
DECLARED        | Explicitly stated by either party.              | HIGH       | HIGH
                | "We'll deliver a prioritized action plan."      |            |
                | "I need benchmarks for my board."               |            |
────────────────|─────────────────────────────────────────────────|────────────|──────────
TRANSFERRED     | Carried from past experiences with other        | MEDIUM     | HIGH
                | vendors, consultants, or internal projects.     |            |
                | "Last consultant gave us a 40-page report."     |            |
                | "Our last tech partner ghosted after delivery." |            |
────────────────|─────────────────────────────────────────────────|────────────|──────────
INFERRED        | Created by Tim's signals — pricing, language,   | LOW        | MEDIUM
                | branding, how he shows up. Tim didn't say it,  |            |
                | but his behavior implied it.                    |            |
                | Premium price → premium deliverable expected.   |            |
                | "Digital Guidance" → they expect to be guided.  |            |
────────────────|─────────────────────────────────────────────────|────────────|──────────
DEFAULT         | What fills the vacuum when nothing is stated.   | INVISIBLE  | LOW
                | These are the most dangerous because nobody     |            |
                | knows they exist until they're violated.        |            |
                | "I assumed we'd get a follow-up email."         |            |
                | "I thought you'd handle that."                  |            |
────────────────|─────────────────────────────────────────────────|────────────|──────────
SOCIAL          | Set by third parties — referrals, industry      | VARIABLE   | MEDIUM
                | norms, board members, team members not in       |            |
                | the room.                                       |            |
                | "Nettie said you'd change how we think."        |            |
                | "Our board wants ROI metrics."                  |            |

JTBD-to-Origins Mapping: When a JTBD analysis is available, map components directly:

JTBD COMPONENT    | MAPS TO ORIGIN  | REASONING
──────────────────|─────────────────|──────────────────────────────────────
Pull of new       | DECLARED        | What they explicitly want from Tim
Push of current   | TRANSFERRED     | Pain from past experiences shapes
                  |                 | what they expect to be different
Anxiety of change | UNMANAGED       | Fears about what could go wrong —
                  |                 | these become invisible expectations
                  |                 | Tim must surface and address
Habit of present  | DEFAULT         | Current baseline they'll compare
                  |                 | everything against, whether or not
                  |                 | they state it
Desired outcome   | DECLARED        | Success criteria (but often vague
                  |                 | — need to be made specific)
Social job        | SOCIAL          | How stakeholders want to be
                  |                 | perceived — sets expectations for
                  |                 | what Tim's work must enable

Layer 2: Expectation Dynamics — How expectations behave

Expectations aren't static. They move, compound, and decay. Five dynamics to track:

DYNAMIC         | WHAT IT MEANS                                   | RISK SIGNAL
────────────────|─────────────────────────────────────────────────|──────────────────
ASYMMETRY       | Negative expectation violations hurt 2x more   | Client mentions
                | than positive ones help. Losing $100 feels     | a past bad
                | worse than gaining $100 feels good.             | experience
                | (Kahneman, 1979)                                |
────────────────|─────────────────────────────────────────────────|──────────────────
ANCHORING       | First impressions set the reference point.      | Sales/diagnostic
                | Everything after is judged relative to the      | created a specific
                | anchor. If Tim over-promises in sales, every    | promise or
                | session after is measured against that peak.    | impression
────────────────|─────────────────────────────────────────────────|──────────────────
PEAK-END        | People remember the most intense moment and     | How will the
WEIGHT          | the final moment. Everything in the middle      | engagement end?
                | fades. (Kahneman et al., 1993)                  | What's the peak?
────────────────|─────────────────────────────────────────────────|──────────────────
COMPOUNDING     | Expectations cascade across stakeholders.       | Multiple decision-
                | Rob tells his board, the board tells donors,    | makers with
                | donors tell partners. Each retelling shifts     | different contexts
                | the expectation.                                |
────────────────|─────────────────────────────────────────────────|──────────────────
DECAY           | Expectations erode without reinforcement.       | Long gaps between
                | Post-session clarity fades in 72 hours.         | sessions. No
                | After 2 weeks, they remember the feeling,       | written artifacts.
                | not the specifics.                              | Verbal-only work.

Layer 3: Expectation Architecture — What to do about it

Five operations Tim can perform on expectations:

OPERATION     | WHAT TIM DOES                                     | WHEN TO USE
──────────────|───────────────────────────────────────────────────|────────────────
AUDIT         | Discover what expectations exist, especially      | Start of any
              | invisible ones. Ask directly. Listen for signals. | engagement.
              | "What does success look like to you?"             | Before any major
              | "What are you most worried won't happen?"         | session.
──────────────|───────────────────────────────────────────────────|────────────────
DECLARE       | Make implicit expectations explicit. State what   | After discovery.
              | WILL happen, what WON'T, and what's uncertain.   | In proposals/SOWs.
              | "Here's what you'll have after this session."     | Session openers.
              | "This is what I'm NOT going to do."              |
──────────────|───────────────────────────────────────────────────|────────────────
INOCULATE     | Preemptively address transferred expectations     | When you detect
              | that don't apply. Name the past experience.       | transferred
              | "You've probably worked with consultants who      | expectations from
              | gave you a binder and disappeared. That's not     | past experiences.
              | how this works. Here's what IS."                  |
──────────────|───────────────────────────────────────────────────|────────────────
MONITOR       | Check alignment during the engagement. Look for   | Every session.
              | drift signals: confusion, disengagement, the      | Between sessions
              | wrong questions, silence.                         | via follow-up.
              | "Does this match what you expected?"              |
──────────────|───────────────────────────────────────────────────|────────────────
REDIRECT      | Correct a drifting expectation before it becomes  | When monitoring
              | a violated one. Easier than repairing damage.     | detects drift.
              | "I want to adjust what we're aiming for here."    | Before scope
              | "Let me recalibrate what the next session will    | creep hardens.
              | deliver."                                         |

Input Types

This skill accepts any of the following:

• JTBD analysis — Richest source. Maps directly to origins.
• Call transcript — Extract expectations from what was said and implied.
• Client relationship summary — Engagement history, touchpoints, artifacts delivered.
• Proposal or SOW — What was declared vs. what was left ambiguous.
• Pre-session context — "I'm meeting with [X] tomorrow, here's what I know."
• Post-session debrief — "Here's what happened, map what I think their expectations are now."

Output: The Expectation Map

EXPECTATION MAP: [Client/Audience] — [Date/Context]
════════════════════════════════════════════════════

LAYER 1: ORIGINS — What expectations exist?
───────────────────────────────────────────────────────────────────
ORIGIN      | EXPECTATION                          | HOLDER    | EVIDENCE
────────────|──────────────────────────────────────|───────────|──────────────
DECLARED    | [Explicit expectation]               | [Who]     | [Quote/source]
DECLARED    | [Explicit expectation]               | [Who]     | [Quote/source]
TRANSFERRED | [Carried from past experience]       | [Who]     | [Quote/signal]
INFERRED    | [Created by Tim's signals]           | [Who]     | [What signal]
DEFAULT     | [Invisible baseline assumption]      | [Who]     | [Why suspected]
SOCIAL      | [Set by third party]                 | [Who]     | [Who set it]

UNMANAGED EXPECTATIONS (highest risk):
[List any expectation not yet addressed — these are ticking clocks]


LAYER 2: DYNAMICS — How are expectations behaving?
───────────────────────────────────────────────────────────────────
DYNAMIC        | STATUS       | EVIDENCE                    | RISK LEVEL
───────────────|──────────────|─────────────────────────────|──────────
ASYMMETRY      | [Active/None]| [Past bad experience?]      | [H/M/L]
ANCHORING      | [Active/None]| [What's the anchor?]        | [H/M/L]
PEAK-END       | [Managed?]   | [Is peak designed? ending?] | [H/M/L]
COMPOUNDING    | [Active/None]| [Who else is in the chain?] | [H/M/L]
DECAY          | [Active/None]| [Time gap? No artifacts?]   | [H/M/L]


LAYER 3: ARCHITECTURE — What should Tim do?
───────────────────────────────────────────────────────────────────
OPERATION   | ACTION                                    | PRIORITY | WHEN
────────────|───────────────────────────────────────────|──────────|──────────
AUDIT       | [What expectations still need discovery?] | [1-5]   | [Timing]
DECLARE     | [What should Tim explicitly state?]       | [1-5]   | [Timing]
INOCULATE   | [What transferred exp. needs addressing?] | [1-5]   | [Timing]
MONITOR     | [What check should happen at next touch?] | [1-5]   | [Timing]
REDIRECT    | [What's drifting and needs correction?]   | [1-5]   | [Timing]


EXPECTATION MATH: [Client]
──────────────────────────
Emotion = Experience ± Expectations

CURRENT STATE:
Experience Tim is delivering:    [Description]
Expectations client is holding:  [Description]
Predicted emotional outcome:     [Positive/Negative/Neutral — and why]

IF UNMANAGED EXPECTATIONS PERSIST:
[What happens if nothing changes — the risk scenario]

IF EXPECTATIONS ARE ARCHITECTED:
[What happens if Tim runs the architecture operations — the upside]

How This Skill Connects to Plugins

Strategist Plugin

• strategy-audit uses Layer 1 (Origins) to determine if Tim is meeting or missing expectations
• strategy-architect uses Layer 3 (Architecture) to build deliverables that close expectation gaps
• strategy-evaluate uses all three layers to assess post-delivery expectation alignment

Speechwriter Plugin

• speech-design uses Layer 2 (Peak-End Weight) to design emotional arc and close
• speech-audit uses Layer 1 to check if the talk addresses what the audience expects
• speech-evaluate uses Layer 2 (Decay) to assess whether the talk's impact will persist

Instructinator Plugin

• session-architect uses Layer 1 (Declared + Default) to design learning outcomes that match participant expectations
• engagement-check uses Layer 2 (Peak-End) to ensure interaction peaks are well-placed
• dry-run-coach uses Layer 3 (Monitor) to coach Tim on checking alignment during delivery

Mode Router

• mode-router uses this skill's output to determine if the ENGAGEMENT expectations align with the MODE Tim is about to deliver in. Misalignment between engagement expectations and delivery mode is the #1 risk signal.

Running This Skill From JTBD Data

When a JTBD analysis is available, the mapping is direct. Here's the extraction sequence:

1. Pull section → DECLARED expectations (what they want from Tim)
2. Push section → TRANSFERRED expectations (what was bad before, so they expect different)
3. Anxiety section → UNMANAGED expectations (fears that become invisible standards)
4. Habit section → DEFAULT expectations (current baseline everything gets compared to)
5. Desired Outcome → DECLARED expectations (success criteria, often vague)
6. Social Job → SOCIAL expectations (how stakeholders need to be perceived)
7. Messaging Gold → Language for DECLARE and INOCULATE operations
8. Obstacles → Expectations that need AUDIT (still unclear) or REDIRECT (already drifting)

Theoretical Lineage

This framework synthesizes from established research to fill a gap none of them address:

• Oliver (1980) — Expectation Disconfirmation Theory: expectations as reference point for satisfaction. We use: the core equation (outcome vs. expectation).
• Kahneman (1979) — Prospect Theory: loss aversion, reference dependence. We use: Asymmetry dynamic (negative violations hurt 2x).
• Parasuraman, Zeithaml, Berry (1985/1991) — SERVQUAL, Zone of Tolerance: adequate vs. desired service levels. We use: the concept that expectations have a range, not a point.
• Zeithaml, Berry, Parasuraman (1993) — Antecedents of Expectations: explicit promises, implicit promises, word-of-mouth, past experience. We use: Origins layer (but expanded and renamed for operational use).
• Kahneman et al. (1993) — Peak-End Rule: memory of experiences dominated by peak and end. We use: Peak-End Weight dynamic.
• Vroom (1964) — Expectancy Theory: effort → performance → outcome chain. We use: the insight that expectations govern motivation to engage.

The gap this framework fills: None of the above provide a practitioner-level system for proactively designing and managing expectations in a service relationship. They describe what expectations do. This framework tells Tim what to do about them.

Triggers

• "map expectations"
• "expectation audit"
• "what do they expect"
• "expectation map"
• "map the expectations"
• "what are the risks" (when context is client relationship)
• "what am I missing" (when context is client delivery)

What This Skill Does NOT Do

• Design deliverables (use strategy-architect)
• Detect mode drift in real time (use strategy-audit)
• Design talks or training sessions (use speech-design or session-architect)
• Replace JTBD analysis (use jtbd-analysis to discover expectations first, then feed to this skill)
• Make content decisions — this skill is about expectations, not content