The Concept-to-Market Chain
Last updated 12 Oct 2026
At a glance
Concept-to-Market (C2M) is the design-time process that turns a commercial idea into published catalog entities runtime systems can execute against. It runs through three functions (product portfolio, catalog governance and implementation) and ends at catalog publication, where Lead-to-Cash begins.
The picture
How it works
C2M starts with something that is not yet a product (a market signal, a competitor move, a regulatory obligation) and ends at catalog publication. Its unit of work is a product, not a customer; bespoke enterprise offers are the standing exception. Section 1.4 set out the chain; this module is what happens inside its first box. Module 3 covers how the entities are modelled; this module covers the process that decides what goes into the catalog and turns it into something a workflow engine can run.
A different clock, not just a slower one
Design-time and runtime differ in kind, not in tempo. A design-time process produces a definition every future order will execute against, correctable only by publishing a new version, never by fixing the instance in front of you.
A design-time mistake is not discovered at design-time. Review can only test a model against requirements that already exist. A design authority will catch a characteristic with the wrong cardinality, but not a model that is correct today and insufficient next year. The gap surfaces later as fulfilment fallout, a manual step nobody can remove, or an inventory record assurance cannot interpret. By then it is attached to live customers, and correcting it is a migration.
Three functions, three vocabularies
| Function | Decides | Typically owned by | Speaks in | Hands on |
|---|---|---|---|---|
| Product portfolio | What to build, and in what order | Product management, commercial, marketing | SKUs, segments, margin, launch dates | An approved product concept |
| Catalog governance | How it is modelled, and whether it may be published | Catalog and solution architecture, with a design authority | Specifications, characteristics, relationships, versions | A published, versioned specification set |
| Implementation | How it is made executable | IT delivery, integration, OSS engineering | Tasks, adapters, endpoints, test cases, release trains | Configured systems and running workflows |
They are functions rather than teams: in a small operator one group performs all three; in a large one each spans several departments and a systems integrator. They split cleanly by skill and badly by vocabulary, so translation loss between them is structural rather than a failure of communication.
Portfolio to catalog: an approved product concept
Catalog governance needs commercial intent decomposed far enough to model: target segment, price point and pricing mechanism, launch date, the business case, what is promised to the customer in terms specific enough to become a commitment, and which existing products it replaces, extends or must coexist with.
What often arrives is a slide with a name, a price, a date and a phrase such as "always-on connectivity with enterprise-grade resilience". Every word is a modelling question with no answer attached: resilient against which failure, measured how, committed at what level. The catalog function either asks, costing weeks the launch date never budgeted for, or assumes, which costs more and costs it silently, because nothing marks the guess as a guess.
Catalog to implementation: a published specification set
Implementation needs the offerings, the customer-facing services beneath them, the resource-facing specifications they decompose to, and the characteristics, eligibility rules and effective dates on each. They must be published (released to the systems that will execute against them) and versioned, so implementation builds against something that will not move underneath it.
What often arrives is a catalog complete at the product layer and thin below it: a placeholder decomposition, or a single CFS standing in for a family of variants. Implementation still delivers a working product, but what it delivers is the missing decomposition, as a gateway in a BPMN process where a catalog relationship should have been. It runs, but it is invisible to anyone reading the catalog and untestable as a model. Section 8.11 covers how those workflows are built.
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Approved product concept | Product portfolio | — | Catalog governance | The first handoff artefact; commercial intent, not yet a model |
| Product offering and product specification | Product catalog (catalog governance) | — | CPQ, order capture, billing | Published and versioned; where a product definition is corrected |
| CFS and RFS specifications | Service catalog (catalog governance) | — | SOM, orchestration, assurance | — |
| Resource specifications | Resource catalog | — | ROM, resource inventory | — |
| Workflows and system configuration | Implementation (orchestration engine and configured systems) | — | Catalog governance | Should express the catalog, not stand in for missing decomposition |
In practice
C2M is a standing capability, not a programme phase. Transformation programmes reliably fund the first pass (the catalog build, the initial modelling, the launch portfolio) and rarely fund the hundredth. The result is a well-modelled portfolio that degrades from the first change request onwards, because the governance that produced it closed with the programme.
The mechanism to watch through the rest of this module is simple: whatever the catalog does not express, implementation has to build, as workflow logic and integration code. What it builds is harder to see and harder to change than what the catalog would have held, and it is usually discovered only when the next product tries to reuse it.
The trade-off
What it solves
A defined path from commercial idea to a published, versioned definition that every future order executes against, with clear handoffs between three different kinds of competence.
What it does not solve
- It does not catch a model that is correct today and insufficient next year; that surfaces at runtime.
- It does not remove the vocabulary gap between the functions; it only puts artefacts at the boundaries.
What it adds
- A permanent governance cost that has to be funded after the programme that built the catalog has closed.
- Two handoff artefacts whose quality has to be checked, not assumed.
Architecture decision
How is C2M funded and staffed after the initial catalog build?
As a standing capability with its own budget
Choose when The portfolio changes continuously and the catalog is expected to stay authoritative beyond the launch set
Inside each product launch project
Choose when Launches are rare, the portfolio is small, and one team can hold the modelling standards in its head
Breaks if Governance closes with the programme, so later launches model their gaps into workflows and integration code instead of the catalog, and the portfolio degrades from the first change request.
Takeaways
Key Takeaways
- C2M is design-time: its unit of work is a product, and it ends at catalog publication, where Lead-to-Cash begins.
- A design-time mistake is corrected by publishing a new version; once attached to live customers, it is a migration.
- C2M is a standing capability, not a programme phase.
- The concept handoff needs commercial intent decomposed far enough to model; often what crosses it is a price, a date and a marketing phrase.
- Whatever the catalog does not express, implementation builds as workflow and integration code, where it is harder to see and change.
Check yourself
A product launched last year now generates a manual fulfilment step for every order. Why was this not caught in design review?Show answerHide
Review can only test a model against requirements that existed at the time. A model correct then and insufficient now surfaces at runtime, and because it is attached to live customers, fixing it means publishing a new version and migrating.
The catalog holds a single CFS for a product sold in five variants, yet all five work. Where is the variant logic?Show answerHide
In implementation: most likely gateways in BPMN workflows or integration code. It runs, but it is invisible to anyone reading the catalog and cannot be tested or reused as a model.
Put this to work