IntelIP · hudsonaikins · Apr 12, 2026 · Apr 12, 2026
@@ -114,6 +114,10 @@ The paid layer should sit on top of that core through hosted workflows, collabor
 - [Open-Core Roadmap](docs/OPEN_CORE_ROADMAP.md)
 - [Benchmark Scenarios](benchmark_scenarios/README.md)
 - [Growth Assets](docs/growth/README.md)
+- [Benchmark Outreach Pack](docs/growth/benchmark-outreach-pack.md)
+- [Value Proposition](docs/growth/value-proposition.md)
+- [Design-Partner Offer](docs/growth/design-partner-offer.md)
+- [Adoption Dashboard](docs/growth/adoption-dashboard.md)
 - [Design-Partner Operating System](docs/growth/design-partner-operating-system.md)
 - [MVP Pricing Release Guide](docs/release/MVP_PRICING_RELEASE.md)
 - [Woodpecker + Hostinger Runbook](docs/deployment/WOODPECKER_HOSTINGER_SETUP.md)

@@ -10,7 +10,11 @@
 - [Open-Core Roadmap](OPEN_CORE_ROADMAP.md)
 - [Benchmark Scenarios](../benchmark_scenarios/README.md)
 - [Growth Assets](growth/README.md)
+- [Benchmark Outreach Pack](growth/benchmark-outreach-pack.md)
+- [Value Proposition](growth/value-proposition.md)
+- [Design-Partner Offer](growth/design-partner-offer.md)
 - [Design-Partner Operating System](growth/design-partner-operating-system.md)
+- [Adoption Dashboard](growth/adoption-dashboard.md)
 - [MVP Pricing Release Guide](release/MVP_PRICING_RELEASE.md)
 
 ## Deployment and CI/CD

@@ -7,22 +7,24 @@ This folder holds the minimum set of docs needed to turn ProfitCtl into somethin
 1. Read [Value Proposition](value-proposition.md) to understand the public message we should lead with.
 2. Read [Design-Partner Offer](design-partner-offer.md) before asking anyone to pilot the tool.
 3. Read [Benchmark Positioning](benchmark-positioning.md) to choose the right comparison story.
-4. Read [Compare Reporting Guide](compare-reporting-guide.md) before using `profitctl compare` in demos or content.
-5. Read [Design-Partner Intake](design-partner-intake.md) before asking anyone to pilot the tool.
-6. Read [Design-Partner Targeting Rubric](design-partner-targeting-rubric.md) before adding anyone to the first 10 targets.
-7. Use [First 10 Design-Partner Targets](design-partner-target-list-template.md) as the working list.
-8. Follow [Design-Partner Outreach Sequencing](design-partner-outreach-sequencing.md) for first touch through commitment.
-9. Apply [Design-Partner Qualification Criteria](design-partner-qualification-criteria.md) before advancing a target.
-10. Track movement in [Design-Partner Progress Tracking](design-partner-progress-tracking.md).
-11. Keep the weekly dashboard in [Adoption Dashboard](adoption-dashboard.md).
-12. Use [Weekly Review Template](weekly-review-template.md) during Friday review.
-13. Follow [Source-Of-Truth Guidance](source-of-truth-guidance.md) before updating any tracker.
-14. Run the weekly motion from [Design-Partner Operating System](design-partner-operating-system.md).
-15. Capture each serious evaluator with [Design-Partner Evaluation Template](design-partner-evaluation-template.md).
+4. Use [Benchmark Outreach Pack](benchmark-outreach-pack.md) to choose the one approved benchmark asset for the conversation.
+5. Read [Compare Reporting Guide](compare-reporting-guide.md) before using `profitctl compare` in demos or content.
+6. Read [Design-Partner Intake](design-partner-intake.md) before asking anyone to pilot the tool.
+7. Read [Design-Partner Targeting Rubric](design-partner-targeting-rubric.md) before adding anyone to the first 10 targets.
+8. Use [First 10 Design-Partner Targets](design-partner-target-list-template.md) as the working list.
+9. Follow [Design-Partner Outreach Sequencing](design-partner-outreach-sequencing.md) for first touch through commitment.
+10. Apply [Design-Partner Qualification Criteria](design-partner-qualification-criteria.md) before advancing a target.
+11. Track movement in [Design-Partner Progress Tracking](design-partner-progress-tracking.md).
+12. Keep the weekly dashboard in [Adoption Dashboard](adoption-dashboard.md).
+13. Use [Weekly Review Template](weekly-review-template.md) during Friday review.
+14. Follow [Source-Of-Truth Guidance](source-of-truth-guidance.md) before updating any tracker.
+15. Run the weekly motion from [Design-Partner Operating System](design-partner-operating-system.md).
+16. Capture each serious evaluator with [Design-Partner Evaluation Template](design-partner-evaluation-template.md).
 
 ## What These Docs Are For
 
 - making the benchmark scenarios part of the product story
+- packaging the approved benchmark outreach assets into one reusable set
 - making the value proposition explicit for buyers
 - defining a clear design-partner offer
 - keeping demo output short, repeatable, and decision-oriented

@@ -0,0 +1,76 @@
+# Benchmark Outreach Pack
+
+This is the approved benchmark-led outreach set for early `ProfitCtl` conversations.
+
+Use these assets when the goal is to get an evaluator from interest to one concrete `compare` run.
+
+## Operating Rule
+
+Pick one benchmark pair only.
+
+Do not send multiple comparisons in the first conversation. The point is to prove one decision, not showcase every feature.
+
+## Pack 1: Open-Core Packaging
+
+- Question:
+  should the team stay with simple tiered packaging or move toward a clearer mix/open-core shape?
+- Lead metric:
+  recurring margin
+- Benchmark command:
+
+```bash
+profitctl compare benchmark_scenarios/open_core_tiered.yml benchmark_scenarios/open_core_mix.yml
+```
+
+- Shareable report:
+  [open_core_tiered_vs_mix.md](../../benchmark_scenarios/reports/open_core_tiered_vs_mix.md)
+- Best fit:
+  founder, product, or growth-led packaging decisions
+
+## Pack 2: Pilot Vs Steady State
+
+- Question:
+  is pilot revenue making the contract look healthier than it will be in steady state?
+- Lead metric:
+  operating margin
+- Benchmark command:
+
+```bash
+profitctl compare benchmark_scenarios/hybrid_steady_contract.yml benchmark_scenarios/hybrid_pilot_contract.yml
+```
+
+- Shareable report:
+  [hybrid_steady_vs_pilot.md](../../benchmark_scenarios/reports/hybrid_steady_vs_pilot.md)
+- Best fit:
+  founder, sales, CS, or finance conversations around enterprise deal shape
+
+## Pack 3: Covenant Safety
+
+- Question:
+  does the contract still hold up once recurring costs are modeled honestly?
+- Lead metric:
+  covenant status
+- Benchmark command:
+
+```bash
+profitctl compare benchmark_scenarios/hybrid_operating_safe.yml benchmark_scenarios/hybrid_operating_breach.yml
+```
+
+- Shareable report:
+  [hybrid_safe_vs_breach.md](../../benchmark_scenarios/reports/hybrid_safe_vs_breach.md)
+- Best fit:
+  finance, RevOps, or product/finance alignment conversations
+
+## How To Use This Pack
+
+1. choose the benchmark pair that matches the evaluator's question
+2. send one report or one command only
+3. state the lead metric before any secondary metrics
+4. ask whether they want to run the closest version of their own scenario next
+
+## What Not To Do
+
+- do not attach all benchmark reports at once
+- do not lead with Monte Carlo or implementation details
+- do not talk about one-time revenue before recurring economics are clear
+- do not move to calibration until the evaluator agrees the first comparison was useful
@@ -8,6 +8,7 @@ Use this as the working list for the first evaluator pipeline.
 - update weekly
 - replace weak targets fast
 - do not add targets without a clear question and a benchmark match
+- keep named target accounts in a private operating system such as Linear or an internal sheet now that the repo is public
 
 ## Template
 
@@ -35,4 +36,3 @@ Use this as the working list for the first evaluator pipeline.
 ## Weekly Operating Rule
 
 If a target has no response after three touches and no clear reason to keep it, replace it with a better fit.
-