Rotating Field Reframing

---
name: rotating-field-reframing
description: Find breakthrough solutions by questioning fundamental assumptions and approaching problems from unconventional angles—Tesla's method of looking for the "back door" when everyone knocks on the front.
license: MIT
metadata:
  version: 1.0.4879
  author: sethmblack
repository: https://github.com/sethmblack/paks-skills
keywords:
- rotating-field-problem-reframing
- transformation
- writing
---

# Rotating Field Problem Reframing

Find breakthrough solutions by questioning fundamental assumptions and approaching problems from unconventional angles—Tesla's method of looking for the "back door" when everyone knocks on the front.

---

## When to Use

- Stuck on a problem despite significant effort
- Incremental approaches aren't yielding results
- Facing a problem others say is "impossible"
- User asks "What am I missing?" or "Help me reframe this"
- When the obvious approaches have all been tried

---

## Inputs

| Input | Required | Description |
|-------|----------|-------------|
| problem | Yes | The challenge you're stuck on |
| attempts | No | What approaches have already been tried |
| constraints | No | What everyone assumes must be true |

---

## The Origin: Tesla's Rotating Field Insight

When engineers tried to build better electric motors, they focused on the rotor—the spinning part. They worked to improve commutators, reduce sparking, and increase brush life. The problem was framed as: "How do we make the rotor spin more efficiently?"

Tesla asked a different question: "What if I make the magnetic field rotate instead?"

By reimagining the stator (the stationary part) rather than the rotor, Tesla eliminated the commutator entirely. No brushes. No sparking. No maintenance. The breakthrough came not from solving the existing problem better, but from finding a different problem to solve.

"With his motor, while most other investigators worried about changing the direction of the magnetic poles in the rotor, Tesla instead figured out how to create a rotating magnetic field in the stator... If everyone knocks on the front door, Tesla is suggesting, then one way forward is to go around the house and see if there is a back door."

---

## The Reframing Process

### Step 1: Identify the Assumed Problem Statement
How has the problem been framed? What does "solving" it mean to everyone?

Write it down explicitly: "The problem is understood to be [X]."

### Step 2: Map the Conventional Focus
What component, variable, or aspect are people trying to improve? This is "the rotor"—where all attention goes.

### Step 3: Identify the Fixed Elements
What is everyone treating as unchangeable? These are "the stator"—the parts assumed to be static.

Often, the breakthrough hides in what everyone assumes is fixed.

### Step 4: Question Each Fixed Element
For each "fixed" element, ask:
- Why is this assumed to be unchangeable?
- What would happen if this changed instead?
- Is this truly a constraint or just convention?

### Step 5: Invert the Problem
What if the solution isn't in the component being optimized, but in what surrounds it?
- Instead of improving X, what if we changed Y?
- Instead of adding to the system, what if we removed something?
- Instead of making A work with B, what if we eliminated the need for B?

### Step 6: Find the Rotating Field
Look for a solution where:
- The assumed-fixed element becomes the point of innovation
- The problem dissolves rather than being solved
- The new approach is simpler, not more complex

---

## Red Flags That Indicate Reframing Is Needed

- "We've optimized this as much as possible but it's still not enough"
- "This problem is inherent to the approach"
- "We need a breakthrough but all the incremental improvements are exhausted"
- "Experts say this can't be done"
- "Everyone in the industry does it this way"

---

## 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

```markdown
## Rotating Field Reframing

### The Stated Problem
[How the problem is currently understood]

### The Conventional Focus ("The Rotor")
[What aspect everyone is trying to improve]

**Efforts so far:**
- [What's been tried]
- [Why it hasn't been sufficient]

### The Assumed-Fixed Elements ("The Stator")
| Element | Why It's Assumed Fixed | Is It Truly Fixed? |
|---------|----------------------|-------------------|
| [Element] | [The reasoning] | [Assessment] |

### Questioning the Fixed Elements

**Element 1: [Name]**
- Current assumption: [What everyone believes]
- Challenge: [What if this changed?]
- Implication: [What would be possible]

[Continue for each element]

### The Inversion
Instead of [conventional focus], what if we [alternative focus]?

**The Rotating Field Question:**
[The reframed question that shifts attention to the "stator"]

### Potential Breakthrough Directions

| Direction | Insight | Feasibility | Potential |
|-----------|---------|-------------|-----------|
| [Approach] | [What reframing reveals] | [Assessment] | [If it works] |

### The Back Door
**Recommended reframe:**
[The specific new approach that emerges from questioning assumptions]

**Why this might work:**
[Reasoning that supports the new framing]

**What it eliminates:**
[Problems that dissolve under the new framing]

### Tesla's Verdict
[Summary in Tesla's voice—what the "front door" obscured and what the "back door" reveals]
```

---

## Outputs

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

**Format:**
```markdown
## 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.

## Constraints

- Do not use this analysis as the sole basis for critical decisions
- Do not apply this framework to situations outside its intended scope
- Acknowledge that analysis is based on available data, which may be incomplete
- Honor the complexity of real-world situations that resist simple categorization
- Present findings with appropriate confidence levels
- Recognize the limits of the methodology

## Example

**Input:** "We're trying to reduce customer support ticket volume but we've already improved our docs, added chatbots, and created video tutorials. Volume is still too high."

**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


## Rotating Field Reframing

### The Stated Problem
Customer support ticket volume is too high despite multiple self-service improvements.

### The Conventional Focus ("The Rotor")
Improving support deflection—creating better self-service options so customers don't need to contact support.

**Efforts so far:**
- Improved documentation (better content)
- Added chatbots (faster answers)
- Created video tutorials (visual learning)
- Still seeing high ticket volume

### The Assumed-Fixed Elements ("The Stator")
| Element | Why It's Assumed Fixed | Is It Truly Fixed? |
|---------|----------------------|-------------------|
| Customers will have questions | Products are complex | Maybe—depends on complexity |
| Support exists to answer questions | That's what support does | No—support could have other functions |
| Questions arise from lack of information | Give info, questions decrease | No—questions might arise from other causes |
| The product is what it is | Engineering isn't changing | No—product design affects support needs |

### Questioning the Fixed Elements

**Element 1: Customers will have questions**
- Current assumption: Complexity is inherent, questions are inevitable
- Challenge: What if the product was simpler?
- Implication: Fewer questions at the source, not better answers

**Element 2: Support exists to answer questions**
- Current assumption: Support is reactive to customer problems
- Challenge: What if support prevented problems before they occurred?
- Implication: Proactive outreach, not waiting for tickets

**Element 3: Questions arise from lack of information**
- Current assumption: More/better info = fewer questions
- Challenge: What if questions arise from product friction, not information gaps?
- Implication: Tickets are symptoms of product problems, not knowledge problems

**Element 4: The product is what it is**
- Current assumption: Support must adapt to the product
- Challenge: What if the product adapted based on support data?
- Implication: Support becomes product feedback, engineering removes friction

### The Inversion
Instead of improving how we answer questions, what if we eliminated why questions arise?

**The Rotating Field Question:**
"What if we measured support tickets not as a support metric, but as a product quality metric?"

### Potential Breakthrough Directions

| Direction | Insight | Feasibility | Potential |
|-----------|---------|-------------|-----------|
| Ticket → Bug report | Every ticket signals product friction | High | High |
| Support → Product team | Move support into product org | Medium | High |
| Reactive → Proactive | Reach out before confusion hits | Medium | Medium |
| Deflection → Elimination | Remove ticket causes, not just tickets | High | Very High |

### The Back Door
**Recommended reframe:**
Stop treating support tickets as a support problem. Treat them as product telemetry. Every ticket category that exceeds threshold triggers a product fix, not a documentation improvement.

**Why this might work:**
- Documentation solves symptoms; product fixes solve causes
- One product fix eliminates all future tickets of that type
- Support team becomes product intelligence, not cost center
- Scales multiplicatively (fix once, benefit forever) vs. linearly (answer each ticket)

**What it eliminates:**
- The endless documentation maintenance cycle
- The assumption that ticket volume is about information access
- The separation between support data and product decisions
- The "deflection" framing that treats customers as problems to redirect

### Tesla's Verdict
You have been polishing the commutator when you should have been reimagining the field. Your support team sees every friction point in your product—they are your most valuable sensors, yet you use them as shock absorbers. The front door approach says "answer questions better." The back door reveals: "your questions are the product speaking. Listen, then change the product, and the questions cease." Edison would add more documentation. I would remove the need for it.

---

## Integration

This skill is part of the **Nikola Tesla** expert persona. Use it to find breakthrough solutions hiding in your assumptions—the back door that makes the front door irrelevant.

"Mr. Tesla may accomplish great things, but he certainly never will do this." — Professor Poeschl, before Tesla proved him wrong by reframing the problem entirely.