BetterFleet Product Ontology¶

Organising Principle: Domain Independence¶

Each domain represents a real-world problem space that exists independently of BetterFleet. It should be recognizable to an EV fleet operator, grid engineer, or charge point operator regardless of which software they use.

This is the distinction between an ontology and a taxonomy:

• An ontology maps the domain relationships.
• A taxonomy classifies BetterFleet features.

An ontology-first approach means:

• Domain names are stable as the product grows, so new features slot into existing domains rather than forcing renames.
• The structure can be shared with customers, analysts, and partners without being BetterFleet-specific.
• It serves as a durable foundation for roadmapping and capability conversations.
• It supports clearer, cleaner, more independent feature definitions.

Each domain also has sub-themes that make the ontology usable for finer-grained planning and analysis.

For internal product questions, use Where to Ask Product Questions to map these domains to Slack channels.

Domains and Sub-Themes¶

mindmap
  root((BetterFleet
  Ontology))
    Smart Charging
      Charger Control
      Load Management
      Protocol & Interoperability
    Energy & Cost Management
      Site Energy & Infrastructure
      Advanced Energy & Grid
    Operations & Dispatch
      Depot & Integration
      Dispatch & Scheduling
      Fleet & Vehicle Management
    Roaming & Shared Charging
      Out of Depot
      3rd party in Depot
    Incidents & Notifications
      Alerting
      Detection
      Incident & Resolution Mgmt
    Reporting & Insights
      Cost, Carbon & Compliance
      Fleet & Charging Analytics
      Operational Dashboards
    Resilience & Security
      Platform Reliability & Safety
      Security & Access Control
    Accessibility & Usability
      Onboarding & Support
      User Experience

Analytical Lenses¶

Domain Lens¶

Question: What problem space does this feature address?

This is the primary organising lens. It is stable, internal, and used for roadmapping and development planning. It maps to how engineers and product managers think about the system.

Physical Lens¶

Question: What asset in the physical or operational chain does this feature act on?

Seven nodes: Vehicle · Charger · Site · Grid · Fleet · Network · Organisation

This lens is useful for identifying gaps, planning integrations, and communicating with infrastructure and operations stakeholders. It shows where product capability sits in the charge-to-dispatch flow.

Persona Lens¶

Question: Who is the primary user of this feature?

Six personas: Depot Operator · Fleet Manager · Energy Manager · IT / Security · Finance / Sustainability · Commercial / Network

This lens is useful for UX prioritisation, sales packaging, and identifying underserved user types.

Marketing Lens¶

Question: What outcome does this feature enable for a buyer?

Five outcome clusters: Fleet Readiness · Cost & Carbon Control · Operational Visibility · Trusted Platform · Unlock Your Infrastructure

This lens is useful for go-to-market messaging, sales decks, and RFP responses. It is derived from the domain ontology rather than driving it, so marketing language remains grounded in product reality.

Feature Definition Principles¶

A clean feature entry satisfies four conditions:

Single domain. The feature belongs unambiguously to one domain. If it could reasonably be placed in two, it is doing double duty and should be split. The test is whether two different product managers would independently file it in the same place.

Single primary actor. The feature has one primary persona. If it serves two fundamentally different users in different ways, it is usually two features with shared implementation rather than one feature with two users.

Atomic capability. The feature describes one thing the user can do, not a bundle of related behaviors. Names joined by & or and are usually candidates for splitting unless they are always delivered together and never used independently.

Testable scope. A clean feature can be scoped into a ticket without ambiguity about what is and is not included. If the boundary requires a paragraph of explanation, the definition is too broad.