Boundary Conditions

Riemann SphereBeing attracted to complexity, I naturally chose ‘Complex Analysis’ as a module in college (who could resist, right?). The subject turned out to be calculus in the realm of imaginary numbers – fascinating in its own way (hello Riemann sphere), and certainly complex in places, but not about complexity per se.


There is a forest of writing about the increasing complexity in business. Everything seems to be speeding up and growing more interconnected. Called by Bain “the silent killer of profitable growth”[i], complexity must be confronted by everyone in business who wants to survive and to win. The current era has seen major financial institutions toppled as the complexity of front-line work outstripped the ability of executives to manage it, from CFDs and CDOs in Finance to the underestimation of the liabilities of long-term risk in Life Insurance.

If we drop down to that user level within insurance operations, we see unique forms of complexity at the intersection of calculations, retroactivity, compliance and multi-layered record-keeping.

As a leading product vendor, a part of our mission is to simplify the life of the end user so that he or she can devote more time to high quality decision-making, collaboration and communication.

But here we encounter Tesler’s Law[ii], which tells us that complexity cannot be destroyed, but must be divided in a zero-sum-game between the realms of the system and the user. To simplify the world of the user, we must unavoidably complicate our system.

Where to draw the boundary?

System or user?

Any Product Manager worth his or her salt regards added system complexity with a very wary eye. The extra costs of design, build and test, maintenance, training and in particular customer implementation and later roadmap enhancement, ratchet up non-linearly. A solution that goes the extra mile, (e.g. automating less common customer service scenarios), may have a 10x higher total cost of ownership over time.

Several one-time market-leading, but undisciplined, vendors have, over time, “choked on their own complexity”.

The economics of feature selection and feature sophistication dictate that the resultant differentiation must pay off, and must be seen to pay off, many times in terms of customer satisfaction and increased market success.

Two to Tango

The ultimate arbiter of market success is of course the buyer. Here we do find a subtle contradiction: technology assessment models in our industry can actually deter sophistication. As with complex purchases in other industries, there exists a tendency among buyers to commoditise, e.g. via capability check-listing. The historical, rational and psychological reasons for this are for another day’s musings, but the effect is to frame evaluation as a question of whether, and not how well, the stipulated requirement is supported.

Weaker vendors can game this system via box-ticking. They support only the most basic ‘happy path’, enlisting the beleaguered user as the messiness of the real world intervenes and deviations occur.


We believe the human realm is where carriers truly differentiate. It is no place to leave the humdrum labour of repetitive, and sometimes intricate and error-prone, administrative tasks.

FINEOS was founded to put people back at the centre of core insurance operations (“person-centricity”). A part of this is absorbing complexity, selectively, on their behalf.

Yes, we have to be careful not to outpace our customers’ ability to adopt and value our solutions, which is why we collaborate so closely.

Yes, we have to start simply and only layer in sophistication incrementally. This is fully aligned with our Agile methodology.

Yes, we need a uniquely deep understanding of our domain. That is what sets FINEOS apart.



You may also be interested in