Five decisions beneath the customer interface

In February 2024, a planned promotion combined a fixed reduction with a percentage offer. Commercial colleagues regarded the proposal as familiar. The engineering team nevertheless found two plausible interpretations of the same synthetic €120 eligible basket. Applying €20 first and then ten per cent produced €90. Applying ten per cent first and then €20 produced €88. The calculation was simple; the unresolved question was which offer the retailer intended to make.

I approved a twelve-week programme with €680,000 of authority to clarify the shared capability and its use in the campaign. We prepared 126 authored basket examples, covering relevant combinations and boundaries. Eighteen produced disagreements between the interpretations supplied by different functions. Those examples were test material, not a count of customer complaints or incorrect live charges. I asked Dorian Velcenne, our commercial director, to resolve the policy with his team before we treated either implementation as the required behaviour.

The campaign sponsor wanted to proceed with the earlier interpretation because the launch calendar was already crowded. I supported a four-week deferral. Engineering could have implemented one choice quickly, but doing so would have allowed the team that wrote the code to settle a commercial disagreement without the right authority. The time cost was real. We used it to align the selected order, the customer explanation and the examples that would remain with the shared capability after the campaign ended.

We released against the agreed examples, with the commercial decision recorded and the implementation reviewed against it. I did not describe either arithmetic sequence as universally correct or infer a statutory rule from the exercise. The case concerned this fictional offer and its approved conditions. Nor did resolving eighteen disagreements prove that every future promotion would fit the same model; later combinations would still need examination by the appropriate owners.

Looking back, I would bring representative examples into the campaign's first discussion, before its date and creative wording become commitments. The delay was preferable to an unresolved release, but it was still a delay we might have reduced through earlier questioning. My lesson was to use technical specificity to expose the business choice, then return that choice to the person authorised to make it.

In September 2024, our product team was preparing to assess a new browsing feature. The experiment had a planned equal allocation, yet the recorded analysis contained 92,000 control observations and 108,000 treatment observations out of 200,000. The treatment appeared to attract more clicks. A large recorded sample made the result look substantial, but the imbalance raised a prior question: whether the observations represented the experiment we believed we had run.

I backed an eight-week measurement investigation and preparation programme costing €410,000. Analysts and engineers examined assignment and capture separately. They found differential event loss in the reporting path. This did not mean that an uneven count, by itself, identified every possible cause; it gave us a discrepancy to investigate. Once the capture defect was established, the available click comparison could not support the causal reading the product proposal required.

The product sponsor argued that the observed improvement was too attractive to ignore and that the calendar favoured a decision. I rejected the proposal to promote the compromised result into a release justification. We repaired the capture path and prepared a fresh trial with its allocation, measurement period and decision criteria stated beforehand. The new trial was a separate piece of evidence. I did not claim that repairing the system retrospectively recovered the missing observations or made the original comparison trustworthy.

The immediate consequence was a deferred feature decision and work that did not produce a celebratory growth chart. We retained the investigation as an engineering lesson, including the point at which measurement quality should stop an interpretation. There is no subsequent conversion or revenue improvement asserted in this case. A click measure would in any event need an explicit relationship to the business question; a sound experiment on one interaction would not automatically establish a lasting commercial benefit.

I would now require allocation and capture checks to be reviewed before a team presents a winner narrative. That sequence matters because an attractive result creates pressure to explain away defects. The programme strengthened our ability to say that a decision was not yet supported. For a CTO, investing in that capability is part of responsible product development, even when its first visible result is a proposal that must wait for better evidence.

In March 2025, we examined search results for homewares queries whose meaning included a physical constraint. A request for a narrow shelf was not satisfied merely because the returned product description used similar words. Its dimensions and intended orientation mattered. A ranking could look relevant to a language model and still present something the customer could not use in the space described. I wanted the product review to make that failure visible before discussing a general search improvement.

We funded ten weeks of work at €920,000. Category specialists reviewed a fixed set of 600 queries, including ninety that depended on dimensions. In the top-five results for that ninety-query slice, the model-only route produced forty-seven product occurrences judged unsuitable for the stated requirement. We then combined query interpretation with verified catalogue attributes. The corresponding review found eleven unsuitable occurrences. These were repeated result occurrences where applicable, not necessarily forty-seven or eleven distinct products or customers.

The remaining cases involved unresolved interpretation of the requested dimension or orientation. An attribute filter could enforce the field it was given and still be unhelpful if the query had been mapped to the wrong field. We retained those cases for specialist examination. The category sponsor challenged the restricted result set because broader exposure could help customers discover alternatives. I chose to give the explicit fit requirement priority, with alternatives presented distinctly rather than treating them as confident matches to a constraint they did not satisfy.

The result justified further work on the combined approach within that defined evaluation. It did not establish a website-wide conversion effect, represent every query or prove that all returned products would fit a customer's actual room. The fixed review set and its judgement criteria remained part of the account. I also kept the cost of maintaining dependable catalogue attributes visible; relevance was not a capability the software team could sustain through model work alone.

My retrospective change is to classify the important kinds of customer constraint before comparing ranking approaches. We initially spent too long looking at a broad relevance score whose average concealed the cases that mattered most. A more useful early discussion would have asked category colleagues what makes a result unusable. That question gives engineering a sharper product objective and allows the business to decide openly when discovery should yield to an explicit requirement.

In July 2025, our mobile-basket team wanted to release interface improvements without waiting for the website's six-week release train. The existing arrangement joined changes that did not always need to travel together. At the same time, the basket depended on shared calculation and validation. Splitting the interface would not make it sensible for several components to invent their own version of the commercial total. The architecture needed to provide useful freedom while retaining an authoritative decision before customer commitment.

I approved a sixteen-week programme costing €1.6 million. The team separated selected interface concerns, defined the shared service contract and kept final recalculation at the agreed authoritative boundary. We examined eighteen proposed interface changes. Fourteen could be released without the full website train under the new arrangement; four still required coordinated backend changes. That distinction became part of planning rather than an exception hidden after the architectural announcement.

The delivery sponsor wanted a simpler message that the mobile basket was now independent. I did not support it. The four coordinated changes were not evidence that the programme had achieved nothing, but neither could we erase their dependency to strengthen the headline. We documented the kinds of change that crossed the shared contract and the review needed when a proposal altered commercial interpretation. Product teams retained room to improve the interface while recognising which decisions could affect the wider transaction.

We reported the fourteen and four alongside the earlier release arrangement. I did not translate them into an end-to-end productivity percentage or imply that every subsequent feature would fit the same pattern. The programme's value was a clearer boundary and a demonstrated set of changes that no longer needed the full train. The cost included engineering work on coordination and ownership, not simply extracting visual components or increasing the number of services.

I would now classify likely contract changes when the feature idea is first considered, rather than waiting until delivery planning. That would help teams recognise earlier whether they are proposing a presentational change or a different commercial behaviour. The lesson is not that all dependencies should disappear. It is that the ones we keep should have a purpose people understand, so product autonomy remains useful without making shared obligations someone else's unexpected problem.

In February 2026, we reviewed a proposed product-image pipeline for our homewares pages. Delivery performance was important, especially for customers using limited connections. Yet a smaller or faster image could still show the wrong finish, and a correct photograph could remain difficult to understand when its description failed to convey what mattered. I wanted the programme to improve the product experience as a whole instead of treating asset size as the only acceptance question.

We allocated nine weeks and €530,000 to a bounded programme with 240 reviewed product variants. The review found thirty-two image-to-variant mismatches and sixty-one description defects. These were review findings within the selected set; the counts could overlap on a variant and did not represent distinct customer incidents. Category owners checked the product name, finish, material and dimensions against the relevant record. The team corrected the identified defects before the pilot rather than allowing a delivery optimisation to distribute them more efficiently.

The performance sponsor was concerned that content review would dilute the programme's focus. I accepted the additional coordination because the image was part of the product's meaning, not merely a file attached to a page. We considered the role of each image in context. A meaningful product view needed an appropriate textual alternative, while a decorative element required different treatment. Repeating every visible word or adding a generic phrase to every image would not have answered that design question.

The result was a corrected pilot set and a pipeline with clearer ownership of the variant relationship. I did not claim whole-site accessibility compliance, a statutory conclusion or an established sales effect. Those statements would exceed the work described. The programme also did not settle every future content decision: new variants and new uses of an asset would still need the relevant context and review. Delivery performance remained part of the technical assessment without replacing the other acceptance conditions.

In retrospect, I would establish the variant and content relationships before setting the compression objective. We began with a file-performance proposal and then discovered decisions that should have shaped its scope from the start. The useful lesson was to ask what must remain true of the product when an optimisation changes its representation. That question allowed the team to improve delivery while keeping responsibility for the customer's understanding visible.