Shreyas Doshi on Product Management: When Strategy Masquerades as Execution
I've been listening to this Lenny's Podcast episode with Shreyas Doshi while staring at my to-do list - scattered pile of papers on and under the table that somehow manages to grow longer despite my constant attention (by adding more tasks). After years of monitoring system alerts, it's interesting how familiar these product management frameworks feel. The patterns are the same; they just wear different names.
I'm not a product manager. My background is in systems administration, where "pre-mortems" aren't frameworks but daily reality - that familiar dread before a major system change when you know something might go wrong but can't quite pinpoint what. But there's something in Doshi's approach that feels universal — like he's giving names to patterns that infrastructure folks have always known existed.
The LNO Framework: Patterns in Plain Sight
Doshi talks about this framework where tasks are categorized as Leverage (L), Neutral (N), or Overhead (O). The idea is simple: prioritize high-leverage tasks, minimize overhead, recognize that the same task can shift categories depending on context.
What struck me wasn't the framework itself but his observation about why we avoid the L tasks. We know exactly which tasks are high-leverage — they're the ones that haunt us, the ones we're not doing or not doing well enough. They're the ones that require deep thought, that might expose our limitations, that can't be checked off in a satisfying fifteen-minute burst.
I felt uncomfortably seen. How many times have I avoided writing that strategy document or making that difficult decision by convincing myself I just don't have time? How often have I filled my day with busy work — the digital equivalent of rearranging desk supplies — while the truly important work sits untouched?
(I'm literally pausing writing this to check some GPT agent trying to deploy HELO WORLD on Cloudflare. The irony isn't lost on me.)
Pre-Mortems: Learning from Future Failures
There's something deliciously morbid about pre-mortems. In infrastructure, we call them disaster recovery plans. In product, they're pre-mortems. In medicine, they're morbidity and mortality conferences or failure mode analyses. Different names, same pattern: systematically imagining failure before it happens.
It's not about being pessimistic - it's about understanding that complex systems have failure modes baked into their design. So instead of the usual optimistic planning, you gather your team and say: "Imagine this project has completely failed six months from now. What happened?"
It's like inviting your anxiety to the planning meeting instead of letting it ambush you at 3 a.m.
Doshi suggests creating a shared vocabulary around potential failures — "tigers" (actual threats), "paper tigers" (seeming threats that aren't actually worrisome), and "elephants" (undiscussed issues). I love this. It transforms vague dread into something you can point at, name, discuss.
I wonder how many corporate disasters could have been avoided if someone had created psychological safety for people to say: "I think there's a tiger in the room, and it's getting hungry." (and when he is hungry, he is angry).
Most Execution Problems Aren't Execution Problems
This might be the most profound insight from the entire podcast: most execution problems aren't actually execution problems. Anyone who's ever debugged a persistent system issue knows this pattern. The alert says CPU spike, so you add more capacity. The logs show timeout errors, so you adjust thresholds. But sometimes the real problem is in the architecture itself.
It's like treating a broken leg with painkillers - you might feel better temporarily, but you're still not going to walk right. The same applies whether you're dealing with system architecture or team dynamics:
When teams are misaligned, it's rarely because they need more sync meetings or better project management tools.
It's usually because:
They're pursuing different strategies
No one knows what the strategy actually is
The culture rewards individual achievements over collaboration
I've sat through countless meetings where we've tried to solve what looked like execution problems with more processes, more documentation, more check-ins. Meanwhile, the fundamental misalignment festered beneath the surface.
Doshi calls these "bandaid solutions" — when you keep applying the same fix to a problem that keeps returning. The bandaid keeps falling off because you're not treating the actual wound.
Opportunity Cost vs. ROI: The Trap of "Good Enough"
In high-leverage roles, Doshi suggests focusing on minimizing opportunity cost rather than maximizing ROI. This subtle shift changes everything. Instead of asking "Is this a good use of my time?" (to which the answer is often yes), you ask "Is this the best use of my time?" (to which the answer is frequently no).
I think about all the "positive ROI" tasks I've prioritized - the equivalent of installing patches without questioning the underlying architecture. They keep the lights on, sure, but they don't prevent the next outage.
It's not that those tasks weren't valuable — they were. But were they the most valuable thing I could have been doing? Probably not. There's something comforting about tasks with guaranteed positive returns, even small ones. The ambiguity of potentially high-impact work is much harder to face.
High Agency: Finding a Way When There Isn't One
Doshi describes "high agency" as finding a way to get what you want without waiting for perfect conditions. It's about ownership, creative execution, and resilience — especially when facing disadvantages.
This resonates deeply. The world doesn't arrange itself for our convenience. Resources are limited, stakeholders are distracted, priorities shift. Waiting for ideal conditions means waiting forever.
I'm trying to cultivate this mindset, though it's harder than it sounds. There's a fine line between high agency and delusion — between finding creative solutions and ignoring reality. But I suspect that line is further out than most of us imagine. We give up too easily, accept constraints too readily.
What I'm Taking Away
Key Questions to Ask:
Am I focusing on what truly matters?
Am I avoiding important work because it's difficult or scary?
Am I solving surface problems while ignoring deeper issues?
Am I making the best use of my time, not just a good use of it?
I don't have perfect answers to these questions. I probably never will. But asking them feels like a step in the right direction — a small act of high agency in a world that constantly pulls us toward the urgent rather than the important.
If you found this helpful (or if it just made you uncomfortably aware of your own procrastination habits), consider subscribing.
I can't promise I'll always tackle the highest-leverage topics, but I'll try. And when I fail, I'll at least have the vocabulary to explain why.
The beauty of recognizing these patterns is that they show up everywhere once you start looking. Whether you're managing servers or teams, projects or products, the underlying dynamics remain surprisingly consistent. Not because someone designed them that way, but because that's how complex systems tend to behave.