The package was only part of the experience
A media package can be described through its contents, price and conditions. A household’s experience contains something else as well: the choices people have made while using it. Favourite lists, familiar arrangements and personal ways of finding material can become part of what makes the service understandable. These choices may look small beside the commercial package. They can still carry effort and meaning for the person who made them. When the package changes, the product leader needs to ask what happens to that accumulated experience rather than assume that moving the formal entitlement is the whole task.
I failed to give that question enough weight in a fictional 2004 migration decision at Tsumihana Broadcasting. I approved reset logic that treated the new package as a fresh starting point. In a test of 120 profiles, thirty-eight with customised favourites lost those preferences; eighty-two profiles using the defaults did not experience that specific loss. The count was not evidence that most customers preferred a reset. It showed how the chosen test exposed different consequences for two kinds of existing use. The unaffected default profiles could not stand in for the people who had invested effort in arranging something of their own.
The original approach had an attraction. A reset made the internal transition easier to describe and avoided carrying some differences into the new package arrangement. I supported that simplicity. Mirei Hatamori challenged the assumption because it assigned the cost of tidying the transition to the users whose choices disappeared. Her objection was not that a product must preserve every historical setting forever. It was that we had treated an important part of the existing experience as disposable without first examining what that meant for the people who used it. I had allowed the internal starting point to become the customer’s starting point as well.
That difference matters because the service already knew something about the user’s choices. Asking someone to reconstruct them after a package change can appear to the team as a small additional task. To the person, it may feel like work they had already completed and had no reason to repeat. The product account should not assume that the effort is negligible merely because the setting is technically secondary to the package. The right question is what the transition can preserve, what it cannot, and how those limits should be handled before the change reaches the household.
My approval made the assumption harder to question
I regard the approval itself as part of the case. It would be easy to describe the reset as a problem found during testing and the revised approach as the team’s eventual success. That version would leave out why the assumption had become established. I was the product manager who accepted the simplified transition. Once that happened, colleagues could reasonably interpret preservation work as an addition to the agreed scope rather than an unresolved question inside it. The challenge had to reach someone whose decision had helped define the boundary. My response therefore needed to change the brief, not merely thank the person who noticed the consequence.
We allocated JPY 28 million to retaining preferences through the migration work. The decision gave up part of the original transition’s simplicity and accepted more work around mapping and exceptions. I did not regard that as evidence that the team should always choose the more elaborate solution. I regarded it as the cost of correcting an assumption we had not examined sufficiently. A useful account names the reason for accepting that cost. Otherwise the story can become a general celebration of complexity, when the actual judgement concerned a particular kind of user effort that the simpler approach would have discarded.
The later check covered fifty-four profiles. Forty-nine mapped as intended and five required manual review. Those figures matter because they prevent the correction from being narrated as complete preservation for everyone. The revised approach had improved the treatment of preferences in the tested set, but the unresolved profiles still needed a responsible path. I would not describe them as harmless exceptions simply because there were fewer of them. A small group can reveal an important limitation in the mapping logic, and the people responsible for the release need to understand that limitation before making a broader claim.
There is also a difference between preserving a setting and understanding why it existed. The team may be able to carry a preference into the new arrangement without knowing the household’s reasons for choosing it. That is not always a problem; a service does not need to interrogate every ordinary choice. It does mean that product leaders should be cautious about replacing established preferences with defaults on the assumption that the new arrangement is objectively better. A default can be sensible for someone who has not made a choice and inappropriate for someone whose earlier choice expresses a different need.
Preservation needs an account of the exceptions
I now want migration proposals to describe three things separately: the formal package transition, the treatment of user preferences and the route for cases that cannot be mapped as intended. This is not a demand for an unlimited historical promise. Some settings may no longer have an equivalent, and some changes may require the person to decide again. The product should make that situation intelligible. It should not allow the absence of a perfect mapping to justify a universal reset before the available alternatives have been considered. The exception account is where the practical boundary of preservation becomes visible.
The colleague who questions that boundary needs enough context to be useful. A diagram of the new package may not show what existing users stand to lose. A test involving only default profiles may make the transition appear complete. Product reviews should therefore contain examples of different existing use, including the choices the organisation does not itself prefer. This is one reason I keep the thirty-eight customised profiles in the story. They make the cost of the approved assumption concrete without requiring a claim about every household or turning a test count into an estimate of the whole subscriber base.
The broader principle is modest: a change in what the organisation offers should not casually discard the work a customer has done to make the service usable. Where something must change, the reason and remaining choices deserve explanation. Where preservation is possible, its cost should be judged against the work a reset would impose on users. I learned that principle through an approval I had to reverse, not through an unbroken record of anticipating every consequence. The five profiles still awaiting review remain in the account because responsible correction includes what the correction has not yet resolved.