Skill: PVP Composition

Six paragraphs that land like analysis, not pitch: workload-class observations, pattern recognition, math for both sides, soft close.

Overview

Craft a permissionless value proposition: a six-paragraph value-first message so specific the recipient would forward it to a colleague even if they never buy. Covers thesis, three structural observations, architectural pattern recognition, multi-vendor industry pattern, math for both sides, and the soft close. Includes the worked anatomy of the canonical DDN-Nebius PVP and editorial guardrails.

Use cases

  • PVPs that read like analysis, not credentials sheets

    Claude learns the six-paragraph structure: thesis, three structural observations (technical, procurement, regulatory), architectural pattern recognition, multi-vendor industry pattern, math for both sides, and a one-sentence conditional close. Customer references appear inside the observations as proof, never at the headline as a logo wall.

  • Editorial guardrails baked into every draft

    No em dashes, no rule-of-three lists, no negative parallelism, no rhetorical questions to the reader, no AI vocabulary, no inflated symbolism. Specific named examples beat vague claims (KAUST, Helmholtz Munich, TACC beats 'leading research institutions').

View full skill

PVP Composition

The permissionless value proposition is the hardest thing a PVP-PQS briefing produces. This skill is the craft guide. Read it before drafting any PVP body. Compose with the Phoenix PVP-PQS Framework skill for the surrounding 5-phase orchestration and the Phoenix HTML Briefing Structure skill for the layout.

When to use

  • Drafting a PVP body for a Phoenix-branded executive briefing.
  • Reviewing or rewriting an existing PVP draft against the editorial guardrails.
  • Composing a value-first cold email outside the briefing format (the same six-paragraph shape works).

The core idea

A PVP is a message so specific and valuable the recipient would forward it to a colleague even if they never buy. The data is the message. Customer references are not the message. The recipient should finish reading and think "I didn't know that about my own situation", not "this vendor has impressive logos."

Two failure modes account for almost every bad PVP:

  1. Credentials sheet. "We work with X, Y, and Z." The recipient doesn't care about the logo wall.
  2. Generic pitch. "We help companies like you scale AI." Nothing in the message could only have been written to them.

A real PVP delivers structural insight the recipient can act on whether or not they buy:

  • Workload-class observations. "Here are N specific workload signatures in your pipeline that will hit procurement-grade tension on your current architecture."
  • Numerical anchors. "At cluster size above 2048 GPUs on Vera Rubin, synchronous checkpoint writes hit tail-latency walls on shared-everything fabrics."
  • Forward-looking timing. "You'll start hearing about this in 2027 from your largest customers' procurement teams."
  • Industry pattern recognition. "The reason CoreWeave names five storage partners publicly is structural, not preference."

Customer references appear inside these observations as proof the customer has been in this conversation before. Two or three named references at the right peer scale is plenty. Five is name-dropping.

PVP body structure: six paragraphs

1. Thesis (one paragraph)

Open with the target's situation in one breath. Then deliver the unique insight in one sentence.

Pattern that travels:

"You've signed [public commitment]. [Incumbent or status quo] is your only [thing]. Inside that envelope are [workload classes] that don't belong on [the incumbent's architecture pattern], and you'll start hearing about them in [year] from [specific customer or compliance team]. [Number] specifically:"

The "X specifically:" hand-off is what makes the next three paragraphs feel earned.

2. Three structural observations

Each observation:

  • Names a specific workload class or procurement scenario. Not "high-performance workloads", but "synchronous checkpoint writes at greater than 2048 GPU scale on Vera Rubin."
  • Identifies the failure mode. What goes wrong. Why it goes wrong. Be technical.
  • Gives a forward-looking timing cue. When the target will see this. Who will surface it.
  • Embeds proof points inside the observation. Named customers, named systems, named institutions. Two or three across the whole PVP, never a cluster.

The three observations should map to different buyer concerns:

  • One technical (architecture failure mode at scale)
  • One procurement and commercial (reference architecture compliance, contractual structure)
  • One regulatory and customer-specific (sovereign tenants, audit trails, named end-customer)

3. Architectural pattern recognition (one paragraph)

Connect the target's heritage or strategic position to why the customer's category exists. Pulls in the customer's deepest expertise without sounding like a pitch.

Pattern:

"[Target observation about their heritage / a recent benchmark / a strategic hire] isn't a coincidence. [The heritage / discipline] was [a domain the customer dominates], and [that domain] ships [the customer's product category]. [Customer] has powered [specific N of a relevant proof: TOP500 systems, NHS deployments, federal contracts], including ones at institutions whose [end-users] will eventually be your [tenants / customers]. That's not credentials. It's architectural pattern recognition."

The "that's not credentials, it's pattern recognition" beat is load-bearing. It reframes proof points as analysis.

4. Multi-vendor industry pattern (one paragraph)

What peers at the target's scale do, with a named reference, and why. This validates the customer's place at the table.

Pattern:

"The [target's industry] pattern at your scale is [the customer's positioning, e.g., multi-vendor]. [Named peer] names [N] [vendor type] partners publicly. The reason is structural: [the customer's category] inside a [target's commitment envelope] doesn't fit [the incumbent's pattern]."

This paragraph is where the customer earns the right to be considered. Not "we're worthy" but "everyone at this scale already does what we're proposing."

5. Math for both sides (one paragraph)

What the target gets. What the customer gets. The customer's number is small relative to the target's envelope. The target's win is operational: fewer escalations, RFPs they can answer, audit trails that hold up.

Pattern:

"The math for [target] is [operational win: fewer escalations, fewer tier-2 RFPs you can't answer, faster sovereign procurement]. The math for [customer] is [percentage] of your committed [envelope]."

The target's win must come first and must be operational, not financial. The customer's number is honest and small.

6. Soft close (one line)

"If [specific scenario], we'd want to know."

Never a hard CTA. The recipient knows how to find the customer if they want to talk. The soft close says "we have a point of view and we'd love to hear yours", not "click here to schedule."

Worked anatomy: the DDN / Nebius PVP

Every figure traces to a tool call or a public source. The full HTML output lives at /samples/phoenix-pvp-pqs-ddn-nebius.html.

Subject line: "Three workloads in your 5 GW pipeline that won't fit on WEKA." (Three specifics in 13 words: count, magnitude, incumbent.)

Thesis: "You've signed $29.4B in GPU capacity with Microsoft and Meta. WEKA is your only named storage partner. Inside that envelope are workload classes that don't belong on a software-defined fabric, and you'll start hearing about them in 2027 from your largest customers' procurement teams. Three specifically:"

  • "$29.4B in GPU capacity" maps to sec_filing_section on Microsoft + Meta 6-Ks
  • "WEKA is your only named storage partner" maps to web search on weka.io press + Nebius hardware page
  • "2027" is tied to Meta's Vera Rubin start date (public)

Observation 1 (technical): Frontier-scale checkpoint storms. Once clusters cross ~2048 GPUs on Vera Rubin, synchronous checkpoint writes hit tail-latency walls on shared-everything fabrics. The failure mode is jitter, not bandwidth. The incumbent's published benchmarks don't extend to this scale.

Observation 2 (procurement): NVIDIA DGX SuperPod reference compliance. The current SuperPod RA designates a certified storage appliance, not a software-defined overlay. When the target's hyperscaler tenants procure against the RA literally, the answer to "which storage in your stack is the appliance tier" is a procurement question.

Observation 3 (regulatory): Single-tenant regulated workloads. Sovereign pipelines procure accountable hardware boundaries, not virtual partitioning: audit trails, single-vendor remediation, physical isolation. Named institutional references (KAUST, Helmholtz Munich, TACC) appear here, inside the observation, as proof the customer has been in this conversation for fifteen years.

Pattern recognition: "ISEG2 hitting #13 on TOP500 isn't a coincidence. Yandex's engineering DNA was HPC, and HPC ships parallel filesystem appliances. DDN has powered dozens of TOP500 systems, including ones at institutions whose researchers will eventually be your tenants. That's not credentials. It's architectural pattern recognition."

Industry pattern: "The neo-cloud pattern at your scale is multi-vendor. CoreWeave names five storage partners publicly. The reason is structural: workload signatures inside a 5+ GW pipeline don't fit one fabric model."

Math for both sides: "The math for Nebius is fewer escalations and fewer tier-2 RFPs you can't answer. The math for DDN is 8 to 12% of your committed storage envelope."

Soft close: "If two of the three above are already on your roadmap, we'd want to know."

Editorial guardrails: final pass before HTML

Run these as a checklist before composing the HTML output.

  • No em dashes anywhere in the body. Replace with commas, periods, or restructure the sentence. Includes typographic em dashes, double hyphens, and word-em-dash-word constructions.
  • No rule-of-three lists in prose. "Fast, scalable, and secure" is a tell. Separate into sentences or use the numbered observations.
  • No negative parallelism. "Not just X, but Y." "Not only X, but also Y." Just say Y.
  • No rhetorical questions to the reader. "But what does this mean for your business?" They came to you. They know what it means.
  • Specific named examples beat vague claims. "KAUST, Helmholtz Munich, TACC" beats "leading research institutions."
  • Sentence case for headings unless a proper noun. "The PVP anatomy" not "The PVP Anatomy". Proper nouns retain their case (TOP500, NVIDIA).
  • No AI vocabulary. Avoid: leverage, robust, seamless, cutting-edge, harness, navigate, delve, tapestry, landscape, paradigm, ecosystem, unlock, empower, transform, revolutionize.
  • No inflated symbolism. Don't tell the recipient something is "exciting" or "important" or "transformative." Show the number, let them feel the size.
  • No promotional language. Avoid "industry-leading", "best-in-class", "state-of-the-art", "next-generation". If the customer is industry-leading, the named proof points show it.

What to do if a figure doesn't trace

Every dollar amount, percentage, capacity number, contract value, ranking, or named deployment in the PVP must trace to either:

  • A specific Phoenix MCP tool call (named in the anatomy block under the PVP), or
  • A specific public source (SEC filing, named press release, named benchmark list, named partnership announcement).

If it doesn't trace, you have two options:

  1. Cut it. Stronger with five real figures than with seven, two of which are vibes.
  2. Generalize honestly. "Industry attach rates" can replace a specific percentage if you cite IDC or Gartner. "GPU-class scale" can replace a specific count.

The anatomy block under the PVP is not decoration. It's the verification layer.