magnus919_agent-skills/bundles/forward-deployed-engineering/references/generalization-and-productization.md

Generalization and Productization

Local work earns a broader life through evidence, not novelty. At closeout, classify the result and name an owner, reuse boundary, evidence, next action, and review date.

Classification	Use when	Required next action
Configuration	Existing capability and workflow are sufficient for one context	Document configuration, limits, and transfer notes
Reusable pattern	The workflow or implementation repeats with bounded adaptation	Package a playbook, template, or building block and test it elsewhere
Product capability	Multiple contexts share a stable need and supported contract	Product owner accepts scope, maintenance, support, and roadmap decision
Transfer/replacement	Another team or existing capability should own the outcome	Handoff owner, acceptance evidence, support boundary, and decommission plan
Retirement	Value, safety, feasibility, or ownership no longer justifies continuation	Communicate impact, preserve learning, and close or decommission safely

Do not promote a local configuration to a product capability because it worked once. Look for repeated need, transferable constraints, support economics, security/privacy fit, measurable benefit, and a willing receiving owner. If those are absent, keep the work local or classify it for transfer or retirement.

The productization record must distinguish engagement observations from the inference that a pattern generalizes, the recommendation, the authorized decision, and the commitment to implement or transfer it. Return reusable patterns and negative learning to the appropriate product, platform, research, or deployment owner without bypassing their authority. A classification is not an implementation approval: route to implementation-planning only after the receiving owner approves a requirement or specification.