Forty-six per cent was the result we chose not to ship

The most attractive number in an engineering experiment is not always the number that belongs in the product summary. In one Pelvori project, a compression candidate reduced transmitted bytes by forty-six per cent on the agreed sample. It also increased processing time by seventy-one per cent. A lighter candidate produced a smaller byte reduction with a much smaller processing increase, and the client selected that compromise. The larger improvement remained useful evidence, but it was not the result we chose to ship. Keeping that distinction clear was part of the engineering decision.

The client was developing an industrial diagnostic accessory and wanted to reduce the volume it transmitted. That request was reasonable, but transmission was not the only work the device had to perform. The processor also had other obligations, and the product owner needed to understand the effect of adding compression. We therefore retained both byte volume and processing time in the comparison. A proposal that showed only the first measure would have made the stronger compression candidate appear obviously preferable while concealing the resource cost that ultimately changed the choice.

## Keep the other resource in the experiment

An optimisation proposal should identify the constraint it is intended to relieve and the resources it may consume in return. That sounds straightforward, but project summaries often narrow as they travel. A team asked to reduce data volume may report success in those terms alone, leaving another team to discover the processing consequence later. I want the experiment to carry a small but relevant account of the trade-off from the start. The right measures depend on the device and use; adding every possible metric can obscure the decision just as effectively as reporting only one.

The comparison needs a consistent basis. We used the agreed sample and recorded configuration for the uncompressed reference and both candidates. That did not make the sample representative of every future payload. It made the observed differences interpretable within the exercise. If one candidate had been tested on easier data or a different operating condition, the percentages could have looked comparable while answering different questions. Engineers should preserve enough detail for another competent reviewer to understand the comparison and identify where a further test is needed before a wider product commitment is made.

Processing time is also not automatically energy consumption. A shorter transmission or a longer computation can have effects that depend on hardware and operating conditions. Our experiment did not establish battery life, so I did not allow the byte reduction to become a battery claim. Likewise, fewer bytes did not automatically mean lower network charges; the commercial arrangement was a separate matter. These boundaries are not reasons to avoid optimisation. They help the business distinguish a measured engineering result from a benefit that still requires additional evidence or a different kind of calculation.

## Compare candidates against the product's actual constraint

The lighter option reduced transmitted bytes by twenty-seven per cent and increased processing time by twelve per cent on the same recorded workload. The client product owner preferred it after reviewing the available processing margin and the device's other work. That was a contextual choice. A different processor, payload or operating schedule could justify another decision. I did not want the team to describe the selected algorithm as universally better merely because it was the better compromise for this product. The reasoning should remain available so that a future change can be assessed against the original constraint.

The comparison and implementation required ₹24 lakh in engineering effort. That cost belonged in the project account alongside the selected result. It should not be hidden because the work produced an improvement, nor should the rejected candidate be treated as wasted effort simply because it was not adopted. The experiment helped establish the shape of the trade-off. A business can learn from an option it decides against, provided the work was bounded and the decision uses the evidence. The problem arises when exploration has no clear question or when a rejected result is later claimed as a delivered benefit.

There were further conditions to examine, including less typical payloads and concurrent device activity. We assigned those to the manufacturer's acceptance programme and our agreed follow-up work. A sensible choice based on the available evidence does not remove the need for that validation. It should make the remaining questions more precise. I prefer to state what could change the decision, such as a different workload or a tighter processing margin, rather than describe the selected setting as settled for every future variant of the device. That gives the product owner a practical basis for reassessment.

## Publish the benefit of the chosen configuration

Commercial colleagues initially wanted to keep the forty-six per cent reduction in the benefit summary because it was the strongest result produced during the project. I understood the appeal, but the summary needed to describe the configuration the client had chosen. We retained the larger figure in the engineering account as a rejected alternative, with its processing cost. The delivered configuration was associated with the twenty-seven per cent reduction observed in the stated experiment. Otherwise the customer could reasonably expect a benefit that the product was deliberately not configured to pursue.

This distinction matters beyond sales language. Internal investment reviews also compare outcomes with proposals, and a programme can appear successful by reporting the best isolated result from several incompatible experiments. The organisation then loses the ability to learn from the actual choice. A useful closeout should explain the alternatives, the selected configuration, its cost and the conditions under which the measured benefit was observed. It should also identify any benefits that remain estimates or require later confirmation. The aim is an account that finance, product and engineering colleagues can discuss without each relying on a different implied version of the solution.

A board overseeing a significant technology investment should ask where an improvement has moved cost. Faster processing may require more expensive hardware; fewer transmissions may require more local work; a simplified architecture may transfer effort to a client integration. The answer is not always a reason to reject the proposal. It is a reason to assess the whole relevant trade-off and understand who bears it. Directors should also ask whether the headline benefit describes the chosen option or the strongest result from an experiment that management ultimately decided was unsuitable for the product.

I would make the next optimisation review start with the decision rather than the percentage. What constraint matters to the product, which alternatives are credible and what evidence would cause the owner to choose differently? The team can then design a comparison that informs those questions. In our case, the smaller byte reduction was the more useful outcome because it respected the processing constraint the client needed to preserve. The larger number was not a failure to celebrate or a success to borrow. It was evidence that helped us understand the price of pushing one measure further than the product could sensibly support.