Positioning and the rule of "three"

This is an excerpt from my upcoming Developer Marketing and Developer Relations book. Be sure to subscribe to this newsletter and be notified when pre-sales are available.

Spend any time with marketing people and you’ll quickly see how much they adapt to “three bullet” thinking. Broad statements are usually followed by three bullet points that support the statement. It’s not a hard and fast rule, but there is some science and a lot of history behind it.

Somewhere around the middle of the 300s BCE, the Greek philosopher Aristotle devised a rhetorical framework that shapes (among many things) marketing messaging to this day. He posited that the best, most effective persuasive messaging contained three elements:

• Ethos, an appeal to credibility and authority
• Pathos, an emotional connection
• Logos, logic and reasoning

A little more recently, in 1956, a cognitive psychologist named George Miller authored a seminal paper entitled, “The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information.” Whether we consciously know it or not, all marketing people have internalized his work and use it daily. In the paper, he made a few observations:

• People can hold at most seven (give or take two) chunks of information in their short-term memory
• Information is best when it is chunked into smaller pieces (this is why telephone numbers often have “breaks” in them and credit card numbers are grouped into four chunks of three to four numbers)
• The more items you add, the more cognitive load increases

Over time, marketers have adopted this work and it has become the de facto model, whether or not we know of its origins. We think in small, digestible chunks of information so as not to overload our prospects’ cognitive load. We try to provide logical breaking points in our messaging. In so doing, we have effectively standardized on a positioning framework that looks something like this, with one primary positioning statement and three supporting points:

Positioning Statement
 
- Supporting point 1
- Supporting point 2
- Supporting point 3

You see this everywhere you go in marketing collateral. But with developer marketing, we take Miller’s work and suffuse it with Aristotle’s rhetorical framework, and our positioning frameworks often look like this:

Positioning statement

- An emotional point about why you will love this product
- A logical point about what unique capabilities this product has for you
- A credible point that explains why you can depend on this product

This is the positioning framework I created as the first Director of Marketing for Amazon Web Services:

Amazon Web Services is a cloud computing platform
that helps developers build scalable applications quickly.

- Flexible (Pathos): Easy to use and get started.
  How: Self-service APIs that let you provision infrastructure
  in minutes, not weeks. No procurement process required.
  Without it: Developers wait weeks for provisioning approvals
  and commit to multi-year contracts before writing a line of code.
  Proof: Pay only for what you use, no upfront commitment,
  sign up with a credit card and start building immediately.

- Cost-effective (Logos): No contracts, pay as you go,
  transparent pricing.
  How: Usage-based billing with per-hour granularity and a public
  pricing page that requires no sales call to access.
  Without it: Teams over-provision infrastructure to avoid running
  out of capacity, paying for resources they never use.
  Proof: Reduces capital expenditure, turns infrastructure into
  operating expense, customers report 30-60% cost savings.

- Dependable (Ethos): Scalability and reliability from the company
  who knows how to run infrastructure at web scale.
  How: The same infrastructure that powers Amazon.com, with
  multi-region redundancy and automated failover.
  Without it: Teams build and maintain their own redundancy,
  pulling engineering time away from product development.
  Proof: Powers Amazon.com, 99.95% SLA, proven at massive scale.

Differentiation summary: AWS is the only cloud platform that
combines self-service simplicity with Amazon-scale reliability,
so developers can build anything without managing infrastructure.

Notice how each pillar now has four layers. The value claim tells you what. The mechanism tells you how. The consequence tells you what happens if you don't. And the proof gives you evidence. This structure comes from combining Aristotle's rhetorical framework with ideas from several other positioning practitioners, and it holds up across every developer product I have worked on.

In my experience, most developer-focused products evolve their positioning into some form of the following:

Positioning that identifies the uniqueness of a product in a market

• A supporting point about productivity improvements or ease of use (appeal to the emotion of the buyer)
• A supporting point that dives into what's unique about the product and what that enables (appeal to logic)
• A supporting point about dependability or scalability, or both (appeal to credibility)

For each pillar, add a mechanism sentence explaining how your product delivers on the claim. Developers do not trust claims without mechanisms. "Fast" means nothing. "Written in Rust with a columnar storage engine optimized for time-series queries" means everything. The mechanism is the bridge between the value claim and the evidence.

Then add a consequence sentence for each pillar: what happens if the customer does not act? What is the cost of the status quo? This is especially powerful for enterprise sales, where loss aversion drives decisions, and for breaking through status quo inertia, which is often your biggest competitor.

After all three pillars, write a differentiation summary: one sentence that synthesizes the entire differentiation story. This closes the narrative loop from problem to solution. It becomes your reusable asset for press boilerplate, executive summaries, and the sentence your CEO uses when someone at a dinner party asks what your company does.

The expanded template looks like this:

Positioning statement

- Pillar 1 (Pathos): [Value claim]
  How: [Mechanism that enables it]
  Without it: [Consequence of inaction]
  Proof: [Features, metrics, customer evidence]

- Pillar 2 (Logos): [Value claim]
  How: [Mechanism that enables it]
  Without it: [Consequence of inaction]
  Proof: [Features, metrics, customer evidence]

- Pillar 3 (Ethos): [Value claim]
  How: [Mechanism that enables it]
  Without it: [Consequence of inaction]
  Proof: [Features, metrics, customer evidence]

Differentiation summary: [One sentence synthesizing all pillars]

For the complete copy-paste version with anchor tests, competitive differentiation, and proof point sections, see the positioning template.

Problem-framing variants

Your positioning statement contains a problem. But the same product can frame its problem three different ways, and the framing you choose shapes your entire narrative.

Category-anchored: frame the problem as a gap in the category. "Most backend platforms force you to stitch together products from multiple vendors, each with its own API, billing model, and failure mode." This works best when you are entering an established category and want to show why your approach is different.

Use-case-anchored: frame the problem as a daily workflow pain. "Developers spend 40% of their time on infrastructure instead of product features." This works best when you are creating a new category and need to build empathy before naming the solution.

Alternative-anchored: frame the problem as frustration with the current approach. "Managing separate authentication, storage, and database services means separate vendor relationships, separate outages, and separate bills." This works best when you are displacing an incumbent.

All three framings can be true at the same time. The question is which one best matches your go-to-market motion. Try writing all three, share them with five customers, and see which one generates the strongest "yes, exactly" reaction.

Validating your positioning

A positioning statement is only as strong as the tests it survives. Before moving to messaging, run these four tests. If any of them fails, go back and revise. Messaging cannot compensate for positioning that does not hold up under scrutiny.

1. The duck test. If it walks like a database, call it a database. Does your positioning clearly name what you are in language a developer would use? If you need to explain your category label, it is wrong. "Service business" fails. "Time-series database" passes. "Developer platform" is borderline and probably fails. Credit to Dave Kellogg for this framing.

2. The category test. Can your category alone answer "what is this?" Can your primary use case alone answer it? If the answer to either is no, the element is too vague. I happened upon a company called FletchPMM and they call this "the anchor sufficiency test," which is pretty cool. Whatever you call it, this is the single most practical validation step you can apply after writing a positioning statement.

3. The swap test. Can your primary competitor say your positioning statement truthfully by replacing your product name with theirs? If yes, you have table stakes, not differentiation. April Dunford articulated this test best: "If your competitor can say the exact same thing, you don't have positioning."

4. The consequence test. Does each pillar have a tangible, specific consequence of inaction? "Teams will struggle" is vague. "Teams over-provision by 40-60% and lock into three-year contracts" is specific. If the consequence is vague, the pillar is probably not solving a real problem. This is another concept from Kellogg's FABC framework.

Together, these four tests catch problems that any single framework misses.

Argument columns: a second view of your pillars

Everything above organizes your positioning horizontally: one headline at the top, three pillars beneath it, proof points beneath each pillar. This is the right primary structure. It ensures consistency across all content.

But content creators also benefit from a vertical view. Take each pillar and stack its elements into a column: the sub-problem, the value claim, the mechanism, the features, and the benefit. Each column is now a self-contained narrative that can be lifted out as a blog post, a sales talk track, a LinkedIn post, or a section of a conference talk.

This is not a different framework. It is the same content viewed sideways. The horizontal hierarchy ensures consistency. The vertical columns enable execution. For a detailed treatment with templates, see the positioning template.

When I went through my Greek philosopher phase in my early 30s, I was shocked and humbled to learn that Aristotle was a far better Product Marketing Manager than me. Two thousand years later, his rhetorical framework still holds, and the additions above only make it sharper.

For the AI prompt that generates a complete positioning framework using this methodology, see my complete developer marketing guide. For more frameworks and templates, see my book Picks and Shovels.