A design pattern is a reusable solution to a recurring problem in a context. The term was popularised in software by the Gang of Four (Design Patterns: Elements of Reusable Object-Oriented Software, 1994): Observer, Singleton, Factory, and so on. Each pattern names a problem, a solution, and the trade-offs. The value is not in copying code but in shared vocabulary and in knowing that a problem has a known shape. "We need loose coupling between this and that" → Observer. "We need one instance shared across the system" → Singleton (with caution). The pattern is a template, not a law; you adapt it to the situation.
Patterns transfer across domains. The same idea — standardise the approach to recurring problems so that teams can communicate and avoid reinventing — appears in org design (two-pizza teams, DRI), in product (onboarding flows, pricing tiers), and in strategy (platform play, land-and-expand). When someone says "we're doing a freemium" or "we're using a hub-and-spoke model," they're invoking a pattern. The benefit is speed and alignment; the risk is applying a pattern where the context doesn't match and the "solution" creates new problems.
The discipline is to treat patterns as a starting point. Name the problem you have. Check if a pattern fits. If it does, use it and document the adaptation. If it doesn't, don't force it — the pattern's context has conditions (e.g. "when you need to notify many observers without tight coupling"). Violating those conditions turns a pattern into an anti-pattern. The strategic move is to build a small repertoire of patterns for your domain and to recognise when you're in pattern territory versus when you need a one-off design.
Section 2
How to See It
You're in design-pattern territory when you notice that a problem you're solving has appeared before — in your codebase, in another team, or in the literature — and that a named approach exists. The diagnostic: can we describe our solution in a sentence that would make sense to someone who knows the pattern?
Business
You're seeing Design Pattern when a company describes its GTM as "land and expand" or "PLG with sales assist." The pattern names a repeatable structure — land with a small footprint, expand usage and seats — that others have used. The company is reusing a known playbook and adapting it to their product.
Technology
You're seeing Design Pattern when an engineer suggests "we need a circuit breaker here" or "this is a good place for a queue." The pattern (circuit breaker, queue) encodes a solution to a recurring problem (cascading failure, decoupling producers and consumers). The team can reason about the design without re-deriving it.
Investing
You're seeing Design Pattern when a pitch is framed as "we're the X for Y" or "we're applying the marketplace pattern to Z." The pattern gives a mental model — investors map the company to a known template and then ask how this instance differs and whether the pattern's success conditions hold.
Markets
You're seeing Design Pattern when market structure is described in standard terms — two-sided market, platform, aggregator. The pattern summarises how value flows and where power sits. Analysts use these patterns to compare companies and to spot when a company is mis-applying a pattern (e.g. calling itself a platform without network effects).
Section 3
How to Use It
Decision filter
"When facing a recurring problem, ask: is there a named pattern that fits? If yes, use it and document how we adapted it. If no, solve it and consider naming the solution so it can become a pattern for next time. Don't force a pattern when the context doesn't match."
As a founder
Build a small set of patterns for product, GTM, and org — the plays you run repeatedly. Document them so the team can say "we're doing the X pattern here" and everyone knows the shape. When a new problem appears, check the repertoire first. When you adopt a pattern from outside (e.g. freemium, two-sided marketplace), state the conditions under which it works and how your context fits or differs.
As an investor
Patterns help you parse pitches quickly: "platform," "vertical SaaS," "infrastructure." The due diligence question is whether the company's context matches the pattern's success conditions. A platform pattern without network effects or multi-sided demand is a misapplication. Ask: what pattern are you really running, and does your situation support it?
As a decision-maker
Use patterns to communicate and to avoid reinventing. When you standardise a process or structure, give it a name and document the problem it solves and when to use it. When someone proposes a design, ask: which pattern is this, and does our context fit? Patterns reduce ambiguity and capture learned trade-offs.
Common misapplication: Applying a pattern without checking the context. Patterns have preconditions. Using Singleton when you don't need a single instance, or land-and-expand when expansion isn't possible, creates technical or commercial debt. Read the "when to use" part of the pattern.
Second misapplication: Treating patterns as mandatory. Not every problem has a standard pattern; some need a custom solution. Forcing a pattern onto a problem that doesn't fit produces awkward design and confusion. Patterns are tools, not rules.
Grove institutionalised patterns at Intel — the OKR pattern, the strategic inflection point framework, the "disagree and commit" pattern for decisions. He didn't invent all of them, but he named them, documented when to use them, and made them part of the company's operating language. Patterns reduced ambiguity and sped up execution.
Andreessen uses pattern language in investing: "network effects," "platform," "full-stack." He maps companies to patterns and then asks whether the instance fits the pattern's success conditions. The pattern is a lens; the edge is in knowing when the pattern applies and when the company is a different beast.
Section 6
Visual Explanation
Design Pattern — Recurring problem → Named solution with known trade-offs. Apply when context matches; adapt when needed. Misapplying the pattern (wrong context) turns it into an anti-pattern.
Section 7
Connected Models
Design patterns sit with modularity, abstraction, and the reuse of structure across problems.
Reinforces
[Abstraction](/mental-models/abstraction)
Abstraction hides detail behind an interface. Design patterns often rely on abstraction — e.g. program to an interface, not an implementation. The pattern defines the abstract shape; the concrete implementation varies. Both reduce complexity by elevating the level of discourse.
Reinforces
[Modularity](/mental-models/modularity)
Modularity is the decomposition of a system into independent pieces with clear boundaries. Patterns like Observer, Factory, and Adapter support modularity by standardising how components connect. The pattern is a recipe for a kind of modular structure.
Tension
Anti-patterns
Anti-patterns are recurring solutions that are ineffective or harmful. A design pattern applied in the wrong context becomes an anti-pattern — e.g. Singleton causing global state and testing pain. The tension: the same named structure can be pattern or anti-pattern depending on context.
Tension
Technical Debt
Technical debt often accumulates when a quick fix is chosen over the "right" pattern. The tension: patterns take time to apply; debt is the cost of not applying them. The balance is to use patterns where the problem will recur and to accept one-off solutions where it won't.
Section 8
One Key Quote
"Design patterns are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context."
— Gang of Four, Design Patterns (1994)
The key is "in a particular context." Patterns are not universal; they're solutions that work in a defined situation. The practitioner's job is to know the context of each pattern and to apply it only when the situation matches. Customise to the problem; don't force the problem into the pattern.
Section 9
Analyst's Take
Faster Than Normal — Editorial View
Patterns are vocabulary. When a team can say "we're using a circuit breaker" or "we're doing land-and-expand," communication is faster and misalignment is lower. Build a shared pattern language for your domain — product, eng, GTM — and use it. Add new patterns when you solve a recurring problem in a way worth repeating.
Check the context. Every pattern has a "when to use" and "when not to use." Skipping that check is how good patterns become anti-patterns. Before adopting a pattern, state the problem you have and the conditions that make this pattern appropriate. If the conditions don't hold, don't use it.
Name your own patterns. When you solve a problem in a way you'll see again, name it. "We do the X pattern for Y." That turns local knowledge into reusable structure. The best teams have a small set of internal patterns that capture how they work.
Avoid pattern theatre. Using a pattern for its own sake — "we're a platform" when you're not, "we use microservices" when a monolith would do — is cargo cult. The pattern should fit the problem. When in doubt, describe the problem first; then see if a pattern fits.
Section 10
Summary
A design pattern is a reusable solution to a recurring problem in a given context. It gives shared vocabulary and avoids reinventing. Use patterns when the problem and context match; adapt them; document when to use them. Don't force a pattern when the context doesn't fit — that creates anti-patterns. Build a small repertoire for your domain and name new patterns when you solve recurring problems well.
Patterns for resilience and operations: circuit breaker, bulkhead, timeouts. Practical patterns for building systems that survive production.
Leads-to
[Refactoring](/mental-models/refactoring)
Refactoring is improving structure without changing behaviour. When you recognise that existing code implements (or should implement) a pattern, refactoring can align the code with the pattern. Patterns give a target shape for refactoring.
Leads-to
Repeatable Systems
Repeatable systems are processes or structures you can run again with confidence. Design patterns are repeatable at the design level — you repeat the solution structure. Documenting patterns is a step toward repeatable systems at scale.
