Concept and mechanism
Exploring stakeholders starts with understanding who uses, decides, funds, and supports the service. These perspectives may belong to different people. In an international service, average daily demand may conceal a small group with critical night deadlines. Segment by tasks, hours, constraints, and desired outcomes, using enough evidence to avoid stereotypes. A need is also not necessarily the solution someone requested. Twenty form fields may conceal a need to compare exceptions or demonstrate approval. Investigate current work and difficulties before turning the suggestion into a final technical specification.
Guided application
A value proposition should help customers compare concrete options. “Modern cloud” says little about report timing, available support, or required integration effort. Explain intended outcomes, conditions, costs, and known risks. If portal adoption is low, distinguish lack of awareness, poor fit, and journey obstacles. Visit statistics alone do not explain abandonment. Combine observation, support contacts, and interviews with target users. GOV.UK guidance is used as a complementary research method; it does not establish banking procurement rules or replace the organization’s authorized supplier-selection criteria.
A daytime offering may serve one group well while leaving another unsupported during the night batch.
Common pitfalls
Need equals requested feature; average audience as every audience; promotion as the automatic response to low adoption.
Related topics: Relationships, collaboration, and trust · Demand, requirements, and service offerings
Explain value through the work the offering enables and the conditions under which it does so.
Reference: GOV.UK: Learning about users and their needs · ITIL 4 DSV; observed JA v1.0.1 (2025 copyright), current EN revision comparison pending