PMs are Drowning
Every day, your kids are pestering you in the car no matter the distance, ARE WE THERE YET. But Sang, I don’t have kids and I don’t drive them to soccer or karate, you may be muttering right now. WRONG. In fact, you have 14 children, and they all need to get to different places, at different times, for different reasons, and some of them don’t even know if that’s really what they want in their short little lives. Sometimes you need to hold their hands and console them, other times you need to lightly admonish them with a little frowny frown. SOUND FAMILIAR? For healthy, functional children who grow up well adjusted, good parenting is a big key to success, and it’s no different for businesses. Your stakeholders deserve love, nurture, and guidance. They’re not inferior, they’re not superior. Respect them but verify they deserve the respect. Don’t be that frazzled parent who constantly looks like their lives are hanging on by the thread of a desperation. Come, take my hand.
Manage Outcomes, Not Tasks
Every requirement should start with the question: When should I stop working on this?
What we’re talking about here is no different from the countless frameworks, methodologies, checklists, and blog posts out there (JTBD, ODI, Impact Mapping, Feature Validation, North Star Framework), but what I want to focus on is the point of using any of these from a practical perspective. We iterate endlessly because we don’t know when we’ve delivered enough business value to justify moving on. We’re stuck in improvement purgatory while higher-value opportunities sit untouched because we never validated if our current work was worth doing in the first place. Even more difficult, business value is not an absolute measure, it’s a constantly moving target that’s relative. That means we need to regularly interrogate it again and again.
Key Point: Depending on who defined the requirement(s), it is ALWAYS worth interrogating whether or not it should be a requirement at all in the first place. Obviously if the CEO says this is the requirement and you don’t have a choice, then that’s your non-negotiable (however even in this situation you can leverage your communication skills to steer change). But if you or someone you work with developed this requirement, maybe even with a stakeholder, always ask yourself
So How Do I Know When to Stop? (and start doing something else)
Step 1: Extract the Real Problem (Not Their Solution)
What they say: “We need an email template system”
What you ask: “What happens today without email templates that costs us money or opportunity?”
What you discover: “Sales reps waste 2 hours/day on formatting, missing 3 prospect calls worth ~$50K/month in pipeline”
Document this:
Stated need: [What they asked for]
Real problem: [What actually hurts the user]
Cost of problem: [Quantified impact - always in time or money]
Evidence: [How we know this is real - data, observations, quotes]
Step 2: Define “We’re Stopping When” Together
Agree on the minimum bar for success.
Document this:
We're stopping when: Sally the rep confirms she can send her 5 most common emails in under 5 minutes each
Key question: “If we stop when Sally confirms this, will you agree there are other fish to fry now?”
Step 3: The Ship Decision
Force this conversation at least once a check-in/sync cycle:
“We’re stopping when [xyz]. The evidence shows [current state]. Do we have agreement that we can stop now?”
Three acceptable answers:
- YES: Ship it, move to next problem
- NO, because [specific gap]: One more sprint to be able to stop
- NO, wrong approach: Stop immediately, move to next problem
Unacceptable answer: “It needs more features” without connecting to the original stopping marker
Key question: If stakeholders start asking for new features, ask: “Since we’re stopping when xyz, does this new feature help us stop earlier or more cheaply?”
Red Flags: You’re Drowning Again When…
🚨 Emergency Signals:
- You’ve been “almost done” for more than 2 weeks
- You can’t explain the problem without using the words “optimize,” “streamline,” or “enhance”
- Your stakeholder says “just one more small thing” for the 4th time
- You’re not sure who would actually use this feature daily
- You haven’t talked to the end user in over a week
✅ You’re Swimming When:
- You can name the specific person whose day gets better when you ship
- Your “ship decision” criteria haven’t changed in a week
- You have evidence (screenshots, usage data, most importantly user feedback) that it’s working
Your Daily Survival Ritual
Every morning, ask yourself:
- Who am I helping today? (Name a specific person)
- How will I know if I helped them? (Specific evidence)
- What am I NOT doing today? (Protect your scope)
If you can’t answer these clearly, you’re probably drowning again.
The Hard Truth
You will never feel “ready” to ship. There will always be one more improvement, one more edge case, one more stakeholder opinion.
Successful PMs ship good-enough solutions that real people actually use, then iterate.
Drowning PMs polish perfect solutions that never get used because they never ship.
Your job is to create measurable improvements in real people’s lives, but the way you’re evaluated is how well you create alignment amongst stakeholders.
I hope this post helped you gain some actionable clarity into the two sides of the PM coin!