The Concept-to-Market Chain

Concept-to-Market starts with something that is not yet a product — a market signal, a competitor move, a regulatory obligation — and ends at catalog publication. Lead-to-Cash begins at the first order taken against a published offer. Everything before that line is design-time, and design-time runs on a different clock.

Section 1.4 set out the chain; this module is what happens inside its first box. Section 1.3 established the catalog as the control point downstream and Module 3 covers how the entities are modelled. Neither describes the process that decides what goes into the catalog, or turns what comes out of 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. Two consequences follow, both routinely absent from programme plans.

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 modelled with the wrong cardinality, but not a model that is correct today and insufficient next year. The gap surfaces later as fallout in fulfilment, as a manual step nobody can remove, or as an inventory record assurance cannot interpret — by which time it is attached to live customers, and correcting it is a migration.

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. What follows is a well-modelled portfolio that degrades from the first change request onwards, because the governance that produced it closed with the programme.

Three functions, three vocabularies

C2M runs through three functions — Product Portfolio, Catalog Governance and Implementation. 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.

The two handoff artefacts

Portfolio to catalog: an approved product concept

What the catalog governance function needs is a commercial intent decomposed far enough to model: target segment, price point and pricing mechanism, launch date, the business case it must hit, 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 carrying the name, the price, the date and a description in marketing language — "always-on connectivity with enterprise-grade resilience". Every word of that 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

What the implementation function needs is a published, versioned specification set: the offerings, the customer-facing services beneath them, the resource-facing specifications those decompose to, and the characteristics, eligibility rules and effective dates attached to each. Module 3 covers what those entities are. What matters here is that they are 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: the offering exists, priced and eligible, while the decomposition beneath is a placeholder or a single customer-facing service standing in for a family of variants. Implementation still delivers a working product, but what it delivers is the missing decomposition — 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 5.7 covers how those workflows are built.

That is the mechanism worth watching through the rest of this module: whatever the catalog does not express, implementation has to build, and what it builds is harder to see and harder to change than what the catalog would have held.