Product Model
Target model for relationship operations.
Product Model
This section is product direction. It is not a description of the current shipped app. The current app implements authentication, account/session views, status endpoints, and generated API docs; the relationship operations domain is still roadmap work.
Target thesis#
Arn should become a relationship operations layer for high-touch B2B work. The long-term goal is a shared operating layer for companies that sell to, buy from, implement with, support, and depend on other companies.
The first product wedge should be narrower than the full ambition: implementation and relationship work where communication, files, decisions, obligations, owners, and permissions are scattered across tools.
Target category shape#
| Horizon | Product shape | Proof needed |
|---|---|---|
| Now | App foundation | authentication, account, API, docs, and product positioning are coherent |
| First domain | Implementation operations | source-backed status, blockers, decisions, files, owners, and visibility work for one relationship |
| Expansion | Relationship operations | customer and vendor workstreams share one permissioned relationship record |
| Long term | B2B OS | cross-company work runs through Arn's communication, context, and policy layer |
Target operating layers#
Rendering diagram...
Product principles#
- Communication is the source of work: commitments, blockers, decisions, and files appear in messages and systems before they appear in planning tools.
- Relationships are the organizing unit: messages and records should resolve to companies, people, workstreams, and permissions.
- Summaries need evidence: every generated status, risk, decision, or obligation should point back to source events.
- External collaboration is permissioned by default: customers, vendors, partners, and guests should see only what they are allowed to see.
- Systems of record stay important: CRM, support, CLM, procurement, finance, and project tools should receive approved updates rather than become the whole workspace.
- The OS emerges from primitives: the B2B OS should emerge from reliable communication sync, identity, permissions, information condensation, work coordination, and system sync.
Read next#
- Category - Relationship operations positioning
- Implementation - First planned product wedge
- Architecture - Target communication, information, and permission primitives
- Strategy - Long-term B2B OS direction and staged roadmap