Established 'what vs how' framework for Product-Engineering communication

Situation

In weekly sync with Brady and Brian, established a clear framework: Product defines the 'what' (exit criteria with specific, aggressive targets like 'ISO builds <4 hours'), Engineering defines the 'how'. Vague communication to leadership creates unnecessary reactive work and must stop. Escalation path defined: weekly syncs or on-demand to Peter for process breakdowns only.

Reasoning

Continuation of the shift from coaching Product to holding them accountable via systematic frameworks. The ISO build time incident was a concrete illustration - Brady's vague comment to Greg triggered an hour of reactive work from Peter and Justin. By creating a bright-line rule (what vs how), it eliminates ambiguity and protects engineering from being told how to do things. The escalation path keeps Peter as process enforcer, not technical arbiter.

Additional Context

Part of ongoing campaign to professionalize Product-Engineering interface. Previous decisions: Stop coaching product (1/30), PRD contract process (1/30), Reinforced handoff process (1/28), Redirected Brady (1/22). Set up right before Dubai trip so framework operates while Peter is away.

Observed Evidence

Fathom summary: 'Product must use precise language with leadership. Vague statements create unnecessary work for Engineering.' Key takeaway: 'Product defines the what (exit criteria), Engineering defines the how.' Specific incident: vague ISO build time comment triggered reactive work for Peter and Justin. Action item assigned to Brady: add ISO build-time target to exit criteria doc.

Matching Patterns

Confidence Breakdown

Reasoning Depth Analysis