As a new analyst in the User Account Management team in Playtech I often find myself making a challenging choice. On the one hand there is the option to build a new feature, create a new configuration, etc. On the other hand, there is the option to create a new automated rule and custom tags to simulate the same outcome. The dilemma of dev vs no dev. And it is often not a clear-cut case.
As fellow analysts or product owners know, a proper feature for a set of use cases is… neat and tidy. It is easy to refer to when answering questions from users. It can be reused. It can be further developed. It feels like something got done.
The challenging alternative is to choose an already existing powerful tool (for example Automation Service Engine) that can be used to create business rules based on defined parameters. This is awesome! No more dev for us 😉 We have created a tool that replaces custom dev. But wait, we need to do some small tweaks to this tool before it becomes capable of achieving the desired outcome.
After having done some soul searching on this eternal dilemma, I have found it comes down to these 5 considerations:
Backwards Compatibility
We have 118 operators with a total of 385 brands. When adding new configuration options, we need to be extra careful to make sure that current setups do not suffer. Often this means we need to come up with a default value that would maintain the status quo in addition to the new value that would enable the new behavior. Boy have I ever felt the caricature of “repairing an airplane mid-flight” to hold truer.
Let's take Self-Exclusion for example. It is already quite complex and at the same time business-critical. If we make a minor change and this feature then starts acting even in a slightly different way, we’ll potentially have several major regulatory breaches that can end up in large fines or even lost operating licenses for whole countries.
.png)
Futureproofing
If we invest time here now, will it be reusable for future cases? Will there be similar requests in the future? In what ways do we need to design flexibility into the feature? This comes down to the infamous “gut feeling”. I have a gut feeling that in the future we will see a lot more focus on active intervention in regulations. Licensees would have to actively monitor their player base to determine at-risk players and proactively suggest different self-governed limits or indeed apply limits without consent (but still with a duty to inform). This would mean a well-rounded interface that would incorporate communication features, at risk player discovery (using machine intelligence), flagging said players, and responsible gaming features well at hand. This would be a considerable interdisciplinary effort. Would it be worth the investment?
Maintainability
We are the guardians of the system. We should know the best ways to solve business and regulatory requirements by using either existing features or creating new ones where appropriate. The more ad hoc solutions we offer, the more cumbersome it becomes to maintain. The limitations of the human memory in combination with the problems of organizational memory mean we would soon have no overview how different configurations are achieved or know how the system behaves when using combinations of said ad hoc solutions that are not specifically designed to work together. I would argue that if there is a combination that is only meant to work together and excludes all other options, then this can effectively be considered a new separate feature. The goal is to have fewer dependencies and fewer configuration options within one feature.
Fast Release Cycle
Every party involved in software product development wants to have a solution that requires the least amount of work possible. Our time is extremely valuable, and the cost of missing opportunities is even higher.
The time constraints also come into play regarding go-live dates, certification deadlines and so on. If there is a faster option for developing a new feature that must be adopted by all parties down the line… often the best solution is to go ahead with the workaround. Sometimes the workaround becomes permanent, sometimes we get to phase two.
Adaptability
I am picturing the IMS setups of existing licensees as brides on their wedding day. It took months of preparation and multi-party negotiations to get every detail right (and somehow still over budget?) If possible, no-one must touch the setup that works. Do not fix what is not broken, right? Mostly people are just too afraid to upset the bride.
But it is also our hope that when we create a cool new feature that would benefit existing licensees, they may become interested in improving their business processes, security, or customer experience. Indeed, they are paying for a continuously developing platform so they can benefit from new features, and we are actively promoting them.
These features need to be extremely easy and fool-proof to adopt. If a client gets burned once they will be even more hesitant to change their working setup the next time.
No Clear Answer
Usually, you can get some sort of an answer to almost any problem by creating the famous Pros and Cons table. The problem is - I cannot draw a table (I tried) with all these considerations and two columns – one to tick if in favor of dev and other for no dev. It is not a binary choice, but more like a scale. Sometimes the scale is only slightly in favor of one or the other in each aspect, sometimes more decidedly so.
Finally, I would like to give you some insight into how I adapted to this situation – maybe fellow analysts will recognize the steps below:
1. A new-to-me, established, fully functional, super customizable system. There cannot be a problem too big that cannot be solved with a few simple tweaks.
2. Uh-oh. Tweaks are not enough. New features are the order of the day! Everything should be solved with new features.
3. Wait… could we add a small checkbox here in this feature to create a configuration option?
4. Too many configurations! Who on earth can keep track of them all?
5. Aha! A rule engine… and tags! Let’s see how many problems could be solved just by using them?
6. Write an article
7. Continue to learn and develop.
Liina's article was also published in BA Times (resources for Business Analysts).