I want a narrow launch to expose only the journeys that work. Defined tiers, disabled features and verified purchase flows are different states, and the release needs to say which one is real.
I want a narrow launch to describe what a product can actually do today. A schema can contain several membership levels while the first release exposes only free membership, and those are separate facts. The stored names do not prove that billing, upgrades or every entitlement are ready. When I look at a product with paid levels defined but disabled, I want to know which parts are working, which parts have only been specified, and which parts still need building. Calling all of it complete because the database has the right fields would erase the distinction that matters most to someone deciding whether to turn it on.
The first boundary I draw is between an internal model and a public promise. A tier name in an admin screen can describe a future offer without implying that anyone can buy it. A public pricing card with an active purchase button makes a different promise: that the purchase leads to the access described beside it. I do not want an interface to borrow credibility from code that happens to exist elsewhere in the repository. The useful question is whether this particular journey works from the first click to the resulting account state, with the rules and price that the page actually shows.
I would keep working capabilities while narrowing what a launch exposes. Deleting a functioning entitlement check merely because the related offer is disabled throws away useful work. But keeping that check does not authorise saying that the entire offer is ready. Payment collection, account changes, cancellation and the messages a member receives are different parts of the journey, and each needs its own evidence. The distinction I want in the backlog is precise: implemented and verified, implemented but unverified, or still to build. A single flag called enabled cannot carry that whole account of readiness, however convenient it would be if it could.
That also changes what I expect from a disabled feature. If the plan is to enable it later, I want the existing behaviour tested now and the remaining work named. I do not assume that passing tests today removes the need to check the launch conditions again later. Dependencies change, configuration changes, and the surrounding product can move while the feature stays untouched. My reason for preserving the code is to avoid rebuilding something useful, not to claim that an old verdict can stand in for a fresh decision about a real release. Readiness belongs to a particular version and environment, not permanently to a flag.
The public side can stay much simpler than that internal record. I would show the membership people can use and explain what it includes, without presenting disabled paid offers as available purchases. If there is an interest form, it needs to save an actual expression of interest and say what happens next. If there is no working next step, I would not draw a button that suggests otherwise. A small release can still be complete for the journey it promises. What makes it misleading is allowing the visible promise to stretch past the behaviour that a person can actually reach and use.
The wording I want at handover is equally specific: this journey works, these capabilities are disabled, and these remaining steps must clear before another offer opens. That gives the next person something they can verify without interpreting the confidence of whoever wrote the report. It also lets me distinguish a deliberate product decision from unfinished implementation without pretending that either one is the other. Launch scope is a choice about what to make available; readiness is a claim about what has been built and checked. I can choose a narrow scope without inflating that claim, and I can preserve useful work without promising that switching it on will be the only work left.