Product RFC

Product RFCs are the living documents that capture a teams actual thinking as they make hard product decisions. Linear publishes these openly rather than treating them as internal secrets. The practice sits at the center of their moat. While competitors copy the dark canvas and Cmd K bar they cannot easily copy the discipline of writing down convictions in public before shipping. The cycles RFC explains why Linear rejected Scrum rituals in favor of six week cycles followed by a cooldown week. It lays out the problems with velocity tracking and story points. It shows how the new model supports a keyboard first workflow where engineers ship multiple issues per day without ceremony. The triage RFC replaces prioritization meetings with a clear set of rules that move issues from inbox to active to completed. These are not high level overviews. They contain the exact logic the product uses. The project model RFC details the flat structure that avoids the bloat of traditional hierarchies. Together the library forms a public decision log that explains the entire philosophy behind the product. The writing style stays consistent with the rest of Linears voice. Technical enough to satisfy engineers. Warm enough to feel human. Specific enough to remove ambiguity. The RFC on unifying design and engineering explains why they refuse the traditional handoff process. It details the exact hiring filters they use to find designers who ship production code and engineers who can critique typography. This transparency turns what most companies treat as cultural folklore into observable practice. Readers see the stack of decisions the article calls the real moat. Interface choices flow from these documents. The spring physics values get debated in the motion RFC. The tight typography rules appear in the design system RFC. Publishing them publicly commits the team to live by their own rules.

A Product RFC is not a launch announcement. It is not a polished blog post with screenshots and customer quotes. It is not written after the feature ships to justify the outcome. Most companies that claim to publish RFCs produce documents that read like marketing collateral. Linear keeps the raw engineering memo format complete with open questions and links to discarded prototypes. The voice stays technical and warm. The documents avoid corporate jargon. They favor clear trade off discussions over victory narratives. This separates them from the typical B2B SaaS content that promises ten times velocity without showing any work. Surface copies like Plane ship a Linear looking interface but run on SCRUM rituals and Jira style backlogs. Their lack of public RFCs reveals they never did the thinking work that produced Linears model in the first place. The same gap appears in Shortcut ZenHub Tability and the rebuilt Height. They borrowed the visual language. They skipped the convictions.

Linear published an RFC in 2020 that defined their entire approach to issue tracking. The document runs over four thousand words. It starts with a brutal assessment of the market. Jira works for enterprises but crushes small teams with ceremony. Clubhouse and the early Shortcut leaned too heavily on stories and points that slow everyone down. The RFC then presents Linears alternative. A single unified issue type. Status based workflow. Cycles for timeboxing without deadlines. Powerful search and keyboard commands replace manual sorting. The document includes early sketches that evolved into the final interface. It calls out specific interaction details like the Cmd J jump to command and how it ties into the data model. It discusses the typography choices that make identifiers readable at a glance. Readers see exactly how the keyboard first decision drove the entire object model. The motion section explains the spring values chosen for issue transitions so they feel fast but not jarring. By publishing this single document Linear gave the industry a blueprint that many teams still study in 2026. Candidates reference it during interviews. Competitors copy pieces of it and wonder why the whole thing does not feel the same.

The design engineering unification RFC provides a second concrete example. Written when the company was still small the document rejects the traditional wall between disciplines. It spells out the exact skills they hire for. Designers must ship production React code. Engineers must critique spacing and motion. The RFC includes real examples of diffs where designers pushed code that engineers then refined. It details the cost of handoff in both time and quality. The document even includes the original job descriptions that implemented this philosophy. Teams that later tried to adopt the Linear surface without this unification found their iteration speed remained slow. The public RFC made the requirement obvious. You cannot steal the output without stealing the input.

Publish Product RFCs when your team knows who it is for and possesses the writing ability to explain hard choices without spin. They work for products aimed at technical teams that value transparency and speed. The documents act as hiring filters that attract people already aligned with your taste. They build trust faster than any landing page. They create a public body of work that compounds into authority within the industry. Linear benefits from this daily. Their RFCs turn product decisions into community assets. Use the practice once your core model has stabilized and you want to defend it publicly. The act of writing forces sharper decisions across the entire organization from brand voice to motion details.

Avoid Product RFCs when your direction still flips based on the last sales call. The documents will document your lack of conviction in high resolution. Skip them if your internal writing reads like LinkedIn sludge. The public version will repel the very users you want to attract. Regulated industries or companies with heavy legal teams will dilute the documents until they lose all flavor. Consumer products gain nothing from exposing roadmap thinking. Teams stuck in design versus engineering handoff culture will produce RFCs that feel disconnected from the actual shipped product. If you only want the dark theme and spring animations then stop at the surface. Adding RFCs without the supporting decisions creates a visible seam that users feel immediately.

Product RFCs turn your private taste into public proof that screenshots can never deliver.