A product demonstration can look simple because it leaves someone out. One person enters the details, moves through the screens and reaches a completion message. The sequence is easy to explain and satisfying to watch. A business customer may need another authorised person to act before the task is actually complete. I believe that second person and the interval between their actions belong in the product definition, rather than in an exception process discovered after the first demonstration has been approved.
I learned this through an error I made in the fictional 2004 opening prototype at Erlavane. The pilot involved 120 businesses, fifty-six of which required two internal approvers under their own mandates. Thirty-eight of those businesses were blocked by the single-approver path I had favoured. The design had made the easiest sequence shorter without making the complete task workable for that group. Owen Bellarven’s challenge forced me to examine what the apparent efficiency had omitted.
Define completion from the business task
I would begin by asking what must be true for the customer’s task to be complete. That question can involve more than one person and more than one moment. It is different from asking whether a user has reached the last screen. In the case, the businesses’ own approval arrangements created a dependency the prototype did not accommodate. We did not claim that every business legally needed two approvers, and the product team could not remove the bank’s relevant checks to make the journey look easier.
The important distinction is between a clear interface and an incomplete model of the work. Clarity remains desirable. A customer should understand what is required and what happens next. But clarity achieved by ignoring a necessary participant only transfers complexity to the person who discovers the omission. The user may not know whether the request has been submitted, whether another person has been invited or whether the process must start again. The operating team then inherits questions the design should have anticipated.
The original response proposed sending every exception to an unspecified manual route. That would have protected the simple demonstration at the cost of an unexplained second service. I accepted that the product needed a more explicit account of pending approval, decline, retry and assisted completion. The assisted route could remain appropriate for some circumstances, but it needed a defined purpose and connection to the digital journey. It could not simply be a place to put the customers whose tasks complicated the preferred story.
Make the waiting state part of the proposition
Waiting for another person is not necessarily an error. It can be an expected state of a business task. I would design the account of that state so the first participant understands what has happened, what remains and which action is available to them. The second participant needs an equally clear account of what they are being asked to decide. Product, operations and the relevant control owners must establish those meanings together, because a reassuring message cannot create authority the participant does not have.
Decline also deserves its own treatment. A second person may decide not to proceed, and the first participant should not be left with a success-looking screen that hides the decision. Retry may require a different response depending on what changed and what the relevant process permits. These conditions should be specified without assuming a universal rule for every account or institution. The fictional example concerns a particular pilot problem; a real product needs its own evidence about the participants, permissions and operating requirements involved.
A$420000 supported the rework in the case. That expenditure did not establish that all thirty-eight blocked businesses subsequently completed opening. We changed the journey to acknowledge the missing participant and states, but the case did not measure every later completion. I retain that limit because a design correction and a customer outcome are different claims. A product leader should be able to explain what was delivered without borrowing the most favourable result that might eventually follow from it.
The team also gave up the original promise of an unusually short path. That was a real trade-off, not a reason to pretend the first design had been sensible for everyone. I would rather have a slightly longer account of the task that allows participants to understand their part than a short sequence whose apparent completion collapses when another person’s decision becomes necessary. The challenge is to make the required complexity intelligible, not to deny that it exists.
Measure simplicity without removing necessary responsibility
Screen count alone is an incomplete measure of a business journey. Fewer screens may help, but the reduction can conceal an omitted decision or shift work into calls, retries and uncertainty. I would examine what the customer is trying to complete and where effort moves when a step disappears. This does not require treating every possible exception as equally common or important. It requires identifying the conditions material to the product’s intended users before using a narrow demonstration as evidence of general usability.
Research should include the people who participate beyond the initial user. Otherwise the product may be optimised for the person who begins the task while the person who authorises it is treated as an external dependency. I would ask how they receive context, what they need to assess and how their decision returns to the first participant. The operating account should also explain what happens when one person is unavailable. The appropriate response depends on the product and responsible owners; it should not be improvised through a misleading completion message.
For senior management, I would describe the scope of the tested journey as carefully as its successful completion rate. A result from single-person cases cannot automatically stand for a multi-person population. The account should identify which tasks and participant arrangements were represented and which remain untested. That helps the delivery decision without demanding that every report contain the full design specification. The concise statement should preserve the condition that materially changes what the observed success means.
The board’s interest, where the issue is material, is in whether the product promise and supporting evidence align. Directors should not design the approval screens. They can ask management whether the intended customer groups and consequential exceptions have been considered, and how unresolved conditions affect release. A product executive moving towards a first board role should translate experience into that kind of oversight question, rather than carry operating authority into a setting where the responsibility is collective and differently defined.
My conclusion is that the second approver belongs in the product before the fast path becomes its identity. A business journey is not complete because the demonstration’s only participant has finished clicking. The task may require another person, a wait, a decline or an authorised assisted route. Recognising those conditions early allows simplicity to mean understandable work, instead of an attractive absence of the work the customer still has to do. The product becomes more credible when its promise includes the necessary participants rather than leaving them to discover their role after launch.