When to Use MOMENTUM

This page helps you decide if MOMENTUM is a good fit for your situation – or if it's overkill.

This Methodology Is a Good Fit If...

You're Building a Real Product (Not a Prototype)

Indicator: You plan to iterate on this for months or years, and you care about long-term coherence.

Why: MOMENTUM's value compounds over time. The more you ship, the more your strategy history matters. Early-stage one-off features? Not a good fit. A sustainable product direction? Perfect.

You Want to Scale PM Work Across a Team

Indicator: Multiple people (or you plus AI) need to understand and act on product direction.

Why: Strategy as versioned source-of-truth makes onboarding trivial. New PM joins? Read product-strategy.md. Junior PM wants to shape epics? They have a clear spec. AI assistant making suggestions? It has constraints to follow.

You Use AI as a Coding or Thinking Assistant

Indicator: You rely on Claude, ChatGPT, or similar tools to draft docs, generate epics, or spot inconsistencies.

Why: AI works best with explicit constraints. Vague strategy = AI hallucinates. Clear strategy = AI executes your intent.

You Need to Defend Your Decisions

Indicator: You work in a regulated industry, or you have stakeholders who ask "why did we build this?"

Why: Strategy + evidence provide an audit trail. Every feature traces back to a decision. Every decision traces back to research.

You're Doing Discovery or Experimentation

Indicator: You're learning fast and your strategy shifts frequently.

Why: MOMENTUM is designed for rapid learning. You can evolve strategy without getting lost.

You Have a Long-Lived Product with Team Turnover

Indicator: People leave, new people join. You need continuity.

Why: Strategy lives in Git, not in someone's head. When someone leaves, the product's direction doesn't go with them.

This Methodology Is Overkill If...

You're Shipping a Prototype or MVP to Validate Assumptions

Indicator: You have one core hypothesis to test. You're building it in 4 weeks.

Why: The overhead of versioning strategy isn't worth it yet. Move fast, learn, then revisit.

Better approach: Skeleton strategy (maybe just slides), then adopt full framework if it validates.

You're a Solo Founder, Moving Very Fast

Indicator: You're the only person making decisions. You iterate weekly.

Why: You already have strategy in your head. Writing it down costs time. Wait until you hire or need to hand off.

Better approach: Start lightweight (README + notes). Formalize when someone else joins.

Your Product Is a One-Off or Maintenance Mode

Indicator: You maintain existing features; you're not building new direction.

Why: There's no strategy to evolve. You're following requirements, not defining direction.

Better approach: Use a simpler system (ticketing, kanban). Save this framework for products you're actively shaping.

You're Working with Legacy Complexity (20+ Year Platforms or Multi-Product Suites)

Indicator: You have an extensive codebase, complex business logic, unclear domain boundaries, and poor documentation. Or you're maintaining a legacy monolith.

Why: The framework's power comes from compressing strategy and evidence into a clear, coherent picture. With a 20-year-old legacy platform or a multi-product suite (office suite with email, docs, sheets, presentations), there's often too much historical context and intertwined complexity to fit into a single strategy document.

This isn't a limitation of the framework – it's a limitation of information density. Neither a human nor an AI can compress decades of complex business logic and loosely-coupled features into one context file without losing critical nuance.

Better approach: - Multi-repo strategy: If you're maintaining separate products within a suite (e.g., email client, document editor, spreadsheet), give each its own strategy repo. Share governance and decision frameworks, but keep product strategies separate. - Domain-driven approach: Break your platform into explicit domains. Each domain gets its own strategy + evidence. Reference shared constraints and architectural decisions from a top-level "platform strategy." - Reverse-engineer strategically: You can extract strategy + evidence from existing documentation, backlogs, and team interviews, but focus on intent layers you want to preserve going forward, not every historical decision. - Use as a foundation: This framework works well for modernization efforts ("here's what the legacy system does; here's what we're rebuilding") but not for capturing every detail of the existing system.

You're Constrained by Legacy Tools (Jira-Only, No Git Access)

Indicator: Your org requires everything in Jira. You can't create a separate docs repo.

Why: The framework's value relies on artifacts living in Git with versioning and review. If you can't do that, the system loses its backbone.

Better approach: Advocate for Git access. If you can't get it, adapt the concepts to your tools (versioned strategy in Confluence, etc.), but accept lower fidelity.

Your Organization Doesn't Trust Written Strategy

Indicator: Strategy lives in meetings. Decisions are made by whoever spoke last.

Why: The framework assumes you want intentional strategy, reviewable and deliberate. If that's not valued, it won't work.

Better approach: Start with team alignment on "why versioned strategy matters." If that doesn't stick, this framework isn't your bottleneck.

Common Anti-Patterns (What Goes Wrong)

❌ Treating Strategy as a Static Document

Wrong: "We wrote strategy in Q1. It's done. Now we execute."

Right: Strategy is the anchor, but evidence evolves constantly. Re-examine strategy quarterly (or sooner if you learn something big).

Fix: Block calendar time monthly for strategy review: "Is what we're shipping still aligned?"

❌ Writing Epic-Level Detail in Strategy

Wrong: product-strategy.md is 20 pages describing every feature.

Right: Strategy is concise. Epics provide the detail.

Fix: If strategy becomes too long and detailed, move specifics into epics. Strategy should be skimmable in 10 minutes.

❌ Treating Epics as Task Lists

Wrong: Epic: "Build the API," "Design the UI," "Test everything."

Right: Epic: "Users can authenticate without a password," broken into stories that each deliver value.

Fix: Ask: "Is this something a user does, or something we build?" If it's the latter, it's a task, not an epic.

❌ Ignoring Evidence Until It's Too Late

Wrong: Ship a feature. Don't check if it's used. Six months later: "Why do we have this?"

Right: Ship a feature. Check production behavior weekly for the first month. Update evidence.

Fix: Assign someone (PM or analyst) to "watch" each feature for 4 weeks post-launch.

❌ Cascade Changes Without Question

Wrong: "Strategy changed, so all in-flight work stops. Regenerate all epics and stories."

Right: Strategy changed. Review in-flight work. Prioritize what to keep, what to pivot, what to deprecate.

Fix: When strategy changes, hold a decision meeting: "Which in-flight work is still worth finishing?"

❌ Using Framework as a Substitute for Good Judgment

Wrong: "The framework says strategy is the source of truth, so we never listen to users unless it's in production."

Right: Strategy is the source of truth for what you commit to. But listen to users before you ship. Use that to shape strategy.

Fix: Remember: strategy informs execution. Good feedback (even pre-production) also informs strategy updates.

❌ Versioning Strategy for Every Tiny Change

Wrong: PR for every punctuation change. Strategy has 50 commits in one day.

Right: Batch reasonable changes. Major decisions (scope, non-goals, success metrics) get their own commits. Typo fixes: batch with others.

Fix: Commit strategy changes when you've thought about them (not every thought). Typical cadence: 1–2 commits per week.

A Way to Start Small

If you're unsure, begin with this subset:

Write product-strategy.md. Capture problem, users, goals, non-goals, constraints, success metrics.
Write product-evidence.md. Ground your strategy in research, data, and trade-offs explored.
Shape one epic from a key strategy section.
Slice the epic into 3–4 stories. Execute them.
Review: Is this working? Does the framework feel helpful or bureaucratic?

If yes → keep going, add more epics/stories.
If no → adapt it (lighter weight, less structure) or move on.

Questions to Ask Before Adopting

Is strategy important to this product, or is it "just execute the brief"?
If important: framework is worth it.
If just execution: simpler system is fine.
Will we ship more than one version of this product?
If yes: framework helps you not drift.
If no: lighter approach is fine.
Do we have or plan to have multiple people working on product strategy?
If yes: framework creates clarity and review.
If no: less critical (but still helpful for onboarding later).
Do we need to justify our choices to stakeholders?
If yes: strategy + evidence in Git is powerful.
If no: informal notes might be enough.
Are we comfortable with "strategy anchors execution" as a mental model?
If yes: framework matches your thinking.
If no: you might prefer a more fluid approach.

Summary: Is This for You?

Adopt fully if: You're building a sustained product, you care about strategy clarity, you work with others (human or AI), and you have Git access.

Start light if: You're early-stage but want structure; adopt gradually.

Skip it if: You're prototyping, you're solo and moving fast, or your org doesn't support versioned docs.

The framework is a tool. Use it if it makes you faster and clearer. Otherwise, adapt it or use something else.