CUST.Reference:10 - Sources and Synthesis

The source lines answer different questions. Service productization explains how an offering can become sufficiently specified and organized for repetition. Product-family and mass-customization work explains commonality, solution-space boundaries and customer choice. Order-decoupling and postponement work explains where common preparation ends and customer-dependent work begins. Field-engineering accounts explain continuing contact between local implementation and product development. Solution and outcome-based work connects provision, relationships, responsibility and economics.

CUST adopts those contributions at their stated reach. It rejects a universal “local success becomes product” sequence, a universal advantage of postponement, and an inference from a vendor’s organizational description to measured effectiveness. Existing full framework Methods provide practical engineering, implementation, accounting and operating treatments; a limited external abstract is not used to replace them.

CUST.Reference:10.1 - Productization, families and customer choice

• Wirtz, Fritze, Jaakkola, Gelbrich and Hartley, “Service products and productization” (2021), DOI 10.1016/j.jbusres.2021.08.033. The abstract, Sections 3–4 and selected discussion in Sections 5–6 support specification of a service product and its organized provision. This is a conceptual contribution, not measured evidence that CUST improves performance. CUST adapts the commercial framing for public and nonprofit provision while retaining actual resource requirements.
• Valtakoski and Järvi, “Productization of knowledge-intensive services: Enabling knowledge sharing and cross-unit collaboration” (2016), DOI 10.1108/JOSM-01-2015-0004. The primary abstract of two longitudinal cases supports attention to goals, shared understanding and collaboration. It does not supply a fully read transfer procedure; CUST.6 obtains that treatment through Implementation Facilitation.
• Salvador, de Holan and Piller, “Cracking the Code of Mass Customization” (2009). The article’s main text and three-capability account provide the historical anchor for solution-space development, robust process design and choice navigation, including services. CUST.3 and CUST.4 retain the three distinct questions instead of treating customization as a menu of features.
• Simpson, Siddique and Jiao, “Platform-Based Product Family Development” (2006). The bounded chapter treatment, especially printed pages 4–6, supports top-down family development and bottom-up consolidation, with a commonality/differentiation tradeoff. It is not a reading of the entire book or a source for every service-family construction.
• Bakås, Buer, Skjelstad and Kløve, “A Framework for Solution Space Development in Mass Customization” (2023), DOI 10.1007/978-3-031-34821-1_15. The primary abstract supports a continuing front-end/back-end learning account. It does not support importing the paper’s unread full module procedure. The positive family construction here remains explicit in CUST.3 and in its full suppliers.

These contributions favor an explainable common basis and permitted variation over premature standardization. They leave room for useful local residue. When similarity is merely superficial, CUST keeps separate offerings rather than forcing one family.

CUST.Reference:10.2 - Differentiation and its operating consequences

• Olhager, “Strategic positioning of the order penetration point” (2003), DOI 10.1016/S0925-5273(03)00119-1. The primary abstract and indexed introduction support the distinction between forecast-driven common work and order-driven work. No complete algorithm is claimed from that bounded reading.
• Harfeldt-Berg and Olhager, “The customer order decoupling point in empirical operations and supply chain management research: a systematic literature review” (2024). The primary indexed abstract establishes a broad empirical review and multiple contextual factors; it is not used as a fully read taxonomy or a universal selection rule.
• Naldi, Galizia and Bortolini, “Balancing storage cost and customization time in product platform design: a bi-objective optimization model” (2025). Its model and stated assumptions make competing time and storage objectives concrete. Deterministic demand, cost and time, just-in-time custom components, sufficient warehouse space and the treatment of production cost bound the result. CUST.4 retains the tradeoff but does not transfer the model unchanged to software or services.

The serious alternative is early differentiation or entirely order-driven work. CUST.4 compares these with a shared base and later differentiation using the actual delay, resource and variation constraints. The most recent model is not declared best for a different operating setting merely because it is recent.

CUST.Reference:10.3 - Field work and return to the common offering

• Palantir, students and early-talent role descriptions. The official distinction between work on a capability for many customers and work across capabilities for one customer illustrates different directions of engineering attention. It is an organizational description, not independent causal evidence.
• akshayk, “Who are Palantir FDEs?” (15 July 2026). The complete text, excluding linked images and video, is a practitioner’s account of continuing field/product learning. It qualifies a reading of field work as only a temporary probe. Its experience claims remain those of the author.
• OpenAI, Forward Deployed Engineer role description. The official role description connects implementation, adoption, reusable practices and feedback to product teams. It describes intended work rather than demonstrating an outcome.

CUST.5 retains the durable field/product connection while bounding each inquiry and protecting current service. A permanent function can perform many bounded inquiries; it need not remain one endless pilot. Negative evidence and a useful local-only outcome are valid receiving results.

CUST.Reference:10.4 - Solutions, provision and outcome promises

• Tuli, Kohli and Bharadwaj, “Rethinking Customer Solutions: From Product Bundles to Relational Processes” (2007). The primary abstract supports the relation between requirements, integration, deployment and subsequent support. It is not used as a fully read implementation manual.
• Storbacka, “A solution business model: Capabilities and management practices for integrated solutions” (2011). The author-posted abstract supports attention to commercialization and industrialization across solution work. It does not justify importing every capability in the unread full model.
• Sjödin, Jovanovic, Visnjic and Parida, “Value Creation and Value Capture Alignment in Business Model Innovation: A Process View on Outcome-Based Business Models” (2020). The abstract and indexed publisher passages support continuing alignment of value creation and capture, rather than relying on contract form alone. The full continuous article was not the basis of this treatment.
• Rolls-Royce, TotalCare. The official offer illustrates selected engine-life and maintenance responsibilities and payment related to engine flying hours while the customer retains operational responsibilities. It is neither the actual contract nor independent evidence of performance, and it supplies no universal clinical, agricultural or social-outcome recipe.

CUST.4 uses the complete SYSE.8 offering/provider Method for the consequential choice. The provider’s influence, other parties’ contributions, observation, acceptance, risk and resources must support the promise. Observability alone is insufficient; complete control of every cause is not a universal prerequisite. A narrower supported promise remains an available result.