How the bot hype can be a competitive advantage for FinTech challengers 🔥🔥🔥
At Ernest, we have spent the last six months building a personal financial chatbot 🤖 from scratch that’s “better than your banking app”. We have experienced the bot hype ourselves and know the uncertainty new paradigms and technology disruption can bring. We believe this innovation will have a huge impact over the next few years and cannot imagine how scary this FinTech wave looks for incumbents. But, we are also aware of the risks for us challengers too.
Unfortunately, the bot field is still overheated 🔥 and there is no indication the noise will go down anytime soon.
So we have to be careful to handle Hype Cycle risks. For Ernest this means, reading a lot, auditing tons of technologies and paradigms, and cherry picking the best (technologies and paradigms) for our use case. We think we have dodged some of those risks and we decided to share some lessons learned from the front.
TL; TR
Focus, incremental changes and a sprinkle of magic
Chatbots are a hot 🔥 field and so here at Ernest we often discuss if it’s better to use or build something. This approach is great but it comes at a price. So we follow a pragmatic approach to minimise the inefficiencies.
Focus
We have two different Trello boards:
- one to handle our roadmap
- one for day to day activities.
The roadmap board
We use a sort of Story Mapping where every column has a major functionality ordered by priority from left to right. Each card in a column is a story sorted by importance from the top to the bottom.
The roadmap represents our vision, and it’s the result of external and internal feedback. Once we find something interesting (e.g. tech, UI, UX, etc.), we double check if it’s already present as a feature in our roadmap. Otherwise, we do an internal review, and if it has the potential to add significant value to the product, we add it as an idea. Then once a month, we discuss our roadmap to check progress, review priorities and decide if it is worth moving new ideas in to the pipeline or if it would be better to archive or postpone.
The day to day activity board
It is a typical Kanban board where each column represents a stage in our workflow.
It’s fed by the roadmap plus operative tasks (e.g. bugs, DevOps activities, design, spikes, etc.). It is a collective effort to deliver value ASAP through the continuous delivery pipeline.
Once we have something ready, large or small, we push it to the next step or environment so that it can be reviewed, tested and eventually released in production.
Incremental changes
We can’t deliver our whole vision in one step, so we have to deal with limited resources and time. Therefore, we deliver incremental changes and refactor once we come across any limitations of our previous implementations.
A quick example is the Message Pipeline, which has been refactored three times since the start.
Phase 1
We built a MVP to receive a message from Facebook Messenger and return a response to the user based on their intents.
Phase 2
We reworked to abstract Facebook Messenger as a channel, we added a raw template system, and we added a simple queue job system to decouple message reception from the delivery.
Phase 3
Once, the pipeline workflow was clear we refactored the whole code to use a functional paradigm with immutable data structures as foundation, a composable template system and a distributed notification system.
Clearly, we didn’t get it right first time but we adopted an incremental approach adding one brick at a time, turning significant problems into smaller ones.
It could sound a bit naive but this approach is one of the main reason why we can deliver deep insights faster and better than banks. They clearly have more resources but they also have a heavy tech legacy and a culture not ready to embrace the change.
Sprinkle of Magic
Easy to say: “Delivery faster and better” but how?
Use the right tool for the job
However, in tech using the right tools come with a high fragmentation infrastructure costs. Even worse looking in the bot design where lately “conversational UI” became quite popular.
A conversational interface is any UI that mimics chatting with a real human.
Too many times, the idea of Conversational UI is considered just as an exchange of text messages. It is not. A modern Conversational UI is made by a mix of things: text, images, buttons. Potentially every single message can be a micro application with which to interact.
From a design and technology perspective, it means keeping a lot of stuff together.
Let me list few of them
- Multiple chat channels (e.g. Facebook Messenger, native app, web app)
- Collect the messages
- Delivery simple or structured messages (e.g. text only, images with texts, buttons, etc.)
- Rich HTML/JS views (this is essential once you have to show something more than just a text message)
- Business logic (e.g. we need to fetch banks data, crunch that data, identify insight, etc.)
Delivery of this kind of experience requires a lot of the right tools. In order to avoid fragmentation we use Docker ✨ in our infrastructure to deploy everything we need. Due to Docker’s agnostic nature we can mashup different technologies without major changes to our IT infrastructure.
Wrap up
FinTech is a busy place, so the capability to iterate fast and embrace the change (e.g. new technologies, new design approaches, etc.) are key to the success. In the bot field this is twice as valid: everything is too new and changing far too fast to pick one option and stick with it all the way.
Adopt a pragmatic and focused approach, invest in your core infrastructure and automate whatever you can automate, ✨ this will make the real difference in the long run.
If you want to see how we do things at Ernest, signup to our beta and try our chatbot 🤖.
If you have built or you are building something in this field, we are keen to read your thoughts in the comments section. If you liked this post, please show us your appreciation by adding a ❤️ ️below
