Harmeet Zerqemvi

The journal · Product promises and operating-mode context

Eight hours belonged to one mode, while our picture sold another

I approved a runtime headline that drifted away from the condition supporting it. The correction changed the product proposition rather than inventing a defect in the battery.

The measured figure and the imagined task had separated

The eight-hour runtime in our 2018 product account came from low-mode testing. The main use image showed work in high mode. Under the defined test conditions, that mode lasted 3.2 hours. Twelve of thirty customer jobs we reviewed needed six hours in high mode. I had approved the headline, and the presentation made it too easy for a reader to attach the longer duration to the task shown beside it.

The problem was not that the low-mode measurement had no value. It described a particular condition. The problem was the product promise formed when that figure travelled without its condition into the main account. A customer did not necessarily read the runtime as an isolated laboratory observation. It could become part of a plan for the work the lamp was being presented as helping them complete.

We withdrew the unqualified headline and spent ₹37 lakh on repositioning and field-material repair. This case does not describe a battery defect or recall. It also does not invent a customer loss to make the error more dramatic. The responsibility I retain is for the meaning of the product proposition, including the relationship between the specification and the image I allowed to explain it.

That relationship is easy to underestimate. Product teams often treat a figure as technical content and an image as illustrative content, with different owners reviewing each. The customer experiences them together. A correct figure can support an incorrect impression when the surrounding story encourages a different use condition. The leadership question is therefore not only whether each element is defensible in isolation, but whether their combination describes the offer honestly.

The thirty-job review made the consequence concrete. Twelve jobs required six high-mode hours, which the defined 3.2-hour result did not support. That did not mean every customer had the same requirement. It showed that the mismatch was relevant to a real kind of buying question within the reviewed population. Product leadership needed to preserve the difference rather than treat the customer as responsible for reconstructing it from scattered details.

The condition belongs where the customer forms the promise

I now want the operating condition beside the promise at the point where the customer is likely to rely on it. This is not an argument for placing every technical qualification in a headline. It is a question about which condition changes the meaning of the main offer. If a duration depends on a mode different from the one implied by the presentation, that distinction is central to the product choice.

The revised account had to explain mode and intended use without turning one test result into a universal assurance. Runtime can be assessed under defined conditions, and the product team should not silently extend that result to every environment, battery state or task. Engineering retains the testing and release authority. My responsibility is to make sure the commercial proposition does not ask the evidence to support more than it establishes.

There is a temptation to solve this kind of problem with a qualification that appears after the attractive message has already done its work. The reader first forms a clear promise, then encounters a detail that requires them to reinterpret it. Some details can properly follow later. A condition that changes which task the product can support should not depend entirely on that later reinterpretation. The main account needs to remain coherent on its own terms.

I also resist the opposite response of removing useful specifications because they require context. Customers still need to compare products and understand the basis of a claim. The low-mode duration remained meaningful when accurately described. A careful proposition does not hide the number; it helps the reader connect the number to the appropriate choice. Clarity is more useful than either an unqualified headline or an account so evasive that no comparison is possible.

This requires collaboration across product, engineering and commercial work. Engineering explains what was tested and accepted. Commercial colleagues explain the questions customers bring to the offer. Product leadership should make those accounts meet before the range is described as though the difficult distinctions have already been settled. None of the functions can assume the customer will repair a gap that the enterprise has left between them.

A correction should retain the cost and the original approval

The ₹37 lakh expenditure was a correction cost. I do not turn it into an investment return or claim that the revised account produced a measured improvement in sales. Those would require evidence beyond the reviewed case. The immediate outcome was a narrower, more accurate proposition and repaired field material. That outcome is worth explaining without giving the story an unsupported commercial victory.

My original approval is equally important. If the account begins only with the correction, I appear as the leader who noticed somebody else's ambiguity. In fact, I had accepted the presentation that allowed the ambiguity to form. Retaining that fact makes the case useful to someone assessing my judgement. It shows both the error and the way I changed my review, rather than removing the difficult part from the public narrative.

The incident did not lead me to treat every misunderstanding as proof that a product is defective. Technical performance and the meaning of the offer are related but distinct questions. A product can perform within its defined conditions while the proposition encourages a different expectation. The response should identify which problem the evidence establishes and involve the appropriate owners, rather than choose the most dramatic label available.

It also changed how I listen to a customer's intended task. A question about six hours of high-mode work cannot be answered by repeating the product's longest measured duration. The task needs to remain in the conversation. A different product, mode or supported arrangement may be relevant, but that choice requires its own assessment. The commercial desire for a simple answer does not make an unrelated specification responsive to the question.

What I retain is a practical standard for product communication: the customer should recognise the task and conditions we used to describe the offer. A measured figure, a picture and a promise should not be allowed to drift into three different accounts. Keeping them connected helps the enterprise make a clearer commitment, gives the buyer a more intelligible choice and leaves technical authority where it belongs. That is a product responsibility I now examine before approving the most attractive number on the page.