Breaking Down Work

This guide explains how to approach new work using Epilogue Tracker's user-centric methodology.

The Three Questions

Before starting any work, ask:

1. Which user (actor) benefits from this?
2. What goal of theirs does this support?
3. What interaction describes how this helps them?

If you can't answer these questions, either find the user need or seriously consider not doing the work.

Step-by-Step Process

1. Identify the User Need

When you receive a task like "add caching to the API", don't start coding. First, ask why:

• Why do we need caching? → API responses are slow
• Why does that matter? → Users wait too long
• Which users? → Customers browsing products

Now you have:

• Actor: Customer
• Problem: Waiting too long

2. Create or Find the Goal

Check if a relevant goal exists:

et list goals --actor customer

If not, create one:

et create goal \
  --id "fast_browsing" \
  --description "Browse products without delays or waiting" \
  --actor "customer" \
  --success-criteria "Page loads under 2 seconds"

3. Create the Interaction

Now document the work as an interaction:

et create interaction \
  --id "api_response_caching" \
  --description "Fast API responses through intelligent caching" \
  --performed-by "customer" \
  --goal "fast_browsing"

4. Do the Work

Now implement the caching, knowing exactly:

• Who benefits (customer)
• What they get (fast browsing)
• How to measure success (page loads under 2 seconds)

5. Validate

After completing work, validate the model:

et validate

Example: Feature Request

Request: "Add dark mode to the app"

Bad Approach

# Jump straight to implementation as a task
# No user context, no success criteria

Good Approach

Step 1: Who wants this?

• Users who work at night or prefer dark interfaces

Step 2: Create/find goal

et create goal \
  --id "comfortable_viewing" \
  --description "Use the app comfortably in any lighting condition" \
  --actor "customer" \
  --success-criteria "Can switch between light and dark themes, preference is saved"

Step 3: Create interaction

et create interaction \
  --id "theme_switching" \
  --description "Toggle between light and dark themes" \
  --performed-by "customer" \
  --goal "comfortable_viewing"

Example: Bug Fix

Bug: "Login fails intermittently"

Bad Approach

# Fix the bug without documenting user impact

Good Approach

Step 1: Which goal is affected?

et list goals --actor customer | grep -i login

Or create if missing:

et create goal \
  --id "reliable_access" \
  --description "Access my account reliably whenever I need to" \
  --actor "customer" \
  --success-criteria "Login succeeds 100% of the time"

Step 2: Document the fix as interaction

et create interaction \
  --id "login_reliability_fix" \
  --description "Reliable login without intermittent failures" \
  --performed-by "customer" \
  --goal "reliable_access"

Example: Technical Debt

Task: "Refactor the order processing module"

Challenge the Work

Ask: Why refactor?

• Current code is hard to maintain → That's a developer problem, not a user problem
• Hard to add new payment methods → Users want payment options!
• Prone to bugs → Users want reliable ordering!

Find the User Goals

et create goal \
  --id "flexible_payment" \
  --description "Pay using my preferred payment method" \
  --actor "customer"

et create goal \
  --id "reliable_ordering" \
  --description "Complete orders without errors or failures" \
  --actor "customer"

Document the Work

et create interaction \
  --id "payment_flexibility" \
  --description "Support for multiple payment methods" \
  --performed-by "customer" \
  --goal "flexible_payment"

et create interaction \
  --id "order_reliability" \
  --description "Robust order processing without failures" \
  --performed-by "customer" \
  --goal "reliable_ordering"

When Work Isn't Justified

Sometimes you can't find a user goal. This is valuable information:

• Internal tooling? Your users might be developers or ops teams.
• Pure tech debt? Should probably wait until it blocks user value.
• "Nice to have"? If no user needs it, maybe skip it.

The discipline of connecting work to user goals prevents building things nobody asked for.

Quick Reference

# Before starting work:
et list actors                      # Who are our users?
et list goals --actor <id>          # What do they want?
et list interactions --goal <id>    # What supports this goal?

# Document the work:
et create goal --id ... --actor ... --description ...
et create interaction --id ... --goal ... --description ...

# Verify:
et validate

Next Steps

• Validation: Keep your model healthy
• CLI Reference: Full command documentation