The "What/Rule vs. How/Tech" Framework: Bridging the Gap Between Product Managers and Engineers

Author: Tech Leadership & Organizational Alignment
Tags: #PMDeveloperCollaboration #WhatHowFramework #Agile #ProductManagement #TechLeadership #R&R

📌 Introduction: The Frustrating Barrier of "I Don't Know Code"

"Developer, I don't know technical details, so just make the error handling look nice."
"Why are engineers asking me how database exceptions should behave?"

In many tech organizations, product managers throw up defensive walls the moment technical edge cases arise, while developers grow frustrated by vague, incomplete product specifications.

This conflict stems from a failure to delineate operational boundaries. The What/Rule vs. How/Tech Framework establishes clear collaborative ownership.

📌 1. Deconstructing the What/Rule vs. How/Tech Framework

[The Collaboration Boundaries Framework]

                        PRODUCT MANAGER (PM)                     SOFTWARE ENGINEER
                ┌──────────────────────────────────┐   ┌──────────────────────────────────┐
WHAT & RULE     │  - Business Goal & User Value    │   │  - Validates Feasibility         │
(Functional)    │  - Edge Case User Journeys       │   │  - Highlights Edge Case Risks    │
                │  - Explicit UX Copy & Modals     │   │                                  │
                └──────────────────────────────────┘   └──────────────────────────────────┘
                                                                        ▲
                                                                        │ Collaborative Bridge
                                                                        ▼
                ┌──────────────────────────────────┐   ┌──────────────────────────────────┐
HOW & TECH      │  - Respects System Constraints   │   │  - System Architecture & DB      │
(Technical)     │  - Asks Clarifying Rule Questions│   │  - API Schema & Protocols        │
                │                                  │   │  - Performance & Security Specs  │
                └──────────────────────────────────┘   └──────────────────────────────────┘

📌 2. Real-World Scenario Comparison

Scenario: PG Payment Timeout Exception Flow

❌ Unhealthy Interaction:

• Engineer: "If the payment gateway times out after 10 seconds, should we trigger an auto-cancel or leave the transaction in a pending state?"
• PM: "I don't know how payment APIs work. Just handle it cleanly in code."
• Result: Engineer guesses business policy, implements silent cancellation. Client complains when double-charge disputes occur later.

⭕ Healthy What/Rule vs. How/Tech Interaction:

• Engineer (Highlighting Technical Constraint): "Payment Gateway network timeouts occur in ~0.5% of calls. When a timeout occurs, our backend cannot verify if the user's card was charged or not."
• PM (Defining Business Policy): "Got it. From a user trust perspective, we must never double-charge. If status is unknown, set order state to 'Verifying Payment', send SMS notification to user within 3 minutes, and route the ticket to customer operations."
• Engineer (Designing Technical Solution): "Understood. I will implement a background retry queue with exponential backoff and a 5-minute timeout fallback worker."

📌 3. Five Golden Rules for PM-Engineering Alignment