The Written Position Protocol
Force strategic clarity by committing your positions to paper
The Written Position Protocol codifies Horowitz's observation that good product managers communicate crisply to engineering in writing and take written positions on important issues, while bad product managers voice opinions verbally and then lament that nobody listened. Writing forces a level of clarity that verbal communication does not—you cannot hide behind vague handwaving when your reasoning must survive on paper. Written positions create accountability (your logic is documented), enable asynchronous alignment (stakeholders can engage on their schedule), prevent revisionist history ('I told you so' claims become impossible when positions are documented), and force problem decomposition (writing reveals when you are combining multiple problems into one). The protocol distinguishes between gathering information, which should be done informally, and giving direction, which should always be formalized in writing.
- Gathering information should be informal; giving direction must be formal and written
- Writing forces clarity that verbal communication allows you to avoid—you cannot hide behind ambiguity on paper
- Written positions create accountability, prevent revisionist history, and enable asynchronous alignment
- The discipline of writing regularly—status reports, position papers, competitive analyses—separates professionals from amateurs
- Identify Decisions That Require Written PositionsNot every decision needs formal documentation. Focus on the important strategic choices: competitive responses (silver bullets), architectural decisions with long-term consequences, tough product tradeoffs, and market strategy (which segments to attack or yield). These are the decisions where verbal opinions get lost, misremembered, or ignored. If a decision will still matter in three months, it deserves a written position.Pro tipA good rule of thumb: if you have voiced an opinion on something more than twice without seeing action, it needs to be a written position document.
- Write a Clear Position DocumentStructure your document with: the decision or issue at hand, relevant context and data, your recommended position with supporting reasoning, alternatives considered and why they are inferior, and specific next steps. Keep it concise—one to two pages maximum. The goal is clarity and actionability, not comprehensiveness. Crisp writing reflects crisp thinking; if you cannot explain your position briefly, you do not yet understand it well enough.WarningDo not pad your document with hedging language or excessive caveats. A position document that recommends everything recommends nothing.
- Distribute and Drive AlignmentShare your written position with all relevant stakeholders and explicitly ask for feedback or objections within a stated timeframe. Written positions create accountability in both directions—they force you to commit to a view, and they force disagreeing parties to articulate their objections rather than simply ignoring your recommendation through inaction.Pro tipEnd every position document with a clear 'decision needed by [date]' deadline. Without a deadline, even excellent documents die in inboxes.
- Build a Discipline of Regular Written CommunicationExtend the writing discipline beyond ad hoc position papers to regular cadences: weekly status reports sent on time, FAQ documents that preempt repetitive questions, competitive analyses updated quarterly, and product roadmaps that are living documents. Horowitz notes that good PMs send status reports on time every week because they are disciplined, while bad PMs forget because they do not value discipline. The habit of regular writing creates a compounding knowledge base that makes you increasingly effective.
Horowitz observed a recurring failure mode: product managers would voice opinions about product risks or strategic concerns verbally in meetings. When those concerns proved valid and the product failed, they would point out that they had predicted the failure. But because they never committed their warnings to writing, their predictions had no organizational impact—nobody else remembered or could verify the prediction, and the PM gained no credibility from being right.
Horowitz contrasts PMs who complain about spending all day answering sales force questions (bad) with PMs who create leverageable collateral like FAQs, presentations, and white papers (good). The bad PM treats each sales question as a unique interruption. The good PM recognizes patterns, creates documents that answer categories of questions, and frees their time for strategic work that only they can do.
Ben Horowitz developed this protocol at Netscape and later at Opsware, observing a consistent pattern: the product managers who failed were often the ones with good ideas but poor communication discipline. They would share opinions in hallway conversations, then feel frustrated when those opinions were not implemented. After failures, they would claim they had predicted the problem—but without written evidence, their warnings had no organizational impact. Horowitz made written communication a core competency requirement for his PM teams, distinguishing it from informal information gathering which should remain casual and frequent.