docs: realign product roadmap
This commit is contained in:
parent
38a2cec475
commit
b772cf634a
@ -1,15 +1,15 @@
|
||||
# Product Roadmap
|
||||
|
||||
> **Status:** Active
|
||||
> **Last reviewed:** 2026-04-30
|
||||
> **Last reviewed:** 2026-05-02
|
||||
> **Use for:** Current product roadmap, release themes, and prioritization context
|
||||
> **Do not use for:** Implementation truth, spec completion status, or delivery guarantees without repo verification
|
||||
> **Scoped maintenance:** 2026-05-01 lifecycle/provider-missing wording alignment only; no full roadmap re-review was performed.
|
||||
> **Scoped maintenance:** 2026-05-02 repo-based roadmap drift correction and queue/backlog alignment after the audit-derived product-truth review.
|
||||
>
|
||||
> Strategic thematic blocks and release trajectory.
|
||||
> This is the "big picture" — not individual specs.
|
||||
>
|
||||
> Queue boundary: the active candidate queue lives in `spec-candidates.md`; older audit-derived candidate packages are historical inputs only.
|
||||
> Queue boundary: the active candidate queue lives in `docs/product/spec-candidates.md`; the promotable candidate backlog there is manual promotion only, not auto-prep; older audit-derived candidate packages remain historical inputs only.
|
||||
|
||||
---
|
||||
|
||||
@ -28,18 +28,23 @@ ## Current Productization & Moat Priorities
|
||||
|
||||
| Order | Theme | Repo truth | Product posture | Why now | Candidate posture |
|
||||
|---|---|---|---|---|---|
|
||||
| 1 | Customer Review Workspace Productization v1 | Reviews, Evidence Snapshots, Review Packs, Customer Review Workspace, and accepted-risk foundations are repo-real | fast sellable | clearest sellability blocker between current repo truth and a customer-safe governance-of-record surface | active P0 candidate |
|
||||
| 2 | Risk Acceptance & Accountability productization | Exception / risk-acceptance workflow is repo-verified, but customer-safe accountability presentation is not fully productized | fast sellable | strong MSP and German midmarket moat around documented decisions, expiry, reviewability, and audit trail | fold into Customer Review Workspace Productization and review/reporting follow-through, not a new greenfield foundation |
|
||||
| 3 | Governance Decision Surface Convergence | Governance Inbox, My Findings, Intake, and Exception Queue are repo-real, but convergence is not | almost | reduces admin-tool sprawl and turns multiple queue surfaces into calmer decision work | active P1 candidate |
|
||||
| 4 | Compliance Evidence Mapping v1 | Canonical controls, evidence, stored reports, reviews, and findings foundations are repo-real; customer-safe compliance mapping is not | foundation-only | strong governance moat for compliance-oriented MSP and Mittelstand reviews without certification claims | active P2 candidate |
|
||||
| 5 | Governance-as-a-Service Packaging v1 | Review packs, exports, evidence, and accepted-risk foundations are repo-real; recurring executive/MSP packaging is not | foundation-only | turns governance truth into a repeatable MSP deliverable instead of one-off manual reporting | active P2 candidate |
|
||||
| 6 | Cross-Tenant Compare & Promotion v1 | Portfolio triage exists; compare and promotion are not repo-proven | not implemented | strongest MSP multiplier after customer-safe review and decision workflows are calmer | active P1 candidate |
|
||||
| 7 | Private AI Execution Governance Foundation | Spec 248 exists, but no repo-real governed AI execution layer is proven | only spec / not implemented | strategic moat later, but not ahead of current productization and portfolio-action gaps | keep as later strategic lane, not near-term blocker |
|
||||
| 1 | Auditor Pack Delivery & Executive Export v1 | Review-pack export, evidence, tenant review, customer review productization, compliance mapping, and governance packaging foundations are already spec-backed and partially repo-real | fast sellable | clearest remaining step between repo-real governance truth and auditor-/executive-ready delivery | manual promotion only, not auto-prep |
|
||||
| 2 | Customer Review Workspace Productization v1 | Reviews, Evidence Snapshots, Review Packs, Customer Review Workspace, and accepted-risk foundations are repo-real | fast sellable | clearest customer-safe governance-of-record surface gap | spec-backed follow-through, not active queue |
|
||||
| 3 | Governance Decision Surface Convergence | Governance Inbox, My Findings, Intake, and Exception Queue are repo-real, but convergence remains incomplete | implemented but not productized | reduces admin-tool sprawl and turns multiple queue surfaces into calmer decision work | spec-backed follow-through, not active queue |
|
||||
| 4 | Compliance Evidence Mapping v1 | Canonical controls, evidence, stored reports, reviews, and findings foundations are repo-real; customer-safe compliance mapping follow-through remains | implemented but not productized | strong governance moat for compliance-oriented MSP and Mittelstand reviews without certification claims | spec-backed follow-through, not active queue |
|
||||
| 5 | Governance-as-a-Service Packaging v1 | Review packs, exports, evidence, and accepted-risk foundations are repo-real; recurring executive/MSP packaging follow-through remains | implemented but not productized | turns governance truth into a repeatable MSP deliverable instead of one-off manual reporting | spec-backed follow-through, not active queue |
|
||||
| 6 | Cross-Tenant Promotion Execution v1 | Cross-tenant compare preview and promotion preflight are repo-real; execution is not | not implemented | strongest MSP multiplier after review and packaging lanes are calmer | manual promotion only, not auto-prep |
|
||||
| 7 | Governance Decision Pack & Approval Workflow v1 | Decision convergence and decision-based operating framing are strong enough for a bounded human-in-the-loop slice, but the workflow itself is not implemented | not implemented | next narrow decision workflow without autonomous remediation | manual promotion only, not auto-prep |
|
||||
| 8 | Customer-Facing Localization Adoption v1 | Locale foundation is repo-real; customer-facing adoption, glossary completion, and regression hardening remain | implemented but not productized | turns existing localization groundwork into customer-safe polish | manual promotion only, not auto-prep |
|
||||
| 9 | Billing & Subscription Truth Layer v1 | Plans, entitlements, and commercial lifecycle are repo-real; billing/subscription truth is not | not implemented | closes the remaining commercial truth gap | manual promotion only, not auto-prep |
|
||||
| 10 | Stored Reports Surface v1 | Stored-report substrate is repo-real through evidence and review foundations; product surface remains incomplete | foundation-only | makes retained governance artifacts usable without manual digging | manual promotion only, not auto-prep |
|
||||
| 11 | First Governed AI Runtime Consumer v1 | Governed AI policy foundation is repo-real; no first governed runtime consumer is proven | not implemented | bounded post-foundation AI adoption after higher-priority sellability gaps | manual promotion only, not auto-prep |
|
||||
|
||||
Explicit anti-sprawl boundaries for this priority set:
|
||||
|
||||
- Do not reopen risk acceptance as a broad new foundation theme; reuse the existing exception/risk-acceptance workflow and productize its customer-safe accountability trail.
|
||||
- Do not reopen private AI as a fresh roadmap idea; the foundation already exists at spec level and should remain behind current customer-facing and MSP-facing sellability gaps.
|
||||
- Do not reopen private AI as a fresh roadmap idea; the foundation already exists in `specs/248-private-ai-policy-foundation/spec.md`, and the open roadmap question is only when to promote the first governed runtime consumer.
|
||||
- Do not treat the promotable candidate backlog in `docs/product/spec-candidates.md` as an automatic prep queue; those items require explicit product decisions.
|
||||
- Do not prioritize Tenant Trust Score / public governance profile, insurance connectors, Copilot shadow-IT governance, local-first/on-prem proxy, or a standalone Betriebsrat mode before customer-safe review consumption, decision convergence, compliance mapping, governance packaging, and compare/promotion are materially clearer.
|
||||
|
||||
---
|
||||
@ -92,7 +97,7 @@ ### R1.9 Platform Localization v1 (DE/EN)
|
||||
- Search/Sort/Filter auf kritischen Listen für locale-sensitives Verhalten prüfen
|
||||
- QA/Foundation: Missing-Key Detection, Locale Regression Tests, Pseudolocalization Smoke Tests für kritische Flows
|
||||
|
||||
**Queue status**: no standalone active candidate right now; remaining localization work should be folded into customer-facing productization and UI-maturity follow-through unless a narrower repo-real gap emerges.
|
||||
**Queue status**: no standalone active candidate right now; the historical foundation package is `specs/252-platform-localization-v1/spec.md`, and the remaining follow-through is `Customer-Facing Localization Adoption v1` in `docs/product/spec-candidates.md` as manual promotion only, not auto-prep.
|
||||
|
||||
### Product Scalability & Self-Service Foundation
|
||||
Self-service and supportability foundation that keeps TenantPilot operable as a low-headcount, AI-assisted SaaS instead of drifting into manual onboarding, manual support, and founder-dependent customer operations.
|
||||
@ -107,7 +112,7 @@ ### Product Scalability & Self-Service Foundation
|
||||
- Customer-facing transparency hooks: product surfaces should be designed so customer read-only views, review workspaces, support requests, and review-pack downloads can reuse the same underlying entities instead of becoming parallel one-off features
|
||||
- Private AI readiness hooks: support, review, diagnostic, and decision surfaces should be designed so later AI assistance can use governed context builders, data classification, usage budgets, local/private model policies, cache fingerprints, and human approval gates instead of direct feature-level AI calls
|
||||
|
||||
**Active specs**: — (not yet specced)
|
||||
**Repo reality**: this is no longer an unspecced greenfield foundation. Onboarding, diagnostics, support requests, contextual help, entitlements, telemetry, customer health, and operational controls are already spec-backed or repo-real; the remaining roadmap gap is broader customer/self-service productization plus the narrower `Billing & Subscription Truth Layer v1` follow-up tracked in `docs/product/spec-candidates.md`.
|
||||
|
||||
---
|
||||
|
||||
@ -137,11 +142,12 @@ ### R1.x Foundation Hardening — Governance Platform Anti-Drift
|
||||
- No AWS/GCP/SaaS connector implementation in this slice; this is anti-drift foundation work only
|
||||
|
||||
### R2 Completion — Evidence & Exception Workflows
|
||||
- Review pack export (Spec 109 — done)
|
||||
- Review pack export (`specs/109-review-pack-export/spec.md` — repo-real follow-through)
|
||||
- Exception/risk-acceptance workflow for Findings → Spec 154 (repo-real foundation; the next product gap is accountability-trail productization in customer-safe review, expiry/re-review visibility, and management-ready reporting)
|
||||
- Formal evidence/review-pack entity foundation → Spec 153 (evidence snapshots, draft) + Spec 155 (tenant review layer / review packs, draft)
|
||||
- Formal evidence/review-pack entity foundation -> `specs/153-evidence-domain-foundation/spec.md` + `specs/155-tenant-review-layer/spec.md`
|
||||
- Workspace-level PII override for review packs → deferred from 109
|
||||
- Customer Review Workspace Productization v1 → sharpen customer-facing review consumption: baseline status, latest reviews, findings, accepted risks, evidence/review-pack downloads, customer-safe redaction, calmer access states, and no admin/remediation actions
|
||||
- Customer Review Workspace Productization v1 -> `specs/258-customer-review-productization/spec.md` and the adjacent follow-through in `specs/259-compliance-evidence-mapping/spec.md` + `specs/260-governance-service-packaging/spec.md`
|
||||
- Auditor Pack Delivery & Executive Export v1 -> manual-promotion follow-up that builds on `specs/109-review-pack-export/spec.md`, `specs/153-evidence-domain-foundation/spec.md`, `specs/155-tenant-review-layer/spec.md`, `specs/258-customer-review-productization/spec.md`, `specs/259-compliance-evidence-mapping/spec.md`, and `specs/260-governance-service-packaging/spec.md` rather than reopening them as active queue work.
|
||||
- Support Diagnostic Pack → connect tenant/review/finding/report/operation contexts into a reusable support bundle before support demand scales
|
||||
- In-App Support Request with Context → attach the relevant diagnostic pack and ticket reference to support workflows without creating a separate support data model
|
||||
- Product Knowledge & Contextual Help → reuse canonical glossary, outcome/reason semantics, and report/finding terminology as the product-help source layer
|
||||
@ -168,13 +174,13 @@ ### Workspace, Tenant & Managed Object Lifecycle Governance
|
||||
- Retention / compliance lifecycle: retained, export requested, deletion requested, deletion scheduled, legal hold / retention hold, purge due, purged
|
||||
- Restoreability lifecycle: restorable, metadata only, blocked by dependency, not restorable, expired by retention
|
||||
|
||||
**Roadmap posture**: Strategic P2 enterprise-trust candidate, not immediate implementation. This should not block Customer Review Workspace Productization, Governance Decision Surface Convergence, or Cross-Tenant Compare & Promotion.
|
||||
**Roadmap posture**: The taxonomy-first foundation is now captured in `specs/262-lifecycle-governance-taxonomy/spec.md`. The narrower runtime follow-through is `Workspace & Tenant Closure Lifecycle v1` in `docs/product/spec-candidates.md`, and it remains manual promotion only, not auto-prep.
|
||||
|
||||
**Important boundary**: Do not implement a narrow policy-only ghost lifecycle patch, Laravel `SoftDeletes` rollout, workspace deletion flow, tenant deletion flow, purge engine, or retention framework before this lifecycle taxonomy is agreed.
|
||||
|
||||
**Approved narrow exception**: Spec 261 (`provider-missing-policy-visibility`) now captures the bounded policy-only provider-missing truth correction. Keep future lifecycle, deletion, retention, and purge work taxonomy-first; do not generalize Spec 261 into the broader lifecycle model.
|
||||
|
||||
**Spec candidate**: `Workspace, Tenant & Managed Object Lifecycle Governance v1` in `docs/product/spec-candidates.md`.
|
||||
**Spec-backed foundation**: `specs/262-lifecycle-governance-taxonomy/spec.md` is the agreed taxonomy-first package. Keep closure/runtime follow-through separate from the taxonomy and promote it only through `Workspace & Tenant Closure Lifecycle v1` in `docs/product/spec-candidates.md`.
|
||||
|
||||
### Platform Operations Maturity
|
||||
- CSV export for filtered run metadata (deferred from Spec 114)
|
||||
@ -228,6 +234,7 @@ ### Product Usage, Customer Health & Operational Controls
|
||||
|
||||
### Private AI Execution Governance Foundation
|
||||
Strategic AI platform foundation for using AI inside TenantPilot without hard-coding public cloud AI calls, leaking tenant data, losing cost control, or forcing later rewrites.
|
||||
**Repo reality**: `specs/248-private-ai-policy-foundation/spec.md` already captures the governed AI foundation. The open roadmap gap is no longer whether a foundation should exist, but when to promote the first governed runtime consumer.
|
||||
**Goal**: Make AI local/private-first, explicitly governed, budgeted, cacheable, auditable, and human-approved. External public AI providers are disabled by default and only usable through workspace-level opt-in, data classification, redaction, usage limits, and approval gates.
|
||||
**Why it matters**: TenantPilot sells governance, compliance readiness, evidence, and tenant trust. AI cannot be bolted on through direct feature-level API calls. The platform needs a reusable execution boundary so support summaries, finding explanations, review packs, decision packs, and customer communications can use AI later without rebuilding privacy, cost, provider, approval, and audit controls each time.
|
||||
**Depends on**: Product Knowledge & Contextual Help, Support Diagnostic Pack, Decision Pack Contract & Approval Workflow, Product Usage & Adoption Telemetry, Plans / Entitlements & Billing Readiness, Operational Controls & Feature Flags, Security Trust Pack Light, audit log foundation, and workspace/RBAC isolation.
|
||||
@ -364,7 +371,7 @@ ## Long-term
|
||||
|
||||
### Tenant-to-Tenant / Staging→Prod Promotion
|
||||
Compare/diff between tenants, mapping UI (groups, scope tags, filters, named locations, app refs), promotion plan (preview → dry-run → cutover → verify).
|
||||
**Source**: 0800-future-features, Spec 043 draft.
|
||||
**Source**: 0800-future-features and `specs/043-cross-tenant-compare-and-promotion/spec.md`.
|
||||
|
||||
### Recovery Confidence ("Killer Feature")
|
||||
Automated restore tests in test tenants, recovery readiness report, preflight score.
|
||||
@ -388,12 +395,14 @@ ## Infrastructure & Platform Debt
|
||||
| No shared lifecycle taxonomy for workspace, tenant, managed-object, retention, export, purge, and restoreability states | Local fixes such as ghost-policy handling, workspace deactivation, tenant removal, retention, or purge can create inconsistent deletion semantics and audit gaps | Covered by Workspace, Tenant & Managed Object Lifecycle Governance candidate |
|
||||
| No structured support diagnostic bundle yet | Support cases require manual context gathering across tenants, runs, findings, providers, and reports | Covered by Product Scalability & Self-Service Foundation |
|
||||
| No formal security trust pack yet | Enterprise sales and customer security reviews require repeated manual explanations | Covered by Solo-Founder SaaS Automation & Operating Readiness |
|
||||
| No product usage/adoption telemetry yet | Founder cannot see onboarding drop-off, feature adoption, trial health, or support-triggering surfaces without manual investigation | Covered by Additional Solo-Founder Scale Guardrails |
|
||||
| No customer health score yet | Churn, inactive customers, stale reviews, unhealthy provider connections, and unresolved high-risk findings may be noticed too late | Covered by Additional Solo-Founder Scale Guardrails |
|
||||
| No explicit operational controls / feature flags lane | Incidents or risky features may require code changes or manual database intervention instead of safe operator controls | Covered by Additional Solo-Founder Scale Guardrails |
|
||||
| No private AI execution foundation yet | Future AI features may call model providers directly, leak tenant context, become hard to audit, or require rewrites to support local/private models | Covered by Private AI Execution Governance Foundation |
|
||||
| No AI usage budgeting / cost governance yet | AI-assisted summaries, decision packs, reviews, and support workflows may create uncontrolled compute/API costs and queue pressure | Covered by Private AI Execution Governance Foundation |
|
||||
| No AI data classification / context-builder boundary yet | Raw provider payloads, personal data, or customer-confidential tenant context could be over-shared with models instead of sanitized purpose-specific context | Covered by Private AI Execution Governance Foundation |
|
||||
| Auditor-ready executive export is not yet productized | Review truth still stops short of auditor-/executive-ready delivery without additional packaging | Covered by the manual-promotion backlog in `docs/product/spec-candidates.md` |
|
||||
| Cross-tenant promotion execution is missing | Compare preview and preflight stop short of the actual portfolio action | Covered by the manual-promotion backlog in `docs/product/spec-candidates.md` |
|
||||
| Governance decision pack and approval workflow is missing | Decision-based operating still lacks a bounded approval-ready action package with explicit audit trail | Covered by the manual-promotion backlog in `docs/product/spec-candidates.md` |
|
||||
| Customer-facing localization adoption is incomplete | Repo-real locale groundwork is not yet fully productized across customer-safe governance surfaces | Covered by the manual-promotion backlog in `docs/product/spec-candidates.md` |
|
||||
| Billing and subscription truth is missing | Commercial readiness still stops short of a durable billing/subscription truth layer | Covered by the manual-promotion backlog in `docs/product/spec-candidates.md` |
|
||||
| Stored reports still lack a clear product surface | Retained evidence and review artifacts remain harder to consume than they should be | Covered by the manual-promotion backlog in `docs/product/spec-candidates.md` |
|
||||
| Workspace and tenant closure follow-through is not started | The taxonomy exists, but closure/runtime semantics are not yet productized | Covered by the manual-promotion backlog in `docs/product/spec-candidates.md` |
|
||||
| First governed AI runtime consumer is missing | The governed AI foundation exists, but no bounded runtime consumer proves the model end-to-end | Covered by the manual-promotion backlog in `docs/product/spec-candidates.md` |
|
||||
| No no-customization governance yet | Customer-specific requests can silently turn the product into consulting work and create hidden maintenance obligations | Covered by Additional Solo-Founder Scale Guardrails |
|
||||
| No business-continuity / founder-backup plan yet | Solo-founder operations create continuity risk for incidents, illness, vacation, access recovery, and customer trust | Covered by Additional Solo-Founder Scale Guardrails |
|
||||
| No `.env.example` in repo | Onboarding friction | Open |
|
||||
@ -406,31 +415,27 @@ ## Infrastructure & Platform Debt
|
||||
|
||||
---
|
||||
|
||||
## Priority Ranking (from Product Brainstorming)
|
||||
## Priority Ranking (Current Manual Promotion Order)
|
||||
|
||||
1. Product Scalability & Self-Service Foundation
|
||||
2. Product Usage, Customer Health & Operational Controls
|
||||
3. Private AI Execution Governance Foundation
|
||||
4. Decision-Based Operating / Governance Inbox
|
||||
5. MSP Portfolio + Alerting
|
||||
6. Drift + Approval Workflows
|
||||
7. Evidence / Review Packs + Customer Review Workspace
|
||||
8. Standardization / Linting
|
||||
9. Promotion DEV→PROD
|
||||
10. Recovery Confidence
|
||||
11. Solo-Founder SaaS Automation & Operating Readiness
|
||||
12. Additional Solo-Founder Scale Guardrails
|
||||
1. Auditor Pack Delivery & Executive Export v1
|
||||
2. Cross-Tenant Promotion Execution v1
|
||||
3. Governance Decision Pack & Approval Workflow v1
|
||||
4. Customer-Facing Localization Adoption v1
|
||||
5. Billing & Subscription Truth Layer v1
|
||||
6. Stored Reports Surface v1
|
||||
7. Workspace & Tenant Closure Lifecycle v1
|
||||
8. First Governed AI Runtime Consumer v1
|
||||
|
||||
---
|
||||
|
||||
## How to use this file
|
||||
|
||||
- **Big product and operating themes** live here.
|
||||
- **Concrete spec candidates** → see [spec-candidates.md](spec-candidates.md)
|
||||
- **Concrete spec candidates** → see `docs/product/spec-candidates.md`
|
||||
- **Lifecycle / deletion / retention work must be taxonomy-first**: do not promote narrow ghost-policy, workspace deletion, tenant deletion, purge, or retention specs until the shared Workspace, Tenant & Managed Object Lifecycle Governance candidate defines the platform semantics.
|
||||
- **Company automation / solo-founder operating items** live here as strategic tracks first; only product-impacting or repeatable engineering work should become spec candidates.
|
||||
- **Solo-founder guardrails** should remain visible even when they are not immediate product specs, because they define what must become measurable, controllable, delegable, or documented before customer volume grows.
|
||||
- **Governance positioning is Microsoft-first, provider-extensible**: roadmap language should keep the initial product scope focused on Microsoft tenant governance while avoiding unnecessary Microsoft-only coupling in platform-level abstractions.
|
||||
- **AI positioning is local/private-first and provider-adapter-based**: roadmap language should avoid direct feature-level public AI calls and instead route AI through use-case registries, data classification, context builders, policy gates, budget gates, provider adapters, audit trails, and human approval workflows.
|
||||
- **Small discoveries from implementation** → see [discoveries.md](discoveries.md)
|
||||
- **Product principles** → see [principles.md](principles.md)
|
||||
- **Small discoveries from implementation** → see `docs/product/discoveries.md`
|
||||
- **Product principles** → see `docs/product/principles.md`
|
||||
|
||||
Loading…
Reference in New Issue
Block a user