Enable Not Serve
Enable Not Serve
The ethos of the products we create is to enable our colleagues and customers to self-serve their own needs rather than product teams or service teams having to serve customers and colleagues in response to their requests. This enables teams to focus on engineering, operating and supporting the product rather than taking time out to service requests from users.
Considerations
Avoiding the need to serve users of our products means that we do not have to dedicate time and effort to satisfying user requests. By emphasising a self-service led approach product teams can maximise the effort they give to providing additional features and services, to correcting escaped defects and to resolving operational issues.
Users benefit because they do not have to queue for service. Delay and its associated costs are avoided by fulfilling users requests without human intervention. Cost of delay for customers is reduced or eliminated.
Levels
Green
Features Enable Users
Product features are designed on the basis of enable, not serve. Features in solutions are designed to satisfy this principle.
Where features have been historically deployed that do not conform to this principle, there are prioritised plans to move from a request and service model to an enabling model.
Amber
Some Features Enable Users
There is no consistently applied design principle focusing on enable, not serve. Some features may offer services with an enabling model.
There is a significant number of services that require a request and service model.
Some plans may exist to migrate existing features towards an enabling model, but these do not cover all services and may not be clearly prioritised.
Red
Features Do Not Enable Users
Features demanding a request and service model are routinely implemented.
There is no consistent challenge to move new services towards an enabling model.