Thread by @nurijanian

When execs say “just whip up the PRD by tomorrow,” most junior PMs say yes... and immediately set themselves up to fail.

I did this for years until a principal PM taught me how to bridge the gap between speed and quality.

Here’s the 4-part framework I wish I had on day one:

1/ when your exec says "we need that prd by tomorrow, it shouldn't take more than a few hours" but you know it needs days of work, you're experiencing the classic product estimation gap.

2/ veterans know this happens because executives and product managers operate with different mental models of documentation.

executives think about prds as:
1. a simple description of what to build
2. a checkbox for process compliance
3. something that should be quick to produce

3/ experienced pms know prds actually require:
1. stakeholder interviews across 4-6 teams
2. technical feasibility assessments
3. data analysis to validate assumptions
4. multiple review cycles to align everyone
5. refinement based on engineering feedback

4/ after watching junior pms struggle with this for years, i've developed a 4-part framework for setting realistic expectations:

1. Acknowledge the business goal
2. Clarify the complexity
3. Explain the options
4. Document the agreement

let's break this down with a real example

5/ when an exec says "we need the prd for the new checkout flow by tomorrow," don't simply agree or disagree.

first, affirm: "i understand shipping this feature quickly is critical for q3 revenue targets."

6/ next, reveal complexity: "for context, a complete checkout flow prd typically requires input from payments, fraud, legal, and ux teams, plus technical architecture review."

7/ then present options: "i can deliver a high-level spec tomorrow that covers user flows, or a comprehensive prd with all requirements by next tuesday."

8/ finally, document: "i'll add both options to our project plan so everyone can see the tradeoffs."

9/ senior pms know this approach works because it:
1. shows you understand business imperatives
2. educates without undermining authority
3. maintains your control over quality
4. creates a shared reality

10/ one pm asked me, "what about when they still insist on the impossible timeline?"

this is where product leadership separates from product management.

11/ avoid saying "that's not possible." instead say, "here's what's achievable in that timeframe."

then be specific about what will be missing: security review, localization requirements, edge cases, etc.

12/ in my experience, adding historical data changes conversations: "the last three checkout features with rushed prds resulted in an average of 14 critical bugs discovered post-launch."

13/ another technique i teach new pms: use what i call the "context/concern/compromise" structure:

"given our goal to launch next month, i understand the urgency. my concern is that rushed requirements led to a 3-week delay in our last launch. i can deliver a version 1 prd tomorrow focusing on core user flows, then complete edge cases by wednesday."

14/ the psychological barrier is very real: we fear looking slow or unresponsive.

what veterans understand is that setting realistic expectations and delivering on them builds exponentially more credibility than promising the impossible.

15/ a chief product officer once told me: "i don't need yes-people. i need truth-tellers who help me understand what's actually possible."

executives ultimately want predictability over promises.

16/ implementing this approach transformed my team's results:
- far fewer post-launch critical bugs
- higher engineering team satisfaction
- significantly reduced weekend work
- stronger cross-functional partnerships

next time you face pressure to deliver a prd overnight, remember that your role isn't to acquiesce but to translate reality.

contains PRDs and prompts that can accelerate parts of this process, but the communication strategy matters most.tiny.cc/product-bundle