Define product packages by outcome rather than by hours worked.
A robust product package describes the target state, performance limits, evidence, and change policies, rather than simply selling a number of hours.
For management and agencies, "defining product packages based on results" can be evaluated primarily on two points: "target state" and "hidden transparency." This comparison makes the professional boundaries tangible.
Published: 3 min read · Author: Sebastian Geier
How does an open service become a clearly defined deliverable?
An open service becomes a deliverable by first defining the achievable target state. Scope, participation, exclusions, and acceptance are derived from this; hours remain an internal cost estimate.
Target State
Target State – The package specifies a deliverable that the client and provider can verify based on the same criteria.
Scope of Work – Included work, necessary collaboration, and explicitly excluded tasks are clearly identifiable before the contract is awarded.
Acceptance Process – For each deliverable, the verification process, the reviewing role, and the handling of justified deviations are clearly defined.
Implicit Transparency
Implicit Transparency – Vague formulations such as "complete implementation" effectively turn the package into an unlimited project.
Incorrect Result – A deliverable artifact may be complete even though the promised functional state has not been achieved.
Unpaid Variants – Undefined special cases are incorporated into the regular service without any price or deadline implications.
Acceptance Process
Percentage of orders accepted without subsequently added mandatory services.
Rework and unplanned variants per released package version.
Counter-test: "Hidden Transparency"
A website package does not promise a specific number of development days, but rather a published, tested page type with defined content. Missing customer texts and additional interfaces are listed as prerequisites or options.
Scope of Work
First, the customer goal and the visible end state are described in acceptable sentences.
Next, service modules, collaboration, exclusions, and permissible variants are assigned to the target state.
Finally, a complete sample order verifies the calculation, handovers, and acceptance before the package is offered.
What "Defining Product Packages by Results" means for related tasks
An in-depth question answered Documenting a Digital Service Model from Sales to OperationWhat must a service model capture from the sales phase to ongoing operations?
Further Perspectives Presenting financing options transparently without diluting the pricing logic.
If you want to practically implement "Defining Product Packages by Results," you can refer to Robust Website Systems This focuses on "Service Product and Modularization" and "Target State."
Conclusion: Define product packages based on deliverables
A deliverables package sells a clearly defined target state, not available time. Only performance limits and acceptance make this promise reliable.
Sources and Further Information
The following official documentation and standards provide the technical classification.
Learning about users and their needs – GOV.UK Service ManualThe official service design guideline requires observed user needs as the basis for service and product decisions.
4. Make the service simple to use – GOV.UK Service ManualThe official service standard combines simple processes, real-world user testing, and a consistent end-to-end experience. ...4: A digital service model connects promises and delivery capabilities across the entire lifecycle. Versioning prevents product changes from retrospectively creating conflicting expectations.
Key Thesis
First, the verifiable target state is defined; then the scope, participation, exclusions, and acceptance follow. Hours remain an internal calculation parameter, not the sold performance promise.
What This Is Not About
A product package is not a renamed hourly allowance or an open promise to somehow accomplish everything necessary.
What it's about
It describes a verifiable target state, the services included to achieve it, and the conditions under which the result can be accepted.
Digital Products & Growth Systems
Structure services as standardized Digital Products.
The question "How can an individual service be transformed into a standardizable digital product?" is a separate review step within the "Defining product packages based on results" framework.
Digital Products & Growth Systems
Standardizing status models for projects, content, and approvals
Adds a separate decision to "Defining product packages based on results": How is a status model created that encompasses projects, content, and approvals?
Insights Overview
All VELUNO Insights at a Glance
Further analyses on Website Systems, digital visibility, and robust working models.
Performance limit: concrete checkpoint
A frequently sold hourly rate is a suitable next step. Its target state is described separately from scope, participation, and internal effort estimation.