A familiar commercial phrase can create the illusion that a product requirement is already understood. Everyone in the room recognises the words, so the conversation moves quickly to delivery dates, interface designs and the systems that must change. Only later does a specific basket reveal that the participants imagined different behaviour. The software team may be the first to discover the difference because its implementation cannot remain as pleasantly ambiguous as the original phrase. It has to return an answer for this customer and these items at this moment.
I do not regard that discovery as evidence that commercial colleagues should write technical specifications. It shows the value of a shared example. A retailer's specialists understand the intention, the economics and the customer explanation; engineers understand where an implementation needs a definite interpretation. The useful conversation brings those perspectives together before either becomes a finished artefact that is expensive to change. A prototype can help, but the prototype itself may already embody one person's unexamined choice. I often prefer to start with a few ordinary examples whose meaning everyone can inspect without needing to understand the code.
## Two answers can both follow the instructions
Consider the synthetic basket from our promotion review. Its eligible amount was €120, with a €20 reduction and a ten per cent reduction to apply. Taking away €20 before calculating the percentage left €90. Calculating the percentage first and then taking away €20 left €88. Neither arithmetic operation was difficult. The ambiguity lay in the intended order and the conditions of the offer. A test could verify either sequence perfectly while leaving the commercial disagreement unresolved. Asking whether the software was correct therefore required an earlier answer about which behaviour the business had approved.
The two-euro difference mattered because it made the interpretation visible. I would not extrapolate it into a loss estimate without knowing the applicable baskets, frequency and approved policy. That would introduce a new set of assumptions before resolving the original one. The example's first purpose was to support a decision, not to produce an alarming programme justification. It allowed the commercial owner to consider the offer and its wording, then gave engineers an agreed result against which to implement and review. A small example can be powerful precisely because it is understandable without a large financial narrative around it.
Our set of 126 authored examples exposed eighteen disagreements. That count described the review, not eighteen live charging incidents or a measured error rate across customer activity. I wanted the distinction retained because a useful discovery can become misleading when its unit changes in the telling. The examples included situations selected to clarify the intended behaviour; they were not a random sample of every possible basket. Their value came from the questions they surfaced and the decisions that followed. Completing them did not prove that every future combination would fit the same model without further examination.
## Authority belongs beside the example
Once an ambiguity is visible, somebody still needs to resolve it. The engineer who identifies the question should not become the policy owner merely because the release cannot proceed without an answer. At Solmerive, the commercial team had that responsibility. My role was to make the alternatives clear, explain their implementation consequences and ensure that the selected behaviour could be carried consistently through the product. This division did not absolve technology of judgement. I remained responsible for challenging an incomplete instruction and for refusing to present an unresolved interpretation as a finished capability.
The campaign sponsor had a real reason to resist delay: launch time was scarce and other activity was already planned. We accepted a four-week deferral rather than allowing the existing code to determine the policy by momentum. I would not turn that choice into a universal rule that every ambiguity requires the same delay. The useful principle is to identify what remains undecided, who owns it and what each available route would cost. In some circumstances a narrower offer might be appropriate. In ours, the responsible team needed to settle the examples and the explanation before the intended campaign could proceed coherently.
There is also a communication responsibility after the decision. If the implementation uses one interpretation while the customer wording invites another, the internal agreement has not reached the person who needs it. Engineers may not own that wording, but they can provide the examples that help commercial and content colleagues assess it. I want the calculation, the approved conditions and the explanation reviewed as related expressions of the offer. This is more useful than expecting a technically accurate screen to repair a commercial phrase whose meaning was never made clear to the people reading it.
## Keep the reasoning after the campaign ends
The examples should survive the immediate release. A later team may reuse the same capability for another campaign, introduce a different interface or extend the range of applicable products. If it inherits only a collection of passing tests, it may see what the software does without understanding why the business chose that behaviour. I want the responsible decision and its scope to remain alongside the examples. This does not require preserving every meeting or turning a small feature into a vast document. It requires enough context to identify when a future request changes the approved meaning and needs a new decision.
That continuing context is part of architecture. A shared calculation can make several products consistent, but it also concentrates responsibility for change. The owner must know which conditions the capability represents and which are outside its current account. Otherwise reuse merely spreads an assumption farther. A product team should be able to ask whether its proposed offer belongs within the shared rule, needs an explicit extension or should remain separate. The answer involves commercial meaning as well as software design, and it is better reached before a new launch date makes one implementation feel inevitable.
For a CTO, the larger lesson is about the relationship between precision and authority. Engineering can make a choice exact without making it legitimate, agreed or well explained. I want technical precision to reveal the decision that belongs to the business and then preserve its intended meaning. Our retrospective change was to bring representative baskets into the first campaign discussion. That would not eliminate every disagreement, but it would make the important ones available earlier, when the team still has room to consider them. The best example is often the one that helps responsible colleagues disagree constructively before a customer receives the answer.