- Taking all the notes
- Updating all the tickets
- Chasing every status
Startup: Let engineers own their tasks
BigCo: That's what delivery managers are for
Leaders: If your PM is doing this, your org has unclear roles.
3/ Stop playing project manager
"But things won't ship on time!"
Startup: Time box efforts, not outcomes. Let tech lead manage capacity
BigCo: Partner with your TPM, don't compete with them
The moment you own the timeline, you lose the ability to negotiate scope.
Leaders: Clear ownership prevents double work.
4/ Stop being the requirements police
"But they'll build the wrong thing!"
Wrong approach: Detailed specs + heavy process
Right approach: Clear outcomes + guard rails
Startup:
- One-pager with clear success metrics
- Weekly team working sessions
- Rapid prototypes and feedback
- Document decisions, not specifications
BigCo:
- Focus on the "why" and business case
- Get sign-off on outcomes, not features
- Keep technical specs as appendix
- Document key trade-offs and decisions
Leaders: Measure outcomes, not requirement compliance.
5/ Stop being the backlog janitor
"Someone needs to groom the backlog!"
Startup: Delete it. Start fresh. What matters now?
BigCo: Archive old tickets quarterly. Keep only next quarter visible.
Your job isn't managing tickets.
Your job is managing value creation.
Leaders: Large backlogs = unclear strategy.
6/ "But my team expects me to do all this!"
Startup: Have the hard conversation about role clarity
BigCo: Get your manager involved in resetting expectations
Script:
"I've been doing X, but it's preventing me from focusing on Y, which delivers more value because Z"
Leaders: Back your PMs in these conversations.
7/ What to do instead:
Startup PMs:
- Own strategy, not tickets
- Focus on weekly customer learning
- Partner with tech lead on trade-offs
- Keep process minimal
BigCo PMs:
- Build stakeholder coalition
- Focus on quarterly outcomes
- Partner with TPM/EM roles
- Document key decisions
8/ For PM Leaders:
Your PMs fall into these traps because:
- Role confusion
- Unclear expectations
- Wrong incentives
- Fear of losing control
Fix the system, don't blame the PM.
9/ Reality check:
Doing "product owner" work feels safe
- Clear deliverables
- Visible progress
- Team happiness
But it's a career trap.
Real PM work feels uncomfortable:
- Ambiguous problems
- Uncertain outcomes
- Hard trade-offs
That's how you know you're doing it right.
Follow @nurijanian for more PM reality checks 🤘🏼
• • •
Missing some Tweet in this thread? You can try to
force a refresh
I spent 3 years working with an engineering team that openly despised product managers.
Every interaction felt like negotiating with someone who wanted me to fail.
Here's what that toxic dynamic taught me about when to fight and when to walk away:
1/17
The warning signs were there from day one:
- Requirements were never "detailed enough" but they wouldn't explain what they needed
- Status updates? "You're the PM, you should know"
- Questions? "Stop wasting our time"
- Meetings? Either I was micromanaging or not involved enough
2/17
The worst part wasn't the hostility.
It was watching myself become smaller. Apologizing for existing. Walking on eggshells around people who were supposed to be partners.
I started dreading Monday mornings. My confidence evaporated. I questioned if I belonged in product at all.
Most PMs drown in context from devs, design, stakeholders, and user feedback that changes every 4 hours.
Your brain can't hold this. Stop pretending.
The filtering system that actually works: 🧵
1/ Every junior PM thinks they need to process everything.
Track every Slack thread. Attend every meeting. Read every doc. Respond to every ping.
Reality: 90% of "urgent" context has a 4-hour half-life.
You need better filters, not less chaos.
2/ Most PMs batch emails. Elite PMs batch context.
First hour: Strategic inputs (roadmap, vision, major decisions)
Mid-morning: Dev blockers and design reviews
Early afternoon: Tactical inputs (bugs, features, quick wins)
Late afternoon: Stakeholder updates
End of day: FYI inputs (updates, announcements)
But many PMs who claim to have it are using it as an excuse to avoid actual customer research.
I think I know what's the real deal:
Real product sense comes from pattern recognition across thousands of user interactions, not from reading case studies or doing framework exercises.
The PM with 10 years of experience who says "I just know" actually means "I've seen this exact failure mode 47 times before."
The biggest lie in product management: trusting your gut without feeding it data first.
That senior PM who makes seemingly instant good calls has already internalized 500+ customer conversations, watched multiple product cycles play out, run dozens of failed experiments, and burned through every bad assumption at least twice.