Add WP51 ICP and pricing hypothesis

ICP_AND_PRICING_HYPOTHESIS.md

@@ -0,0 +1,426 @@
+# WP51 — ICP and pricing hypothesis
+
+Status: business/design/documentation-only.
+
+Repository: `solidprivacy-nl/scrub`
+
+## 1. Short summary
+
+This document defines a first ICP and pricing hypothesis for SolidPrivacy Scrub after WP50.
+
+The hypothesis compares two early validation tracks:
+
+```text
+Scrub Legal — legal teams and legal document workflows.
+Scrub Zorg  — care-organization teams and operational document workflows.
+```
+
+This is not a sales plan and not a production offer. It is a working hypothesis for interviews, controlled pilots and positioning decisions.
+
+## 2. Assumptions and limits
+
+Current assumptions:
+
+- Scrub is still a risk-driven MVP, not a certified production platform.
+- The Hugging Face app is a demo and development surface.
+- The intended confidential route is local processing.
+- Scrub output requires human review.
+- Scrub Key output is pseudonymized and reversible with the key.
+- DOCX comments, metadata and hidden parts remain a known product-risk area until the DOCX hygiene line is further integrated.
+- PDF support remains text/TXT-only; no OCR and no restored PDF output.
+- Residual-risk reports are support tools, not guarantees.
+
+Commercial boundary:
+
+```text
+Do not sell full automation, production certification, legal compliance guarantees, medical compliance guarantees, or complete anonymization as current capabilities.
+```
+
+## 3. ICP Legal
+
+### Best-fit organization type
+
+The strongest first Legal ICP is likely:
+
+```text
+Small to mid-sized Dutch legal teams that frequently prepare confidential documents for AI-assisted review, summarization, drafting or sharing.
+```
+
+Potential segments:
+
+- small and mid-sized law firms;
+- legal departments;
+- legal operations teams;
+- privacy/compliance teams with legal document flows.
+
+### User
+
+Likely users:
+
+- lawyer;
+- legal assistant;
+- paralegal;
+- legal operations employee;
+- privacy/compliance reviewer.
+
+### Buyer
+
+Likely buyer:
+
+- managing partner;
+- legal operations lead;
+- head of legal;
+- privacy/compliance lead;
+- innovation lead.
+
+### Approver or blocker
+
+Likely approver/blocker:
+
+- privacy officer;
+- security officer;
+- IT lead;
+- records/information governance lead;
+- professional-risk owner.
+
+### Suitable workflows
+
+Best first workflows:
+
+- preparing legal text for AI support;
+- sharing a scrubbed version for review;
+- creating safer examples for internal analysis;
+- controlled reinsert after AI or review;
+- residual-risk discussion before external use.
+
+Avoid as first workflows:
+
+- high-volume batch processing;
+- direct production publishing;
+- scanned PDF workflows;
+- workflows that depend on perfect DOCX hidden-content cleanup.
+
+### Main pain
+
+Legal users need to preserve meaning while reducing exposure of sensitive values. Generic redaction or manual replacement is slow, inconsistent and hard to audit.
+
+### Why they may pay
+
+Willingness-to-pay drivers:
+
+- lower manual review burden;
+- safer AI preparation;
+- clearer audit trail;
+- reversible pseudonymization through Scrub Key;
+- better context preservation than blunt redaction;
+- local-first direction.
+
+### Sales risks
+
+Hard parts:
+
+- high trust bar;
+- fear of missed sensitive values;
+- need for local deployment;
+- unclear liability expectations;
+- current DOCX/PDF limitations;
+- buyers may expect full automation too early.
+
+### What a pilot must prove
+
+A Legal pilot must prove:
+
+- user understands the workflow;
+- review effort is acceptable;
+- output stays readable;
+- residual-risk reporting is useful;
+- Scrub Key risk is understood;
+- current limitations are clear enough.
+
+## 4. ICP Zorg
+
+### Best-fit organization type
+
+The strongest first Zorg ICP is likely:
+
+```text
+Dutch care organizations with project, quality, privacy, IT or innovation teams that prepare operational documents for internal analysis, training, supplier conversations or AI support.
+```
+
+Potential segments:
+
+- care organizations with privacy/quality teams;
+- care-technology project teams;
+- functional application management;
+- innovation and information-management teams;
+- digital transformation teams.
+
+### User
+
+Likely users:
+
+- project manager;
+- privacy or quality officer;
+- functional application manager;
+- policy or support staff;
+- innovation staff;
+- information-management staff.
+
+### Buyer
+
+Likely buyer:
+
+- manager ICT;
+- privacy officer or DPO-adjacent owner;
+- quality manager;
+- innovation manager;
+- operations or transformation lead.
+
+### Approver or blocker
+
+Likely approver/blocker:
+
+- privacy officer;
+- security officer;
+- ICT management;
+- information governance;
+- legal/procurement for later production use.
+
+### Suitable workflows
+
+Best first workflows:
+
+- preparing operational documents for internal learning;
+- safer AI-assisted summarization of project notes;
+- creating controlled training examples;
+- sharing scrubbed versions with internal project teams;
+- discussing residual-risk reports with privacy/quality staff.
+
+Avoid as first workflows:
+
+- direct processing of production care records;
+- unmanaged cloud-demo usage for confidential material;
+- high-risk clinical decision workflows;
+- large batch processing.
+
+### Main pain
+
+Care organizations have many operational documents with sensitive context. Teams want to use AI and share examples, but privacy review is slow and risk-sensitive.
+
+### Why they may pay
+
+Willingness-to-pay drivers:
+
+- safer internal AI experimentation;
+- less manual preparation work;
+- better privacy-office confidence;
+- local-first route;
+- audit and residual-risk language for governance;
+- support for training/project examples.
+
+### Sales risks
+
+Hard parts:
+
+- strong need for privacy approval;
+- local deployment expectations;
+- unclear ownership between ICT, privacy, quality and operations;
+- low tolerance for confusing limitations;
+- current DOCX hidden-content risk must be explained clearly.
+
+### What a pilot must prove
+
+A Zorg pilot must prove:
+
+- the workflow is understandable for non-legal users;
+- local-first direction is credible;
+- review effort is acceptable;
+- residual-risk reporting helps governance;
+- current limitations do not create false confidence.
+
+## 5. Legal vs Zorg comparison
+
+| Dimension | Legal hypothesis | Zorg hypothesis |
+|---|---|---|
+| First value | AI/share preparation for legal documents | AI/share preparation for operational documents |
+| Strongest buyer pain | Meaning-preserving confidentiality control | Privacy-safe internal analysis and learning |
+| Trust bar | Very high | High, with governance focus |
+| Access path | Harder, more trust-driven | Potentially faster through care-sector network |
+| Best first offer | Guided controlled pilot | Guided controlled pilot / workshop |
+| Main blocker | liability and professional trust | privacy/security approval and local deployment |
+| Likely wedge | legal AI preparation | operational document preparation |
+
+Initial commercial priority hypothesis:
+
+```text
+Scrub Zorg may be the fastest validation wedge because the project already has care-sector context and access. Scrub Legal remains a strong product story but may require more trust evidence before conversion.
+```
+
+## 6. First buyer personas
+
+### Legal persona A — Managing lawyer / legal owner
+
+- Wants safer AI use without losing legal context.
+- Needs trust, control and auditability.
+- May pay for risk reduction and workflow efficiency.
+- Blocks if the tool sounds like unsupported automatic anonymization.
+
+### Legal persona B — Legal operations / privacy lead
+
+- Wants repeatable process and governance.
+- Needs residual-risk language and review evidence.
+- May prefer a controlled pilot before buying.
+
+### Zorg persona A — Privacy/quality lead
+
+- Wants safer internal sharing and AI preparation.
+- Needs clear boundaries and local processing direction.
+- May sponsor a guided pilot if governance is clear.
+
+### Zorg persona B — ICT/project lead
+
+- Wants practical tooling for project and support documents.
+- Needs easy local run path and clear support model.
+- May become buyer or internal champion.
+
+## 7. Pricing model comparison
+
+| Model | Advantage | Disadvantage | Risk | Best moment |
+|---|---|---|---|---|
+| Free demo/discovery | Low friction | No revenue signal | Attracts unqualified users | Before pilot |
+| Paid pilot | Validates willingness to pay | Requires clear scope | May feel early if product limits are unclear | After demo interest |
+| Consultancy-assisted pilot | High trust and learning | Time-intensive | Hard to scale | Best first paid offer |
+| Per user per month | Simple SaaS logic | Less aligned with local desktop/security route | May underprice value | Later MVP |
+| Per organization per month | Fits governance buyer | Needs support model | Needs mature local deployment | Later pilot/early production |
+| Local desktop license | Fits local-first promise | Requires packaging/support | Premature before WP49B or later | After packaging proof |
+| Enterprise/support model | Fits larger organizations | Complex sales | Too heavy early | Later only |
+
+## 8. First pricing hypothesis
+
+This is a cautious hypothesis, not a price list.
+
+Suggested bands:
+
+```text
+Discovery/demo: free or very low threshold.
+Paid controlled pilot: small fixed fee.
+Consultancy-assisted pilot: higher fixed fee because guidance and review sessions are included.
+Later subscription/license: only after product validation and local deployment proof.
+```
+
+Suggested initial direction:
+
+```text
+Start with a consultancy-assisted paid pilot rather than a self-serve subscription.
+```
+
+Reason:
+
+- product trust is not yet fully proven;
+- users need guidance on limitations;
+- feedback quality matters more than scale;
+- a guided pilot can validate willingness to pay and risk language.
+
+## 9. Pilot offer vs production offer
+
+### Pilot offer
+
+Purpose:
+
+- learn;
+- validate workflow value;
+- measure review burden;
+- collect structured feedback;
+- test messaging and trust.
+
+Included:
+
+- controlled document set;
+- guided session;
+- feedback interview;
+- residual-risk discussion;
+- no production claim.
+
+### Production offer
+
+Later only.
+
+Requires before offering:
+
+- local runtime confidence;
+- document hygiene path;
+- clearer support model;
+- security/privacy approval material;
+- packaging or deployment decision;
+- pricing validation.
+
+## 10. What must not be sold or claimed yet
+
+Do not claim:
+
+- production certification;
+- full automation;
+- full anonymization without review;
+- complete DOCX hidden-content handling;
+- OCR or restored PDF output;
+- guaranteed detection of all sensitive values;
+- encrypted Scrub Key container;
+- enterprise deployment readiness;
+- compliance approval.
+
+Allowed positioning:
+
+```text
+A guided, local-first-oriented workflow for controlled document scrubbing validation, with human review, Scrub Key awareness and residual-risk visibility.
+```
+
+## 11. Validation questions
+
+Use these in interviews or guided pilots:
+
+1. What document workflow would you want to use Scrub for first?
+2. What would make you trust or distrust the output?
+3. How much review time is acceptable per document?
+4. Which missed items would be unacceptable?
+5. Which false positives are annoying but acceptable?
+6. Is the Scrub Key concept clear?
+7. Do the warnings make the workflow safer or more confusing?
+8. Are DOCX/PDF limitations clear enough?
+9. Would local processing change your willingness to test or buy?
+10. Who would approve a pilot in your organization?
+11. Who would block it?
+12. What would make you pay for a controlled pilot?
+13. What would make you refuse to buy?
+14. Would you prefer a guided pilot, desktop license or subscription later?
+15. What evidence would you need before production use?
+
+## 12. Go / no-go criteria
+
+The hypothesis gets stronger if:
+
+- users understand the workflow;
+- users accept human review;
+- users see clear time or risk value;
+- users understand limitations;
+- users can explain Scrub Key risk back correctly;
+- users consider a paid pilot reasonable;
+- a clear buyer and approver path emerges.
+
+Pause or revise if:
+
+- users want only automatic anonymization;
+- users require immediate production certification;
+- users reject local install or controlled pilot constraints;
+- DOCX/PDF limitations block the main use case;
+- willingness to pay is absent;
+- the buyer is unclear.
+
+## 13. Recommended next step
+
+Recommended next workpackage:
+
+```text
+WP52 — Pilot intake and NDA process
+```
+
+WP52 should define the practical intake and agreement process before any real external pilot activity is started.