diff --git a/README.md b/README.md index 06c37da..c594a49 100644 --- a/README.md +++ b/README.md @@ -114,6 +114,7 @@ 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) +- [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) diff --git a/docs/DOCS_INDEX.md b/docs/DOCS_INDEX.md index ceae1d3..1755529 100644 --- a/docs/DOCS_INDEX.md +++ b/docs/DOCS_INDEX.md @@ -10,6 +10,7 @@ - [Open-Core Roadmap](OPEN_CORE_ROADMAP.md) - [Benchmark Scenarios](../benchmark_scenarios/README.md) - [Growth Assets](growth/README.md) +- [Design-Partner Operating System](growth/design-partner-operating-system.md) - [MVP Pricing Release Guide](release/MVP_PRICING_RELEASE.md) ## Deployment and CI/CD diff --git a/docs/growth/README.md b/docs/growth/README.md index 77ede48..14c70e5 100644 --- a/docs/growth/README.md +++ b/docs/growth/README.md @@ -7,12 +7,15 @@ This folder holds the minimum set of docs needed to turn ProfitCtl into somethin 1. Read [Benchmark Positioning](benchmark-positioning.md) to understand the message we should lead with. 2. Read [Compare Reporting Guide](compare-reporting-guide.md) before using `profitctl compare` in demos or content. 3. Read [Design-Partner Intake](design-partner-intake.md) before asking anyone to pilot the tool. +4. Run the weekly motion from [Design-Partner Operating System](design-partner-operating-system.md). +5. 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 - keeping demo output short, repeatable, and decision-oriented - giving us a simple intake loop for early users and design partners +- turning evaluator conversations into repeatable product and GTM feedback ## What These Docs Are Not For @@ -20,4 +23,3 @@ This folder holds the minimum set of docs needed to turn ProfitCtl into somethin - long-term brand work - enterprise sales playbooks - vague growth language without a direct action - diff --git a/docs/growth/design-partner-evaluation-template.md b/docs/growth/design-partner-evaluation-template.md new file mode 100644 index 0000000..5d0db3b --- /dev/null +++ b/docs/growth/design-partner-evaluation-template.md @@ -0,0 +1,78 @@ +# Design-Partner Evaluation Template + +Use this template for every serious evaluator or design-partner loop. + +## Company + +- Company: +- Contact: +- Role: +- Date: + +## Qualification + +- Concrete pricing or contract decision in motion: +- Best matching benchmark pair: +- Why they are a fit now: + +## Install + +- Install path used: + - `curl install` + - `Homebrew` + - `source build` +- Install completed without help: +- Friction encountered: + +## Activation + +- First command run: +- Did they complete one compare run: +- Scenario used: +- Metric they trusted first: +- Output they found most useful: + +## Calibration + +- Did they provide real inputs: +- Which inputs were available immediately: +- Which inputs were hard to map: +- Did calibration complete: + +## Decision Signal + +- Real question they were trying to answer: +- Did the output change or clarify the decision: +- Would they use `ProfitCtl` before a real pricing or contract decision: +- Confidence level: + - low + - medium + - high + +## Design-Partner Signal + +- Open to follow-up call: +- Open to design-partner loop: +- Success criterion for follow-up: + +## Product Friction + +- Onboarding friction: +- Scenario/config friction: +- Output/reporting friction: +- Trust or verification friction: + +## Recommended Next Action + +- `docs fix` +- `install fix` +- `config/model fix` +- `reporting/output fix` +- `design-partner call` +- `not a fit` + +## Follow-Up Notes + +- next owner: +- next date: +- specific ask: diff --git a/docs/growth/design-partner-operating-system.md b/docs/growth/design-partner-operating-system.md new file mode 100644 index 0000000..dcdab83 --- /dev/null +++ b/docs/growth/design-partner-operating-system.md @@ -0,0 +1,225 @@ +# Design-Partner Operating System + +This is the operating model for turning `ProfitCtl` from a credible open-core CLI into a product with provable user value. + +The goal is not vague “growth.” The goal is to get real teams to install the product, run it on a real decision, and tell us whether it changed the decision quality. + +## Operating Goal + +Over the next 4 to 6 weeks, drive 5 to 10 serious evaluator loops through this sequence: + +benchmark -> install -> compare -> calibrate -> follow-up + +For each evaluator, capture: + +- whether they installed without help +- whether they ran a benchmark or their own config +- whether they trusted the output enough to discuss a real pricing or contract decision +- what blocked broader internal adoption + +## Who We Are Targeting + +Start with teams that already have a pricing or contract decision in motion. + +Best-fit evaluators: + +- B2B SaaS founders deciding between tiered, mix, or hybrid pricing +- product or finance leads reviewing recurring margin before shipping packaging changes +- RevOps, sales, or CS leaders defending pilot-heavy contract structures +- teams that can share a small set of real inputs for calibration + +Bad-fit evaluators for this phase: + +- users looking for generic financial planning software +- teams without a concrete pricing or contract question +- users who want a hosted collaboration product today +- users who cannot install a CLI or provide inputs + +## Core Offer + +Lead with one offer only: + +> We will help you compare one pricing or contract shape against one realistic alternative before you commit to it. + +That keeps the conversation anchored to the product value the CLI already delivers. + +## Funnel Definition + +The funnel is deliberately short. + +1. `Target` +One company/contact with a clear pricing, packaging, or contract question. + +2. `Qualified` +They fit the target criteria and can articulate the decision they are trying to make. + +3. `Installed` +They installed `profitctl` locally or via Homebrew. + +4. `Activated` +They ran one benchmark comparison or a config close to their own scenario. + +5. `Calibrated` +They provided enough real input to map or normalize assumptions. + +6. `Design Partner` +They agreed to one follow-up loop with a defined success criterion. + +## Required Assets + +Every evaluator motion should use the same assets: + +- [Benchmark Positioning](benchmark-positioning.md) +- [Compare Reporting Guide](compare-reporting-guide.md) +- [Design-Partner Intake](design-partner-intake.md) +- [Design-Partner Evaluation Template](design-partner-evaluation-template.md) +- one benchmark pair from [`benchmark_scenarios`](../../benchmark_scenarios/README.md) + +If an evaluator cannot get through the motion with those assets, the product or docs are still too weak. + +## Standard Motion + +### Step 1: Pick the right benchmark pair + +Choose the benchmark pair that matches their question: + +- tiered vs mix +- steady-state hybrid vs pilot-heavy hybrid +- covenant-safe vs covenant-breaching contract + +Do not demo every feature. + +### Step 2: Drive to install + +Use the public install path first: + +```bash +curl -fsSL https://raw.githubusercontent.com/IntelIP/ProfitCtl/main/scripts/install.sh | bash +``` + +Or Homebrew: + +```bash +brew tap IntelIP/profitctl +brew install profitctl +``` + +The install itself is part of the product test. If it requires hand-holding, record that as product friction. + +### Step 3: Drive to one compare run + +Use one command only, matched to the benchmark pair: + +```bash +profitctl compare benchmark_scenarios/open_core_tiered.yml benchmark_scenarios/open_core_mix.yml +``` + +Or the closest pair to their contract shape. + +### Step 4: Drive to a real decision + +Ask: + +- Which result would have been hard to see without this comparison? +- Which metric did you trust first? +- Would you use this before a real pricing or contract decision? + +If the answer is weak, do not jump to feature building. Identify whether the problem is positioning, install friction, config mapping, or output clarity. + +### Step 5: Drive to calibration + +If they see value, ask for the minimum real input needed to calibrate: + +- current pricing shape +- free, paid monthly, and paid annual behavior +- payment-fee assumptions +- target contract shape +- one success condition they care about + +### Step 6: Drive to a design-partner commitment + +The design-partner ask should be simple: + +- one contract or packaging question +- one follow-up cycle +- one success criterion + +Example success criteria: + +- “The tool helps us reject or justify one pilot-heavy deal.” +- “We can compare our current packaging against one proposed change with real numbers.” +- “Product and finance both trust the same recurring-margin output.” + +## Weekly Cadence + +Run the same cadence every week. + +### Monday + +- review open evaluator loops +- select 5 to 10 new targets +- choose the benchmark pair for each + +### Tuesday to Thursday + +- run outbound and follow-up +- capture install, activation, and calibration outcomes +- convert strong evaluators into design-partner calls + +### Friday + +- review the week using the evaluation template +- identify the top 3 blockers across all conversations +- create or update execution issues in Linear + +## Metrics That Matter + +Track only the metrics that show whether the product is becoming easier to adopt and easier to trust. + +Primary metrics: + +- number of qualified evaluator conversations +- install success rate +- first `compare` run success rate +- number of calibrated scenarios +- number of active design partners +- number of evaluator loops that influenced a real pricing or contract decision + +Secondary metrics: + +- GitHub release download trend +- Homebrew install trend +- docs/help friction themes +- top missing config or output patterns + +## What Counts As Product Proof + +The product is ready for harder outbound and broader marketing when: + +- 5+ evaluators completed install and first compare without hand-holding +- 3+ evaluators ran calibration on real inputs +- 3+ evaluators said they would use `ProfitCtl` before a real decision +- at least 2 design partners agreed to a follow-up operating loop +- the top recurring blockers are documented and actively being addressed + +## Failure Modes To Avoid + +- turning every evaluator conversation into bespoke services work +- adding new CLI surface before understanding adoption friction +- confusing benchmark interest with real product activation +- optimizing for vanity metrics instead of install/use/decision proof + +## What To Do Next After Each Week + +Every weekly review must end with exactly these outputs: + +- one short written summary of what changed +- updated evaluator notes +- 1 to 3 execution issues in Linear +- a clear choice: + - improve onboarding + - improve scenario mapping + - improve output clarity + - continue outreach with the current motion + +If the work does not feed one of those outcomes, it is probably noise.