Harmeet Zerqemvi

The journal · Product state and ordinary workplace handover

The lamp remembered its setting, but the next user did not inherit that knowledge

A retained mode was a feature of the prototype, not proof that a colleague taking it over would understand its state. Handover became part of the product question.

The feature worked inside a longer sequence

In a 2023 prototype study, fourteen users in thirty-six handover tasks misread the brightness setting retained after restart. The lamp remembered a mode, but the person taking it over did not necessarily understand the mode being inherited. We funded a ₹68 lakh physical-mode-indicator programme, with engineering retaining control design, safety assessment and release authority. The case contains no accident claim or conclusion that every later misunderstanding was eliminated.

The finding changed the question we asked about the feature. It was possible to describe retained state as a convenience: the product could return to a previous setting rather than require the same selection again. That description focused on continuity for the person who already knew the state. A portable workplace product could also pass to someone else, whose understanding did not travel with the stored setting.

The handover sequence therefore mattered as much as the feature's isolated behaviour. One person used the lamp, another received it and a restart brought the retained mode into a new task. The product could perform the memory function while still leaving the next user uncertain about the current condition. Treating the technical existence of retained state as proof of an understood experience would have skipped that ordinary transition.

I did not want the finding reduced to a judgement that users had failed to pay attention. The study concerned how people interpreted a prototype in defined tasks. Product leadership should examine what the design makes understandable before assigning the burden entirely to a user. At the same time, the observations did not prove a universal error rate. Fourteen of thirty-six described the reviewed tasks and needed to remain within that scope.

This balance is important because an observation can be dismissed as user behaviour or enlarged into a general claim too quickly. Neither response helps the product team learn. The useful account preserves what happened, the context in which it happened and the decision it suggests investigating. Here, the inherited mode needed to become more visible in the product work, without pretending that the study had already selected and validated a complete solution.

The next person belongs in the product account

A product demonstration often assumes a continuous user who knows why each action has been taken. The presenter understands the current mode, the previous adjustment and the intended next task. A workplace handover can remove that context. The next person may encounter only the object and its current cues. A product account should therefore consider what knowledge the design expects and whether that knowledge is actually available at the moment of use.

For our lamp, the question was not simply whether a label could be added somewhere. It concerned how the current mode would be recognised during the relevant sequence. Engineering needed to assess the control and indicator design. Product leadership needed to make the handover need explicit and keep it connected to the proposition, rather than treat it as a minor explanatory detail after the main feature had already been declared successful.

That does not mean every product must forget its state at restart. Retained settings can serve a legitimate purpose. The decision should examine the intended work and the different people who may encounter the product. A universal rule about remembering or resetting would be easier to state than the actual design judgement. It would also bypass the task-specific evidence that the study had made available.

I wanted commercial colleagues to understand the distinction as well. A feature list can say that the lamp retains a setting without explaining why that helps a particular user or what the next person needs to recognise. The offer becomes more useful when it describes the supported experience rather than only the stored capability. That account must still remain within technical assessment; product language cannot make an untested indicator reliable by describing it confidently.

The same thinking influenced how I reviewed adjacent features. I began asking what happens before the person reaches the moment shown in the demonstration and what happens after they leave it. Where does the product move? Who uses it next? Which information is assumed to remain known? These questions do not require an elaborate story for every feature. They help identify the ordinary transitions in which a simple feature description may leave out a material part of the experience.

A funded indicator programme still needed assessment

The ₹68 lakh programme was a commitment to address the handover question. It did not establish that the revised approach had already removed every misinterpretation. I keep that distinction because a product narrative can turn the approval of design work into an achieved outcome without showing the intervening evidence. Funding a response and validating its performance are different stages, with different responsibilities.

Nikhil and the engineering team retained control design, safety assessment and release decisions. My role was to prioritise the customer problem, connect it with the range proposition and support the resources needed to examine it. I did not use the CPO title as authority to certify a particular control behaviour. The boundary made the product account more credible because it showed how judgement and specialist acceptance worked together.

The case also remains within ordinary non-hazardous industrial workspaces. It makes no emergency-lighting, medical or explosion-proof claim and offers no instruction for modifying a lamp. Those limits are not an attempt to make the story less useful. They keep the example attached to the product and setting it actually describes, rather than allow a general lesson about handover to imply suitability for unexamined uses.

I would judge the later work by whether it made the intended state more understandable in the relevant tasks, alongside the qualified assessments the product required. I would not be satisfied merely that the indicator existed in the revised design. The feature and the user's interpretation would still need to meet. That is the connection the original study showed us not to assume, and the next review should preserve the same discipline.

The lesson I would share with another product leader is to include the next person in the promise. A remembered setting is information stored by the device; understood state is information available to its user. They may coincide, but one does not automatically establish the other. Examining that gap turns an apparently small handover observation into a meaningful product question, while keeping the proposed response, its cost and the evidence still required in clear view.