THE SHORT ANSWER
A digital product is a software-enabled system that helps a user achieve an outcome through an interface, behavior, data or connected service. Examples include web applications, mobile apps, SaaS products, marketplaces, internal tools and online services. A content website can be valuable without needing accounts, workflows or application complexity.
Begin with the user outcome
A workshop registration product helps someone choose a session, submit details and receive a result. An appointment product coordinates availability and booking. An internal tool may help a team review records. The interface matters, but the product includes the rules, data and operations needed to complete the outcome.
Ask what the user is trying to accomplish, what must happen behind the interface and what the organization must continue operating after launch.
Evidence & context: GOV.UK Service Manual
Digital products take several forms
| Form | Primary role | Typical behavior |
|---|---|---|
| Content website | Publish information | Read, navigate, contact |
| Web application | Complete interactive tasks | Accounts, workflows or saved state |
| Mobile application | Serve device-centered use | Installed experience and device capabilities |
| SaaS | Provide software as an ongoing service | Recurring access, administration and support |
| Marketplace or platform | Coordinate participants | Supply, demand, trust and transactions |
| Internal tool | Support organizational work | Restricted workflows and operational data |
A website does not automatically need application complexity
A public site that explains a service, publishes resources and accepts a simple contact request may not need user accounts or a database. Adding persistent profiles, permissions and custom workflows creates new development, security and maintenance responsibilities.
Use one product-building sequence
Move through PROBLEM → USER → OUTCOME → REQUIREMENT → PROTOTYPE → BUILD → TEST → LAUNCH → LEARN. Each stage should reduce a specific uncertainty rather than add features by momentum.
Next, compare website, web app, mobile app and SaaS before writing the product requirement.
Sources & further reading
- How the web works
MDN Web Docs. Standards-oriented learning material on clients, servers, DNS, HTTP and browser rendering. It is a simplified conceptual introduction rather than a complete architecture guide.
- Learning about users and their needs
GOV.UK Service Manual. Public-service design guidance linking user needs to stories, acceptance criteria and continued research. Its process should be adapted to the product and risk context.
Examples and exercises are illustrative unless attributed to a source. No independent expert review is claimed.
A correction, a counterexample or an experience worth sharing?
Join the conversation ↗