convoke-agents 2.0.0

package/_bmad/bme/_vortex/workflows/proof-of-concept/steps/step-05-evaluate.md

@@ -0,0 +1,114 @@
+---
+step: 5
+workflow: proof-of-concept
+title: Evaluate Feasibility
+---
+
+# Step 5: Evaluate Feasibility
+
+You have test results. Now answer the real question: can we build this at production scale, or did the PoC reveal problems that change the picture? This step moves from raw data to a defensible feasibility verdict.
+
+## Why This Matters
+
+Test results without interpretation are just numbers. A PoC that meets its pass criteria under lab conditions might still be infeasible at production scale due to cost, operational complexity, or compounding edge cases. Conversely, a PoC that narrowly missed a threshold might be feasible with a known optimization path. This step forces you to think beyond "did the test pass" and into "what does this mean for the real system" -- because that is the decision your team actually needs to make.
+
+## Your Task
+
+### 1. Summarize Test Results Against Criteria
+
+Pull forward your pass/fail criteria and test results into a single verdict table:
+
+| Criteria | Threshold | Measured Result | Verdict |
+|----------|-----------|----------------|---------|
+| *From Step 1* | *Pass threshold* | *From Step 4* | Pass / Fail / Inconclusive |
+| *From Step 1* | *Fail threshold* | *From Step 4* | Pass / Fail / Inconclusive |
+
+**Overall PoC Result:** Pass / Fail / Inconclusive
+
+### 2. Assess Scalability Gap
+
+The PoC tested feasibility at PoC scale. Production is different. Assess the gap:
+
+| Dimension | PoC Scale | Production Scale | Gap | Confidence That Gap Is Closable |
+|-----------|-----------|-----------------|-----|-------------------------------|
+| **Data volume** | *What the PoC used* | *What production requires* | *Multiplier (e.g., 100x)* | High / Medium / Low |
+| **Concurrent users** | *PoC load* | *Expected production load* | *Multiplier* | High / Medium / Low |
+| **Availability** | *PoC uptime* | *Production SLA target* | *Delta* | High / Medium / Low |
+| **Error handling** | *Stubbed/minimal* | *Production-grade* | *Effort estimate* | High / Medium / Low |
+| **Security** | *Bypassed/minimal* | *Production requirements* | *Effort estimate* | High / Medium / Low |
+| **Cost** | *PoC cost (if any)* | *Projected production cost* | *Monthly/annual estimate* | High / Medium / Low |
+
+**Guidance:** If your confidence that the gap is closable is "Low" for any dimension, that is a significant finding. It does not automatically mean "infeasible" -- but it means there is unresolved technical risk that may need further investigation.
+
+### 3. Evaluate Integration Readiness
+
+If the PoC involved external systems, assess integration health:
+
+| Integration | PoC Behavior | Production Concerns | Risk Level |
+|-------------|-------------|-------------------|------------|
+| *API / service / library* | *How it behaved during testing* | *Rate limits, versioning, reliability, cost at scale* | High / Medium / Low |
+
+### 4. Identify Technical Debt and Unknowns
+
+What did the PoC NOT test that production would require?
+
+| Unknown | Why It Matters | Estimated Effort to Resolve | Blocks Production? |
+|---------|---------------|---------------------------|-------------------|
+| *What we still do not know* | *Impact on production feasibility* | *Hours / Days / Weeks / Unknown* | Yes / No / Maybe |
+
+Be honest here. The temptation after a successful PoC is to declare victory and move on. But if there are significant unknowns that the PoC did not address, those unknowns do not disappear -- they become surprises during production development.
+
+### 5. Render the Feasibility Verdict
+
+Based on all evidence, choose one:
+
+**FEASIBLE** -- The technical approach works. Proceed to production planning.
+- All pass criteria met
+- Scalability gaps are closable with known techniques
+- No blocking unknowns
+- Cost projections are acceptable
+
+**FEASIBLE WITH CONDITIONS** -- The technical approach works, but with caveats.
+- Most pass criteria met; exceptions have known mitigations
+- Some scalability gaps require further investigation
+- Conditions must be documented and tracked
+
+**INFEASIBLE (this approach)** -- This specific approach does not work.
+- One or more critical pass criteria failed
+- Scalability gaps are not closable with known techniques
+- Does NOT mean the goal is impossible -- only that this approach failed
+
+**INCONCLUSIVE** -- More data is needed before a verdict.
+- Results are ambiguous or contradictory
+- Key scenarios were not testable within PoC scope
+- Recommend a follow-up PoC with tighter scope
+
+| Verdict | Rationale | Key Evidence |
+|---------|-----------|-------------|
+| *Your verdict* | *Why you reached this conclusion* | *The 1-3 most important test results or findings* |
+
+**If FEASIBLE WITH CONDITIONS, list conditions:**
+
+| Condition | Risk If Unmet | Owner | Timeline |
+|-----------|--------------|-------|----------|
+| *What must be true for feasibility to hold* | *What happens if this condition fails* | *Who resolves it* | *When it must be resolved* |
+
+---
+
+## Your Turn
+
+Summarize results against criteria, assess the scalability gap, identify unknowns, and render your feasibility verdict. Share your evaluation and I will help you stress-test the conclusion before we document it.
+
+---
+
+**[a]** Advanced Elicitation -- Deep dive into feasibility analysis with guided questioning
+**[p]** Party Mode -- Bring in other Vortex agents to challenge your feasibility assessment
+**[c]** Continue -- Proceed to documenting findings and Vortex routing
+
+---
+
+## Next Step
+
+When your feasibility verdict is rendered and reviewed, I'll load:
+
+{project-root}/_bmad/bme/_vortex/workflows/proof-of-concept/steps/step-06-document.md

package/_bmad/bme/_vortex/workflows/proof-of-concept/steps/step-06-document.md

@@ -0,0 +1,125 @@
+---
+step: 6
+workflow: proof-of-concept
+title: Document Findings & Route
+---
+
+# Step 6: Document Findings & Route
+
+The PoC is complete and the verdict is in. Now package everything you learned into a structured artifact that your team can act on, and route to the next step in the Vortex based on what the evidence tells you.
+
+## Why This Matters
+
+A PoC without documentation is a PoC that gets repeated. Six months from now, someone will ask "did we ever test whether X was feasible?" and if the answer lives only in your memory or a stale branch, the team will spend another week rediscovering what you already know. Structured documentation turns a PoC into an organizational asset -- a permanent record of what was tested, what was learned, and what decision it enabled. The Vortex Compass then ensures that learning flows to the right next step instead of sitting in a folder.
+
+## Your Task
+
+### 1. Compile the PoC Summary
+
+Bring together all findings into a structured summary:
+
+| Section | Content |
+|---------|---------|
+| **Technical Question** | The core question this PoC set out to answer (from Step 1) |
+| **Approach** | What was built and how (from Steps 2-3) |
+| **Key Results** | Top 3-5 findings from testing (from Step 4) |
+| **Feasibility Verdict** | Pass / Fail / Conditional / Inconclusive (from Step 5) |
+| **Conditions** | Any conditions attached to the verdict (from Step 5) |
+| **Unknowns Remaining** | What the PoC did NOT answer (from Step 5) |
+
+### 2. Document Technical Findings
+
+For each significant finding from Steps 3-5, create a structured record:
+
+| Finding | Evidence | Impact | Recommendation |
+|---------|----------|--------|---------------|
+| *What you discovered* | *Test data, metrics, or observations that support it* | *How this affects production feasibility* | *What to do about it* |
+
+**Capture both positive and negative findings.** A PoC that confirms feasibility is just as valuable for what it proves works as what it proves does not work. Document:
+- What worked better than expected (and why)
+- What worked worse than expected (and why)
+- What was surprising (and what it implies)
+- What was not testable within PoC scope (and what would be needed to test it)
+
+### 3. Record Technical Decisions
+
+If the PoC informed any architectural or technical decisions, document them:
+
+| Decision | Alternatives Considered | Why This Choice | Confidence |
+|----------|----------------------|----------------|------------|
+| *What was decided* | *What other approaches were evaluated* | *Evidence from the PoC that supports this choice* | High / Medium / Low |
+
+### 4. Generate the PoC Artifact
+
+Package the documentation into a structured artifact:
+
+**Save to:** `{output_folder}/vortex-artifacts/poc-{poc-name}-{date}.md`
+
+The artifact should include:
+1. **Technical Question** -- What we set out to answer
+2. **Approach** -- What we built and how we tested it
+3. **Results** -- Raw findings and metrics
+4. **Feasibility Verdict** -- The conclusion with supporting evidence
+5. **Conditions & Unknowns** -- Caveats and open questions
+6. **Technical Decisions** -- Choices made based on PoC evidence
+7. **Recommendations** -- Next steps based on the verdict
+
+### 5. Final Quality Check
+
+Before routing, verify the documentation is complete and honest:
+
+- [ ] Could someone who was not involved in the PoC understand what was tested and what was learned?
+- [ ] Are the results reported accurately, without spin or cherry-picking?
+- [ ] Is the verdict supported by the evidence, not by the outcome you wanted?
+- [ ] Are conditions and unknowns documented prominently, not buried?
+- [ ] Would this documentation prevent someone from re-running this exact PoC unnecessarily?
+
+---
+
+## Your Turn
+
+Compile your findings, document technical decisions, and generate the PoC artifact. Confirm when the artifact is saved and we will route to the next Vortex step based on your results.
+
+---
+
+## Vortex Compass
+
+Based on what you just completed, here are your evidence-driven options:
+
+| If you learned... | Consider next... | Agent | Why |
+|---|---|---|---|
+| Technically feasible, ready for business validation | proof-of-value | Wade | Technical risk retired -- now validate the business case with a value-focused experiment |
+| Technically feasible, but hypotheses need engineering | hypothesis-engineering | Liam | Feasibility confirmed -- now engineer testable hypotheses from the problem definition |
+| Feasibility uncertain, need a focused experiment | lean-experiment | Wade | Run a targeted technical experiment to resolve the specific remaining uncertainty |
+| Feasibility uncertain, need more user/market data | user-interview | Isla | Technical unknowns require user context or domain expertise to resolve |
+| Infeasible with this approach, pivot needed | pivot-resynthesis | Mila | Current approach failed -- re-synthesize the problem to find alternative technical paths |
+| Infeasible, fundamental technical blocker | learning-card | Max | Document the blocker as an organizational learning so the team does not revisit this dead end |
+| Results available, need to capture learnings | learning-card | Max | Document technical learnings for the team's knowledge base |
+| Results change the problem definition | research-convergence | Mila | PoC findings reframe the problem -- re-converge research with new technical evidence |
+
+> **Note:** These are evidence-based recommendations. You can navigate to any Vortex agent
+> at any time based on your judgment.
+
+**Or run Max's [VN] Vortex Navigation** for a full gap analysis across all streams.
+
+### Insufficient Evidence for Routing
+
+If the evidence gathered so far does not clearly point to a single next step:
+
+| To route to... | You need... |
+|----------------|-------------|
+| Wade (proof-of-value) | Clear "feasible" verdict with pass criteria met and scalability gaps assessed |
+| Wade (lean-experiment) | Specific unresolved technical uncertainty with a testable question |
+| Liam (hypothesis-engineering) | Confirmed feasibility and a problem definition ready for hypothesis generation |
+| Isla (user-interview) | Specific technical unknown that requires user or domain context to resolve |
+| Mila (pivot-resynthesis) | Evidence that the current technical approach is a dead end |
+| Mila (research-convergence) | New evidence from the PoC that changes the problem framing |
+| Max (learning-card) | Completed PoC with findings worth preserving for the team |
+
+**Workflow-specific signals:**
+- Verdict is "Inconclusive" with no clear next test --> consider revisiting **step-02** for tighter scoping
+- Verdict is "Feasible with Conditions" but conditions are untestable --> consider routing to **Isla** for domain research
+- Verdict is "Infeasible" but the goal is still worth pursuing --> consider routing to **Mila** for alternative approaches
+- All pass criteria met but team has no hypothesis to test next --> consider routing to **Liam** for hypothesis engineering
+
+**Recommended:** If uncertain, run **Max's [VN] Vortex Navigation** for a full gap analysis.

package/_bmad/bme/_vortex/workflows/proof-of-concept/validate.md

@@ -0,0 +1,30 @@
+# Validate Proof of Concept
+
+**Status:** Coming in v1.2.0
+
+**Agent:** Wade (Lean Experiments Specialist)
+
+**Stream:** Externalize
+
+## Overview
+
+This validation workflow helps you review proof-of-concepts to ensure they answer the technical question without over-engineering.
+
+## What Gets Validated
+
+- Is the technical question clearly stated?
+- Is the approach appropriate (not over-engineered)?
+- Are implementation details documented?
+- Are results based on evidence?
+- Is the feasibility decision justified?
+- Does this focus on learning over production quality?
+
+## Coming in v1.2.0
+
+This validation workflow will be available alongside the proof-of-concept workflow in March 2026.
+
+## Questions?
+
+For questions or to request early access:
+- GitHub Issues: https://github.com/amalik/convoke-agents/issues
+- Tag with: `workflow:proof-of-concept` and `v1.2.0`

package/_bmad/bme/_vortex/workflows/proof-of-concept/workflow.md

@@ -0,0 +1,26 @@
+---
+workflow: proof-of-concept
+type: step-file
+description: Validate technical feasibility before business case
+author: Wade (lean-experiments-specialist)
+version: 1.2.0
+---
+
+# Proof-of-Concept Workflow
+
+Validate that you CAN build this before validating that you SHOULD.
+
+## Steps Overview
+
+1. **Define Technical Risk** - What could prevent this from working?
+2. **Design PoC Scope** - Smallest test of technical feasibility
+3. **Build Prototype** - Create proof-of-concept
+4. **Test Technical Assumptions** - Does it work?
+5. **Evaluate Feasibility** - Can we build this at scale?
+6. **Document Findings** - What did we learn?
+
+---
+
+## INITIALIZATION
+
+Load step: {project-root}/_bmad/bme/_vortex/workflows/proof-of-concept/steps/step-01-risk.md

package/_bmad/bme/_vortex/workflows/proof-of-value/proof-of-value.template.md

@@ -0,0 +1,29 @@
+---
+title: "PoV: {pov-name}"
+date: {date}
+type: proof-of-value
+status: {status}
+---
+
+# Proof-of-Value: {pov-name}
+
+## Value Hypothesis
+
+{value-hypothesis}
+
+## Market Test Results
+
+{results}
+
+## Business Case
+
+{business-case}
+
+## Decision
+
+{decision}
+
+---
+
+**Created with:** Convoke v2.0.0
+**Workflow:** proof-of-value

package/_bmad/bme/_vortex/workflows/proof-of-value/steps/step-01-value-hypothesis.md

@@ -0,0 +1,75 @@
+---
+step: 1
+workflow: proof-of-value
+title: Define Value Hypothesis
+---
+
+# Step 1: Define Value Hypothesis
+
+You have proven you CAN build this. Now the question is: SHOULD you? This step forces you to articulate exactly what business value you are claiming before you test whether anyone agrees.
+
+## Why This Matters
+
+Most products fail not because they cannot be built, but because nobody will pay for them. A value hypothesis makes the business case explicit and testable: who gets value, what kind of value, and how much that value is worth. Without a crisp value hypothesis, teams drift into building features that are technically impressive but commercially irrelevant. The proof-of-value workflow starts here because you cannot validate demand for something you have not clearly defined.
+
+## Your Task
+
+### 1. What Input Are You Working From?
+
+Wade expects a validated technical feasibility signal — typically from a proof-of-concept workflow or equivalent:
+
+- **HC4 Experiment Context** (from Wade's `proof-of-concept` workflow) — technical feasibility confirmed
+- **HC3 Hypothesis Contract** (from Liam's `hypothesis-engineering` workflow) — testable hypothesis with riskiest assumptions mapped
+- **Any validated technical artifact** — Wade accepts input from outside the Vortex pattern
+
+You can also bring a product idea that has been validated as technically feasible through other means. The key requirement is confidence that the thing CAN be built — this workflow tests whether it SHOULD be built.
+
+### 2. Provide Your Input
+
+Please provide the file path or describe the technical validation context you want to build a business case around. For example:
+- `_bmad-output/vortex-artifacts/hc4-experiment-context-2026-02-25.md`
+- Or: "We have confirmed technical feasibility for X and now need to validate market demand"
+
+### 3. Define the Value Hypothesis
+
+Complete the Value Hypothesis Canvas:
+
+| Dimension | Your Answer |
+|-----------|-------------|
+| **Target Customer Segment** | Who specifically will pay for this? Not "users" — which segment, role, company size, or persona? |
+| **Problem Being Solved** | What pain or job-to-be-done does this address? Reference evidence from upstream artifacts. |
+| **Proposed Value** | What specific value does the customer receive? Be concrete: time saved, revenue gained, cost reduced, risk eliminated. |
+| **Value Magnitude** | How much value? Quantify where possible: "saves 4 hours/week" not "saves time." |
+| **Current Alternatives** | What do customers do today? What are they paying for existing solutions? |
+| **Switching Cost** | What would it take for a customer to switch from their current solution to yours? |
+| **Willingness-to-Pay Signal** | What early evidence (if any) suggests customers would pay? Stated interest does not count — look for behavioral signals. |
+
+### 4. Articulate the Value Hypothesis Statement
+
+Using the canvas above, draft the value hypothesis in this format:
+
+> **We believe that** [target customer segment] **will** [pay $X / change behavior Y] **for** [proposed value] **because** [rationale grounded in evidence] **instead of** [current alternative].
+
+### 5. Identify the Riskiest Value Assumption
+
+Every value hypothesis embeds assumptions about the market. Identify the single most dangerous one:
+
+- [ ] **Demand assumption** — Do enough customers have this problem to sustain a business?
+- [ ] **Willingness-to-pay assumption** — Will they pay what we need to charge?
+- [ ] **Switching cost assumption** — Is the switching cost low enough that customers will actually move?
+- [ ] **Value magnitude assumption** — Is the value large enough relative to price to justify purchase?
+- [ ] **Competitive assumption** — Will incumbents or alternatives erode our value proposition?
+
+**Which one, if wrong, kills the entire business case?** That is your riskiest value assumption.
+
+---
+
+## Your Turn
+
+Provide your technical validation input, complete the Value Hypothesis Canvas, draft the hypothesis statement, and identify the riskiest value assumption. Share your work and I will help sharpen it before we design the validation approach.
+
+## Next Step
+
+When your value hypothesis is defined and the riskiest assumption is identified, I will load:
+
+{project-root}/_bmad/bme/_vortex/workflows/proof-of-value/steps/step-02-validation-design.md

package/_bmad/bme/_vortex/workflows/proof-of-value/steps/step-02-validation-design.md

@@ -0,0 +1,94 @@
+---
+step: 2
+workflow: proof-of-value
+title: Design Validation Approach
+---
+
+# Step 2: Design Validation Approach
+
+You have a value hypothesis. Now you need to design the experiment that will prove or disprove market demand — not through surveys or stated preferences, but through behavioral commitment signals.
+
+## Why This Matters
+
+Stated interest is cheap. "Would you use this?" always gets a yes. The only evidence that counts for business value is behavioral: will people sign up, put down a deposit, pre-order, invest time to onboard, or choose your solution when a viable alternative exists? Designing the right validation approach means choosing a method that forces real commitment signals from real customers — not polite enthusiasm from friendly prospects. If your validation method cannot distinguish between "that sounds cool" and "take my money," it will not tell you anything useful.
+
+## Your Task
+
+### 1. Select Your Validation Method
+
+Choose the method that best matches your value hypothesis and the riskiest assumption you identified in Step 1:
+
+| Method | Best For | Commitment Signal | Effort Level |
+|--------|----------|-------------------|--------------|
+| **Fake Door / Landing Page** | Testing demand for a new product or feature | Click-through rate, email signup, waitlist join | Low |
+| **Pre-Order / Deposit** | Testing willingness to pay a specific price | Actual payment, deposit placed | Medium |
+| **Concierge / Wizard of Oz** | Testing whether the value proposition works when delivered manually | Repeat usage, referral, payment after trial | High |
+| **Letter of Intent / Pilot Agreement** | Testing enterprise or B2B demand | Signed LOI, committed pilot timeline | Medium |
+| **Pricing Page Test** | Testing price sensitivity and willingness-to-pay thresholds | Plan selection, pricing tier click-through | Low |
+| **Competitive Displacement** | Testing whether users will switch from existing solution | Active migration, cancellation of alternative | High |
+| **Crowdfunding Campaign** | Testing market demand at scale with real payment | Funding pledges, backer count | Medium |
+
+**Guidance:** The best method tests your riskiest value assumption directly. If your riskiest assumption is willingness-to-pay, use a method that requires actual payment. If it is demand, use a method that captures real sign-up behavior. Never rely on methods that only capture stated preferences.
+
+### 2. Define Your Target Audience
+
+| Dimension | Your Specification |
+|-----------|-------------------|
+| **Segment definition** | Who exactly are you testing with? Match the target customer segment from your value hypothesis. |
+| **Sample size** | How many participants do you need for a meaningful signal? (Minimum: 30 for quantitative, 5-8 for qualitative) |
+| **Recruitment channel** | How will you reach them? Paid ads, existing community, cold outreach, partner network? |
+| **Screening criteria** | What qualifies someone as a valid test participant? What disqualifies them? |
+| **Competitor usage** | Are they currently using an alternative? Which one? This is critical for switching cost validation. |
+
+### 3. Define Pre-Committed Success Criteria
+
+Write these BEFORE you see any results. This prevents post-hoc rationalization.
+
+| Metric | Target Threshold | Failure Threshold | Why This Number |
+|--------|-----------------|-------------------|-----------------|
+| **Primary metric** (e.g., conversion rate, deposit count) | *What result confirms value?* | *What result kills the hypothesis?* | *Justify the threshold with market benchmarks or unit economics* |
+| **Secondary metric** (e.g., price sensitivity, churn intent) | | | |
+| **Guardrail metric** (e.g., customer acquisition cost, time to convert) | | | |
+
+**Critical rule:** Define both success AND failure thresholds. A result between them is "inconclusive" — which means you need a better test, not a pivot.
+
+### 4. Design the Experiment Protocol
+
+| Element | Your Design |
+|---------|-------------|
+| **Test duration** | How long will the experiment run? Minimum time to reach sample size. |
+| **Control condition** | What is the baseline comparison? Existing alternative, no-solution, different price point? |
+| **Stimulus** | What exactly will participants see, experience, or be offered? |
+| **Measurement method** | How will you capture the commitment signal? Analytics, payment processor, manual tracking? |
+| **Contamination risks** | What could pollute your results? Selection bias, novelty effect, social desirability? |
+| **Abort criteria** | Under what conditions do you stop the experiment early? (e.g., zero conversions after 50% of sample reached) |
+
+### 5. Pre-Mortem: What Could Invalidate This Test?
+
+Before you run the experiment, identify what could make the results meaningless:
+
+- [ ] **Selection bias** — Are you only reaching people who are already enthusiastic?
+- [ ] **Novelty effect** — Would they engage just because it is new, not because they would actually pay?
+- [ ] **Social desirability** — Are they saying yes to be polite or supportive?
+- [ ] **Wrong proxy** — Does your commitment signal actually predict real purchasing behavior?
+- [ ] **Insufficient sample** — Is your sample large enough to draw conclusions?
+
+---
+
+## Your Turn
+
+Select your validation method, define your audience, set pre-committed success criteria, design the protocol, and run the pre-mortem. Share your validation design and I will help you stress-test it before you invest time running the experiment.
+
+---
+
+**[a]** Advanced Elicitation — Deep dive into experiment design with guided questioning on pricing models, competitive positioning, and sample sizing
+**[p]** Party Mode — Bring in other Vortex agents to challenge your validation design
+**[c]** Continue — Proceed to willingness-to-pay testing
+
+---
+
+## Next Step
+
+When your validation approach is designed and pre-committed criteria are set, I will load:
+
+{project-root}/_bmad/bme/_vortex/workflows/proof-of-value/steps/step-03-willingness.md

package/_bmad/bme/_vortex/workflows/proof-of-value/steps/step-03-willingness.md

@@ -0,0 +1,96 @@
+---
+step: 3
+workflow: proof-of-value
+title: Test Willingness to Pay
+---
+
+# Step 3: Test Willingness to Pay
+
+This is where stated interest meets behavioral reality. You are about to find out whether your target customers will put real skin in the game — money, time, or effort — for the value you are proposing.
+
+## Why This Matters
+
+Willingness-to-pay is the single most lethal filter in product development. Teams regularly build products that users say they want but will never pay for. The gap between "I would totally use that" and "here is my credit card" is where most business models die. This step forces you to design and prepare a willingness-to-pay test that captures real behavioral commitment — not hypothetical interest. If customers will not pay (or meaningfully change their behavior) for your value proposition, you do not have a business. Better to learn that now than after building the product.
+
+## Your Task
+
+### 1. Define Your Pricing Hypothesis
+
+Before you test willingness-to-pay, you need a pricing hypothesis to test against:
+
+| Dimension | Your Answer |
+|-----------|-------------|
+| **Pricing model** | How will you charge? Subscription, one-time, usage-based, freemium, transaction fee? |
+| **Price point(s) to test** | What specific price(s) will you test? Include at least 2-3 price points if possible. |
+| **Unit economics basis** | What does the price need to be for the business to work? (Cost to serve + margin target) |
+| **Competitive price anchors** | What do existing alternatives cost? Where does your price sit relative to them? |
+| **Value-to-price ratio** | What is the ratio of value delivered to price charged? (Target: 3x-10x perceived value over price) |
+
+**Guidance:** If you cannot articulate why a customer would see 3x or more value relative to price, the pricing is likely wrong — either the price is too high or the value proposition is too weak.
+
+### 2. Choose Your Willingness-to-Pay Method
+
+Select the method that matches your context:
+
+| Method | Signal Strength | How It Works |
+|--------|----------------|--------------|
+| **Van Westendorp Price Sensitivity** | Medium | Ask 4 pricing questions to find acceptable price range. Good for early signal. |
+| **Gabor-Granger** | Medium | Show a price, ask "would you buy?" Increase/decrease until you find the threshold. |
+| **Fake Door with Price** | High | Show a landing page with real pricing. Measure click-to-purchase behavior. |
+| **Pre-Order with Payment** | Very High | Ask for actual payment (refundable or non-refundable deposit). |
+| **Pilot with Pricing** | Very High | Deliver the value manually (concierge) and charge real money. |
+| **Competitive Switch Offer** | High | Offer your product at a specific price to users of a competing solution. Measure switch rate. |
+
+**Signal strength hierarchy:** Actual payment > Payment intent (card entered) > Price-specific click-through > Stated willingness. Always aim for the highest signal strength your context allows.
+
+### 3. Design the Willingness-to-Pay Test
+
+| Element | Your Design |
+|---------|-------------|
+| **Test type** | Which method from above? |
+| **Price points being tested** | List all price points or tiers. |
+| **Commitment mechanism** | What does the participant do to signal willingness? (Enter credit card, place deposit, sign LOI, click "buy now") |
+| **Value framing** | How will you communicate the value proposition before showing the price? |
+| **Anchoring strategy** | What reference price (competitor, cost of status quo) will you anchor against? |
+| **Decoy pricing** (if applicable) | Are you using a pricing tier structure with a strategic decoy? |
+
+### 4. Set Willingness-to-Pay Thresholds
+
+Define what the results mean BEFORE you see them:
+
+| Outcome | Threshold | Interpretation | Action |
+|---------|-----------|----------------|--------|
+| **Strong signal** | *e.g., >15% conversion at target price* | Value hypothesis confirmed at this price | Proceed to full validation |
+| **Moderate signal** | *e.g., 5-15% conversion* | Demand exists but price sensitivity is high | Adjust pricing, retest |
+| **Weak signal** | *e.g., 1-5% conversion* | Value proposition resonates but willingness-to-pay is insufficient | Revisit value hypothesis or target segment |
+| **No signal** | *e.g., <1% conversion* | Customers will not pay for this value at any tested price | Kill or pivot the value hypothesis |
+
+### 5. Account for Common Willingness-to-Pay Traps
+
+Before you execute, check for these traps:
+
+- [ ] **Friendly customer bias** — Are you testing with people who know you personally and would "support" you rather than make a real purchasing decision?
+- [ ] **Price anchoring distortion** — Have you accidentally anchored participants to a low price before revealing the real one?
+- [ ] **Feature laundry list bias** — Are you showing a feature list instead of communicating the core value proposition? Features impress; value converts.
+- [ ] **Pain of paying avoidance** — Is your payment mechanism so frictionless that it does not test real willingness? (A one-click signup is not the same as entering a credit card.)
+- [ ] **Wrong segment** — Are you testing willingness-to-pay with people who have the problem but not the budget authority?
+
+---
+
+## Your Turn
+
+Define your pricing hypothesis, choose your willingness-to-pay method, design the test, and set your thresholds. Share your plan and I will help you identify any gaps before you move into execution.
+
+---
+
+**[a]** Advanced Elicitation — Deep dive into pricing strategy, competitive positioning, and unit economics modeling
+**[p]** Party Mode — Bring in other Vortex agents to stress-test your pricing assumptions
+**[c]** Continue — Proceed to running the validation test
+
+---
+
+## Next Step
+
+When your willingness-to-pay test is designed and thresholds are pre-committed, I will load:
+
+{project-root}/_bmad/bme/_vortex/workflows/proof-of-value/steps/step-04-test.md