Product implemented
This path is for product structure: personas, journeys, v3 IA, page families, surface contracts, competitive context, governance implications, and product gaps.
Product Positioning That Should Be Clear
From a product-owner point of view, GPUaaS is doing three things at once:
- delivering end-user GPU capacity and app workflows;
- defining the customer hierarchy and IAM model the rest of the platform will inherit;
- proving the shared-platform contracts that future products will consume.
The portal should make all three visible without forcing product readers into raw architecture docs.
Product Decision Route
| If product needs to answer... | Open this first | Then go here |
|---|---|---|
| what is actually implemented now | Product Team Handoff | Current State and Roadmap |
| what users and admins are really trying to do | User Interactions | Use GPUaaS |
| whether navigation and page family design are coherent | Product IA and Role Model | Journeys and v3 IA |
| what the tenant, department, project, and resource hierarchy actually is | Tenant, Department, Project, And Resource Hierarchy | Product IA and Role Model, Use GPUaaS |
| whether a feature is competitive and launch-worthy | Competitive Context | Launch, Allocation, and Runtime Flow |
| whether a gap is product, readiness, or implementation debt | Current State and Roadmap | Security & Production Readiness, Portal Roadmap |
Product Reading Order
- Product Team Handoff
- Current State and Roadmap
- Product Strategy
- User Interactions
- Product IA And Role Model
- Tenant, Department, Project, And Resource Hierarchy
- Launch, Allocation, And Runtime Flow
- Journeys and v3 IA
- Competitive Context
- Page-level contracts, migration notes, and gap analysis.
Product Reader Map
Product pages in the portal should explain the journey and point to the canonical product specs. They should not become a second backlog or competing product source of truth.
Product Completion Rule
A feature is only product-complete when the portal can explain:
- the primary user path,
- the admin/operator path,
- the recovery or blocked path,
- the implemented versus deferred boundary,
- and the next owner if a gap remains.
Pages
- Product Team Handoff
- Current State and Roadmap
- Product Strategy
- User Interactions
- Product IA And Role Model
- Tenant, Department, Project, And Resource Hierarchy
- Launch, Allocation, And Runtime Flow
- Journeys and v3 IA
- Competitive Context
What A New Product Team Should Learn
| Topic | Summary |
|---|---|
| Product handoff | What is implemented now, what is in the active queue, what pages a PM should read first |
| Product vision | Secure self-service GPU platform for capacity discovery, provisioning, access, monitoring, and consumption-based billing |
| User journey center | Sign in, choose tenant/project context, launch workload, track task, access runtime, manage storage, monitor billing, release |
| Admin/operator surface | Manage inventory, users, allocations, audit, payments, node fleet, health, incidents, and release evidence |
| App developer path | App SDK, manifest, examples, artifact trust, promotion, and API/event contracts |
| Product gaps | UI migration, generated API reference, billing diagnostics, deployment profiles, app runtime lifecycle, and hard isolation maturity |
What Product Should Not Have To Infer
- whether the queue is still active or the feature is already shipped;
- whether a UX surface is documented but not actually implemented;
- whether a platform/readiness issue is being misrepresented as product scope.