Areas of practice

The product includes the part that does not fit the first presentation.

Choosing a business proposition rather than accumulating features

I use research to decide which job a business-banking proposition should do and which needs belong outside its core. The 2023 bundle began with forty features, but seasonal and steadier businesses did not need one identical collection. We selected account, payments and cash-flow export as a coherent centre, with credit separately assessed. The sixty-business pilot retained forty-one users after ninety days and recorded nineteen who declined. I want both choices visible rather than treat the smaller proposition as a universal answer. My responsibility is to make scope understandable and testable, working with the owners of lending and operating conditions. A product can become more useful through a clearer boundary without every requested capability surviving into the package or every pilot participant becoming a continuing customer.

Designing the participants and interruptions in an approval journey

A business task can depend on several people acting at different times. I learned to include those relationships after approving a single-approver opening flow that blocked thirty-eight businesses in the 2004 pilot. A pending second approval, a decline, a retry and an assisted route are product states, not merely exceptions to be hidden from the demonstration. I work with operations and the relevant control owners to establish what each participant may do and what the customer should understand next. This does not authorise bypassing checks or assuming one approval rule fits every business. The practice is to preserve the actual task while seeking a clear journey, so simplicity comes from understandable decisions rather than from omitting a person whose action is still required.

Making an optional merchant service a real choice

I distinguish a capability’s usefulness to a particular merchant from the case for putting it into everyone’s default package. At Serravon, research and a pilot supported an accelerated-settlement option alongside a credible standard route. Twenty-two of sixty pilot merchants chose acceleration; thirty-eight stayed with standard service. I did not treat every non-selection as a product failure. The proposition needed visible timing, price and conditions, with treasury and operations retaining responsibility for feasibility and delivery. My contribution is to define the intended need and the choice clearly before adoption becomes the only measure of success. A more selective offer can respect different business requirements without claiming that the same service produces a cash-flow benefit for every merchant.

Owning the product’s exit and its remaining misunderstanding

Product responsibility continues when a feature is being retired or a prototype is improving but remains unclear. The invoicing transition needed additional history fields for 440 businesses, with eighty still supported at the extended review. The cash-view redesign left fourteen of 180 test participants misreading forecast receipts as spendable funds. These are different situations, but both require the unfinished condition to remain visible. I work with operating and control colleagues to decide what support, evidence or revision is needed before a wider claim can be made. The aim is not to avoid closure indefinitely. It is to prevent a convenient completion statement from transferring an unresolved dependency or misunderstanding to the customer, where the product team can no longer see it as clearly.

How I lead

I want the product team to understand what a business customer must do when the straightforward path no longer fits. A second approver, an optional settlement choice or an unfinished migration is part of the product, not an inconvenience to be hidden behind its launch story. I would rather narrow the promise and support the remaining journey than make a broader claim whose exceptions the customer has to discover alone.

At scale

The responsibility, in figures

168

Product colleagues

Seven direct reports at October 2026; lending and control mandates separately owned

A$34 m

Delegated FY 2026–27 product expense

Function scope rather than bank assets, credit authority or treasury funding

Years developing business propositions

From March 1994 analysis through merchant payments and a return to banking

In practice

Decisions and their consequences

Case I

The forty-feature bundle became a smaller proposition a business could actually choose

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.

Case II

The approval journey needed a second person whom my prototype had omitted

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.

Case III

Faster settlement remained an option instead of becoming every merchant’s paid default

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.

Case IV

The retirement plan kept an assisted route for customers whose history would not fit

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.

Case V

The cash-view prototype still needed revision after the misunderstanding became less frequent

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.