{"id":130,"date":"2026-08-14T18:09:19","date_gmt":"2026-08-14T10:09:19","guid":{"rendered":"https:\/\/oribridge.org\/blog\/?p=130"},"modified":"2026-08-16T13:26:36","modified_gmt":"2026-08-16T05:26:36","slug":"product-portability-audit","status":"publish","type":"post","link":"https:\/\/oribridge.org\/blog\/product-portability-audit\/","title":{"rendered":"Product Portability Audit: Keep the First Offer Honest"},"content":{"rendered":"

The test design is already on the table. It names a buyer hypothesis, one learner action, a route to examine, and a stop condition. The team is now drafting the invitation. Someone adds: \u201cIncludes the live office hour and the downloadable field guide.\u201d<\/p>\n

That is the point at which a course becomes a promise.<\/p>\n

After a bounded test has been designed, make a promise register: list every asset the first offer says a learner will receive, give it a named route, record any dated limitation or unresolved condition, and choose one action\u2014test, replace, defer, or stop promising it.<\/strong> The earlier question of how to design the evidence belongs to the H2-08 test-design comparison (companion decision worksheet). This page begins only after a test design exists: do not let the invitation promise assets the documented route has not been shown to carry.<\/p>\n

Why this is a creator workflow question<\/h2>\n

Course owners already recognise launch preparation as a collection of commitments, not just files. Teachable publishes a course-launch checklist for creators; it is a first-party signal that creators actively prepare a course offer before releasing it.1<\/a><\/sup> Teachable\u2019s enrollment documentation and Kajabi\u2019s lesson\/quiz import documentation also illustrate that a course can be administered through specific people and specific objects.2<\/a><\/sup>3<\/a><\/sup><\/p>\n

None of those sources establishes a China market, a China route, or the need for this exact worksheet. They provide the overseas reader\u2019s familiar starting point: before someone sees an offer, its contents and learner-facing components have to be stated.<\/p>\n

The China-specific addition is that a named route may carry some of those stated assets differently. The promise register makes that difference visible instead of treating it as a later production surprise.<\/p>\n

\n

An asset inventory asks what exists. A promise register asks what you are entitled to say a learner will receive through this route, on this date.<\/strong><\/p>\n<\/blockquote>\n

The route question that changes a line in the invitation<\/h2>\n

Before an invitation names a live session, e-book, or other asset, verify the exact route and record a dated observation for the representative lesson. A help-centre description that cannot be re-opened today is not evidence that the asset is filtered, accepted, or deliverable. Until the route is verified, write the promise as pending route verification<\/strong>; do not silently include the asset, delete it, or infer a China-wide rule.<\/p>\n

That evidence still does not establish account eligibility, listing, payment, access, distribution, buyer demand, or commercial performance for any course. The decision is about keeping the invitation honest while the route remains untested.<\/p>\n

Choose an action, then write the invitation to match it<\/h2>\n

TEST<\/h3>\n

Use TEST<\/strong> when the asset is part of the first promise and the approved test design can observe the particular route question. Record the asset, route, test owner, date, conditions, observation, and what result changes the promise. This is not a license to test every course component at once.<\/p>\n

REPLACE<\/h3>\n

Use REPLACE<\/strong> only when the authorised product owner agrees the substituted activity still supports the stated learner action. A different format can change the teaching method; it cannot be silently improvised because the original item is inconvenient.<\/p>\n

DEFER<\/h3>\n

Use DEFER<\/strong> when the asset may be valuable later but is not necessary to make the first test\u2019s invitation truthful. The invitation should name what is included now, rather than imply that a later component is already available.<\/p>\n

STOP PROMISING<\/h3>\n

Use STOP PROMISING<\/strong> when the excluded asset is integral to the original offer and there is no approved, evidenced alternative. This is not a failure of the course. It is a refusal to sell a different product under the same words.<\/p>\n

Keep this tool in its lane<\/h2>\n

Do not use this register to select a test design, identify all content dependencies, or conduct access\/payment\/delivery acceptance. Those are adjacent but different decisions:<\/p>\n