Small Jumps Decomposition

Small Jumps Decomposition

Break large, intimidating problems into sequences of smaller, tractable steps. Based on Shannon's observation that "it seems to be much easier to make two small jumps than one big jump in any kind of mental thinking."

When to Use

• A problem feels overwhelming or impossible
• User doesn't know where to start
• Direct solution attempts have failed
• Complex multi-step project needs planning
• Learning something that seems too difficult
• Any "I can't do this" situation

Inputs

The Decomposition Process

Step 1: Define the Endpoints

Clearly state:

• Current state: Where are you now? What do you have, know, or control?
• Desired state: Where do you need to be? What does success look like?
• The gap: What's the distance between them?

Step 2: Identify Why It Feels Like a Big Jump

Ask:

• What makes this seem impossible to do directly?
• What knowledge or capability is missing?
• What uncertainty exists?
• Where does the complexity come from?

Step 3: Find Intermediate States

Ask: "What would be a step closer to the goal that I could definitely reach?"

Look for:

• Partial solutions
• Simplified versions
• Components that can be solved independently
• Checkpoints where progress can be verified

Step 4: Chain the Small Jumps

Connect intermediate states from current to desired:

• Each jump should be tractable (you know how to make it)
• Each jump should be verifiable (you know when you've made it)
• The chain should be complete (last jump reaches the goal)

Step 5: Make the First Jump

Identify the very first small jump and make it. Then the next. Progress builds confidence and reveals the path.

Workflow

Step 1: Gather and Review Inputs

Collect all relevant information:

• Review the provided data and context
• Identify key parameters and constraints
• Clarify any ambiguities or missing information
• Establish success criteria

Step 2: Analyze the Situation

Perform systematic analysis:

• Identify patterns and relationships
• Evaluate against established frameworks
• Consider multiple perspectives
• Document key findings

Step 3: Generate Recommendations

Create actionable outputs:

• Synthesize insights from analysis
• Prioritize recommendations by impact
• Ensure recommendations are specific and measurable
• Consider implementation feasibility

Output Format

## Small Jumps Decomposition

### The Big Jump
**From:** [current state]
**To:** [desired state]
**Why it feels big:** [what makes direct approach hard]

### Intermediate States
| State | Description | How to Verify |
|-------|-------------|---------------|
| S0 | [current state] | [already here] |
| S1 | [first intermediate] | [how to know you're here] |
| S2 | [second intermediate] | [how to know you're here] |
| ... | ... | ... |
| Sn | [desired state] | [success criteria] |

### The Small Jumps
1. **S0 → S1:** [what to do, why it's tractable]
2. **S1 → S2:** [what to do, why it's tractable]
3. ...

### First Jump to Make Now
[Specific, concrete action to take immediately]

### Verification Plan
[How to check progress at each stage]

Decomposition Strategies

Functional Decomposition

Break by what different parts DO:

• "This system needs to read, process, and output"
• Solve each function separately

Sequential Decomposition

Break by order of operations:

• "First X happens, then Y, then Z"
• Solve in order

Component Decomposition

Break by parts:

• "This has a frontend, backend, and database"
• Solve each component

Difficulty Decomposition

Break by complexity level:

• "Let me solve the simple case first"
• Progressively add complexity

Knowledge Decomposition

Break by what you need to learn:

• "I need to understand A before I can do B"
• Learn, then apply

Constraints

• Each small jump must be genuinely tractable, not just smaller
• Don't decompose so finely that overhead exceeds benefit
• Maintain sight of the overall goal while working on pieces
• Some problems don't decompose cleanly—recognize when holistic approach is needed
• Verification at each step prevents wasted work on wrong paths

Outputs

Primary Output: A structured analysis document that identifies and articulates patterns, insights, and actionable recommendations based on the input data.

Format:

## Analysis: [Topic]

### Key Findings
- [Finding 1]
- [Finding 2]
- [Finding 3]

### Recommendations
1. [Action 1]
2. [Action 2]
3. [Action 3]

Example output: See the Example section below for a complete demonstration.

Example

Input: "I want to build a SaaS product but I've never built anything beyond simple scripts. I don't know where to start and the whole thing feels impossible."

Output:

Why this works:

This example demonstrates the key principles of the skill in action. The approach is effective because:

• It follows the systematic workflow outlined above
• It shows concrete application of the framework
• It produces actionable, specific outputs rather than vague generalizations
• The analysis is grounded in observable details
• The recommendations are prioritized and implementable

Alternative applications:

This same approach can be applied to:

• Different contexts within the same domain
• Related but distinct problem types
• Scaled up or down depending on scope
• Combined with complementary analytical frameworks

Small Jumps Decomposition

The Big Jump

From: Can write simple scripts, no product experience To: Running SaaS product with paying customers Why it feels big: Requires web development, backend, database, payments, deployment, marketing—dozens of skills you don't have yet, and they all seem to depend on each other.

Intermediate States

The Small Jumps

1. S0 → S1: Learn basic HTML/CSS. Build a static page about your product idea. Tractable because HTML is simple and tutorials abound.

2. S1 → S2: Add a tiny bit of JavaScript or use a simple framework. Make a button that changes something. Tractable because it's one interaction.

3. S2 → S3: Add a database (start with SQLite or a simple cloud DB). Save form input, display it later. Tractable because modern frameworks handle this.

4. S3 → S4: Deploy using a platform like Vercel, Netlify, or Railway. Tractable because they're designed for beginners and have free tiers.

5. S4 → S5: Build one valuable feature. Show it to potential users. Get feedback. Tractable because it's ONE feature, not a product.

6. S5 → S6: Integrate Stripe using their documentation. Test mode first. Tractable because Stripe has excellent beginner docs.

7. S6 → S7: Find one person willing to pay for the value you provide. Tractable because you only need one.

8. S7 → S8: Iterate based on customer feedback, add features, find more customers. Tractable because you now have skills and validation.

First Jump to Make Now

Build a static HTML page describing your product idea. Just HTML, no styling needed. One page, one hour. Put it in a GitHub repo.

This does three things:

1. Gets you started (momentum matters)
2. Forces you to articulate what you're building
3. Proves you can make something visible in a browser

Verification Plan

• S1: Can you send someone a file and have them see your page?
• S2: Can you type in a field and see something change?
• S3: Close browser, reopen, is your data still there?
• S4: Can a friend access your URL?
• S5: Has someone outside your friends used it and told you what they think?
• S6: Can you make a test payment appear in Stripe?
• S7: Has someone paid real money?
• S8: Do you have multiple paying customers and recurring revenue?

Shannon's insight: "It seems to be much easier to make two small jumps than one big jump." The gap from "scripts" to "SaaS" is terrifying. The gap from "scripts" to "one HTML page" is trivial. Chain enough trivial gaps together and you've crossed the terrifying one.

Integration

This skill is part of the Claude Shannon expert persona. Shannon emphasized that complex mental work becomes tractable when broken into smaller steps, each of which is achievable with current capabilities.