After studying high-performing PMs for years, I noticed something strange:
The most impactful product managers often do LESS than their peers.
They write shorter docs. Hold fewer meetings. Create simpler processes.
They've mastered making impact look effortless.
Here's how:
I spent my first 3 years as a PM writing 30-page PRDs no one read and creating complex processes no one followed.
I thought "good product work = hard product work."
But what if the opposite is true? What if making it harder actually reduces your impact?
Greg McKeown in his book Effortless suggests we ask: "Why is this so hard?" followed by "What if this could be easy?"
This simple inversion challenges everything in product culture.
Every time you feel you're pushing a boulder uphill, that's your cue: there's probably an easier path.
Principle 1: Define exactly what "done" looks like.
Vague goals = endless work.
Bad: "Create a comprehensive product strategy"
Good: "A 1-page strategy document with 3 clear objectives, approved by leadership by Friday"
What's your current "done" definition?
Principle 2: Take the minimum viable action.
Steve Jobs walked to a whiteboard and drew a rectangle.
"Here's the new application. You drag your video into the window. Then click BURN. That's it."
What's the simplest version of your current project?
Principle 3: Start from zero, not from complexity.
Most PMs start with everything possible, then try to cut back.
Elite PMs start with nothing, then add only what's essential.
"What's the minimum number of steps required for completion?"
Principle 4: Embrace the "zero draft" approach.
Don't start by trying to write the perfect PRD.
Start by writing a terrible one. The "zero draft" - so bad it doesn't even count as a first draft.
This breaks the paralysis of perfectionism.
Principle 5: Establish upper AND lower bounds.
"Never less than X, never more than Y"
Example:
- Never less than 3 customer conversations per week
- Never more than 15 customer conversations per week
What's your sustainable pace?
I get it. You're thinking: "Our product is complex, so our processes need to be complex too!"
I thought the same until I noticed something:
The most complex products often have the simplest PM processes behind them.
Complexity requires clarity, not more complexity.
"But my stakeholders expect comprehensive documentation!"
Reality: They want their needs met, not documentation for documentation's sake.
Try this: Next time, deliver a 1-page summary instead of a 20-page PRD. See what actually happens.
Most PM work produces linear results:
- Documentation = one-time output
- Meetings = time in, decisions out
- Daily stand-ups = daily updates
But elite PMs focus on residual results - effort that compounds over time.
Examples of residual PM work:
- Creating decision frameworks teams can use autonomously
- Building dashboards that provide ongoing insight
- Documenting principles (not just procedures)
- Teaching others to facilitate their own meetings
Small effort, ongoing returns.
The question that transformed my PM career:
"Is this a lever or a boulder?"
Levers: Small effort, big impact
Boulders: Big effort, small impact
I now spend 80% of my time looking for levers, not pushing boulders.
Finding leverage in product work is all about having the right frameworks at your fingertips.
I've found helpful for this - curated frameworks so I'm not reinventing wheels.
- PMs who don't understand system dependencies
- "Product people" who can't think in flows
- Leaders who demand random features
- Roadmaps built on hope
But what if product management was actually about systems?
"Thinking in Systems" blew my mind:
1/ Most technical people are trained to see the world as a series of cause-and-effect relationships:
- Input → Process → Output
- Problem → Solution
- Bug → Fix
Roadmaps 101: Not a schedule. Not a backlog. A communication tool.
Here’s how to get it right:
1. Why You Need a Roadmap
If you don't have a roadmap, three bad things happen. Your team builds random features. Your stakeholders constantly ask when things will be ready. Your customers don't understand what's coming next.
If you have a roadmap, everyone knows what's important and when to expect it.
2. What Goes in a Roadmap
A roadmap has three main parts. These parts answer three questions.
Part 1: Where are we going? This is your product vision. Write one sentence about what problem your product solves.
Part 2: What are we building? These are your major features or improvements. Group them into themes like "Better Search" or "Faster Checkout."
Part 3: When will it be ready? These are your time estimates. Use quarters or months, not specific dates.
“Tell me about a time you influenced without authority.”
It’s not about persuasion.
Here’s what they’re really testing:
First, understand what kills most answers.
Candidates tell stories about convincing people. They talk about charisma. They focus on winning arguments.
But that's not influence without authority. That's just being loud.
If you tell a story about winning a debate, then you already failed.
What interviewers are ACTUALLY testing:
They want to know if you can create shared context. Can you make everyone see the same picture? Can you understand what matters to each person in the room?
This is the core PM skill. Not persuasion. Alignment.
But your stakeholder skills will make or break you.
I lost multiple battles as a PM by being "right" but ineffective.
Here's what I’d do differently now:
1/ First, understand why smart people push back against good data:
• They have context you don't
• They're optimizing for different goals
• They see risks you haven't considered
• They have pressure from their stakeholders
• Past experiences are coloring their judgment
2/ The immediate urge is to:
- Gather more data
- Build stronger arguments
- Rally support
Stop.
Your goal isn't to win the argument.
It's to make the best decision for the product AND maintain relationships.
It's 2 AM and you're googling "how to use ChatGPT for product requirements without getting fired"
Let me save you the panic attack.
Here's the truth nobody's telling you about AI and product work:
1/ Everyone is already using it.
That senior PM who produces flawless PRDs in 2 hours? AI.
The PM who suddenly writes eloquent user stories? AI.
Your manager who "just has a gift" for structuring requirements? Also AI.
You're not cheating. You're catching up.
2/ But here's where junior PMs mess up:
They type "write me a PRD for a payments feature" and copy-paste whatever comes out.
Then wonder why:
- It sounds generic
- Has obvious hallucinations
- Doesn't match company style
- Gets them side-eye in reviews