A Product Problem With An Internet Banking Application Cost A Customer US$100,000

As product managers we are generally quite proud of our products. We do our best to work with potential customers and collect requirements. We ride herd over our developers to make sure that a good product is developed and that it rolls out smoothly. What happens if there is then a flaw in how the customer uses the product – are we at fault?

Kai Olsen from the University of Begen wrote an interesting piece that ended up in Computer magazine awhile back about such an incident. This story has a lot to teach us product managers.

It turns out that there was a very ordinary bank customer in Norway who used the Internet to do much of her banking. One day she wanted to transfer a large sum of money (roughly US$100,000) to her daughter. When she keyed in the daughter’s account number during the transfer, she accidentally keyed in one digit too many.

This mistake resulted in the money being sent to an unknown third party who clearly thought that they had won the lottery. This third party promptly proceeded to gamble away much of the money before the police were able to step in and confiscate the remaining part.

Needless to say, this case got a lot of press in Norway. New banking regulations were requested to prevent this kind of slip up in the future. Obviously Internet banking had a lot more risk to it than most people thought.

In this case the end user was wrong – she entered too many digits. Before pressing enter, she could have corrected her error. At the same time, the system also could have caught and corrected her error. This did not happen – the team that built the system had not put such checks into the design.

The specific details around how this error occurred were as follows. The daughter’s account number was 71581555022. The user entered 715815555022. The standard length of a Norwegian account number is only 11 digits so the incorrectly entered account number was truncated to 71581555502.

To make things even more amazing: the last digit in a bank account is a modulo-11 calculated number that should catch single key typing errors and cases in which two numbers have been interchanged. However, due to an unlucky coincidence the number that she typed was a valid account number.

Clearly the end user was very upset about what had happened. She took her case to the Norwegian Complaints Board for Consumers in Banking. She ended up losing her case – they said that she made the error and has to take the responsibility for it.

The user is taking the case to a higher court. She claims that since she typed in 12 digits, it was the responsibility of the system to give her an error message instead of just dropping all digits after the 11th.

As product managers we try our best to create high quality products that will serve our customers well. This case points out a clear failure of a product manger to do this job completely. What went wrong here?

How our customers interact with our product is, if not the most important pat, than at least one of the most important parts of any product. Yes, we’d all like to have a very cool iPod / iPhone like interface that everyone raves about. However, even if we can’t have that, it sure seems like it is a requirement that we have an interface that operates correctly and in a manner that won’t harm our customers.

Who do you think was at fault here – the bank or the customer? Do you think that the bank should give her her money back? Have you ever had a product that had a serious user interface problem? How did you go about resolving it? Leave me a comment and let me know what you are thinking.

No related posts.

The IT field can learn a great deal about new product development from other industries. This time we’re going to learn from the big drug firms – they make excellent teachers. If you think about it, we’ve got a lot in common: both industries have to make big bets on unproven projects with the hopes that they will help make the company lots of money. Sometimes it works, more often than not it doesn’t.

The pharmaceutical business views all projects as belonging to one of two different groups: a truth-seeking group and a success-seeking group. The truth-seeking group of projects is focused on evaluating novel new product possibilities and weeding out the bad bets. The success-seeking group of projects is focused on making those products that have been cleared for development as profitable as possible. Hmm, can anyone think of an IT project that wasn’t automatically thrown into the success-seeking group without first spending some time in the truth-seeking group?

Eli Lilly has used this two-step approach to manage their new product development since 2001. What they’ve discovered is that it has been able to deliver products at 2x the speed and for about 1/3 of the cost. However, you never get anything for free. There are some side effects to using this two-step strategy:

• It will postpone the start up of successful projects.

• However, at the same time it will reduce the risk of failure in an IT environment in which the cost of development is high and the impact of a failure would also be high. If you work in an IT department that has had a lot of project failures, then this is an approach that can help you to absorb a great deal of risk early on in the project.

The sole purpose of an IT project in the truth-seeking group is to reduce the uncertainty about an IT project’s ability to deliver what the company is looking for as quickly and effectively as possible. Two types of IT errors can happen to a project that is in this group:

• Managers can ignore evidence that is telling them that the IT project won’t be able to deliver what it was designed to.

• The project is killed early before it has a chance to prove that it can deliver what the customer is looking for.

What this means is that for a product management team that is supposed to successfully launch new profitable products, they must avoid making both of these errors. Good luck killing bad products early while not killing good products too early! Using the two-group method allows a new way of thinking to be used to evaluate IT products. The teams can perform experiments on the products in the truth-seeking group in order to determine if they will be able to solve the end user’s problems. The teams need to be rewarded when an IT project in this group fails — they’ve just saved the company a great deal of money and frustration .

The problem with putting all IT projects automatically into the success-seeking group lies with us product mangers. Once we are assigned a product, we will use every trick in our book to gather whatever materials, facts, or figures are needed to show that we are still on track at each and every status review. Until it’s too late, nobody will ever know that our product is doomed for failure.

Using a two group approach to IT products will allow an IT department to implement a new metric: “speed to failure”. If a product is going to fail, then you’d like it to do so a quickly as possible. This type of approach to IT product development is not just another type of process reengineering. Rather it’s a whole new way of thinking that can reduce the risk associated with IT products while at the same time improving an entire IT department’s productivity.

Tags: IT product development, IT products, risk reduction, product failure

No related posts.