Document {{ORG_PREFIX}}-021
Product & Market Offer Definitions¶
1. Purpose¶
This document is {{ORG_NAME}}'s generic, reusable definition of what it offers and to whom — the controlled home of the offer definitions this system maintains. For each product × market offer (here "product" includes services) it records:
- the market's needs — expressed as the jobs that market is trying to get done and the outcomes it is trying to achieve (a Jobs-to-be-Done / outcome lens; see §3.1);
- how {{ORG_NAME}}'s offer satisfies those jobs and outcomes; and
- the claims {{ORG_NAME}} makes for the offer — each one {{ORG_NAME}} can currently meet and demonstrate.
This is the generic layer. It is the source a specific customer proposal is
built from — a proposal takes an offer defined here and tailors it to one
customer's requirements. That case-by-case tailoring and its pre-commitment
review are not in this document: they are run per job under
customer-requirements-contract-review-procedure, with the evidence in the
job file. Keeping the two apart is deliberate — this document
changes only when an offer changes, not when a customer does.
This document is also not where objectives live. When {{ORG_NAME}} chooses
to drive improvement in a particular offer, it attaches objectives to it through
the sleeve method in ims-objectives-improvement-plan. Every offer has a
definition here; only selected offers additionally carry a sleeve.
2. Scope¶
In scope: the generic definition of every product × market offer within the IMS scope — its market, the jobs and outcomes that market values, how the offer satisfies them, and the claims made for it; and the maintenance of those definitions.
Out of scope: per-customer proposals, quotes, contracts and their
pre-commitment review (see customer-requirements-contract-review-procedure);
offer-level improvement objectives (the sleeve method in
ims-objectives-improvement-plan); and the decision of which markets to serve,
which is business strategy determined outside the IMS and recorded here only as
the set of offers the organisation has chosen to define.
3. Content¶
3.1 What an offer definition contains¶
Each offer is defined against the same four elements, so any two offers are comparable and any proposal can "drop in" from one:
| Element | What it captures |
|---|---|
| Offer and market | The service, and the market segment it is offered to, in {{ORG_NAME}}'s own commercial language (e.g. "Scheduled equipment inspections — facility-manager clients"). |
| Jobs & outcome statements | What this market is really trying to get done, and the outcomes by which it judges success — written as outcomes the buyer cares about, not as features {{ORG_NAME}} provides. These are the durable "what the buyer values" statements; they change rarely. |
| How the offer satisfies them | For each job/outcome, how {{ORG_NAME}}'s offer meets it — the delivery approach, deliverables, and the standard held. Where a job is only partly met, that is stated honestly rather than overclaimed. |
| Claims | Every claim made for the offer anywhere it is communicated (turnaround, accreditation, capability, capacity). Each must be one {{ORG_NAME}} can currently meet and demonstrate — an unsubstantiatable claim is removed, never softened (per customer-requirements-contract-review-procedure §3.2). |
The Product & Market Offers register (Airtable) is the live index of
these definitions — one row per offer, with Definition Ref linking to the
offer's section here. The register is the index; this document is the
authoritative definition.
3.2 How offer definitions are created and maintained¶
The method behind these definitions is the requirements-determination step
of customer-requirements-contract-review-procedure (§3.2). That step fills
in the four §3.1 elements for each offer, holds the Claims element to its own
gate ({{ROLE_TOP_MANAGEMENT}} confirms every claim can currently be met and
demonstrated), and folds two further requirement feeds into the definition:
the legal obligations the compliance-obligations process identifies for the
service, and the standards {{ORG_NAME}} imposes on itself beyond anything a
customer or regulator asks. This document is where
the result of that method is recorded and maintained.
An offer is added, changed, or retired through the normal document lifecycle (a
pull request, per document-record-control-procedure), and the Product & Market
Offers register row is updated in the same change. A new offer requirement that
surfaces during a specific contract review (that procedure's §3.3 step 6) is fed
back here so the generic definition stays current.
3.3 Relationship to sleeves and objectives¶
An offer defined here is a candidate for a sleeve: at a management-review
decision, {{ROLE_TOP_MANAGEMENT}} may attach 3–5 improvement objectives to one
offer, run and tracked per ims-objectives-improvement-plan §3.4. The sleeve
does not restate what the buyer values — it references the jobs and
outcome statements defined here and sets measurable objectives to improve
against them. When a sleeve is retired, the offer's definition here is
unaffected; only its objectives lapse.
3.4 Offer definitions¶
[ORG-DECISION: replace the worked example below with {{ORG_NAME}}'s real offers, one subsection per offer, determined per §3.2. Everything in the example — the offer, the market, the jobs, the claims, and all figures — is fictitious and illustrative only.
3.4.1 Scheduled equipment inspections — facility-manager clients¶
(Product & Market Offers row: "Scheduled equipment inspections — facility managers".)
Jobs & outcome statements — what this market values. Facility managers are trying to keep their sites compliant and running without having to chase or second-guess their inspection provider. They judge success by: inspections happening inside the agreed window without being chased; reports arriving in time to action before the next maintenance cycle; and findings written so a non-specialist can approve the remedial work. Technical depth beyond that threshold is not what this buyer is paying for.
How the offer satisfies them. {{ORG_NAME}} schedules and performs the inspection within the client-agreed window; issues a plain-language report within a defined turnaround; and writes findings and recommended actions so a facilities team can act on them without specialist interpretation.
Claims. [ORG-DECISION: list only claims {{ORG_NAME}} can currently
substantiate — e.g. typical report turnaround, any accreditation held, coverage
area. Each claim is verified per customer-requirements-contract-review-procedure
§3.2 step 4 before it is published.]]
4. Ownership and Review¶
| Aspect | Assignment |
|---|---|
| Owner | {{ROLE_QUALITY_MANAGER}} — drafts and maintains the offer definitions |
| Reviewer | {{ROLE_DOCUMENT_CONTROLLER}} — reviews each change for control and consistency |
| Approver | {{ROLE_TOP_MANAGEMENT}} — approves (the merge is the approval), and is accountable for the claims made for {{ORG_NAME}}'s offers |
| Status / Version | Draft, 0.1 |
| Next review date | 2026-08-15 |
| Review trigger | Per the frontmatter review_trigger. |
The Draft → Under Review → Approved lifecycle runs through GitHub pull requests as defined in the Document & Record Control Procedure.
5. Revision History¶
| Version | Date | Author | Description of Changes | Reviewed By | Review Date | Approved By | Approval Date |
|---|---|---|---|---|---|---|---|
| 0.1 | 2026-07-16 | {{ROLE_QUALITY_MANAGER}} | Initial draft | — | — | — | — |
6. Document Control
| Document | {{ORG_PREFIX}}-021 |
|---|---|
| Type | IMS Core Document |
| Version | 0.1 |
| Status | Draft |
| Owner | {{ROLE_QUALITY_MANAGER}} |
| Reviewer | {{ROLE_DOCUMENT_CONTROLLER}} |
| Approver | {{ROLE_TOP_MANAGEMENT}} |
| Next Review | 2026-08-15 |
| Classification | Internal |
Held in the document frontmatter, mirrored to the Document Register.