Skip to content

Workflows: How to Use MOMENTUM Day-to-Day

This page explains the actual workflow of using MOMENTUM to evolve your product.

The Core Loop

The MOMENTUM methodology works in a simple cycle:

  1. Define or refine strategy (strategy + evidence are SSOT)
  2. Shape epics from strategy (strategic outcomes → executable capabilities)
  3. Slice epics into stories (capabilities → testable increments)
  4. Execute stories (implement, test, deploy)
  5. Gather production feedback (real behavior informs evidence)
  6. Update strategy if justified (production behavior grounds strategy)
  7. Cascade changes (if strategy changed, regenerate epics and stories)

This is not a strict waterfall. Steps 2–4 overlap, and feedback flows continuously. But the key insight is: strategy anchors the cycle. Feedback updates strategy. Strategy cascades downward.

graph TB
    A["1. Define or refine<br/>strategy"] --> B["2. Shape epics<br/>from strategy"]
    B --> C["3. Slice epics<br/>into stories"]
    C --> D["4. Execute<br/>stories"]
    D --> E["5. Gather production<br/>feedback"]
    E --> F["6. Update strategy<br/>if justified"]
    F --> G["7. Cascade<br/>changes"]
    G -.->|Loop back| A

    style A fill:#e8f5e9
    style F fill:#fff3e0
    style G fill:#e1f5ff

Note on meetings and feedback:
Throughout this loop, meetings, design reviews, and user feedback inform evidence. See Meeting Notes & Strategy Updates for how to capture decisions and cascade them back into strategy and epics.

Phase 1: Strategy & Evidence

Starting State

You have:

  • A clear problem you're trying to solve
  • Some understanding of who your users are
  • Initial hypotheses about what will help

What You Do

Write product-strategy.md:

  • Problem: What is the user's pain?
  • Goals: What outcomes matter?
  • Scope: What are we building?
  • Non-goals: What are we explicitly not solving?
  • Constraints: Budget, timeline, technical limits, team capacity?
  • Success metrics: How do we know if this worked?

Keep it concise. This is a spec, not a novel.

Write or grow product-evidence.md:

  • Research: What did users tell you?
  • Data: What do current metrics say?
  • Experiments: What have you tested?
  • Trade-offs: What did you consider and reject, and why?

Build this as you learn. It's a living document that justifies strategy decisions.

Key Principle

Strategy doesn't need to be perfect. It needs to be explicit enough that someone else can execute from it without guessing about your intent.

If you're uncertain about something, that's fine – write it down as an open question or assumption.

Phase 2: Shape Epics from Strategy

Starting Point

You have a strategy document that describes several major capabilities or outcomes.

What You Do

For each major strategic outcome (e.g., "enable passwordless authentication"), create an epic:

  1. Problem & Context – Why does this capability matter? (Reference the strategy and evidence.)
  2. Functional Scope – What specific user flows does this include? (Be concrete. "Users can log in using their face" vs. vague "biometric auth".)
  3. Out of Scope – What won't this epic cover? (E.g., "We won't support fingerprint or voice.")
  4. UX & Edge Cases – How should the system behave in error states? What about users without biometric hardware?
  5. Risks & Open Questions – What might go wrong? What do we need to learn?

File it as: /delivery/epic-001-passwordless-auth/epic-001-passwordless-auth.md

Key Principle

Epics are bridges between strategy and execution. They're detailed enough that engineers can build from them, but focused enough that they stay aligned to strategy.

If an epic is hundreds of lines, it's probably more than one epic.

Phase 3: Slice Epics into Stories

Starting Point

You have an epic describing a major capability.

What You Do

Break the epic into 5–8 vertical slices (stories). Each story:

  1. User Story – As a [user type], I want to [capability], So that [value].
  2. Acceptance Criteria – Concrete, testable conditions.
  3. Example: "Given a user with a registered biometric, When they tap the login button, Then the system prompts for biometric verification."
  4. UX Notes – Edge cases, error states, empty states. (Optional but useful.)
  5. Dependencies – Other stories or systems this depends on.
  6. Status – Draft / Ready / In Development / Implemented.

File each as: /delivery/epic-001-passwordless-auth/story-ep001-001.md, /delivery/epic-001-passwordless-auth/story-ep001-002.md, etc.

Vertical Slices, Not Horizontal Layers

❌ Bad: "Build the backend API," "Build the UI," "Write tests."
✓ Good: "User can enroll biometric," "User can log in with biometric," "User can fall back to password if biometric fails."

Each story should deliver some end-to-end value, even if partial.

Key Principle

A story is small enough that one person (or one pair) can implement, test, and ship it in a day or two. If it takes longer, slice further.

Phase 4: Execute

The Loop

  1. Pick a story (or a few) from the prioritized backlog.
  2. Implement, test, deploy (your usual development workflow).
  3. Once shipped to production, gather real user behavior.

Validating vs. Evolving Strategy

A crucial distinction in MOMENTUM is the difference between validating strategy before you build and evolving strategy after you ship.

  • Validation (Pre-production): Feedback from prototypes, user research, and staging experiments is vital. If a prototype receives terrible feedback, that's a strong signal to reconsider the strategy before committing to production. This feedback helps validate or invalidate your hypotheses.

  • Evolution (Post-production): Once a feature is shipped, its real-world performance becomes the definitive evidence. The goal is to use structured feedback from production (e.g., analytics, user behavior, PRs) to formally evolve the strategy SSOT and prevent drift. This is the primary mechanism for changing the canonical strategy over time.

Phase 5: Production Feedback

Interpreting Feedback Signals

Different types of feedback have different weights.

  • Strongest Signal (for evolving strategy): Production data, such as metrics, actual user behavior, and support ticket patterns. This is the source of truth for how the product performs in the wild.
  • Medium Signal (for validating strategy): Direct user feedback on prototypes and staging experiments. This is critical for course-correction before a feature is locked in. If 5 users in a test hate a feature, that's important data.
  • Weakest Signal: Internal opinions and ideas not grounded in data or user research. Use these to form hypotheses to be tested, not to drive strategy directly.

Document It

Add your findings to product-evidence.md. Be factual:

  • "Feature X had 30% adoption in the first week."
  • "Users reported confusion with the error message (5 support tickets)."
  • "We discovered that 80% of users logged in from mobile."

Phase 6: Update Strategy (If Justified)

The Decision

Based on production feedback, ask:

Does this change our strategy?

  • No – File it as a learnings note in evidence. Continue.
  • Yes – Update product-strategy.md with the new insight.

When Strategy Changes

If you update strategy (e.g., "We thought 80% of users would use passwordless auth; actually it's 20%"), then:

  1. Record why – What evidence changed your thinking?
  2. Update the strategy doc (commit with clear message).
  3. Cascade changes – Regenerate affected epics and stories.
  4. Communicate – Let the team know the direction shifted.

Key Principle

Strategy changes deliberately. It should not change on a whim, but based on meaningful patterns from feedback, whether from pre-production validation or post-production performance.

Phase 7: Cascade & Refine

If Strategy Doesn't Change

  • Keep executing stories from the current backlog.
  • Add new stories as you discover them.
  • Epics remain stable.

If Strategy Changes

  • Review in-progress and planned epics.
  • Update epics to align with new strategy.
  • Adjust story priorities.
  • Archive or deprecate stories that no longer fit.

Refinement Over Time

As you learn:

  • You might discover that an "in-scope" capability is actually a "non-goal."
  • You might refine success metrics.
  • You might add new constraints (e.g., "We must support offline mode").

Each of these becomes a strategy update, traceable in Git history.

Continuous Activities (Happen in Parallel)

Keep Evidence Fresh

As features ship and real behavior emerges, continuously update product-evidence.md:

  • "Feature X launched on date Y. Early adoption: Z%."
  • "User research with 10 power users revealed X insight."
  • "We deprecated feature Y because usage was negligible."

Maintain Clarity

Every month or quarter, ask:

  • Does the strategy still make sense?
  • Are we executing on it, or have we drifted?
  • What have we learned that should update our assumptions?

Make sure stories reference their parent epic, which references strategy sections. This traceability is your hedge against scope creep and intent decay.

Example Scenario

Assuming a feature (passwordless login with biometric) enters the workflow:

Initial phase: Write strategy articulating the capability. Create epic describing user flows, constraints, edge cases, and risks.

Execution phase: Slice epic into 5–8 stories, each delivering end-to-end value. Execute them (implementation and testing timeline depends on team capacity).

Production phase: Once shipped, gather real user behavior. Add findings to evidence.

Decision phase: Based on production data, ask: "Does this change our strategy?" If production behavior contradicts assumptions, update strategy. If aligned, continue to next work.

Cascade phase: If strategy updates, regenerate affected epics and stories to align.

The actual duration of each phase depends on your team, product complexity, and learning velocity. Do not impose artificial timelines.

Common Questions

Q: What if we're mid-sprint when strategy changes?
A: Finish in-flight work. Reprioritize next work based on new strategy. Don't churn mid-stream unless the change is critical.

Q: Who decides if strategy should change?
A: You (PM), in consultation with leadership and evidence. It's not a committee vote – it's a decision informed by data.

Q: How often should we revisit strategy?
A: At least quarterly. More often (monthly) if you're early-stage and learning fast.

Q: What if epics become outdated while we're building stories?
A: Update the epic. Add a note explaining what changed and why. Treat it like any other doc update – PR, review, commit.