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. For the surrounding research phases and the briefing layout, use the PVP-PQS briefing workflow in the GTM Marketplace.

When to use

• Drafting a PVP body for an HG-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.

Before you draft: confirm the target is greenfield

A PVP to a company that already runs the customer's product reads as a sales email, not an insight. Check it with HG first, then the web:

1. HG install check. Resolve the customer's vendor and products with get_vendor_information or product_search_and_enrich (search is free), then call company_technographic on the target with vendor_ids or product_ids. A current install (product_last_verified_date within 90 days) means it's not greenfield: pick another target or switch to an expansion angle. No row is good evidence, not proof; HG coverage of a given product can be partial.
2. Public relationship check. Two web searches: "[customer] [target] partnership" and "[customer] [target] customer". Any public relationship disqualifies the greenfield framing.
3. Record what you ran and what each check returned. It's the first claim the reader will test.

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 briefing built around this PVP is the reference run of the PVP-PQS briefing workflow in the GTM Marketplace.

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 Nebius's 6-K filings announcing the Microsoft and Meta agreements. 6-Ks are foreign-issuer filings, so they come from sec_full_text_search (formTypes:["6-K"], Nebius's ticker in tickers, a startDate that covers the announcements), not from sec_filing_section, which reads US domestic 10-K, 10-Q and 8-K filings only
• "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 rendering

Run these as a checklist before the PVP goes into the briefing or the email.

• No em dashes anywhere, including the subject line and quoted examples. Replace with commas, colons, periods, or restructure the sentence. This covers typographic em dashes, en dashes used as dashes, double hyphens, and word-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 HG MCP Server tool call with its parameters (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.

Common pitfalls

1. Leading with logos. References belong inside the observations, two or three at most.
2. Skipping the greenfield check. An HG install row or a public partnership the reader already knows about sinks the whole PVP.
3. Figures with no anatomy line. If you can't name the tool call or the public source, cut the figure.
4. Reading foreign-issuer filings with sec_filing_section. 20-F and 6-K filings go through sec_full_text_search.
5. Financial math first. The target's win is operational and comes first; the customer's number is small and honest.
6. A hard CTA. The close is one soft line.

Reference

• V2 tool docs: https://phoenix.hginsights.com/docs/mcp-tools/v2/sec-full-text-search and https://phoenix.hginsights.com/docs/mcp-tools/v2/company-technographic
• Full docs for LLMs: https://phoenix.hginsights.com/docs/llms-full.txt
• Related skills: hg-mcp-calling-rules, hg-sec-research, hg-citation-discipline, humanizer, opening-line-discipline