When Your First Solution Fails, How Do You Know When to Pivot vs. Persist?
By: Jeremy (TPM turned solo developer, learning to debug my own decisions)
As technical product managers, we’ve all been in this situation: The feature seems simple, the solution seems obvious, you ship it… and it doesn’t work. Not “has bugs” doesn’t work—“fundamentally wrong approach” doesn’t work.
This is the story of how a seemingly trivial scrolling issue taught me a systematic framework for technical problem-solving that every TPM should understand. Because knowing when to pivot versus when to persist is the difference between shipping great products and getting stuck in endless iteration loops.
The Problem: History Window Scrolling That Just. Wouldn’t. Work.
The context: We’d built a beautiful popup history window for VoiceCatcher (see previous post on why we chose a popup). Users loved having a dedicated space to browse their transcription history.
Except for one tiny detail: The scrolling didn’t work.
Not “scrolling was slow” or “scrolling was janky.” The scrolling literally didn’t function in Electron. Users could see their history items, but couldn’t scroll to see more than what fit in the initial viewport.
As a TPM, my instinct was: “This is just a CSS issue. Fix the container height, add overflow: scroll, done.”
Six hours later, I learned why engineers sometimes give TPMs that look when we say “just.”
Attempt 1: The TPM’s “Obvious” Solution
The Approach
Classic TPM thinking: This is clearly a CSS problem. Add explicit scrolling properties to the container.
.sessions-list {
height: 400px;
overflow-y: scroll;
-webkit-overflow-scrolling: touch;
}The Prompt I Used
The scrolling isn't working in our Electron history window.
Show me the CSS to make a container scrollable with a fixed height.
Include webkit properties for smooth scrolling.The Result
Complete failure. The scrolling properties had no effect. The container still wouldn’t scroll.
The Lesson
Just because a solution works in regular web development doesn’t mean it works in Electron. Different rendering contexts have different constraints, and assuming solutions transfer directly is where many technical decisions go wrong.
Attempt 2: The “More Aggressive” Approach
The Approach
If basic CSS doesn’t work, maybe it’s a layout issue. Time for the aggressive approach: absolute positioning with forced scrolling.
.sessions-container {
position: absolute;
top: 0;
bottom: 0;
left: 0;
right: 0;
overflow-y: auto;
overflow-x: hidden;
}The Prompt I Used
CSS overflow scrolling isn't working in Electron.
Give me an aggressive approach using absolute positioning
to force scrollable behavior in a container.The Result
Still failed. Different CSS, same non-scrolling behavior.
The Lesson
When the first approach fails, doubling down on the same category of solution rarely works. This was still treating it as a CSS problem when the root issue was something else entirely.
The Three-Attempt Framework: A TPM’s Debug Methodology
This is where I developed what I now call the Three-Attempt Rule for technical problem-solving:
Attempt 1: Address the Apparent Problem
- Focus: Fix what seems broken
- Mindset: “This should be straightforward”
- Time Box: 1-2 hours maximum
- Success Rate: ~30% (higher for simple issues)
Attempt 2: Question Your Assumptions
- Focus: Challenge your problem diagnosis
- Mindset: “Maybe I’m solving the wrong thing”
- Time Box: 2-4 hours maximum
- Success Rate: ~40% (catches misdiagnosed problems)
Attempt 3: Reframe the Entire Approach
- Focus: Question whether this is the right solution at all
- Mindset: “Maybe this whole approach is wrong”
- Time Box: Full day or complete pivot
- Success Rate: ~80% (finds fundamentally better approaches)
Attempt 3: The Reframe That Actually Worked
The Realization
After two failed attempts, I stopped asking “How do I fix scrolling?” and started asking “Why isn’t scrolling working in Electron?”
The research revealed: Electron DOM interactions behave differently than browser DOM interactions. The scrolling container needed to be the root document body, not a div within the page.
The Solution
Instead of trying to make a container scrollable, we redesigned the entire page structure to make the document itself scrollable:
<!-- OLD: Container-based scrolling (failed) -->
<div class="sessions-container">
<div class="sessions-list">
<!-- history items -->
</div>
</div>
<!-- NEW: Document-based scrolling (worked) -->
<body>
<div class="title-bar"><!-- Fixed header --></div>
<div class="sessions-list">
<!-- history items flow naturally -->
</div>
</body>The Prompt That Led to Success
I've tried CSS container scrolling twice in Electron and it's not working.
What are the fundamental differences between Electron DOM and browser DOM
that could cause scrolling to behave differently?
Show me alternative approaches that work within Electron's constraints.The Result
Perfect scrolling. Not just working scrolling—smooth, natural scrolling that felt native to the platform.
Why the Three-Attempt Rule Works: Cognitive Bias Management
As TPMs, we’re trained to solve problems quickly. But this creates predictable cognitive biases:
Attempt 1 Bias: Solution Fixation
We assume our first diagnosis is correct and focus on implementation rather than validation.
Counter-strategy: Time-box attempt 1 aggressively. When it fails, resist the urge to “try harder” with the same approach.
Attempt 2 Bias: Category Persistence
We question our implementation but not our problem category. “It’s a CSS issue, I just need different CSS.”
Counter-strategy: Force yourself to question the problem category. Is this really a CSS issue? Could it be architectural? Environmental? Conceptual?
Attempt 3 Bias: Sunk Cost Avoidance
By attempt 3, we’ve invested significant time and ego in our approach. The natural tendency is to persist rather than pivot.
Counter-strategy: Treat attempt 3 as a research phase, not an implementation phase. Learn before you build.
The TPM Prompts That Enable This Framework
Here are the systematic prompts I now use for each attempt:
Attempt 1: Direct Solution Prompt
I need to solve [specific problem].
Show me the most straightforward approach using [current technology/framework].
Include code examples and common gotchas.Attempt 2: Assumption Challenge Prompt
I tried [previous approach] to solve [problem] but it failed because [observed failure].
What assumptions might be wrong in my problem diagnosis?
Show me 3 different categories of solutions that address this differently.Attempt 3: Reframe Discovery Prompt
I've tried [approach 1] and [approach 2] to solve [problem].
Both failed because [failure patterns].
Help me reframe this problem:
1. What could be the fundamental constraint I'm missing?
2. What would a completely different approach look like?
3. Are there examples of others solving similar problems differently?Lessons Learned: Pattern Recognition for TPMs
After applying this framework across multiple technical challenges, I’ve identified key patterns:
When Attempt 1 Usually Works
- Implementation bugs in familiar territory
- Configuration issues with known tools
- Missing dependencies or setup steps
- Simple integration problems
When You Need Attempt 2
- Cross-platform compatibility issues
- Framework-specific constraints
- Performance problems that seem like functionality problems
- User experience issues disguised as technical issues
When You Need Attempt 3
- Fundamental architecture mismatches
- Technology choice problems
- Requirements that contradict each other
- Solutions that work in demos but fail in production
The Business Impact: Why This Matters for TPMs
This isn’t just about debugging—it’s about product velocity and team morale.
Without the Three-Attempt Rule
- Engineers get stuck in endless iteration loops
- Technical debt accumulates from band-aid solutions
- Feature delivery becomes unpredictable
- Team confidence in technical decisions erodes
With the Three-Attempt Rule
- Clear decision points prevent endless debugging
- Failed attempts provide valuable architectural insights
- Teams build confidence in their problem-solving approach
- Time-boxing prevents feature scope creep
Practical Implementation for TPMs
For TPMs Who Don’t Code
You can still apply this framework by working with your engineering team:
"Let's time-box this to 2 hours. If our current approach doesn't work,
let's step back and question whether we're solving the right problem."For TPMs Learning to Code
Use this framework to avoid the “just keep trying random things” trap that kills learning momentum.
For Technical Team Management
Establish this as a standard debugging protocol. Engineers often feel pressure to “just make it work” rather than questioning fundamental approaches.
The Tools That Enable Systematic Problem-Solving
The technology that made this framework possible:
Claude/ChatGPT with Cursor
- Real-time debugging assistance
- Pattern recognition across different problem types
- Immediate feedback on alternative approaches
Documentation as Debugging
- Writing down each attempt forces clear thinking
- Failure patterns become visible across attempts
- Success patterns can be replicated
Time-Boxing Discipline
- Prevents sunk cost bias from taking over
- Forces systematic rather than reactive problem-solving
- Creates natural decision points for pivoting
Advanced: The Four-Attempt Exception
Sometimes, you need a fourth attempt—but only under specific conditions:
When Attempt 4 is Justified
- Attempt 3 discovered the fundamental issue but implementation is complex
- You’re pioneering a solution that doesn’t have established patterns
- The reframe revealed multiple viable approaches that need testing
The Fourth Attempt Rule
Attempt 4 should always be building toward a systematic solution, not continuing to debug. If you’re still debugging by attempt 4, you need to escalate or get additional expertise.
The Meta-Lesson: Embrace Productive Failure
The most important insight from this experience: Productive failure is more valuable than quick fixes.
Those two failed attempts taught me:
- How Electron DOM differs from browser DOM
- Why CSS-first approaches aren’t always correct
- How to systematically diagnose platform-specific issues
- Patterns I now recognize in other cross-platform challenges
Quick fixes would have taught me nothing. Systematic failure taught me everything.
Practical Next Steps for TPMs
Start Documenting Your Attempts
Track your problem-solving patterns. You’ll start seeing where your blind spots are.
Practice the Reframe Prompt
When engineers say “this should be simple but it’s not working,” use the attempt 3 prompt to help them reframe.
Establish Team Protocols
Make the three-attempt rule part of your team’s debugging culture. It prevents both under-thinking and over-thinking problems.
Use It for Product Decisions Too
This framework works for product problems, not just technical ones. Customer feedback not what you expected? Three-attempt rule applies.
The Bottom Line
The best technical product managers aren’t the ones who never encounter problems—they’re the ones who have systematic approaches to solving them.
The three-attempt rule isn’t about being methodical for methodology’s sake. It’s about building products that work reliably by understanding problems deeply rather than fixing them superficially.
In VoiceCatcher’s case, those two failed attempts weren’t wasted time—they were necessary research that led to a fundamentally better solution. And now I have a framework that’s prevented dozens of similar issues across other features.
The scrolling works perfectly now. More importantly, I understand why it works, which means I can build on that understanding for future challenges.
That’s the difference between solving problems and understanding systems. And as TPMs, understanding systems is our job.
Jeremy is a technical product manager turned solo developer, building VoiceCatcher as a local-first voice transcription tool. Follow the journey at [project repo] or connect on [social links].
Next in this series: “Information Architecture as Product Strategy: Essential → History → Advanced” - How frequency-based UI ordering drives user adoption and prevents feature burial.