Part two in our “Talking tech with Tavio and Tony’ series. This time Tavio Roxo, CEO and Co-founder of Owls Software, tackle the tricky issue of involving users in the design of platforms.
Tony: The tech basically gets built in the insurance industry for both sides, for the insurance company to use on the one side and for the client to interact with on the other side/ for the system to interact with the client. The question is whether we can we rely on the actual user to help us build the system? That famous saying of Henry Ford, comes to mind, he said, “If I asked my customers what they want, they would have told me they want faster horses”. What is your opinion on this?
Tavio: The first complexity or the first issue that one faces is that a user is an expert in their own field. In the insurance value chain, there are a multitude of different types of users, and a multitude of different types of sub-users.
Theoretically, you are building a system that can be used by a reinsurer an insurer, a UMA, a broker and a policyholder. And once you understand that you’re building the system so that each one of those stakeholders in the insurance value chain are going to consume and interact with the data and the information that lives in the system, you realise that you are now building a system for four or five sorts of broad types of users.
But then, within each of those users, there are multiple subsets of users. So, you’ll have a specialist user on the finance side of an insurer, you will have a specialist user on the claims side in a UMA, you’ll have a specialised user on onboarding new business in a broker.
If you ask the broker, who is onboarding new business, and you ask that particular user what they want to see in the system, you can see already that their answer will be focused very much on the attributes that they require in their business on a day to day to make their lives easier. But that really serves no purpose for a reinsurer, by way of example, or for an insurer user who is sitting in a reporting world and wants to extract just information.
So, when you are building a system, you must consider each one of these stakeholders, users, each one of the functionality requirements, and how all of those interact and engage with each other. It’s a relatively complex task. And so, I don’t know whether users can build systems, I think they can notionally understand where they want to go with the system, but experts must be involved.
Tony: So now you’ve built a system they are using, and they are the ones that are taking the pain of learning to navigate the system. As they get proficient in it, they can potentially find certain gaps or some things that they want to develop further. How do you go about soliciting those or filtering those out or getting one’s thoughts and opinions that are worthwhile?
Tavio: There certainly are users who really understand the game better than other users and you want to utilise that information in the build of the system. But that very same attribute is the constraint that causes the user to think within the box potentially. A good example and was when they were looking to activate SMS notifications for bank transactions. Most surveyed customers said they did not want that functionality. Now it is the standard and what is expected.
So, you must be cognisant of the landscape and of the history that leads you up to where you are, regarding user requirements. And acknowledge that it’s not the beginning and end all of everything and that there is additional stuff outside of what a user perceives as being their world.
OWLS™ Insurance Software
Proud service providers to insurance companies, UMA’s,
administrators, intermediaries and financial services companies.
Tony: Do you have a system for improving a system over time or adapting the system to the changes within the company, and with products? How does that work?
Tavio: I don’t think that it is only something specific to our software, I think it’s something that most software providers do engage with. Firstly, there must be a requirement or a need within the business that ultimately is going to lead to more efficiency, more scale, or a better, frictionless engagement between a user or a customer or an internal administrative user and the system/ output that the system must give.
Once you jump over that, and you say yes, now we need to upgrade because we need to incorporate x and y, then there is a full process where you spec out exactly what you require. Once that has been decided, there are multiple ways to do it, but you go off and you essentially develop it. And then you put it into a staging or into a user acceptance testing environment for the user to test and to understand whether in fact, the functionality that has been built, is going to help that user or solve the particular problem statement. If all those boxes are ticked, then you would ultimately release that into a production environment.
They are thereby enhancing your technology stack in your system incrementally and you do many of these over the course of a year or a month. Ultimately you wake up 24-36 months later, and you realise that this technology has really evolved to work specifically for them and to really help them from an efficiency perspective.
Then you have the satisfaction of seeing how the system has evolved from where it was when you initially started.
Watch or read part one here.