Build Digital Services Around Work, Not Features

“We need a portal” or “we need an app” may be a valid conclusion, but it is a weak starting point. The request says little about what people are trying to accomplish, how work moves today, which decisions cause delay, what information is required, who may see it, where exceptions occur or who will operate the system after launch.

When those questions remain unresolved, a product can be visually polished and operationally hollow. Staff continue using email and spreadsheets around it. Data is re-entered. Permissions reflect convenience rather than policy. Reporting remains manual. The interface is new; the operating burden survives.

Every form, dashboard, notification and approval sits on top of an operating choice. A status label reflects a workflow. A role reflects authority. A field reflects a data requirement. An integration reflects system ownership. A notification reflects who is expected to act and when.

Good digital-service design makes those choices explicit before they harden into code.

• The project begins with preferred screens or products before the current workflow has been understood.
• Different departments use the same terms for different states, approvals or responsibilities.
• No one can state who owns the data model, permissions or administrator role.
• The system is expected to “fix” policy ambiguity rather than implement an approved operating decision.
• Reporting requirements appear late and force manual work or duplicate data collection.
• User acceptance is treated as visual preference instead of evidence that real tasks can be completed correctly.
• Launch is planned, but administrator training, support, ownership and improvement are not.

The responsible starting point is not “What should the software include?” It is “What must users and staff be able to accomplish, under what rules, with what information and with what evidence?”

That framing protects the organization from overbuilding, buying an ill-fitting platform or encoding a broken process. It also creates a stronger basis for deciding which parts should be configured, integrated, automated or built.

The measure of a digital service is not that it went live. It is that people can complete the service more clearly, staff can manage it with less friction, data is better governed, leadership has better visibility and the organization can administer the environment without permanent dependence on a developer.

The best product strategy is therefore inseparable from service design, data governance, security, training and operating ownership. That integration is not extra scope. It is what makes the product real.