Rotating Field Reframing

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

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

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

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

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

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.