Making one product fit widely different organizations

Role
Founding Product Designer [consultant]
Context
End-to-end platform supporting EV charging infrastructure across stakeholders
Stage
Post-seed, just joined
Tags
Seed , 0→1 , Architecture , Multi-stakeholder

1.0 Challenge

How can different organizational structures, including ones not yet encountered, be supported without over-engineering?

Post-seed, turning Relion's MVP into a scalable product meant laying the foundations of its organization model: hierarchy, roles, permissions and sharing.

The multi-stakeholder context initially seemed fairly straightforward: charge point operators run chargers at locations and collaborate with manufacturers and service providers on issue resolution.

Screenshot of the Relion organization and group settings screens.
Charge point operators, manufacturers and service providers collaboring on issue resolution.

But patterns emerging from sales conversations and product discovery showed that each organization we approached was structured differently.

Many operators outsource maintenance to not one but multiple service providers. Others use warranties to delegate issue resolution to manufacturers. Some service providers become operators and manage chargers on behalf of non-technical customers. Cities or larger organizations may split operations (and thus location management) and fieldwork across local entities.

2.0 Response

Working closely with the CPTO, we made a few informed bets, tested them iteratively against known customer structures and converged on a small set of guidelines.

① Organizations represent CPOs, manufacturer or service providers. They contain users, locations and chargers.

② Organizations can be recursively nested to represent structures of any depth. A parent organization can have both sub-orgs and locations of its own.

③ Sub-orgs may inherit user roles and permissions downward, not upward. Access to ressources like networks and parts can follow the same logic.

④ A service provider remains independent, with access to locations depending on service agreements or geography.

CPOs, manufacturers and service providers represented as organizations, recursively nested to reflect structures of any depth.

This, for example, represents a typical North American car dealership network with chargers at every location and different operational structures in the US and Canada.

Although refined as the product scaled, this foundation still underpins every screen and workflow in Relion, supporting hundreds of operators, manufacturers and service providers working together to maintain large networks of chargers. Product architecture shapes the entire user experience, down to the smallest interface details. Below are a few examples.

Global and local filters let organization managers monitor locations across sub-orgs, and third-party managers across customers.
Global and local filters let organization managers monitor locations across sub-orgs, and third-party managers across customers.
Organizations can cascade access to resources like parts to sub-orgs, reducing duplication and administration.
Organizations can cascade access to resources like parts to sub-orgs, reducing duplication and administration.
Screenshot of the Relion sharing and permissions configuration screen.
Users can see a summary of activity across their organization and mute updates where needed.