A draft standard from the Business Gardening framework for representing and exchanging a product as a portable snapshot with a fixed Product → Goal → Job → Work Item hierarchy, where every Job must carry a Job To Be Done and supporting artefacts — documents, designs, APIs, repositories — are linked as URL-addressed Materials rather than added as levels of the tree.
Product Tree Standard
The Product Tree Standard is a draft specification from Gareth Faull’s Business Gardening framework. It defines a portable way to exchange a product’s structure between systems that share no database, workflow or user interface. A conforming document is a snapshot of a living tree at one point in time, or an initial data load into a Garden system. It is not a claim that the product is static. How the tree changes afterwards is left to the framework’s Ledger / Kernel Standard.
- Fixed grammar: exactly one root Product, then Goals, Jobs and Work Items. No extra structural levels are allowed, and anything else must go in metadata, Materials or relationships.
- Meaning at minimum conformance: an identifier and a title are not enough. A Product needs a description and a purpose, a Goal needs an intended outcome, a Job needs a Job To Be Done (actor, situation, motivation, expected outcome), and a Work Item needs a description of the change.
- Materials by URL: any node can link to artefacts, each with a URL and a title plus an optional relationship such as
evidenceordesign. An API is a Material, not a node. - Organisation Goals sit outside the tree: a Product references them by stable identifier, and their internal structure is deliberately not prescribed.
- Twelve conformance rules, written in MUST/SHOULD language.
In API operations, the standard’s own worked example is an API Platform. It has a self-service onboarding Goal, a Job of “understand why I do or do not have access”, and a Work Item that explains access state. That makes it one of the few product-level schemas that treats an API platform as a first-class product with jobs, rather than as infrastructure under one. Because APIs attach as URL-addressed Materials, a Product Tree can point at a catalogued API, operation or capability, for example a Turbo EA business-capability ID or an APIs.json index. That joins what an organisation is trying to do with the interfaces that do it.
Maturity, as observed on 2026-09-24: v0.1 draft by a single author, with no stated license, no JSON Schema and no reference implementation. The standard names canonical serialisation format, identifier syntax, a relationship-type vocabulary and partial snapshots as open questions for later drafts. Its examples are written in YAML.
