There are many ways of having fun with that experiment

My editorial

I am designing an experimental environment for products based on digital technologies. I am coalescing my thoughts around the type of digital products that I am particularly focused on those last weeks, namely on the FinTech. I started sketching the contours of that experimental environment in my last update in French (see Une boucle de rétroaction qui reviendra relativement pas cher ). Now, I am rephrasing the idea in English and giving it a bit of an extra spin. There are two groups, the geeks and the ordinaries, I mean a group of k software engineers – or k teams of them, the unit is to settle later – and a group of n users, allegedly prone to being more or less enthusiastic about FinTech products. The first round of the experiment starts as the users are asked to make a set of financial decisions in a controlled environment. By controlled environment I mean a standardized budget, e.g. €10 000, and a standardized set of possible uses for that small fortune. It would be good to have pretty a wide range, as uses come, covering typical saving (holding liquid capital for future, unspecified uses), investment (buying future possible gains with the present allocation of liquid capital), and typical consumption (e.g. sex, drugs, and rock’n roll).

The users make their financial decisions in that controlled environment. The software engineers are then being presented with various types of data about those decisions. ‘Various’ can range from simple reports like ‘50% of the users decided to invest not less than 40% of their budget into the Smartest President’s next business’, through more and more elaborate data on individual decisions, taking a slight turn by a detailed database of those individual decisions, all the way to the data from behavioural observation of the users (i.e. sequence of clicks, sequencing of the decision-making process, speed and pace of the corresponding sequence, eye-tracking, pulse, breathing, don’t-put-that-thermometer-where-we-can-both-regret-it etc.). Yes, you guessed correctly: we have been just experimenting with the users, and now we are experimenting with the software engineers. What type and what amount of data will be actually useful for them? If they can choose the type and the scope of information provided about the users, what their choice is going to be? From then on, what their response is going to be? ‘Cause now, the software engineers are to present prototypes of FinTech products, as well adapted as possible to what they know about the users.

Here’s the little caveat: the users are not supposed to tell the engineers what they want. There is just objectified observation. Why? Well, what I want is to simulate, in that experimental environment, the real working of a market, only faster. In real markets of standardized digital products, engineers seldom speak in person to the end users. They have reports, and they base their invention on it. In my experimental environment, each engineer can pick and choose the parcel of information for takeaway, and then calibrate their engineering response accordingly.

In that first round of the experiment, I arrange an interaction between the users of FinTech products and the engineers supposed to create those products. At this stage, the experiment is already informative at many levels. At the first and most basic level, it tells is about the patterns of financial decisions observable in users, and about the way they make those decisions. One level higher, I encompass both the data on users and the data on the engineering response, and what I get is knowledge about the interactive engineering process itself. In the presence of the given set of data on users, their decisions, and their decision making, how quickly did the engineers respond by producing prototypes of FinTech products? What is the typical pattern of utility in those products, and what are the idiosyncrasies in individually created FinTech solutions? I go one level higher in the generality of observation, and I am connecting the type and scope of data on users with the pattern of engineering response. Did richer a set of information on the users’ behaviour contribute to create more sophisticated FinTech products, i.e. did those engineers, who chose to work with more extensive an information about users, create something clearly sticking out of the crowd as FinTech solutions come? Maybe there is a golden path of wisdom, as regards the amount of data on users, somewhere between a cursory report about what percentage of them chose to buy government bonds, and extensive a report on how was their body temperature changing during the decision-making process.

Besides the amount of data collected about the users’ behaviour, there are other dimensions in that experiment. The specific profiling of users is, of course, one of them. How does the whole process work with users of different age, economic status, sex, education, professional walk of life and whatnot? Another dimension is the relative complexity of the users’ behaviour, on the one hand, and the complexity in engineering response, on the other hand. Up to a point, the more people we have having a certain type of idea, the more distinct ideas are being crystallized. In a sample of 100 users we can probably come up with greater a number of distinct patterns in the making of financial decisions than in a sample of 10 users. Still, diversity in users is not just their sheer number, it is also the relative disparity of their characteristics. If, in a sample of users, we put people with high school degree, and those with their college diploma hung on the wall, we come with a certain diversity in decision-making. Now, we add those with Master’s degrees. What has changed? Did the addition of one more level in education change the diversity in the making of financial decisions? Now, we can experiment at the same level with other characteristics, and each time the question is the same: how does the relative complexity in the population of users reflect in the relative diversity of the observable patterns in their financial decisions, and in the process of making those decisions?

Just to return to real life, which is sometimes useful in science, I remind: in any type of business, the supplier has to deal with various degrees of complexity in their target market. I am a software company from Romania, I had come up with a super-cool payment platform in the Romanian market, and now I am trying to see the big picture, i.e. the Chinese market. I will be interacting with much bigger, and potentially more diverse a population of customers. How should I change my engineering processes in order to cope efficiently with the situation? This is precisely the kind of questions that my experimental environment can give an answer to.

We go one step further, and we can test the link between the above-mentioned complexity in the set of users’ characteristics, and the complexity of the solutions prototyped by engineers. If I add one more social stratum to the sample of users, does a constant population of engineers come up with more of distinct prototypes of FinTech products? There is another path going (somewhere) from this point: if I keep the complexity observable in users constant, and I change the diversity in engineers, how will it affect the creation of prototypes? In the presence of a constant sample of 100 users, with their descriptive data, will 50 engineers, each working independently, generate greater a diversity in prototypes than 10 engineers? Once again, is there any golden path of optimization in that proportion? What if, besides varying the number of engineers, I shift between various types of diversity in their characteristics, e.g. the number of years spent in the professional engineering of software?

In all that experimenting, and shifting diversities, an economic equilibrium is timidly raising its head. What does an economic equilibrium’s head look like? Well, you can take the Marshallian equilibrium as a good example: two convex curves, crossing at one point, so it is like a Guinea pig with a pair of pointy ears, pointing slightly outwards. This could be something like a rabbit, as well. Anyway, each given set of characteristics in the sample of users, combined with a set of characteristics in the sample of engineers, produces an outcome in the form of a set of prototypes in FinTech products. A set of FinTech products, in turn, generates a certain stream of financial gains for users – like the money they save on paying for electricity or the money they gain from an investment portfolio – and a stream of revenue for the supplier of FinTech. The latter earns money in two basic patterns: either by collecting a small margin on each transaction performed by the user, or by charging the user a fixed monthly fee for the access to the given utility. I suppose that a well-rounded prototype, in a FinTech utility, should contain those components.

Thus, in my experiment, I have the following, compound variables, modifiable in my experimental environment:

  1. a vector UR = {ur1, ur2, …, urm} of m characteristics observable in users;
  2. a vector EN = {en1, en2, …, enk} of k characteristics observable in engineers;
  3. a vector EN(UR) = {en(ur)1, en(ur)2,…, en(ur)l} of l users’ characteristics actually used by the engineers in their work; in the experimental environment this vector can be either exogenously constrained or freely shaped by the engineers themselves;
  4. a vector FU(UR) = {fu(ur)1, fu(ur)2, …, fu(ur)p} of p functional utilities available in those FinTech prototypes; you know, the number of clicks (or screen touches) you need to transfer all your money to the Caiman Islands etc.;
  5. an aggregate stream PF(UR) of users’ payoffs from those FinTech prototypes presented; it can be further decomposed as a vector, namely PF(UR) = {pf(ur)1, pf(ur)2, …, pf(ur)z} of z users’ payoffs, but in my basic scheme I want to use it as an aggregate stream;
  6. an aggregate stream P*Q of revenues that the suppliers of those prototyped FinTech products can derive from their exploitation; once again, P*Q can be also represented as a vector P*Q(UR) = {p*q(ur)1, p*q(ur)2, …, p*q(ur)ß} of ß specific streams per user or per utility, but in my basic model I want to keep it simple;
  7. an aggregate stream EC of engineering and maintenance costs, in suppliers, connected to the basket of FinTech prototypes proposed; again, translation into a vector is possible, although not always necessary;

Now, my basic economic equilibrium, if I keep it more or less Marshallian (you know, the rabbit), would be something like: [P*Q – EC] -> PF(UR). It means that there could be some combination of my experimental variables, which makes the aggregate profits, on the part of suppliers, tend to equality with the aggregate payoffs in users. That Marshallian approach has some catches in it. It supposes the existence of an equilibrium price in FinTech products, i.e. a price that clears inventories and leaves no customer with unsatisfied demand for FinTech utilities. This is tricky. On the one hand, in finance, we assume the existence of at least those most fundamental equilibrium prices, like the interest rate or the discount rate. It was observed already in the 18th century, by Adam Smith, among others, but, interestingly enough, not earlier. When I read that book by Jacques Savary, published in 1675, entitled ‘Le Parfait Négociant ou Instruction Générale Pour Ce Qui Regarde Le Commerce’ (in English: ‘The Perfect Merchant or General Instructions as Regards Commerce’), equilibrium rates in finance tend to be considered as a comfortable exception than as the general rule of the market. Still, here, in FinTech, we are at the junction of finance and digital technologies. In IT, people don’t really like talking about equilibrium prices, and I can hardly blame them, ‘cause the actual diversity in IT utilities is so great that we can throw the assumption of homogenous supply through the (metaphorical) window as well.

Anyway, I can optimize my experimental environment regarding the Marshallian equilibrium, or any other economic equilibrium, actually. I can make a function [P*Q – EC] = f[UR], i.e. a function linking the aggregate profits in the suppliers of FinTech products with the observable complexity in the population of users. I can do the same with the complexity observable in the population of engineers. There are many ways of having fun with that experiment, at this stage, and this is just the first stage. There is more to come. The engineers come up with a range of prototypes in FinTech, and they present them for testing. The users test those prototypes, in an experimental environment, and once again we apply the same philosophy: the users are supposed to be informative by their behaviour, not so much to talk about their impressions.

An interesting question arises, namely that of learning. If I am one of those users, and I am supposed to test those prototypes devilishly, I mean like 6 prototypes tested over 6 days, with 6 cups of coffee in terms of neuro-logistic support, I can’t help learning. At my 3rd prototype tested, I will be using, consciously or not, whatever, the experience accumulated with the testing of prototypes 1 and 2. Thus, what I will be really testing, will not be each prototype separately, but a sequence of prototypes, associated with a process of learning. Someone could say that learning creates a harmful bias (believe me, there are people who think so), and so the edge of learning can be blunted in two basic ways.

Firstly, the experimental environment can take away from me any feedback on the financial decisions I make with a given FinTech utility. When we do something about money, we like seeing the outcomes, it is kind of attached to money in its cultural code. You take away the feedback on results, and, by the same means, you take away the incentive to learn. We could think about such an experimental environment, and yet, I have like a little voice in the back of my head (no, I am perfectly sane) saying that financial decisions without feedback are not really financial decisions. That would be an experiment biased by the absence of bias. Secondly, I can make each user test just one prototype. There is no opportunity for learning in this case. Still, we need to split the sample of users into as many subsamples as we have prototypes to test, and each has to somehow representative.

Now, do I really want to take learning out of the equation? Do I expect the users out there, in the big, wild market of FinTech, using those apps without learning anything? I just think it could be safer to assume that people learn things. What we should be really testing, at this stage of the experiment, could be precisely the phenomenon of learning, with respect to FinTech.

I am working on making science fun and fruitful, and I intend to make it a business of mine. I am doing by best to stay consistent in documenting my research in a hopefully interesting form. Right now, I am at the stage of crowdfunding. You can consider going to my Patreon page and become my patron. If you decide so, I will be grateful for suggesting me two things that Patreon suggests me to suggest you. Firstly, what kind of reward would you expect in exchange of supporting me? Secondly, what kind of phases would you like to see in the development of my research, and of the corresponding educational tools?

5 thoughts on “There are many ways of having fun with that experiment

Leave a Reply