I want the decision record to retain what we declined to promise.

The 2023 business-account proposal contained forty features, intended to make one package look comprehensive. Research involved ninety businesses, including forty-two with seasonal patterns and forty-eight with steadier activity. Their needs did not fall into one convenient feature list. Clara Nethervale challenged the assumption that adding every requested capability would make the combined proposition easier to understand or more useful to each business.

The commercial sponsor wanted the broad bundle to signal ambition. I chose a narrower core built around the account, payments and cash-flow export. A credit line remained optional and subject to its own assessment, rather than appear to be an automatic component of opening the account. Lending, risk and other responsible owners retained their decisions. Product scope could not create eligibility by the way the bundle was presented.

A$4.8 million supported the product work. We developed the smaller proposition and tested it with sixty businesses. After ninety days, forty-one continued and nineteen declined. We retained both outcomes in the pilot account, including the fact that a clearer proposition was not necessarily the preferred choice for every business. The pilot did not establish a market-wide conversion rate or prove that the narrower design alone caused continued use.

The trade-off was a less expansive launch story and fewer capabilities presented as one solution. The team gained a more coherent decision for a business owner to make, while optional needs could be discussed separately. I did not claim that reducing the feature list eliminated every exception or that the pilot established a financial return on the development expense.

I would define the proposition’s central job before collecting features into a package next time. Research should help choose scope, not simply accumulate requests that must all survive into the launch. Clara’s challenge mattered because it made the team ask what the customer was choosing, rather than how much the product could appear to contain. The final offer was deliberately smaller than the first pitch, with its remaining conditions easier to examine.

I approved a business-opening prototype in 2004 that favoured a short, single-approver path. The pilot involved 120 businesses. Fifty-six required two internal approvers under their own mandates, and thirty-eight of those were blocked by the flow. The demonstration looked efficient because it showed one person completing the easiest sequence; it did not represent the task those businesses actually needed to finish.

Owen Bellarven challenged the apparent success and asked what happened while another authorised person had yet to act. The design team initially favoured sending every exception into an unspecified manual process to preserve the simple interface. I accepted responsibility for the missing journey and funded a more explicit response. We needed to show pending approval, decline, retry and a supported assisted route rather than imply that an incomplete application had either succeeded or failed without explanation.

A$420000 supported the rework. The product team worked with operations and the relevant control owners on what each state meant and what a user could appropriately do next. We did not bypass bank checks or claim that all businesses legally needed two approvers. The requirement described the affected pilot businesses’ own mandates, and the actual account-opening conditions remained subject to the responsible bank processes.

The outcome was a design that acknowledged the second person and the interruption between actions. It was not evidence that all thirty-eight blocked businesses subsequently completed opening, because that result was not measured in this case. The cost included a longer and more demanding journey than the one I had originally wanted to demonstrate.

I would now include multi-person and interrupted paths when defining the product’s task, before celebrating the speed of one uninterrupted flow. The lesson was not that every screen should be complicated. It was that simplicity achieved by omitting a necessary participant transfers the complexity to the customer and operating team. A complete proposition has to account for the people whose decisions it depends on, even when they do not act at the same time.

At Serravon Payments in 2011, the team considered an accelerated-settlement service for merchants. Research with three hundred businesses found 120 interested in receiving settlement sooner, while 180 said the standard service met their needs. The commercial proposal favoured placing the paid accelerated service into the default package, presenting it as an improvement every merchant would appreciate.

I chose an explicit optional service. The timing, price and conditions needed to be visible before selection, with the standard route remaining understandable and usable. Treasury and operating owners assessed feasibility and service conditions. The product team could not promise universal timing through a headline or assume that a feature useful to some merchants justified a paid default for everyone.

A$2.1 million supported product development. In a sixty-merchant pilot, twenty-two selected the accelerated option and thirty-eight retained standard settlement. We treated those choices as evidence from that pilot, not as a forecast of the whole market. We did not interpret the standard-service selections as failed adoption; they were consistent with a proposition designed to offer a meaningful choice between different needs.

The trade-off was giving up the larger immediate uptake the sponsor expected from default inclusion. The selected approach required clearer explanation of the option and a more deliberate customer decision. It did not establish a profit improvement, a universal cash-flow benefit or a service outcome beyond the pilot choices. Actual settlement operations and exception handling remained part of the service work rather than assumptions that the launch copy could settle.

I would agree what successful choice looks like before setting an adoption objective. If the product exists to serve a particular need, a customer who does not have that need may be well served by declining it. The useful question is whether the proposition and conditions allow an informed selection, not whether every user can be pushed into the same option. Leaving the standard service credible made the accelerated offer more precise about whom it was intended to help.

In 2018 Erlavane planned to retire a legacy invoicing feature used by fourteen hundred businesses. The proposed ninety-day exit assumed that the standard export would meet everyone’s needs. Review showed that 960 businesses could use it, while 440 required additional history fields. A uniform deadline would have treated those dependencies as a customer problem after the product team had already declared the transition straightforward.

The platform sponsor wanted one closure date to avoid extending support cost. I supported an assisted 180-day extension for the 440 affected businesses while the standard route remained available to the others. The purpose was not to preserve the old feature indefinitely. It was to make the exit work for the dependency we had identified, with a visible account of the work still outstanding.

A$3.7 million supported the transition response. The team worked with operations on the additional fields, guidance and assisted process. Relevant owners assessed permissions and any record-handling requirements; the product team did not invent a universal legal deadline or assume that a migration instruction settled every retention question. At the extended review, 360 of the 440 had migrated and eighty remained on an assisted extension.

The result was therefore incomplete, and I kept it described that way. We had not closed the feature for every customer or realised a claimed full support saving. The trade-off included continued service expense and an untidier completion story. The remaining eighty cases needed an explicit plan rather than being hidden by the larger migrated group.

I would examine the exit dependency when deciding to retire a product, before announcing the date as though the only work were communication. The history a business has built inside a feature can become part of its practical value. Product responsibility includes helping the customer leave that dependency in a usable form. A retirement plan is credible when it accounts for the exceptions still open, not merely when its calendar looks decisive.

A 2025 prototype combined an available-balance view with forecast receipts in a prominent business cash headline. In a test with 240 owners, sixty-seven interpreted the forecast receipts as funds they could spend. The team had intended the combined presentation to make planning easier, but the test showed that the promise perceived by users differed from what the product actually supplied.

The delivery sponsor preferred a small explanatory note to preserve the visual concept and schedule. I chose to separate available balance from the forecast, remove the combined headline and make assumptions visible. Product, design and the relevant risk and operating colleagues worked on the distinction. The response did not convert a forecast into a credit decision or establish a right to draw funds beyond the actual account conditions.

A$5.6 million supported the product work. A new test with 180 owners found fourteen still misreading the revised prototype. That was a better observed result in the new test, but it did not mean the misunderstanding had disappeared or prove that the redesign alone explained every difference between the groups. We retained further revision rather than announce a completed solution or a full launch on the strength of a more attractive percentage.

The cost was a delayed completion story and the loss of a visually compact headline. The product gained a clearer separation of available and forecast information, while the remaining confusion stayed part of the decision. No financial benefit, borrowing outcome or actual customer loss is asserted in this fictional case.

I would test the meaning users take from the headline before polishing the combined visual treatment. A short label or note can be technically accurate while the overall presentation invites a stronger interpretation. The useful result of testing is not always permission to proceed. Here it was evidence that a better prototype still needed work, and a reason for the product leader to keep that unfinished condition visible to the people deciding what should happen next.